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
Amdhals Unix was called UTS from memory. We ran it here many hears ago too.
ln -s
That's really not what he means. This is using a completely non unix oriented system (a mainframe) running a VM (which is not an emulator, virtualization is built into mainframes) to run many instances of linux (which isn't emulated either, linux runs natively on mainframes).
Oh, and the Marist linux-390 listserver is well worth subscribing to.
If you have never touched VM, then you will be well and truely out of your depth. It's a whole different world to Unix/Linux.
So you will have to get a VM person in. Probably only on part time contract, and IBM will can provide that person for an additional fee.
In time you may learn enough to support your very limited VM environment.
ln -s
1. What exactly demands this solution?
2. Can a pure Linux box, with mild tweaking, still not be more useful and create less overhead than this?
Someone in this thread mentioned IBM implementing wildly complex systems in order to push consultation, and on some levels it's true. PeopleSoft does it also. In some cases, Oracle will have a go at this tactic. My advice is to do some searching first, without the input of IBM, and see if you can't find a better solution to whatever problem you're trying to remedy.
Just consider it VMWare for big boys. I'm doing a wee bit of development for Linux on zOS, and most things just work once you get it installed. Lots of options, depending on how you carve up the system. Anyhow, for the most part it is all about fast i/o, rather than monster processing power.
Picked up Linux on the Mainframe over the weekend, but plan to read it on a (very long) plane ride next week - looked like it focused on care and feeding, however.
+++ UGUCAUCGUAUUUCU
I helped a admin friend (pure Novell guy that was somehow tasked with this job) implement TurboLinux on a IBM Z series mainframe. It is kind of easy to work, but you lose some performance, and updates and fixes can be hard to track down sometimes. Clustered Linux solutions could end being cheaper at first, but their TCO may rise higher as time goes on (especially if your company/institution lacks a very competent Linux cluster admin/programmer).
Well I used to work at similar financial company where IBM was pushing something similar as well. What it boiled down to was the following issues.
1. for the equivalent # of VM's it was more cost effective to buy new Intel hardware. The annual maintaince cost for the IBM more than paid for all new hardware.
2. Software availability. The only thing you could run it would be home grown apps or existing opensource apps. No commercial software was available. This company was an all Oracle shop, no DB2. They're primary opensystems backup solution was Netbackup. Which at the time had no client for linux on Z. (a year ago).
3. In house expertise. They had no linux expertise and very little Unix (solaris & HP) (jr admins at best) expertise. Let alone running linux on a Z.
So to sum it up. It's a very expensive, somewhat propritary and inflexiable environment. If you have a specialized use for it and can justify the cost go for it. Otherwise stick with commodity Intel/AMD hardware. It'll be cheaper and easier in the long run.
...that IBM guy will probably be somewhere in the ballpark of $85 an hour. It costs a good sized company about $2,500 a month for part-time offsite HP-UX consultation on an Oracle database. It costs about $5,000 a week to lease a McAfee expert to implement their expanded solutions. Imagine how much a VR guy will cost from IBM.....
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 met a guy just last week who was running linux with a few kernel mods to give him realtime encryption on the whole OS, then was running XP over the top of it in an emulator. There were a few things he couldn't do, but for someome who wants to be sure their data is secure, and doesn't know linux, I thought it was a great solution. It was setup by a firm who does encrypted systems. I do not have the name of the firm.
Karma is like sex. I can't remember the last time I had either of them.
I work for a big financial firm in NYC that is using Z/Linux pretty heavily. I have to say that while we are very happy with the results, it is VERY important to have VM people on staff who are also Linux savvy. IBM has been great in getting us set up, but they don't live with the systems. We do. You'll need to be very careful about what you're using the Linux instances for, and take alook at how they'll use hardware resources, like the OSA cards.
With careful planning, and the expectation that it will be a bumpy start, you'' find that it's a very rewarding experience, both personally and professionally.
I wouldn't get hung up on the whole "local" thing. You just have to understand how IBM works. There's no concept of "local" at IBM. At any one point in time, 50% of IBM employees aren't in a traditional work place.
If you have problems, contact IBM and they will get their best people on it. IBM is all about customer service. You never get fired for buying IBM. From an engineers perspective, it's a pita. The best people in a department end up spending most of their time working on customer problems.
Hell, IBM still supports OS/2. If a Z-Series seems to solve your problem, go for it. IBM will take care of you.
Again, we need to know more about his institution's needs before we can confidently declare which solution (Z\Linux or a cluster) is the best fit for his needs.
http://www.linuxcare.com/
Chrisd
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
>>Has anyone gone through a Z/Linux VM corporate installation and lived through the management of such a solution?"
I have! And let me tell you, it has worked wonderfully!
You do realize that emulating any decrepit UNIX machine must be a rusult of running ancient code that has now been copied into SCO Unixware. You would then be using SCO IP (Idiotic Property). You will have to pay them 100 trillion dollars plus $699 for the Linux.
Speech: Free
Beer: $699.00
finding ways to fish money out of your pocket with every solution. I would love to see how many hours of consultation this migration (and ongoing support) will be out? IBM, single handedly making sure Linux isn't "free, as in beer".
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!
You wear your underwear on the outside?
Familiarity with Linux will not help you setting up the zLinux environment. It works like this: You dedicate a few processors of your mainframe to Linux. These processors will run VM, which has:
The users are defined in a "user directory". There, you can specify how much memory, disk and CPU share you want to give to each user. These users, remember, are in fact virtual machines that will boot an image of Linux compiled for the zSeries processor architecture.
If you want to create and take down Linux images frequenlty, you'll have to install and customize some VM scripts that will do the job for you. When the scripts are installed, you can setup a new Linux image (complete with its own disks, IP address, etc.) with a single operator command.
Most sysadmins of a zLinux machine spend a lot of time in VM. So learning VM is essential if you are going to do this job. VM was created 30 years ago and is somewhat primitive in places, but the resource virtualization mechanism is incredibly powerful and makes up for it.
Finally, make sure that people understand that there might be dozens of virtual CPUs defined under VM but only a few real CPUs. If you have 4 CPUs, a Linux user with an absolute CPU share of 25% will have the equivalent of one CPU. If the Linux image is used for recompiling its kernel, it might be a tad slow. The mainframe has great I/O performance but only run-of-the-mill raw CPU speed.
Good luck.
Exactly. I find it interesting when people comment out of the space of speculation. The original question was for someone with "experience". That doesn't mean that he wanted uninformed opinions based on some notion of logic. If someone hasn't sailed the boat, don't tell me how to do it.
What makes you think I don't already have one?
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
Amdahl's version of Unix was and is UTS. It was spun off in May 2000 as UTS Global LLC. Check out our webpage at http://www.utsglobal.com.
Ahh yes, grasshopper, but when that one uber-box dies(hard disk, fan, power supply, whatever), gets powered off by accident, network cable unplugged, yadda yadda- it affects ALL the virtual machines.
Granted in the Big Iron, you've got lovely hot-swap capabilities and such(processors, memory, etc)...but nothing is foolproof or 100% reliable. It's the old joke with pilots about twin-engine airplanes; the door swings both ways and there's no such thing as a free lunch. On one hand, you've got a spare engine if one dies, but you're 2x as likely to have a failure, you've got a lot of added complexity, and sometimes it still won't save your bacon(twin engine planes have an abysmal survival rate for engine failure in part because of the really shitty way they fly with one engine down). This is VERY applicable- because managing this big IBM server is much more complex(the whole point of this article) than seperate hardware.
Best example I can think of in how hot-swap can still not save the bacon is with the Cisco PIX 5-something(The 1U pizza-box one). It has FULL failover- if you've got two, and one shits the bed COMPLETELY, the other one takes over absolutely everything, including active connections; they share ALL state information for what's called stateful failover. Aside from a momentary blip where things stop for a sec...nobody's the wiser that a piece of very expensive hardware just let the Magic Smoke out. The problem is that the PIX OS version we had was buggy and would crash randomly- and because they were sharing connection tables and everything, they'd BOTH die, which was REALLY bad since the boxes didn't have hardware watchdogs(!). We turned off fully-stateful failover, and the problem went away; we'd notice they'd ping-ponged(there's an 'ACTIVE' led to show you which is live) and we'd power-cycle the other.
So ask the tough questions; instead of asking what's N+1, ask what's NOT N+1, and do a very careful breakdown of what exactly it will cost to run this big huge box, and figure out what the 'per [virtual] machine' costs are...
Please help metamoderate.
you have one rammed up your ass as you posted your message?
To paraphrase YOU...
Have you ever dealt with a MAINFRAME? Large MAINFRAMES are fucking expensive to run 24x7x365. They require a lot of Air Conditioning (many people spend over $1,000 a month on just AC, that's an expense that is never going away), electrical and a shitload of space.
And he diffrence is what? For most applications, clusters, for all their faults are faster and cheaper than mainframes.
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
I've not played with Linux on VM. However, from what I understand it is a sweet thing.
I have played with other OS's running under VM. IBM knows what they are doing in that field.
Combine the two, and I think you have something that should work well. However, I'd weigh the costs. I would think it would a good thing to do if you already have a z-box laying around that has some space cycles. However, I would think that a stack of Dell's or something would be cheaper than buying the IBM equipment.
At my workplace, we run about about two hundred corporate websites. The majority of those are on three boxes from Penguin computing, and the bare minimum required by our contract with IBM are on the z-series. At first we thought it would be a great deal, and looked forward to moving all of our sites over to the high-performance IBM machine. But it failed EVERY SINGLE test we could think to throw at it, except trying to brute-force an RSA key.
They're great number crunchers, but they don't hold up under any kind of pressure as a web server. We had the z-series with no sites on it run benchmarks and compare to our development box with 20 sites hosted, and the development box (Penguin Computing) kicked its ASS.
Every time one of our developers has to ssh into the IBM machine, they yell "Cover me, I'm going in". Our running gag is, if they're not done editing the apache config or whatever in ten minutes, we'll have to send in a rescue team.
My rational, scientific, carefully measured opinion is that the IBM z-series SUCKS. HARD.
Gee, I sure wish I wouldn't get in trouble for sharing our benchmark data with you. Oh well, you'll have to take my word for it and hope the majority agrees.
Austin is more fun than Dallas.
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.
Unless you're in for the mainframe class hardware (and possibly support).
Coz for x86 servers, you can always use vmware e.g. vmware esx.
Not sure if vmware has anything lined up for opteron, but if that goes fine then it'll be cool.
We're fortunate to have a good solid VM guy, so implementation was no big deal on our dev box. But we've noticed a few things along the way...
VM is expensive. Engines on the mainframe are expensive, and are the weak point in Z/Linux. Mainframes normally run batch types of workloads, and have great big fat I/O. They're not necessarily great processing powerhouses.
You can download Linux and install it on the mainframe; but you get zero support. If you want support, open up that big old budget again. When we looked at it, Suse wanted about $20k per year, and RedHat wanted $24k. We flew solo instead. So far it's been fine; but be prepared to pay if you want support (which, by the way, is something the PHB's and mainframe systems programmers are used to having.)
As for operational considerations, I haven't really had any problems with it at all. There aren't many rpms out there for z/os; but you can compile almost anything and use it.
Installation is kind of cheesy; but not horrible. You basically set up your vm guest, log in to it and ftp the linux kernel, ramdisk and parmfile to the guest dasd, giving it a fixed record length of 80 bytes. You then feed these into a virtual card punch (that's right, a virtual Hollerith Punch Card Reader - 80 columns = 80 bytes), then into a virtual card reader, and ipl the reader.
This gives you a running instance of linux that you can use to do a net install of the full distribution.
In the implementation class I took, I was partnered with a mainframe guy who was complaining about how archaic vi was. It made me laugh.
"Dude. We just chopped my kernel into 80 byte blocks and fed it into a card reader. Don't talk to me about archaic."
Hot Damn! It's the Soggy Bottom Boys!
...I did not live through it. So now I'm forced to post from the Other Side, where we have a certifiably shitty Internet connection.
One of my clients, a large insurance firm in the New England area, is in the process of consolidating their NT environment onto VMWare ESX server, which is linux based. This is an IBM X440, running about 30 consolidated NT VMs. Since it's VMWare it can also run linux VMs. They are saving about 500k annually on this setup in associated costs for hardware/support/environmentals. This was a pilot, and they are going to be moving forward with more consolidation based on this.
This really isnt a new concept, most of us know of the IBM P-series, Sun E-10ks and 15ks, and the HP Superdome. All use virtualization in one form or another to provide this kind of setup. Z/series is kind of novel, because....hey...its a Mainframe.
Get a mainframe guy. You will need him. You won't find what you need in handy-dandy HOWTOs on the Internet, nor will you learn it quickly enough to support a system in production (as you are going the IBM big-iron way, I suppose you are talking about a serious operation, unlike some people here who think their AMD web servers are "mission critical"). If the mainframe guy has been truly a mainframe-only guy for most or all of his career, you'll find it hard to even talk to him, much less do what he will do to get the system running smoothly.
And no, I'm not a mainframe guy. I'm the Linux guy who was happy he had a mainframe guy handy. I've been responsible for getting Linux running on a reasonably-sized operation (5 big mainframes), and there is no way I could have mantained the systems all by myself. 10+ years of big-iron experience is not something you can get in a few weekends.
would it be possible to use UML on top of OpenMosix. Theoretically this should allow you to have several cheap intel/amd boxes acting as one (so shared resources) and then running multiple linuxes in UML would allow for an efficient use of those resources. In the end, would this not be close to the Z series, just cheaper? I imagine it might be a bit trickier to admin, but it would be interesting.
> "I allege that SCO is full of it" -Linus
Grain of salt, yada yada...
d bo okAbstracts/sg246824.html?Open
:(
I second the idea that it is very important to have VM skills on site for a customer looking at this. Presumably the customer is already a z/Series account, so they probably already know a thing or two, but they may have bought into the "VM is going away" speech and gotten rid of their VM stuff years ago and gone to z/OS.
Even if they have VM skills from 5-7 years ago - that will still do. VM hasn't changed all that much, it just has some more bells and whistles. So one or two refresher courses for whoever is still around in their shop will get them up to speed on z/VM 4.4 if they knew it 'Back in the day'.
And yes - Linux on VM is still young. Most shops appear to do a lot of 'roll your own' solutions to the administrative problems. Get hooked into the Marist linux390 mailing list, there are a lot of smart folks there who have at least thought about any problem youre likely to have.
I've run/tested every one of SLES 7, 8, RedHat 7.1, 7.2, RHEL3 beta, TurboLinux (old and crusty now) and Debian with pretty much any IBM middleware you could think of. From the linux side - it doesn't know anything about VM, or care. So you as the administrator must make sure it plays politely with the others it lives with. You probably should not just throw 2 Gigabytes of storage at it just because Websphere says it needs it. Running Linux with VM does require some understanding of how to make the most of shared resources. Check out this redbook:
http://publib-b.boulder.ibm.com/Redbooks.nsf/Re
It makes a lot of these points better than I can.
--Anonymous Coward cause I forgot my password
Way back when, Unix was the "Unix Time Sharing System." IIRC, the first Unix running on a mainframe was under TSS. Of course, this all gets silly as the name "mainframe" was derived from a Central Office frame, which earlier computers bore a resemblance to.
"To those who are overly cautious, everything is impossible. "
I've done plenty of these. I'm sure a little Googling will reveal who I work for and that I'm probably not lying. I'm also not an IBMer.
As with anything, "it depends." In my experience, L/390 under z/VM works best in I/O-intensive heavy-throughput roles. Do not throw CPU-intensive work at it. If you need CPU, either build an Intel farm, or use an architecture that's designed for serious computing, like a pSeries.
From a manageability standpoint, you will be flabbergasted how much easier it is to manage a z/VM box with 100 Linux instances on it than it is to maintain 100 rackmounted x86 boxes. And once you get your legs under you with VM, it's amazing how tunable the system parameters are. FCON/ESA (now Performance Toolkit, in z/VM 4.4) is really, really your friend in terms of determining where the system hotspots are. And once you've tasted how to deploy additional servers in two minutes without leaving your chair, it's really hard to go back to old-skool provisioning.
Adam
If you're looking for z/VM and z/Linux expertise, there are several consulting firms that will get you going and train you in what you need to know. One good one, that has a really good reputation in the mainframe community, is Sine Nomine Associates. Tell 'em I sent you. (Disclaimer: Yeah, I work for them. Not on z/VM, though.)
Disinfect the GNU General Public Virus!
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.
Yep. Really good points. Not to disagree with you, but...
FWIW, virtual servers have the same succeptibility to hardware failure as real servers. Any individual user run the same risk regardless. In a VPS setup its, say, 12 users affected times the risk of one server going down. Or on a user per server setup it is, say, 1 user affected times the risk of 1 of 12 servers going down (which is 12 times higher than the risk of one server going down).
At least with virtualisation it's easier, at least on UML, to move backed up UMLs to a new server and restart them (a 15 minute operation) vs. setting up a new server (takes at least a long lunch hour).
Also, more efficient (i.e. better utilisation of hardware) allows you to use more of it. So rather than going out and setting up 12 servers you can set up 1 server and a couple of mirrors and set up some failover and load balancing services. The kind of thing you can do with real servers, but for less money.
Of course with very high cost server's you've got to be tempted to rely on their reliability and not have spare servers just sitting around. It's a bit easier to swallow having spare machines when you're talking about 'regular' servers.
-P
RimuHosting - VPS Linux Hosting
There's another option, too:
Bytemark Hosting offers Linux virtual machines via User-mode Linux.
Bytemark supports Open Source with contributions to Debian and discounts for Open Source developers.
Debian is one of the distro options. Primary DNS on Bytemark's DNS servers is included (running djbdns, win win).
I've have a virtual server from Linode.com for the past few months, and I'm pretty impressed with the whole idea of VMs. Cheaper than a dedicated server, but just as functional.
RMS: Who the hell are these "Z" people, and why are they stealing my thunder???
Emacs: for people who just never know when to
we removed it from the firmware before shipping. It was ugly, so we replaced it. (Damn K&R syntax!)
You can't judge a book by the way it wears its hair.
I have a good friend who is on the Linux engineering team at a top 5 US bank, and they apparently did the math. The Z/VM solution works if you're deploying hundreds or more virtual Linux machines. If you're planning on a "small" deployment, apparently, the cost savings isn't there.
I also work at on the Linux team of a different top 5 US bank, and we were debating the same thing - I'd love to see you post anymore info you stumble across.
I used to work for one of the java application server companies, we tested, and eventually released a port of our app server to z/Linux. As previously stated by many people, the mainframe is just not made for processor intensive tasks. Java is fairly processor intensive... I'll let you draw your own conclusions.
The funny thing is, our app server worked better than Websfear, in fact we were basically their java vm's QA department.
IBM is a hardware and consulting company. They'll make things work for you eventually, but it's going to cost you.
BTW someone mentioned Sinome (spelled wrong I'm sure) consulting. I met one of their guys at an IBM Mainframe conference and I was very impressed.
Not quite, though the effect is similar. Both VM and Linux are supported by a combination of software and microcode. However, IBM has been very successful in putting almost all performance critical code sections in microcode. Thus, VM and Linux are 'emulated', but the overall performance usually ends up being quite close to what could be achieved if the support was indeed natively supported.
Good, bad and decent experiences but what is common? I didn't see one comment where the installation has put any money to hire and/or educate good support. Compared to the number of people needed to support these server farms - it's always less expensive have some good people around for mainframe and (IMHO) Linux. Sorry - I'm old, 30+ years with VM(yes), but from MFT/MVT/DOS to MVS and Unix, Tandem, Windows, and the only thing that will make a difference is one/two good knowledgeable persons (IMHO). I love both mainframes and smaller systems - different tasks ( anybody remember what a real task is - hint, stll none in Unix/Windows/Tandem ). Mainframes ( and Linux running in VM ) can move a amazing amount of data - use your Intel/AMD/PPC systems in grid/cluster/whatever to process it - remember, vector processors, etc. are even much faster than any Intel or AMD. Also - for 7x24 there are no alternatives ( well, maybe Tandem ), these things run years and years. And the myth how difficult they are to manage or write applications - is a myth. Any decent systems programmer can tell you how if you ask nicely. have a nice day.
"On the other hand, if those 20-30 Intel CPUs are rendering CGI for a film, or modeling a jet engine (and thus running near 100% load), a zSeries CPU would only be able to take on the work of 4-5 Intel CPUs, if that."
That's why you get one of these bad boys.
You forgot to put your pinky to your mouth, and you also forgot the finger quotes around Linux
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
I presently consult for a company that makes extensive use of a mainframe (s/390 series 5). Yes, these things are rock fucking solid - you've never seen uptime like this with heavy use Unix servers. However, this company still manages to hang the machine once a year in some way or another. They go down, just not as often as any other kind of machine.
I have dealt very closly with IBM engineers for several years. I pushed Linux on them years ago and they pushed back with AIX (settled on NT due to costs), then they pushed Linux next time around. I actually ran one of their first production Websphere on Linux web sites when their very beta Websphere for Linux was released as a final version.
I still won't claim to be an expert, but given my background with IBM I would have to say that if they are recommending it, then it's probably the worst thing you can possibly do. IMO, they experiment on their customers. At least they did on me. The worst part is that my experience shows they are not very adept at getting people to help you through problems. They'll send somebody in who's read the manual and he'll hack around for a few days before calling in the real guy.
The global economy is a great thing until you feel it locally.
I guess the tubing logistics would be a pain in the * as well as the PSUs generating heat.
I just imagine since AC costs so much, that people haven't thought of any newer or different ideas to save cost in this aspect.
Any innovative solutions out there? This sounds like it could be good idea for a /. story.
..........FULL STOP.
Hey, South Bell man, you sure your code was really innocent? I mean, the freakin' thing must be a CPU hog, admit it. :-)
I googled for VM papers and info, and I found not a lot of worthwhile free info on the web. Do you know of any such info?
I'm really interested in the whole virtual machine thingy, where CPUs, memory, etc. are virtualized.
Who still runs Tandem? Ok, plenty of places still do. But when your primary source for replacement hardware in your systems is good luck on eBay, it's time to start looking at alternatives. Yeah, it does a bunch of cool stuff that nothing else really does, and it's reliable. It's also old and rickety, and kind of dangerous in a business sense.
Covener, you're right. zSeries suck as number crunchers. They are great at intensive I/O jobs. They are great at consolidating servers that aren't all busy at the same time. But "brute-force an RSA key" is exactly what you don't want to spend your expensive MIPS for.
BTW, I found that on a web server mettle test, large file transfer performance was better on zSeries than on RISC boxes. The larger the files, the more advantage to the mainframe. This is an interesting side-effect of having processors dedicated to I/O and freaking huge I/O bandwidth.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
If you think the dissenting opinions on this thread are bad, read the Linux390 mailing list. One thing just about everyone agrees with on the list is this. Do not buy a mainframe to run Linux. If you already have a mainframe that has some spare cpu time, look into consolidating simple services onto LiuxVMs. Generally speaking linux on the mainframe relies on "well in this case" situations that make it cheaper. For instance you can use Samba on a LinuxVM to have a very reliable file-server, but DASD and Shark's are bloody effing expensive compared to pretty much any other system. However, if you already have a well enginered backup system and all the neccisary licensing, perhaps that tips the costs back in favor (or at least break even). There are a great many who see Linux390 as half "geeks looking to do something nifty with linux" and half "IBM looking to show off its linux-commitment and get some free press about its mainframes". Because when you really learn about all the options, benefits, and limitations, there are suprisingly few situations where it's worth it.
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)
:). Personally I would stick with rack mounts... or, use a data center ( offsite ) if the opportunity presents itself.
Reading this sort of shocked me... in the past I worked for a major Canadian trust company ( hint hint ) and contracted to a different major Canadian bank, and both were in bed with IBM. In all honesty, im a bit shocked you have any say in the matter at all! From what I found of the IT departments at both banks... if IBM said it was right... it was right. Hell... I was hired to port a bunch of Visual Age C++ Framework ( forget the name now, but it was IBM's equivelant to MFC but on OS/2 and windows )to a Java compatible object model... so that eventually all their systems could be ported to java. If you remember a few years back ( perhaps 5 ) IBM was the biggest supporter of Java outside of Sun. Before that it was OS2, and for a while there I believe it was smalltalk ( before my time... ). Now, IBM has attached itself to Linux, and will consult all of their major customers to do this migration as well. Thing is... both the companies I worked with did what IBM said, almost blindly... hell, as far as I understand it, they are still porting away from OS/2 to this date... Poor bastards... im glad I left that world behind.
I guess the old adage is true... you never get fired for choosing IBM. You get a good look at the politics within a bank though... and you will see thats where most managers interests lay... self preservation... not doing whats right. Whats the Moral? Hmmm.... I suppose its just that, you should consider yourself lucky, that the financial institute you are work with even questions IBM's judgement
As to the VM solution itself, I have to admit, that particular technology I have had no direct experience with. However, unless you have the budget to have a complete server for backup ( as in standby, not as in storage... ) I dont like the concept in general. If you cant hot swap a server in place of the Z, you are playing with fire putting all your eggs in one basket. I dont care how many redunandcies are built in... you are still running multiple important tasks of one box. If you do have a hot swapable backup... obviously your budget is bigger then mine
There are installations that have been running 24x7x365 for decades
24 Hours a day, 7 days a week, 365 weeks a ????
Imagine a Beowulf cluster of ...
as always, don't use a hammer to turn a screw, etcetera, etcetera.
if you have a solution that requires heavy compute, low-to-medium I/O, no large shared memory ( unless you cough up the money for Myrinet, SCI, or Quadrics ) go with a Linux cluster using x86, x86-64, or (shudder) Itanium2 CPUs.
if you need a high throughput environment w/ fairly good compute, shared memory or not, go w/ a large UNIX machine, like an SGI Altix or Origin 3000, IBM Power 4+ box, HP Superdome ( or whatever they're calling them now ), or Sun Ultrasparc III based machine.
If you need a machine that is up 24x7x365.5 freakin' days a year, multiple OS images, with good throughput and low CPU usage, go w/ a mainframe like the zSeries.
Just bear in mind that the more complex, fault-tolerant, high I/O machine you go with, the bigger the price tag gets. If your problem requires it, spend it.
now signing off, it's 3am and I'm working on an app server for our cluster.
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
"[...]On one hand, you've got a spare engine if one dies, but you're 2x as likely to have a failure..."
True. But remember, the plane goes down only goes down if BOTH engines quit, and:
IF
Probability of one engine quitting=P(x)=0.4% per thousand flight hours
THEN
Probability of TWO engines quitting AT THE SAME TIME is not 2*P(x), but P(x)*P(x),
Which means, in this example, that the value is 0,000016%, not 0,08% (a 5.000 times difference)
"If a boss demands loyalty, give him integrity. But if he demands integrity, give him loyalty." (John Boyd, 1927-1997)
They are Royal Liver - see this report
I'm curious how you addressed meeting scheduling that Exchange provides?
I work at a large 50k employee + company and we have over 50 Exchange servers to support our user base.
I think you have your airplane analogy the wrong way around. The alternative to lots of VMs on a big mainframe is lots of smaller real machines. Which is more likely to crash, your IBM-Boeing 747 with four engines and four hundred passengers, or one of four hundred single engined light aircraft each carrying one passenger?
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
There are a lot of factors in TCO evaluations, and initial investment and service costs are only a part of it. Having gone through an evaluation of a Z900 as a replacement for multiple smaller boxes, it turns out that the amount of space saved in the machine room and the associated reduction in A/C, electricity, and management staff can justify the cost. The MTBF of 35 years is rather cool too.
As an example, a 32-processor system can potentially replace 100 ~ 200 smaller systems depending on the load characteristics.
The beauty of a mainframe is that there are fail-over dies on the ceramic base in case of a failure. The hardware handles the switch from a damaged section to a live standby system without having to go to the OS level. Also, resource management can be finely tuned - switching memory or CPU resources from one VM to another is relatively easy and is all done in software. No opening of boxes and pulling out/putting in memory is required.
A mainframe can be a good fit for companies which have large numbers of servers and are looking to consolidate, and at the same time as increasing reliability.
Mainframers have a well trod path to reliability, follow itA
Flint
On the other hand, if those 20-30 Intel CPUs are rendering CGI for a film, or modeling a jet engine (and thus running near 100% load), a zSeries CPU would only be able to take on the work of 4-5 Intel CPUs, if that.
If you have something cpu intensive, doing lots of floating point calculation then get yourself a pseries (a fancy name for RS/6000) - that's what they're good at and where they still beat the crap out of intel. Then you can pick either linux or AIX, although I'd picked AIX and install their "linux bundle" (pre-compiled open source stuff).
i went thru this last year 12/02 i new nothing of z/vm or linux.. i've been pleased ever since and ready to learn more...
We have installed a number of Linux guest machines using VM. Here are the pros and cons I found.
Cons
Yes you must have somebody who understands VM well. If you have this hardware, you probably already have somebody.
Raw CPU power is not the strength of this setup. If you need that, there are better solutions.
If you go with a commercial Linux distro for the Z series, you can pay big bucks. Our quote from Red Hat for Z was about ten times more than Red Hat AS.
Pros
Easy to create numerous virtual servers. Great for testing. No matter what you do on those virtual servers in Linux, you are not going to screw up anything else (short of sucking up resources).
Very reliable. We have our system connected to an IBM Enterprise Storage System with a ton of disk space. It has redundant everything, calls home (IBM) if there is a problem, and runs like a tank.
Very good I/O performance. Computer Associates has a white paper benchmarking performance vs Wintel (Dell Xeon servers I think).
Also, you might want to take a look at the Debian port for this. That is what we have been using for the last year, and it seems to work as well as the SuSE or Red Hat version, and has a $0 initial cost. There is commercial support for Debian on this platform also.
About six years ago, I installed one of the first P/390 systems in the UK (took 8 months, largely because of the newness of the hardware) and managed it for a couple of years. It was essentially a big PS/2 running OS/2: the S/390 environment and devices (including 3390 DASD) were emulated within OS/2, and VM was installed and run within this (and then OS/390 was installed as a guest system under VM!) And - it all worked superbly. Even OS/390. I've not tried it under Linux (I'd love to, but VM's a bit expensive ...) I imagine the general challenges are very similar.
I haven't been all that impressed with it. I work for a Fortune 500 financial firm and we cut out a LPAR for linux on our development mainframe, installed it, patched it up to the current levels and it hasn't been all that great. The biggest problem that I've had (which I'm still having) is that NFS mounts like to intermittantly hang on writes. There's a lengthy thread about this ats t.ed u/msg15729.html
http://www.mail-archive.com/linux-390@vm.mari
but I never did find a solution. The big pain is that the box requires a reboot (okay, an IPL in this case) to get it out of the nfs hang condition. There's mixed support for it inside the firm - I'm really the only person who has tried to use it to any serious degree. The framers don't seem to want to mess with it (or open a support ticket with IBM on it) so it's pretty much languishing around here. The unix support folks here are too busy fighting other unix platform fires.
All in all, the performance isn't that spectacular. I/O is good, but the number crunching can be beat by a decent x86 system. What else is new?
I heard yesterday that IBM are willing and waiting for UK clients, there is no one in the UK at present to IBM's knowledge running this although if ya want to I'm sure they will be willing to talk
In soviet Russia you don't run anything on VM, VM runs YOU
... using VM. Not everything can be measured in pure dollars and cents. Consider: All the stuff written about "what-if" this or that fails because I have only one box can largely be ignored. All that fail-over stuff is built under the skin of the box. Just because you don't see it as multiple distinct boxes doesn't mean it's not under the covers (multiple power supplies, cpu's, busses, etc.). When something goes wrong in an app you can right off generally cross-off hardware problems. That's because, if there are hardware faults, the system brings in spares and shoots out diagnostics on EXACTLY what's wrong, right down to the card level. So if the sys is quiet about the hardware, it isn't the hardware. One very big advantage is being able to run multiple versions of your OS's simultaneously. That means you don't have to worry about the crusty app running on the dusty box nobody remembers anything about. It's all on your M/F and will move right over if you change hardware. And, of course, business recovery is a dream since your not talking about replicating all those unique boxes you've accumulated over the years. In general, VM should be looked at as a management tool more than pure power under the hood. If you need to manage your corporate computing needs at a corporate, strategic level, VM's for you. But that doesn't mean there won't be a few instances where you've got to have the pure dedicated power for one app. But as the years go by and some apps hang around and must be maintained while focus moves onto other things, you will be very happy you've got VM there to manage your own sanity.
Internet suspend/resume at Intel Research in pittsburgh is another: paper HERE. They also had an article in scientific america awhile back.
One big advantage of managing with VM's is a complete system is just like a file, and thus can be copied and migrated easily. For example, if you have a production server with some faulty hardware, you can migrate the machine to a new host by simply copying the VM files, then repair the hardware, and copy it back.
Of course the efficiency is degraded somewhat do to the VM overhead, but the main argument is cycles are cheap, peopel are expensive. It's cheaper to by a P4 2.4 GHZ for $500 than buy a new sysadmin for $60,000. If you are performance-limited, just replicate instead of buying some fancy hardware (or look into better VM technology like VMware ESX server).
IANAC (I am not a compiler) but as I understand it CPU and RAM are not what make mainframes so much faster for large scale transaction loads than desktop machines ... the I/O throughput of big iron is what makes them able to handle the bigger loads.
A box with a few 3GHz CPUs in it isn't CPU bound anymore - it is I/O bound (back and forth to the memory, hard drives, and users.) If a desktop box can get a 40% boost in performance by doubling the amount of on-CPU cache - that means it is outrunning the I/O of the rest of the machine by at LEAST 40%. Add 20 instances of virtual machines all doing different things and accessing different data and the difference becomes obvious.
Adding more machines with a 100 megabit switched backplane means 12.5 Megabytes (peak) of bandwidth between them. For some things that are easily segmented a cluster is a great way to get performance. And cheap too. But you are right - when failure (or going slow under massive loads) is not an option, and getting your job outsourced to India is not an option, going VMS on big iron is a win-win situation.
Glonoinha the MebiByte Slayer
Here's something about linux on os 390 that I don't understand. Maybe someone can clear it up. So - you spend all this money and now you've got SUSE running ontop of your os 390 mainframe. The thing is - you've thrown away many of the best things about linux (imho) - applications have to be compiled specifically for the 390, and how many opensource developers compile for the 390??? Not many! So now you're running linux - but you don't get many of the benefits of using on OS that is being developed on by the millions of linux freaks out there. Plus - all of your internal apps will need to be compiled for the os390. Go tell your developers that!
Silly question : lets pretend you are running a bunch (10) of Virtual Machines on one big piece of hardware, and on those VMs you are running Windows 2000.
Do you need one license of Windows because it is all running on one machine, or do you need 11 licenses (one for the host operating system, and one per virtual machine) in order to be 'legit'?
I ask this because of the way XP Pro (and presumably Server 2003) is locked down and needs to be activated on a 'per machine' basis - this could be a very real issue in short order.
Glonoinha the MebiByte Slayer
Well the mods are on crack today.
/. - you just have to SOUND correct. Excellent grammar, spelling and punctuation, nice use of paragraphs, good word diversity ... hell yea, +5 Informative, baby!
... NOT.
Come to find out you don't actually have to be correct to score a +5, Informative on today's
Because everybody has a z-series laying around to experiment with, and quite honestly a dual CPU machine built in Pengin's garage is going to dominate a z990 anyday on those difficult high bandwidth web server transactions
I have slashdotted dual CPU desktop boxes, and I have slashdotted high end mainframes and trust me, it is a hell of a lot harder to slashdot a zSeries than a garage built dual Xeon.
Glonoinha the MebiByte Slayer
Well, not at the exact moment...
I've got no experience with virtualization on Z-Series hardware, except that anecdotal evidence from colleagues of mine always contains positive feedback, but with interspersed horror stories... mostly related to IBM Consulting Services and how they cost WAY too much for what the accomplish.
:)
My experience with VM's has so far been with VMWare GSX and ESX. While not really the same, these are based on similar concepts as the mainframe VM's, and ESX especially is a really awesome and reliable product. However, you're still tied to commodity Intel hardware and all the good (and bad) that implies.
On the flip-side, for good multi-path redundancy you can implement multiple VMWare servers in a clustered configuration... where one node exists as a guest on one host, and the next node on the next host and so forth. Yes, you can implement multiple nodes on the same host... but why?
The only problem with these implementations is current lack of support for grouped/teamed network cards which does somewhat limit the ability to provide true multi-path redundancy. GSX gets around this a little by using Windows as a back end (or Linux), and as such can support network teaming through the host OS. Not a perfect solution, but workable.
However, ESX is under pretty much constant development and has become a very stable product. Also, it's only a matter of time before the teamed-NIC problem ceases to be an issue.
My personal feeling is that either the Z or with VMWare you can accomplish what the customer wants... personally I'd go with VMWare because I feel I can get a lot more bang-for-the-buck simply because Intel hardware is cheaper and generally can be as powerful as a mainframe in heavy computational environments. Sure, nothing beats a mainframe for sheer I/O... but that's also nothing you can't work around with a well-configured storage and memory subsystem in a VMWare host or hosts. The only caveat is that you do need to ensure you've properly designed the VMWare system before you start or you WILL get burned. Provide as much multi-path redundancy as you can and you'll get mainframe-like uptime, virtualization and performance... and at probably still a fraction of the cost of a new Z.
My 2c... take it for how much that can actually buy you these days.
just curious, is PHP available for these servers yet? I know apache & mysql run and have binaries available and if php runs as well then this should be a very nice scale up to :)
Of those to whom much is given, much is required.
VM and Linux are 'emulated'
I find that comment misleading. Trying to ferret out whether an instruction is burned into silicon, interpreted by microcode, or run by millicode really isn't a worthwhile exercise and leads to a misunderstanding of what IBM brings to the party with its mainframes.
Through their Interpretive Execution Facility, VM and its Linux guest run directly on the "bare metal" without any emulation.
A couple of IBMers wrote a paper about how VM and the hardware work together to create virtual machines. The context was security, but there's a decent description of how this virtualization thing works. I think it's linkable from the VM homepage (http://www.vm.ibm.com) somewhere.
oops, wrong site
a lot of the comments mention the z's large io and lack of power. if you want power, get a p and install Debian/PPC on it.