Terry,
I am pretty sure the Shop I work for now talked to Marcy.
We have 2 Production z/VM Lpars with 20 Production LINUX guests
We have 1 Development z/VM lpar with 60 Test/Development LINUX guests
We have 1 Play Ground z/VM lpar with 5 LINUX guests -
where a 2nd level z/VM runs for upgrades and maintenance
and where LINUX upgrades and patches are applied and first tested
along with 3 z/OS LPARS's Prod, Dev, and Test
It works very nicely for us
Bill Munson
Brown Brothers Harriman
Sr. z/VM Systems Programmer
201-418-7588
President MVMUA
http://www2.marist.edu/~mvmua/
Marcy Cortes <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
12/04/2008 09:22 PM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Configuartion question
Terry wrote:
"We are moving toward taking our POC into production."
Good job!
If I had my druthers and had only 1 box, I would have a systems
programmers LPAR (mine mine mine), a LPAR that ran all of test/dev
linuxen, and 1 prod LPAR that ran all of prod. If you do have
servers that can't go down very often, run 2 prod lpars, make them
acquire a server on each (at least) and figure how some failover
(active-active or active-standby). Better if that 2nd prod lpar can be
on another box entirely, but if it can't, you'll still have all your
capacity if you lose 1 VM lpar due to some VM error (or VM person's
error).
I'm not sure how your EUAL5 requirements fit in, but you can do lots of
things with multiple OSAs, VSWITCHs, VLAN tagging, firewalls, etc.
Marcy (with too many LPARs)
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
________________________________
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Martin, Terry R. (CMS/CTR) (CTR)
Sent: Thursday, December 04, 2008 5:57 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Configuartion question
Hi
We are moving toward taking our POC into production. This workload is
moving from Solaris running UNIX. The environment is 3 zone
architecture. Our client's business requirements calls for this 3 zone
environment to remain separated. It requires UAL5 security level.
To this end we have six LPARS each sharing 7 IFLS with plenty of real
memory on each. One of the six LPARS is our test LPAR that will have
multiple levels of VM for testing and such.
My question: some of our folks believe that this is an excessive number
of LPARS and that it defeats the purpose of VM. Now I understand how VM
works and its' ability to virtualize reducing the need for large LPAR
configurations. I know that we could, lets' say combine our PROD and
VAL/DEV environments that are currently running in separate LPARS into
one LPAR and run a second LEVEL VM for the VAL/DEV. My contention is
that if it is what is needed to fit the business requirements of the
client then having six LPARS is not catastrophic. We have plans for
another 16 z/Linux guests to run in the existing configuration in the
next few months not requiring additional LPARS. I am not an LPAR bigot.
Can anyone comment in general on the pros and cons of running LPARS as
opposed to running the multiple environments under one LPAR and getting
separation logically by having multi levels of VM rather then physical
separation by having the environments running under a single level of
VM?
In the end it probably will not matter if the client insists that we
need to proceed as we are. Just trying to get a prospective of those who
are more experienced then myself!!
Thanks,
Terry
*************************** IMPORTANT
NOTE***************************** The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
************************************************************************
