The pros and cons of server virtualization

ISPs use server virtualization to share one physical server with multiple customers in a way that gives the illusion that each customer has its own dedicated server. Typically, an ISP will use server virtualization for IIS (Internet Information Server) and/or Microsoft Exchange Server. I've also seen administrators use server virtualization on a file and print server, but this isn’t nearly as common. Server virtualization on an IIS Server allows that server to host multiple Web sites, while employing it on an Exchange Server allows the server to manage e-mail for several companies. Let's look at the advantages and disadvantages to a virtualized ISP environment.

The money issue
Without a doubt, the greatest advantage of server virtualization is cost. For example, suppose that an ISP purchased a high-end server for $30,000. In addition, it needs an operating system for the server. A copy of Windows Server 2003 Enterprise Edition goes for about $8,000. Add in other components and the ISP could easily drop over $40,000 on a single server. Can you imagine if the server could only host a single Web site? The cost to the subscriber would be astronomical. On top of having to recoup a $40,000-plus investment in hardware, the ISP must also pay for bandwidth, salaries, building rental, and other business expenses before it can start turning a profit.

Although there are large companies such as Microsoft and Amazon that require multiple, dedicated Web servers, most of the time Web sites are small enough that quite a few sites can be hosted on a single server. This allows the ISP’s clients to share the hosting expense, driving down the price considerably.

Developing
Server virtualization is also great for development environments. An example is my own personal network. I own three Web sites, and have done every bit of the coding for these sites myself. To assist in the development process, I'm using a virtualized IIS Server.

My development server is a single computer running Windows 2000 Advanced Server and IIS. The server has been assigned seven IP addresses, each corresponding to one of seven sites. The first three sites are the production versions of my Web sites. Although I don’t actually host the sites from this server, I like to maintain a known good copy of each of my sites locally. The next three sites on the server are also copies of my three Web sites, but these are used for development. Every time I make a change to one of my sites, I make the change in this location. This allows me to test my changes without tampering with a production version of the site. The last site that the server hosts is for a new Web site that I'm working on that won’t go into production until the end of the year.

Problems with server virtualization
You must also watch out for pitfalls in server virtualization: scalability and security.

Scalability
Often, the terms scalability and availability are intertwined when people talk about networking. Both terms are relevant to server virtualization. Availability becomes an issue because if the virtualized server were to go offline, every site that the server is hosting will also fail. Most ISPs use a cluster or some other failover technique to prevent such outages.

Scalability is trickier. As I said, server virtualization provides a way for several small companies to share the costs associated with Web hosting. The problem is that while a company may start out small, it could grow quite large. A large company can easily dominate a virtualized server and begin robbing resources from the other sites.

For example, I own an e-commerce site that sells software. When I launched the site, it received very little traffic and wasn’t consuming much disk space. But now the site is getting thousands of visitors every day. On average, a couple of hundred people a day are downloading trial software, and the smallest download on the site is 15 MB. If 200 people are downloading a 15-MB file, there are almost 3 GB in transfers occurring everyday.

Additionally, the site is designed so that when someone purchases software, the site creates a directory with a unique name and places the software into that directory. The idea is that the users can’t use the download location to figure out the path for downloading software that they haven't paid for. These temporary directories are stored for seven days.

The problem is that the more software I sell, the more temporary directories are created. Each of these directories contains anywhere from 15 MB to a couple of GB of data. I actually received a phone call from my ISP recently because I was consuming too much disk space and bandwidth. The ISP was using server virtualization and I was taking resources from other customers.

Obviously, Windows does provide mechanisms that you can use to minimize the effect of excessive use. For example, you could place disk quotas on each site, and you could use QoS to limit bandwidth consumption. However, these are issues that you need to consider before implementing your server, not after it begins to run low on resources.

Security
The virtualization process is designed to keep virtualized resources separate. I've seen a couple of cases, though, in which a virtualized server was accidentally visible to someone who wasn’t supposed to be able to see it. The unauthorized access problem happened a few months ago to one of my Web sites. My ISP uses the directory structure CUSTOMERScustomer name to store each individual Web site. When you're in the Customers directory, you're supposed to see only Web sites that you own. However, one Sunday morning I was about to update one of my Web sites and I was able to see someone else’s site. Apparently, a permission entry had been set incorrectly. I made a quick phone call to my ISP and the permission was changed before any security breaches occurred.

Be careful with bleed over
Finally, bleed over is another issue to watch out for when subscribing to a virtualized server. Bleed over occurs when the contents of one virtual server affect other virtual servers. One of my Web sites has a chat room where I occasionally host live discussions with people in the IT industry. During the middle of a recent live chat, everyone involved in the chat received a pop-up window saying that the total bandwidth allocation had been exceeded. Everyone was booted out of the chat.

Needless to say, this was very embarrassing. I called my ISP and asked why this happened when I'd never experienced chat problems in the past. As it turns out, my ISP was not limiting bandwidth consumption. Instead, another site hosted on the same server had implemented a shareware bandwidth limitation program. Unfortunately, this utility limited bandwidth for the server as a whole, not just for the intended site. The ISP removed this component and the server returned to normal behavior.

TechRepublic originally published this article on 4 August 2003.