Newsletters

Maybe it's a regular ten year cycle. A decade ago, low cost x86 boxes and Linux clusters were supposed to finally put mainframes out of business. But as the number of servers grew, so did the headaches. Take the case of one organization which ended up with 800 servers in its 6,000 square foot data center - 19 different types of Dell 1U, 2U and 3U servers and an Oracle/Linux grid running on two dozen IBM 3850 servers. Floor space became cramped because of server sprawl and a mentality that added a new server for every new application.

Server consolidation and virtualization offer a path to eliminate such server sprawl. Companies have jumped on board with this strategy, installing, according to estimates by analyst firm International Data Corp. (IDC), around 6 million virtual servers with many more on the way. However, although virtualization can provide a solution to physical server sprawl, the virtual servers themselves can get out of control, causing costs to skyrocket.

Bottom line: unless virtualization is properly planned and managed, it can grow into a tangled morass that consumes more time, people and money than the previous operating structure. This comes from the fact that it is so easy to create a new virtual machine (VM). Thus they tend to proliferate, resulting in what is called VM sprawl.

"Organizations are quickly realizing that virtualization without proper planning, management and service optimization capabilities can lead to performance headaches that can stymie attempts to leverage the technology for real business advantage," said John Madden, an analyst for Ovum Research.

Enterprise Management Associates found that most people cited the inability to see, manage and control VMs as one of the biggest problems associated with virtual machine management. This research showed that the difference between organizations that take control of their virtual machines and those that don't can be as much as $3,300 per virtual machine, just in staff costs. And that is only the beginning. Each virtual server is also subject to licensing costs for the operating system and applications, even if they are not serving any business purpose. Zombie servers are an even bigger problem with virtual machines than it is with physical servers, due to the ease and speed of setting up a VM. A VM set up for a quick test or other short term need can keep running indefinitely.

Modeling VMware
The best way to combat virtual server sprawl is to model every proposed new virtual machine or virtual migration.

In VMware ESX server, you have the CPUs and IO on one side with the virtualization infrastructure layer (hypervisor and virtual kernel) in the middle, and then the operating systems (Windows and Linux), applications and guests on the other side.

The current model architecture is simple and straightforward. Guests are represented as workloads. However, an enhanced VMware modeling architecture is under development. This parallels the actual design of VMware. Each logical system is shown, as well as the workloads.

In this enhanced version, the physical CPUs and IO sit outside the logical system which consists of the virtual CPU (VCPU) and the workloads. This is very similar to the way TeamQuest Release 10 deals with AIX modeling.

The VMware agent takes data from each guest as well as the physical server. GUI changes are being included so that it is easy to tell the difference between physical and logical systems. Data is provided on easy to read spreadsheets. You can open the systems spreadsheet or the active resources spreadsheet, for example. The Active Resources spreadsheet can be used for such things as changing the virtual CPU configuration. You can also go to the "number of servers" and rapidly make further changes there.

Server Consolidation
Let's take a look at an example of using TeamQuest Model to model variations involved in server consolidation between one Windows server running a single application and a VMware ESX Server running two guests. To move the application from the Windows server to the ESX Server as a new guest, two questions are needed during preparation.

In the old days, you didn't need this step. Now, however, this needs to be addressed as it is quite often the case that you don't know your endpoint configuration for a particular guest. When you model, though, you still need to pick a starting point and go from there. That starting point might change, but you have to start somewhere.

Several steps during consolidation keep you from making too many configuration mistakes. Step one is to add a logical system. Step two is to add a logical CPU. Step three is to migrate the workload using the "Move Workloads Between Systems" screen.

Now you are set up to model the change and review the results. In the case of the application on the Windows server, its response time of 0.2 seconds shifted to 0.01 seconds when it was consolidated onto the ESX server.

Responding to Growth
Back in the old days of standalone servers, you had limited options. If response times suffered, you had to move the work to a higher-end system or upgrade the server hardware. In a virtual world, you can do several things. You can very easily move the guest. You can adjust the guest attributes, you can change the virtual CPU configuration or change the physical CPU configuration.

Guest relocation using VMotion is very simple. So simple, in fact, that a smart organization will harness TeamQuest to model any such moves before carrying them out. Before moving a host from one ESX Server to another, then, model it and compare the current environment to the proposed shift of that guest to the other system. By validating the move via modeling, you can conduct migrations with confidence that no over-provisioning or resource contention issues will result.

Future Additions
Enhanced VMware modeling functionality will be available in a release scheduled for October 2009.

As for the future, the next generation of TeamQuest will provide a multitude of features to facilitate far more automation of capacity planning, modeling and performance monitoring within VMware environments.