Virtualization: Workload Consolidation
Done properly, consolidating server hardware through virtualization can convey many more business benefits than simply reducing hardware costs.
Adapted from “Microsoft Virtualization” (Syngress, an imprint of Elsevier)
When you think about workload consolidation, imagine the services your datacenter provides. During the initial discussions of workload consolidation, it’s common to slip into thinking about power consumption and rack space. While those are certainly key items to consider in your overall virtualization strategy, thinking about them at this point skews the focus you’ll need for workload planning. So stop thinking hardware footprint and instead focus on the services your datacenter delivers to your business. It is these services you want to focus on consolidating.
Workload consolidation isn’t something you can implement in a cookie-cutter fashion across multiple businesses. Even businesses within the same industry vary slightly in the way they perform their tasks. Therefore we can’t delve into the granular details of workload consolidation, but we can discuss it in generalities.
One of the technologies fairly widespread in most industries is published applications. So let’s begin our examples there. Publishing an application to remote users consists of a fairly complex and sometimes large infrastructure. This can be even larger depending on the number and nature of the applications published.
The evolution from initial design to what it is today is common among servers and published application environments. For example, a farm that was initially designed to publish application “X” five years ago may now publish application “Z,” and not even publish application “X” anymore. Or applications may have been added or removed from the farm altogether. This evolution is inevitable, but it is also a great example of the benefits of workload consolidation.
Let’s say Farm One was built five years ago to publish a single application to 1,200 users. It uses 20 application servers, a licensing server, five Web servers, and an eight-way database server. At the time of its initial design, we used all-new hardware based on vendor recommendations and specifications.
We built Farm One and introduced it into the environment based on vendor recommendations for software configuration, hardware specifications, and the number of users that would connect to and use the application being published. Over time, as with many organizations, the true usage of our farm evolved.
What was originally 1,200 users hitting a single application dropped to about 600 users hitting the original application. An additional application was added to the farm and published to around 200 users. The hardware that was once the latest and greatest has become dated, while the software has continued to get patched, updated and become more efficient. All of these details play into your workload consolidation planning.
The major vendors of application publishing software provide tools and guides that help identify the true usage of your application servers. Using those tools during this phase of your workload consolidation planning is crucial. Keep in mind that even vendor-supplied recommendations for their software are based on general usage. The way your users actually use the application being published can only be determined by thorough examination.
Ease the Load
The original specifications for Farm One called for 20 application servers to support 1,200 users. We are now down to 600 users. However, you can’t assume that the number of application servers can simply drop by 50 percent.
At this point, you will want to contact the vendor supporting the application. You should have collected a matrix of true server usage using the tools provided by that vendor so they can assist you not only in downsizing the size requirements of the farm, but also in ensuring that existing support agreements will be maintained through this process. You’ll want to carefully examine usage statistics as well.
In examining our hypothetical Farm One environment, we’ve discovered that the database of the primary application is no longer accessed nearly as often or as intensely as it once was. This allows us to replace our existing eight-way server with a less-powerful server, or even migrate the database to another database server that may have the required specifications in excess. For our scenario, we’ll migrate the database to another database server.
As mentioned earlier, though, our farm has evolved to include an additional application published to around 200 users. So now we must go through the same steps for this application to determine its true requirements.
With our assessments complete, we have identified the true requirements for the new, consolidated workload of our published applications environment. We have reduced the number of Web servers from five to four, and migrated them into a virtualized environment.
The number of application servers has decreased from 20 to 10, our stand-alone database server is removed completely, and the database is migrated to another database server with excess and available resources. We have also virtualized our licensing server, as well.
Thomas Olzak is the director of information security at HCR ManorCare, an Ohio-based short- and long-term rehabilitation and medical care provider with more than 500 locations spread throughout 32 states. Jason Boomer*,* Robert Keefer and James Sabovik also contributed to this article and the book from which it’s excerpted.
©2011 Elsevier Inc. All rights reserved. Printed with permission from Syngress, an imprint of Elsevier. Copyright 2011. “Microsoft Virtualization” by Thomas Olzak. For more information on this title and other similar books, please visit elsevierdirect.com.