Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Background

There's a wasteful, but unavoidable fact - your servers are overpowered (especially in terms of actual processing power) for most of the applications you run as part of your business. The system requirements for, say, software metering (Keyserver, SPSS license manager, etc.) are negligible. But it has to be on a reliable server, or there will be service interruptions. So the server spends much of its time doing very little. That's a waste.

On top of that, some applications don't "play together" nicely - they both want to listen on a specific network port, they want exclusive control of some resource, or they're just not written well. Buying an extra server for each one of these applications is not only expensive from a hardware standpoint, but it also requires more power, more expensive gigabit networking ports, and so forth. It would be nice to run these appliactions all on the same hardware, but they just don't cooperate well, or one requires Linux and the other Windows, etc.

Borrowing a page from the mainframe world, and operating systems like IBM's VM, virtual servers are becoming increasingly popular as a way to control costs and space needs as well as increase both manageability and flexibility.

So what is it?

It's software, run either as its own operating system or under another (Windows, Linux, etc) that creates a "virtual" environment. It carves out some disk space, an allowed amount of memory, emulates a network interface card, etc. and that is presented as a computer. If you're using the management tools, you see boot up screens, BIOS settings, etc. - just as if it was a real server. In reality, the virtualization software is sharing the host computer's CPU, RAM, etc. between all of the virtual servers running on it. A guest operating system running on virtual hardware are unaware of both the nature of the "hardware" it is running on and other guest / virtual servers running on the same host server.

What is Drew using?

We have five systems running VMware ESX server, VMware's enterprise-level server virtualization package. All five are multi-core hosts running version 3 of ESX. ESX Server actually manages the hosts' hardware, presenting only a Linux-based service console. We're able to use it to run NetWare, Windows and Linux virtual servers. A partial list of virtual servers at Drew: the campus web servers (Ektron and the legacy Apache servers), DNS servers, two of three Windows domain controllers, Blackboard, Moodle the Blackberry Enterprise Server, Macromedia Breeze, Patchlink, license metering (Keyserver, SPSS LM, Mathmatica LM), Ad Astra, Supportworks, as well as Novell Netstorage and Novell Quickfinder Web Search for the Drew web site.

One really nice feature is called "VMotion" - this allows us to take a virtual machine stored on a shared disk in the SAN (our Storage Area Network), and migrate it from one VMware ESX host to another while it's in use. There's a less-than-one-second pause as it completes the task, and the virtual server is running on the other VMware host without interruption. This makes system maintenance on the host systems easier, and gives us a way to deal with hardware failures and hardware upgrades or replacements on the hosts.

We've been using VMware ESX server for four years, and the VMWare workstation product for seven. The server product has been such a success that we added our fourth VMware ESX host system in summer 2006 and a fifth in summer 2007. We will continue to migrate some of our physical servers to virtual ones as leases run out on older server hardware.

Limitations

We can't replace every physical server. For example, VMware ESX server limits how many nodes (servers) you can put in a cluster. The amount of physical RAM we can put in a cost-effective server is currently 32 gigabytes. VMware ESX server makes very efficient use of that 32GB, but it is a limit. Also, because the guest OS doesn't have direct access to the hardware, a guest's clock can "drift" off the correct time unless some care is taken in the initial setup of both the host and guest. Finally, virtual servers stored on the SAN for fault tolerance use more SAN storage than a system attached to the SAN to store only data.