Alan Ackerman wrote:
Someone here says we should not do Linux on zSeries because you cannot do
"stateless computing" on zSeries. Of course, the first question is
"What the heck is stateless computing?"
I found some links:
Stateless Linux at <http://fedoraproject.org/wiki/StatelessLinux>.
Linux on IBM eServer zSeries and S/390: Large Scale Linux Deployment
SG24-6824-00 at <http://www.redbooks.ibm.com/abstracts/sg246824.html?Open>.
It is from 2002, though. Is there a more recent version?
It all depends on your interpretation and intent of the word.
Personally, I like this article on it:
http://arstechnica.com/hardware/news/2008/08/stateless-computing-the-future-of-the-cloud.ars
Specifically, I think these quotes shed some light:
<snip>
a future in which software processes are abstracted so far from the
underlying hardware that companies will discuss processing capacity in
terms of raw computational units rather than discrete servers.
</snip>
and
<snip>
One of the big advantages of this approach is that it makes it
possible for companies to use cheaper hardware. Each individual server
doesn't need to be extremely reliable because processing can always be
moved elsewhere in the event of hardware failure. The placement
engine, however, is still the missing piece of the puzzle.
Virtualization management technologies just aren't smart enough to do
that kind of manipulation in a fully automated way yet.
</snip>
Fundamentally, Stateless computing spawned out of distributed
environments. A core theme being to install your OS to a LUN, have all
data+applications reside there. Use the processor and RAM of
distributed hardware as commodities, assuming they'll fail. When your
x86 hardware fails, your OS image is "stateless," and you just present
the new LUN to another box and you're back in production. Use some form
multipathing+clustering (Tivoli, Veritas, RHT CS, etc) to have this
failover happen automatically. Since the workload dynamically migrates
itself over to another machine, walk into your data center and
rip/replace the failed element(s).
These need has manifested itself in "vmotion", "live migration," etc in
distributed virtualization environments ala VMWare, Xen, and KVM.
Today, this is manifesting itself via "cloud computing." At the core,
we just want our production workload to keep running, to have the
ability to dynamically add physical resources, and have our workload
dynamically migrate itself upon failure. Various x86 technologies
represent implementation methods to achieve those goals. z/VM is
another implementation.
In it's most basic form, I have customers who install their RHEL to a
zFCP LUN, and multipath it [howto @
http://kbase.redhat.com/faq/docs/DOC-15673]. From that point they can
dynamically add their resources (DASD, IFL, network, etc).
To step it up a notch, combine DCCS+XiV and store applications in
memory. Check out Mark Posts' presentation @
http://www.linuxvm.org/present/SHARE112/S9230mp.pdf
Use built in application clustering (Oracle RAC, WebSphere JBoss) in
combination with storage multipathing + dynamic resource allocation (in
partnership with z/VM) to turn your big scary Mainframe into a commodity
Linux machine.
You have options.
Has anyone had any experience with building a stateless Linux on zSeries?
Many of us have, we just don't call it stateless Linux. As Mark noted,
enter the stories of Nationwide, Penn State, and others like them.
A fundamental of Stateless Linux is to assume the hardware is crap, and
will fail. This drives the commoditization of hardware, with the theory
of lowering overall costs. You build out expansive, cheap, hardware
farms. As such you virtualize *all* aspects of the hardware to allow
for vMotion, Live Migration, etc. Statelessness.
For System z I'd argue our mentality is different. Generally we know
better than to believe in large distributed environments, regardless of
how "cheap" the TCA of the hardware is. Time has shown that the extra
costs -- network, people, cooling, etc -- blow up on distributed. We
believe in the hardware, and ensure that our hypervisor+operating
systems fully exploit the features of it. It's the applications we
don't always trust, so we enable various clustering technologies.
Any words of wisdom?
Ignorance is a form of environmental pollution. Different platforms
have different implementations against the same goals. Use this as a
chance to educate your friend
--
Shawn Wells
Global System z Platform Manager
Cell: (+1) 443-534-0130 (GMT -5)
EMail: s...@redhat.com
----------------------------------------------------------------------
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
