[GI Joe]

I haven't been able to find any clear-cut commendations for when we should virtualize new servers instead of purchasing dedicated hardware? Can anyone provide a set of guidelines or conditions for when it makes sense to take a virtual approach? I'm particularly concerned with cost issues. Contrary to media reports, we do try to avoid purchasing $800 hammers.

[Groovy]

I can tell you how our IBM sales guy figures it out.

He gets paid on hardware, not software or professional services. So he thinks nothing should be virtual because nothing is better than hardware.

[Administrator]

There's no real rules as to when you're better off virtualizing than not, but I can give you a fscenario that might help explain it.

Lets say your looking at a p520Q to base you're development efforts on.

You have 30 developers for this project.

When you developed on Solaris, each developer had their won desktop Sparc20 to do their coding on. That way they could write code, test, reboot if necessary without afffecting each other.

Then you had a main test server that was configured like production with production data. In addition, you had a Q/A server for final testing and packaging before rollout to production.

IBM doesn't have single user desktops, so you're going to need to move those developers to individual partitions. Lets assume you micropartition, so each developer gets his how individual partition of 1/10th of a CPU and at least 256 MB of RAM. The partition also needs a root volume group of at least 4 GB - 8 GB would be better plus whatever they need for development efforts. Of course we need IP connectivity to the developer's desktop X software, Hummingbird Xceed, for example.


Lets pause to outline our developer requirements:

1. 30 LPARs
2. 1/10 * 30 = 3 CPUs
3. 256MB * 30 = 7.5GB RAM
4. 8GB HD * 2 (to mirror) * 30 = 480GB
5. 30 network connections

Now why can't we do this with dedicated hardware? You'd need 60 network ports - you don't want a single port failure to stop development at a critical time. You'd need 60 hard drives and 60 fiber channel adapters for SAN disk. You can't even build a p570 to satisfy all of these hardware requirements.

But on a virtualized p550Q this is pretty simple. What do I need?

Lets start with the requirement for the virutal I/O server: .5 CPU and 1 GB RAM.

The 550Q has 4 CPUs, and I've only used 3 1/2. That last .5 CPU will stay in the CPU pool and be available to any partition for peak CPU periods such as compiling code.

We need 9.5 GB RAM, so we'll configure the server with 12 GB RAM and leave that extra 2.5 GB available to all partitions.

The VIO server is going to use two 73GB HDs for the operating system and VIO software. We'll also add four 146GB HDs. I'd put two in lpars_hd0_vg and two in lpars_hd1_vg.

for every LPAR I create, I'll create lparname_hd0_lv in lpars_hd0_vg and lparname_hd1_lv in lpars_hd1_vg.

I'd make sure two of the four drives are located on a different internal bus on the server and served through a different VCSCI device. This will ensure my LPAR rootvg is mirrored across buses and devices.

So far, so good.

Now for the network. My p550Q will have two quad ethernet adapters in it. Adapters en0, en1, en2 and en3 will be etherchanneled to form an agregated device, en8. Adapters en4, en5, en6 and en7 will be etherchanneled to form an agregated device, en9.

Finally, en8 and en9 will be etherchannled into a primary/back device, en10.

This will guarantee that my VIO server has a 4 Gb network pipe to share among all LPARS. Each LPAR will get better than 100Mb of bandwidth average, and much higher burstable speeds.

Once I configure VLANs on each of the LPARS and enable shared ethernet, all LPARS have a route to the outside network.

Then all I have to do is configure VSCSI devices on the SAN and all 30 LPARS are up and fully functional on a p550Q.

Final tally:

4 CPUs
12 GB RAM
6 HDs
2 4-port ethernet adapters
2 dual-4Gb fiber channel adapters.

Ready for the kicker?

The p550Q expands to 8 CPUs and much more memory. I've already got enough network and I/O bandwidth to complete the entire development enviroment - the integration and Q/A partitions - in this one physical server.

Hopefully this give you an idea of when its right to use virtualization. Remember, its not software, its a technique and a technology. In this example we used virtual I/O, micropartitioning, etherchannel and a storage area network to complete the requirements. Without any one of those capabilities, we would have had a drastically different and more expensive solution.