This is a very good point and am takeing this into consideration. What you have lined up for SLES9 seems more logical with the Packageing and patches and updates and what not that have to be done. Where i am in an environment that likes to keep those patches and what not up to date, i can't have the headache everyone else is saying happens when you do file shareing your package management becomes well null and void basically. That just does not work for me. I needs something more stable than that.
-Cameron -----Original Message----- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 1:46 PM To: [EMAIL PROTECTED] Subject: Re: Linux under VM and Cloning > > How much DASD does this really save you? Is it > > worth the time and effort it takes to set this up > A lot of people do it this way. I gave a paper on it at SHARE. You can see a copy at http://linuxvm.org/present/SHARE101/S9343GWa.pdf It covers a wide gamut of the problems of managing multiple Linux servers running under VM. Lately, however, we've been beginning to have second thoughts. When we started the scheme detailed in the presentation, we thought a whole 3390-3 was a lot of dasd and were trying to save as much as possible. Now that we're running about 40 servers, maintenance is becoming a real pain in the patootie. Getting our users to allow us to take down their server so we can change /usr disks is really hard. More and more our users are wanting full 7X24 availability. Our current offering is 1500 cylinders for /, /opt, /bin, /var, etc 3338 cylinders for /usr, read-only shared. swap in v-disk A separate disk with much as they need for /home A read-only disk with the Oracle code on it and a separate LVM volume for Oracle databases, if they want oracle. We are considering changing our offering when SLES9 comes out. The current proposal is to combine the / and /usr disks into one single minidisk of about 5000 cylinders, being half of a 3390-9. Everything read-write. Then, for service, we can just use ssh to send some commands to the server, link an NFS disk in with all the rpm's and just load the rpms directly on to the server. We can even send ssh commands to recycle various daemons. The only thing we'd have to bring the server all the way down for would be to bring in a new kernel. What we give up to do this is disk space. Each server goes from using 1500 cylinders to 5000 cylinders. However, we're beginning to think that disk is cheaper than labor, especially when it comes to dozens of servers to maintain. YMMV. Give it some thought. What does your management want to spend its money on? Disk arrays or headcount? "Good. Fast. Cheap. Pick any two." (David Gerrold, "A Matter for Men") "An Optimist is just a pessimist with no job experience." - Scott Adams Gordon W. Wolfe, Ph.D. Boeing Enterprise Servers 425-865-5940 > ---------- > From: David Boyes > Reply To: Linux on 390 Port > Sent: Thursday, July 8, 2004 7:35 AM > To: [EMAIL PROTECTED] > Subject: Re: Linux under VM and Cloning > > > We are going with a lot of Linux Guests under VM. Close to 20 > > per IFL and are wondering about the experiences with the > > basevol/guestvol scenario. How many People accually use this > > scenario? > > At least a dozen of our customers do. CA obviously does (see Bill's > paper). It's proven to be a pretty good choice when you need a lot of > fairly similar machines that don't change configuration too often. > > > How much DASD does this really save you? Is it > > worth the time and effort it takes to set this up? > > It depends a lot on how well-behaved your applications are in terms of > keeping all their files together. A lot of ISVs violate Mother's Second > Rule (Thou Shalt Not Mix Your Code and System Code), which makes it more > a maintenance issue than a disk space issue. > > IF your application is well-behaved enough to keep all it's pieces > together, then it makes a fair amount of difference. > > > > Could you > > just setup Links to specific disks in VM for a Guest like if > > you just wanted to share the binaries for say Oracle, or the > > /usr directory or /home directory? > > No, because in the case of Oracle and a lot of the ISV software you > mentioned, the application wants to dump code outside the directory that > holds the main binaries. You also need to have write access to the RPM > catalog and some other stuff (something I consider to be a design flaw > in RPM -- no provision for concatenated user and system software> > catalogs). > > /home is difficult because of the multi-system caching problem -- virtal > machines are really separate systems, and each does separate caches of > R/W data that are completely ignorant of each other. Without something > like AFS or GFS to coordinate writes, you get bad corruption problems. > Best solution there is to use NFS or one of the more sophisticated > filesystems mentioned previously to handle /home. > > > Wouldn't this accomplish > > the same thing? What would be the best way to go about this? > > See above. You're somewhat mixing up two problems: shared resources and > operational maintenance. The basevol/guestvol concept is attempting to > handle the operational maintenance problem (ie, how do you distribute > fixes and do configuration control). Sharing disks takes it into > configuration management (how do I share binaries, but deal with the > fact that the applications expect stuff to appear in places outside the > directory holding the binaries). > > "Best" is a hard thing to define. What I'd suggest is: > > 1) Use the basevol/guestvol setup to manage the system configuration > information and /usr, which tend not to be particularly volatile > (changes are usually infrequent). > > 2) Set up a separate guest LAN and create some dedicated guests for the > function of NFS file servers. Mount the "shared" application information > via NFS, ie /opt, /usr/local, etc. Same thing for shared R/W filesystems > like /home. > > 2a) (more sophisticated variation) Set up separate guest LAN and use > some dedicated guests as AFS servers. This takes more sophistication at > the start, but it's more scalable and secure than NFS, and allows better > disk management from a enterprise standpoint. > > > Does SUSE support the basevol/guestvol out > > of the box, or are their some packages that need installing > > to make this work? > > Not out of the box -- it's a configuration decision, not a code thing. > It requires modifying two of the SuSE startup scripts to overmount the > common /etc with the system specific ones during boot. > > > How stable is it running under this > > basevol/guestvol scenario? > > Very. Maintenance planning is the key to making this work. Day to day, > it's a no-brainer. > > I'd venture to say that if more ISVs used a method like this, we'd > finally be able to stamp out the assumption that it's OK to scatter > files around the filesystem, and end up with a lot better world. I'm > *very* glad that CA has adopted this approach. Now we need to work on > IBM, and Tivoli, and ... > > 8-( > > -- db > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A1. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
