Slashdot Mirror
Managing Linux and Virtual Machines?
deijmaster asks: "For a couple of months we have been hearing (as a major consulting firm) IBM people pushing the possibility of installing a Z/Linux VM setup at one of our biggest clients (financial). To a Linux user such as myself this sounds great, at first. Now, I am a bit reluctant when it comes to managing this kind of infrastructure, with little or no local expertise at IBM. Has anyone gone through a Z/Linux VM corporate installation and lived through the management of such a solution?"
I once saw Amdhals version of Unix running on a mainframe at New England Telephone. The ps command yielded about 20,000 running processes and the guy I knew told me that it was just one of 6 VM systems running on the same hardware.
I was impressed.
SG
I haven't worked with a Z/Linux VM before. However, I have used User Mode Linux to create a dozen or so virtual servers per host server. And I'd imagine that the benefits offered by UML would also apply to Z/Linux VMs.
For example, with UML you're able to get much better resource utilisation. e.g. most of the time the machine is idle. When one of the UML servers need the host server's resources, they're there (CPU, network, disk IO, etc). That means you can have multiple UML servers bursting up to the performance potential of the host server. Certainly a better resource utilisation than having several host servers running mostly idle.
Another benefit of virtual machines are their logical separation from the host server. Each virtual server has their own users (including root), applications, file systems, IP address, etc. That means that if security is compromised on one, the others are unaffected. Ditto resources can be allocated to each virtual server according to need. And any mis-configuration on one doesn't affect the other. This compares to running multiple applications on the same server for different purposes (e.g. running HR and Account systems on one server, if email goes down them both systems are affected. In a virtual server setup, only one of the other would be affected.
So... Thumbs up to server virtualization software in general. Particular kudos to UML. And good luck finding out about Z/Linux!
- P
RimuHosting.com - Linux VPS Hosting
I sold and installed the very first Linux application on the S/390 --a Multiprise running VM and it worked great. We used the TurboLinux port and then finally wound up with SuSE.
We compiled the source code and it ran just like it did on a big Intel box. IBM helped with hardware issues which related to load balancing amongst the VM instances. One of their business partners supported the customer, Winnebago Industries with regard to Linux and OS 390.
IBM wasn't much of a factor as far as needing support. They supported the mainframe, the OS and VM just fine. SuSE installed without a single issue.
Some other issues arose in getting the user to learn IBM mainframe lingo, such as IPL instead of boot, and DASD. But, that didn't require much effort. The IBM Redbook on running Linux on the S/390 was all we needed to transfer knowledge. We downloaded it for free in pdf format.
The main benefit I discovered was the ability to consolidate servers. We replaced a bunch of M$ Exchange servers and ran a suite of Open Source apps such as Cyrus IMAP, Open LDAP, Exim, Apache, etc. We were able to get rid of a bunch of distributed servers and put them on one instance.
I suggest that IBM can help, but I don't think you'll be dependent on them. They're very expensive. With Linux on the zSeries or S/390 you can do everything yourself. -- That might not be what IBM wanted, but then they championed Linux, didn't they!
I'm an IBM'er currently on assignment at the world's largest insurance company. I was brought in because they wanted to consolidate servers to a mostly-Linux solution. After piloting Samba 2 beta on zLinux last summer, they balked at the heavy reliance on Z.
The key is for people to realize that the type of workload is critical when deciding to try zLinux, and any barking about Athlon vs. G6 is useless. Also, vendors need to realize that once you compile an app on Linux on any one platform, you're usually a recompile away from running it under Linux on any other platform. Hence my reasoning that any complaints about software availability from a year ago is also useless. More apps are being ported to zLinux everyday.
Linux on Z has a role, it just needs to be explored by more brave souls. Besides, I've always said that if I leave the company, I'd like to create an "ISP in a box" using a z800 and some ESS disk to host a few thousand virtual web servers. I implore people to please visit Linux@IBM for more information.
Intelligent Life on Earth
We've got a production linux instance running under VM alongside our production VSE system. Since the box is fairly underpowered we get a minimal slice of the CPU. This makes the system respond like a 286 with the 'turbo' button turned off.
When the VSE instance bombs out for some reason, and we get effectively 100% of the CPU it responds like a pentium... maybe. Think P166.
Unfortunately in our circumstance we can't 'turn on' more MIPS because then our VSE instance is running on a 'bigger' machine and we end up doubling our licesing costs. Other alternative is to turn on the ILF (integrated linux facility) which dedicates 120Mips to linux only, without affecting other licesning, but that costs $150k. You can buy a lot of 2-way or 4-way pentium boxes with decent RAID arrays and get much better performance for that kind of money.
So if your shop is run by some sort of morons and you've got 100's of spare MIPS to burn, then Linux on the mainframe probably makes some sense. Otherwise, just get some intel boxes. Any savings the mainframe provides in terms of power, cooling, and ligher administration is going to be offset by massive complexity, poor performance, and a lack of easy support for a bizarre platform that few developers have access to.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
IBM mainframe complexes basically never go down. There are installations that have been running 24x7x365 for decades. That's the whole point of owning one.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
They're a heck of lot less wasteful (electrickery into heat) than they used to be, and require a lot less space (again, compared to the past).
Clusters ... I don't know where you get the 'faster and cheaper' line, unless you're talking about applications specifically designed for clusters. When you start writing apps designed for a few thousand simultaneous users, the benefits of the mainframe become apparent. Stability. Speed. The ability to hold gobs of info in ram. Which, BTW, makes them the nearly ideal web server. Security (hey, it's not M$!). Mainframes are a mature technology ... meaning lots of the annoying things (both hardware and software) still plaguing the small boxes have been fixed. (Admittedly, 'mature' often translates into 'f$cking obsolete pos' (i.e. panvalet).)
I don't worry about backups conflicting with apps on the mainframe. I don't worry about the details of storing things reduntantly (although that's quickly getting solved on the smaller boxes). For those things written on WinWhatever, the programmers need to worry about every little upgrade/patch from M$.
Now, most places still give mainframes a room of their own ... and it tends to be a bigger room than servers get. And, if you're happy with something a little slower and little less reliable, a good farm runs less than a mainframe.
But, to put things in perspective, one of my databases (non-mainframe) is moving to a USD 2.1 million machine. That's a fraction ... as in, from 1/4 to 1/20 (depending on options) of a mainframe.
I'm working in both worlds. I like the cost benefits of the smaller boxes. But it still freaks me out when users punch in a query and it takes several seconds (to minutes) for a response, when the delay on the mainframe is done by the time the enter key pops up.