If the "kernel in a DSS" is there for storage (RAM) reasons, i would
recommend against it. There are 3 ways of sharing storage (RAM) that
are effective,
1) kernel in NSS (named saved system) that saves about 1mb per server,
clumsy, very restrictive, and savings not worth the effort
2) XIP (programs in a saved segment) that can save about 20-100mb per
server, fairly easy to setup
3) CMM1 (i do not think/say nice things about CMM2) CMM1 can dynamically
save Gigabytes per server, and easy to implement.
So if storage (RAM) is your concern, I would bypass the NSS as being
ineffective, and focus on CMM (collaborative Memory Management) where
very little time provides significant savings.
Agblad Tore wrote:
Good point, that is what I have been thinking of: How do I effectively solved
this SHARing of disks.
My optimal setup is:
- kernel in a DSS, used by (almost) all servers
- all binary disks shared as readonly
- some binaries requently used (or all binaries ??) in xpram XIP
This setup requires much of people, rules, design, routines, std .......
And how do I get there, still cost-effective ?
Anyone has something like this running with success ?
Or have tried some of it ?
We tried kernel in DSS, worked good, until I added a disk :(
It required the exact disk setup for all servers using it, so adding disks to
an LVM
caused a failure. This just an example of how sensible the setup will be.
I want it stable and robust, it should ignore more or less disks, just boot and
mount what's there ;)
Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar
Tore Agblad
Volvo Information Technology
Infrastructure Mainframe Design & Development
SE-405 08, Gothenburg Sweden
E-mail: tore.agb...@volvo.com
http://www.volvo.com/volvoit/global/en-gb/
________________________________________
From: Linux on 390 Port [linux-...@vm.marist.edu] On Behalf Of Rick Troth
[...@casita.net]
Sent: Tuesday, June 16, 2009 06:00
To: LINUX-390@VM.MARIST.EDU
Subject: Re: To kick or to clone ... that is the question
On Tue, 9 Jun 2009, Scott Rohling wrote:
This is a blatant request for discussion about the pros and cons
of using an automated installation (e.g. RH kickstart - Suse autoyast
(though maybe this has changed - I'm not current on Suse) -
vs cloning a system from a 'golden image'...
and I should say: on zSeries.
Heh ... well ... you got some response to your blatant request.
GMail tells me there have been 65 messages in the thread so far,
not counting those replies which fell out of its threading model.
That's a record in recent memory.
Regarding the cloning -vs- kickstart/autoyast question:
It's not so much about which of those two methods one should use.
If we're serious about virtualization, then we should go deeper
than mere copying or re-deployment of content.
Virtualization of systems is about sharing of resources.
So think hard about sharing disks and not just memory and CPU.
On this point, cloning has a little edge. But both cloning and
jumpstarting (as usually implemented) suffer from difficulty
ferreting out the shared and sharable stuff from the per-system stuff.
But it can be done. Put the sharable stuff onto shared disks.
Got maint?
Apply your maint to the R/W copy, stamp out a new shared disk
from that copy, point the "client" systems to it, instant upgrade
of 500 servers without running 500 instances of RPM (or whatever).
There is always some per-system content
which must be either copied (clone) or deployed (kick).
The personalization of that per-system part is where jumpstart
has a little edge. Ideally, the personality would be retained
even if the rest of the op sys were blown away (er, uh, upgraded).
This is a little harder to do than sharing the op sys, but it can
be done. Start with the easy stuff, like user home directories.
The per-system stuff MIGHT be affected by maintenance.
If so, it complicates the sharing scheme. But it can be done.
So if all you ask is, "should we kick or clone?",
you're missing out substantially on the value of virtualization.
Kick or clone? Neither! Virtualize! And share!
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
begin:vcard
fn:Barton Robinson
n:Robinson;Barton
adr;dom:;;PO 391209;Mountain View;CA;94039-1209
email;internet:bar...@velocitysoftware.com
title:Sr. Architect
tel;work:650-964-8867
x-mozilla-html:FALSE
url:VelocitySoftware.com
version:2.1
end:vcard
