There are many important considerations that should be taken into account prior to moving forward with virtualizing Internet Information Services (IIS). Let’s take a look at a few of them.
Virtual server placement
One of the first considerations involves which host server will be hosting IIS, as well as the hardware resources that are available. Security is also a top concern. To the best of my knowledge, no one has figured out how to perform a hypervisor escape attack, but it’s plausible that such an attack could eventually be developed since IIS is a web-facing application, and your IIS server is directly exposed to the Internet.
If you want to protect your organization from a potential escape attack you should consider placing your IIS server onto a virtualization host that is only used for hosting other web-facing servers. That way if an escape attack does occur, the attacker will only gain access to servers in the perimeter network and not to infrastructure servers on the backend.
Hardware resource consumption
One of the primary concerns with any virtualized environment is usually hardware resource allocation. You need to ensure that your virtualization host is able to provide adequate hardware resources to your IIS server without depriving the hypervisor or other virtual servers of necessary resources. That being the case, I recommend you start out by running the Performance Monitor on your existing Web servers. That way you can get an idea of what hardware resources are currently in use and have a realistic expectation of the resources that will need to be allocated once the server is virtualized.
In any virtual server environment it’s important to take steps to limit the consumption of hardware resources. Doing so not only helps improve performance, but also allows for greater virtual machine density, which improves ROI for your host server. There are a few different things that you can do with IIS to help limit the resources that are being consumed.
One such option is to consolidate your Web servers. IIS does not require you to use a separate server for every website you are hosting. Each website requires a unique URL and unique IP address, but IIS is designed so that you can host many different websites on a single server.
Generally speaking, it’s better to consolidate your websites onto a single server than to use a separate server for each website. By using a single server, you will not have the overhead associated with running multiple copies of the Windows operating system.
If you do decide to consolidate your websites onto a single server, it’s a good idea to create a separate application pool for each site. That way if there is a problem with one website, you won't have to worry about other websites on the server failing as a result.
Another thing that you can do to conserve resources is use a Server Core installation of the operating system. Server Core systems tend to be more secure and perform better than full-blown Windows systems because they have a much smaller footprint. As such, Server Core systems are ideal for virtualization.
A lot of administrators are reluctant to use Server Core with Windows Server 2008 because it lacks the GUI and management tools they are used to. Once Server Core has been initially provisioned, however, it can be managed from the graphical tools on another server. This means it’s possible to manage IIS in basically the same way you are familiar with.
Fault tolerance and load balancing
As you plan to virtualize your IIS server you need to take both fault tolerance and load balancing into account. If you currently have a clustered IIS deployment then you can still virtualize your IIS web servers, but you must be sure not to place each virtualized cluster node onto the same host server. Otherwise, you will end up in a situation where the host server becomes a single point of failure, meaning that if the host server were to fail then every virtual machine running on the host would fail with it.
Therefore, it’s a good idea to cluster your host server even if you haven’t previously operated IIS in a clustered environment. If you are running Microsoft Hyper-V or VMware, it is possible to create a fault-tolerant cluster at the host server level. This prevents the host server from becoming a single point of failure and allows you to take the host server down for maintenance without bringing your virtual servers down in the process.
Network bandwidth considerations
One last consideration that you need to take into account is network bandwidth. Depending on how many virtual machines you have on your host server, it may be impossible to allocate a separate network card to each individual virtual machine. As such, you must consider whether or not your existing network hardware will be able to adequately handle the anticipated amount of traffic.
You should also bear in mind that in a virtual server environment it is sometimes necessary to allocate some of the physical network adapters to the virtualization infrastructure. For example, you will probably have to allocate a network adapter to the host operating system. If you are operating the host server as a part of a cluster then you will also have to allocate one or two network adapters (depending on your configuration) to servicing the cluster.
It may also be possible to allocate multiple network adapters to a single virtual server as a way of improving security and performance. For example, you may wish to use one network adapter for inbound requests from the Internet and a different network adapter to connect to a SQL Server instance on your private network.
As you can see, IIS can function very well in a virtual server environment as long as you deploy IIS in a way that takes security, performance and resource allocation into account.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, is a Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information, visit www.brienposey.com.