Server virtualization.

Most of us wouldn't dream of going on vacation with nothing more than the clothes on our back and a small handbag. Taking along a huge suitcase, however, is not only heavy but requires waiting in the check-in line for some time. Unfortunately, only in a dream world can a handbag be bigger on the inside than on the outside to carry all of your vacation belongings. And in these same dreams, huge suitcases magically morph down to the size of handbags, saving holiday-makers the hassle of carrying and checking in huge, cumbersome luggage.

IT professionals dream of robust networking environments that exist in this same dynamically expanding and contracting dream world. They want their networking environments to be capable of processing weekly payroll, end of month commissions, end of year accounting--A/R, A/P, general ledger "close outs", and at the same time be able to maintain their daily ERP, CRM, and e-mail systems. Most servers, even in extreme conditions, rarely reach maximum processing power. In fact, in a typical workday environment, most servers (particularly Windows) rarely surpass 10% utilization rate.

The Reality

Luckily, at least for IT professionals, the dream world of server "morphing" (or virtualization in the real world setting) is becoming a reality. Although most companies are not taking advantage of virtual server expansion and contraction capabilities today, it is possible to "borrow" CPU and/or memory capacity from other servers, which are currently not being "taxed", and then return that same CPU and/or memory capacity back to their original "owners"--in their original state. Imagine servers being spoofed to think they have unlimited CPU and memory capacity and subsequently never go beyond processing/workload thresholds again!

Engineers at Evolving Solutions, Inc. (a data disaster recovery, storage architecture, and business continuity solutions provider) predict that by the end of 2004/early 2005 servers that auto-monitor and auto-adjust for Data On-Demand requirements will be appearing frequently in larger IT shops. Servers able to auto-adjust to continuously changing CPU and memory needs will become as widely accepted as the current "cascading servers" methodology. More than simply a foray into virtualization, this is a complete leap into "autonomic computing".

Local Server Virtualization 

Imagine employees accessing large files or applications such as Visio or AutoCAD from a local server. Processing power needed for multiple employees to open large files located on a single server can push CPUs and/or memory past predefined thresholds that are typically set at 70%-80%. When they exceed their thresholds, the lack of processing power drastically inhibits data/document retrieval speeds across your LANs and WANs. This often results in hard dollar costs (stemming from replacing smaller servers with larger ones or on clustering the existing servers) and soft dollar costs in the form of a loss in employee productivity. Grow this scenario into an Online Transaction Processing (OLTP) environment and watch hard dollars disappear in the same way baseball caps fly from open convertibles.

Take for example "Local Books", a small fictional book-store on Main Street that sells books written by local authors. The first day they launched their online shopping venue they received 30,000 hits and hundreds of attempted transactions. Because they had not effectively planned for this activity, they found their OLTP and backend database server(s) being significantly taxed. Wait cycles increased because the CPUs and/or memory were functioning constantly beyond an 80% utilization threshold. Spikes in wait times meant website visitors, and online buyers, were negatively affected. All of this happened while their SQL, File and Print, and Exchange servers were running idle at less than 10% utilization.

Unfortunately this type of scenario is typical within many IT shops. While generally planning for system failure, they often forget to plan for success and system scalability. If Local Books had a plan in place to handle additional on-demand ordering, their systems would have been ready for the drastic increase in online orders and would not have dropped or lost any of the transactions.

Had Local Books set up a virtualized server environment, utilizing products like VMware and/or IBM's Orchestrater, their OLTP server never would have reached the processing threshold of 70%-80%. The server would have dynamically accessed any of the available resources from the SQL, File and Print, and/or the Exchange servers to temporarily borrow processing power to complete book order transactions during peak ordering periods--thus eliminating wait times. After the capacity was no longer needed, the OLTP server would have politely returned the capacity back to the respective servers. Local Books' brand equity would have remained intact and a hefty profit would have been made on the opening day of the online store.

In terms of our automotive analogy, a proper server virtualization environment would have allowed the Local Books' OLTP server to virtually grow or "morph" from a two-seater to a four-seater, from a four-seater to a station wagon, and--if needed--from a station wagon to a more powerful truck. And when the extra capacity was no longer needed, the truck would simply shrink back down to a two-seater again.

Remote Server Virtualization

Assume Local Books grew to become National Books, but this time they had a plan for exponential growth. They implemented a virtualized server environment, reduced wait times, and as a result, successfully processed more online orders than they could initially fathom. Now the National Books website receives millions of hits and processes tens of thousands of online transactions and book orders each day.

Without a hardware resource virtualized environment, each time order processing reached its capacity, it would either slow down process requests, create significant "time out" errors or, worst of all, halt the National Books website altogether. The additional "unplanned" traffic on their server could have led to data corruption, lost sales and diminished credibility of their company brand.

But because National Books chose to implement a virtualized server environment, their primary applications could share resources with other (secondary) applications such as: Exchange with J.D. Edwards, SQL with Siebel, SAP with Tivoli, and so forth. Sales and online website transactions would be conducted without slowing down the network, resulting in an increase in per-transaction profitability and brand awareness.

This means that National Books would not have to add servers each time they run a special promotion or have a new "Best Selling Author" book released. As a result, they would be able to save substantial dollars because a virtualized server environment would enable them to increase their "on-demand" CPU and memory resources without having to spend additional hard dollars. National Books' processing horsepower would be guaranteed, no matter how large the demand.

Server Virtualization: Why Not Now?

Many IT professionals may be wondering: If server virtualization is available today, why aren't more IT shops taking advantage of this type of money-saving/resource-sharing solution? Because it is as new a concept now as hybrid vehicles were ten years ago. Ten years from now, hybrid vehicles will no doubt be common place; however, many if not most of you don't want to wait ten to twenty years to virtualize your IT environment.

Server Virtualization: The First Steps

The following three steps are designed to get your company driving in the direction of autonomic computing.

Step 1: Assess & Validate

Conduct an environmental assessment to define each department's server processing needs. Deploy custom configured resource/environmental auditing agents to poll all servers to identify current totals of: CPU, memory, adaptors, and file/system capacity and total used and unallocated disk space (be sure to account for all archive file space as it often takes up 30%-40% of all data storage--much of it in duplicate and triplicate form). During this same assessment you would also identify CPU, memory and adaptor usage peaks, read, write, and wait cycle peaks, and identify all data that has not been accessed over extended periods of time.

Step 2: Rationalize and Critique

Critique your current server environment. Identify and consolidate processing-compatible applications to single servers, or you can virtualize your existing multi-server environment to share processing attributes from a common pool. Only the second choice will aid you in the reduction of purchasing new servers for every new application. As a result, you would increase utilization of your existing servers from a typical 10%-20% to a more effective and efficient 40%-50%. More importantly, you drastically decrease your "unexpected" outages while turning your one-to-one, limited-growth environment into a completely flexible and scalable solution without throwing out your existing investment.

Identify all mission-critical servers. Leave those servers in a one-to-one relationship for your heavy-hitting applications like SAP, PeopleSoft, Siebel and large OLTP databases (such as Oracle). Then, consolidate your non-heavy-hitting applications (File and Print, Exchange, SQL, etc.) and virtualize the remaining servers to form a common pool of hardware resources. Finally, configure the above mentioned CPU, memory, and adaptor resource pool to be shared with the heavy hitting servers/ applications--whenever it is needed.

Step 3: Stop Investing

Look around. Imagine the amount of gas that would be saved if we would all carpool with at least one more person. Stop thinking the only solution is to buy another server; chances are you are not taxing the existing servers you already have. Start "carpooling" your data and available resources!

Tap into your existing hardware pool and reduce the number of servers you feel you have to buy simply to increase on-demand processing capacity. Odds are high that you don't need to add a server to increase your CPU and/or memory horsepower. In fact, if your IT environment is typical, not only may you not need to add to your existing server pool, but chances are you would be positioned to cascade much of your existing servers and reduce your related server budget for years to come ... starting today!

Autonomic Computing

In the very near future, many of today's production-level servers will not only be virtualized but will be configured for and capable of performing internal performance audits or "automated health checks" (from I/O processing needs at the CPU and memory level to page and buffer credit settings at the kernel level). They will automatically adjust and/or reconfigure themselves according to their immediate system needs and be able to virtually morph (growing and contracting at will) to meet almost all on-demand needs, all with either pre-designed human involvement (decision making points, particularly when you are just starting your deployment) or eventually without any human intervention at all.

Virtualizing your servers will enable them to identify their own CPU, Memory, and adaptor requirements. They will reach out to idle servers and borrow capacity in order to complete immediate tasks. Then, without human prompting, these virtualized servers will return the capacity when it is no longer needed.

The ultimate goal of server virtualization is autonomic computing; capacity on-demand that provides an effective road map for managing your information systems regardless of size, processing demands, resource needs, time of day or night, or human availability. Autonomic computing may not be the solution to every problem from "soup to nuts", but it certainly is a solution for most server environments from "coupe to trucks".

www.evolvingsol.com

Jaime J. Gmach is president, and Todd Holcomb is director of professional services at Evolving Solutions (Hamel MN)