Server Virtualization for Small-to-Medium-Sized Companies

As you know, virtualization software allows you to run multiple virtual machines on the same physical host. Each virtual guest runs in a separate environment so errors with the operating system or application will not take down other guests running on the same physical host.

Often small and medium businesses require application functionality similar to enterprise businesses; they just do it on a smaller scale. These applications might include file and print servers, e-mail servers, databases and Web servers. Smaller companies may have a single server running all of these applications. Even in this scenario, companies can benefit from virtualization for security reasons alone. 

Additionally, server virtualization can help heighten security, make restores quicker, improve fault tolerance and reduce server maintenance costs. Aslo see the Server Virtualization White Paper.

Security

Let’s assume that the server is running Exchange 2003 and Outlook Web Access (OWA). With a single server, the OWA server is the same server that also stores the company’s e-mail, database, files and other valuable information. If a hacker is able to compromise the OWA server, they will have access to the entire server, not just OWA, because all of the data resides on the same server.

Larger companies typically install a dedicated front-end server that only handles OWA traffic and does not contain any mail databases or other information. If a hacker manages to hack this machine, they still have to compromise the back-end Exchange Server in order to access any data.

In this single-server scenario, you could set up an Exchange server as a virtual server that is accessed from the Internet. A smaller company would benefit from having a dedicated front-end server without the overhead of purchasing a separate server. If the company is hosting its own Web site this OWA front-end server could also double as  a Web server. Only the Web page information would reside on this virtual server, not any of the company’s critical data files. 

Simplified Bare-Metal Restores

In this single-server scenario, if the server is running Windows Server with Active Directory it is the only domain controller (DC). If you’ve ever had to perform a bare-metal restore of a single server that was acting as a single DC and had other applications running on it like Exchange and SQL Server you know this is a complicated and challenging process. Virtualization can help in this area as well.

There is one file for each virtual guest’s hard drive as well as a configuration file that is stored on the host server. When a server is virtualized a consistent generic hardware platform is created for the virtual server guest regardless of the physical hardware. This means that any virtual guest can run on any server host, because the hardware platform is always the same.

A common backup strategy is to get an image backup of all of the virtual server guests running on the host over the weekend. A script can be created to shut down the virtual server guests on the host and then these files can be backed up to tape or copied to a different location on the host server. During the week, differential backups are performed on each virtual server guest.

In order to restore any virtual server, you must restore the latest image backup of the virtual server and then run the latest differential restore. Because the weekend backups are essentially an image backup of the server, you don’t have to worry about going into Active Directory Server Restore mode or remember not to make the server a domain controller during the recovery process of the DC. 

If the host server entirely crashes you would have to obtain a new server, install the host operating system, install the tape backup software, catalog the tape and then restore your virtual server images and virtual server software. Assuming that you have each server virtualized by application, you could restore the most critical servers first. This would allow your users to gain access to these critical services without having to wait for the entire server to restore. 

Reduced Maintenance Overhead

Virtualization can also save you significant time when you have to bring up a new server. We suggest staging server images with the different operating systems you may need.  This can save you at least an hour or more of setup time when you have to bring up a new server.

For example, you can build an image of Windows Server 2003 with the latest service pack and hot fixes, but don’t join the domain. When you need to build a new server, you can copy this virtual server disk file on the host to a different location and rename it. Then you can create a new virtual server on the host and add in the virtual disk you just copied. When you start the virtual server, all you have to do is rename the server, join the domain, and install the latest hot fixes. This entire process can be completed within 15 minutes, compared with an hour or more to build the server from scratch.

In a small company you may need to run computers with different operating systems that usually require separate servers. With virtualization you can run virtual servers with different operating systems on the same physical host.

In the small and medium market space VMware’s VMServer has the best support for guest OSes. You can run almost any Microsoft OS as well as a wide variety of Linux and Unix OSes on the host server, potentially eliminating the need to purchase additional separate servers.

Multiple Hosts Will Improve Fault Tolerance

Most of the previous scenarios assume that the company has a single server; thus, the single point of failure is not an issue because virtualization will not decrease the fault tolerance of the server. If a single server fails, virtualized or not, the company will go down.

But what if your company has more than one server? Let’s assume that a company has nine servers that run various applications. It may be possible to consolidate these servers onto three physical hosts and still provide fault tolerance if one of the hosts is lost.

If the servers are due for upgrades, instead of purchasing nine new servers, you may be able to consolidate three virtual server guests onto one physical host. Of course, these servers will have more processor, memory and disk capacity than single-purpose servers. In this multiple-server scenario, you can even configure the virtual guests as “warm” guests on a different host server. 

By combining the power of Windows Server 2003 R2’ Distributed File System Replication (DFSR) and virtualization you can easily move virtual guests to a different host in the event of a server crash.

Assuming you perform an image backup of all of the virtual server guests on the weekend and run differential backups throughout the week, you can move the virtual server guests to a different host and recover the servers faster than if they were running on dedicated machines.

Over the weekend you can copy all of the server guest files running on a host to a folder that is replicated with DFSR.  DFSR will then replicate these guest files to a different host server.

DFSR has two features that make it ideal to replicate virtual server guest files: remote differential compression (RDC) and cross-file replication (CFR). RDC will examine a file and only replicate the changes made to the file to a remote server.

Cross-file replication examines a file and searches for files that are available locally to create the desired file. This lends itself very well to replicating virtual server guest files because most of the information in the file remains static and they have a significant amount of the same information stored in them. Although the files themselves can be quite large, the differences in the files on a weekly basis may only be between 100MB to 3GB. 

After the initial replication, the actual time to replicate the virtual guest files should be short. You can create the virtual server guests on the other hosts, but leave them down and only bring them up if you have a problem with one of the host servers.

In this three-host-server scenario, let’s assume you lose host server A, which has three virtual servers running on it. Assuming that you already have the virtual guest files replicated to the other two host servers, you could bring up two guests on server B and one guest on server C. Then you would need to restore the latest differential backup to get the servers as current as possible.

If you design your server host farm with this in mind, make sure to have enough processor, memory and disk capacity to handle the failure of one host server. If you do lose a host server and use this strategy, you should be able to bring up all three guests within a few hours or possibly even faster, depending on how long it takes to restore the last differential backup.

The major drawback to this strategy is the additional storage required to keep “warm” virtual server guest files on the other host servers. This virtual-server configuration also lends itself very well to having a remote disaster recovery warm site or other remote location. Instead of copying the files to a local server, you could use DFSR to replicate the virtual server guest files to a remote server. 

Virtualization Drawbacks

Of course, there are some drawbacks to virtualization. One of the biggest is a potential decrease in fault tolerance.  But if you have multiple hosts and copy the virtual server guest files to other server hosts, you can bring up the virtual server guests on different hosts if one of the servers crashes.

With Virtual Server 2005 and VMware Server a guest server can have a maximum of 3.6GB of memory. If your server requires more than that it shouldn’t be virtualized.

You will probably need more memory on the host server and an OS that is capable of addressing this memory if you plan to host more than a few virtual server guests. Assuming that you plan to run four virtual server guests on a server host, roughly 6GB to 10GB of memory on the host is necessary. This, of course, depends on the memory requirements of each virtual server guest.