Bandwidth of all kinds is a particular problem because it is likely to be the place where problems show up. Not only do almost all applications use bandwidth, but the loads tend to be very variable. If two or more applications peak their I/O or memory demands at the same time, you're likely to have an intermittent problem that will be hard to track down.
This introduces, if not a new level of complexity, at least a new watch point in the virtualized data center.
When the physical server supporting virtualized machines runs out of resources, a whole lot of applications are going to be affected. As Stucker puts it, "Anytime you miss your guess, there's going to be more delta in your peaks and valleys."
Monitoring
The need to assure the availability of resources is an additional reason why virtual/physical server stacks need to be monitored closely. Another reason is that a hardware failure will impact more than one application.
Because monitoring is so critical, virtualization software like VMware and SWsoft's Virtuozzo include tools that help track both physical and virtual resources.
Because loads change over time, monitoring is a continuous process. You can't set it and forget it any more than you can with a physical server. In fact, you have to pay even closer attention to monitoring, because each physical server is supporting several virtual servers and all of them can be affected if the physical server starts to run out of resources.
Third-party tools
One peculiarity of virtualization management is that a lot of companies aren't invested in third-party tools to do it. According to Bob Gill, managing director for servers at TheInfoPro, a New York-based market research firm, surveys show that most virtualization users rely on the tools supplied by the virtualization vendors rather than investing in additional applications to help manage their environments.
In part, this is because companies like VMware and SWsoft already provide management tools with their products. But part of it is also due to the relative immaturity of the virtualization market. At the recent Infrastructure Management Conference in Scottsdale, Ariz., Gill said he expects the market for third-party monitoring and management tools to grow as the market for virtualized servers grows.
Some customers are taking other tacks. At Radiator Express Warehouse, Carvalho employs what he calls a three-tier solution. He uses the tools that are already part of VMware's ESX, which he calls "awesome," but he backs them up with Dell Remote Access Controller, which monitors all the equipment in his physical servers, and WhatsUp Professional from IPswitch Inc. for managing his network.
What to virtualize
Holmes noted there are some myths about what you can and can't virtualize successfully. "Originally, when VMware was the first virtualization product to really penetrate the enterprise market, you had people saying, 'Don't virtualize this or that,' " says Holmes. "That has somewhat changed." As users have become more comfortable with virtualization, it's become clear that a lot more can be virtualized than some people originally thought.
For example, a lot of enterprises were reluctant to virtualize DBMS applications because they need so much memory, processing power and memory bandwidth. But these days, advances in server technology, such as multicore servers that can take a lot more RAM, have made database virtualization more practical.
Ruven Cohen, CTO and co-founder of Enomaly, says that better hardware has a lot to do with the acceptance of virtualized databases. "On the early servers, when virtualization was relatively young, your big stumbling block was what you could put through the server," he says. "With the latest chip sets from Intel and AMD, that is no longer an issue."
That said, in nearly every data center, there are some applications it isn't a good idea to virtualize.
For example, Carvalho runs his production database on Dell eight-way 6850 servers. "I would never virtualize those, because I would lose too much performance," he says.
Similarly, Jamey Vester, a production control specialist for Subaru of Indiana Automotive Inc. in Lafayette, IN, says his company doesn't intend to virtualize its SQL Server cluster. Also, he says, "some of the specialized production and automation applications are very sensitive to the physical hardware."
The critical point is not that these applications are databases, but that they are large, resource-intensive applications. For example, AET's Stucker doesn't virtualize his company's enterprise database, which is an ERP and data warehouse system running on Informix on HP-UX and which Stucker calls "huge." "But we have all kinds of ancillary databases we have virtualized," he adds. "We have a number of SQL Server databases that are virtualized."
Generally, applications that heavily load their servers in terms of bandwidth or capacity are not good candidates for virtualization -- unless you get more powerful hardware.
Establishing and maintaining virtual machines absorbs resources (although how much depends on what kind of virtualization scheme you use). Those resources come out of the same resource pool that supports the virtualized application. If an application is using 80% of a physical server's resources, it's not a good candidate for virtualization unless you put it on a much more powerful server.
The licensing problem is stickier. Some vendors don't license their products to run on virtual machines. Sometimes this is done for business reasons, to keep control of the number of copies running in the enterprise. Sometimes, although more rarely, it is done because there are hard limits in the software that inhibit performance on a virtualized server.
In some cases, the vendor simply doesn't know how the product will perform in a virtualized environment and is trying to avoid possible performance problems. br>
Generally, software vendors are becoming more virtualization-friendly, but you need to check the license before trying to virtualize an application.
Do's and don'ts of managing virtualized servers
DO ...
- Remember there's real hardware down there somewhere.
- Plan your deployment.
- Control virtual server sprawl.
- Choose your tools carefully.
- Balance your servers' loads.
- Monitor physical resources and trends.
DON'T ...
- Ignore physical server load.
- Assume virtualized applications will scale linearly.
- Put the same type of applications on the same machine.
- Try to virtualize all your servers.
Rick Cook learned on computers where the 'database' was the cabinet holding the decks of punched cards. He is a freelance writer specializing in computers and technology who lives in Phoenix; you can reach him at rc@thekeep.com. Over the last 25 years he has written thousands of articles on IT and related subjects, as well as several fantasy novels full of bad computer jokes.