SolutionBase: Steps to take to consolidate multiple IIS servers on one platform

As you deploy more and more Web servers in your organization, your management headaches increase as well. Here's how to consolidate multiple Web servers on one server.

As your business grows and you start deploying more and more Web sites in your organization, you may run into the problem of accumulating so many Web sites that hosting them all becomes a problem. Eventually it gets to the point that you wind up spending a ridiculous amount of money on hardware and on Windows Server licenses for those Web sites. That's when it's time to bite the bullet and start consolidating multiple Web sites into a single server. In the sections below, I'll explain how I performed the migrations in a multiple- Web-site environment and how I coped with the various challenges consolidation presented.

Disk space

One of the very first issues that I needed to address was where I would place the code for each Web site. As you may know, when you set up a Web site in IIS, you must tell IIS the name of the folder containing the Web site's files, and you must also specify the name of the default file. This means that I theoretically could have simply created a bunch of folders with unique names on my consolidation server, copied the Web site code to the appropriate folder, pointed IIS to the folders, and been done with it. In reality, though, this isn't always the best course of action.

The first major flaw to this approach is assuming that each Web site resides within a single folder. Many of my Web sites use databases, which I like to keep isolated from the rest of the site. Don't get me wrong, though. It's a common practice to create a series of subfolders beneath the primary folder. By doing so, you can use one of the subfolders for the site's HTML and ASP code, another folder for the databases, and a third folder for the site's logs. The reason for dividing sites up like this is because typically those who visit your site will need read/write permissions to the database, but read-only permissions to the site's actual code. You can build a fairly secure Web site by using multiple subfolders and assigning each subfolder the appropriate permissions at the NTFS level.

Personally, though, I prefer to store the site's databases on an entirely different drive. This accomplishes a few different things. First, it makes the site just a little bit more secure because the path to the database is neither obvious nor easily accessible from outside the Web application. Second, having the database on a separate volume allows you to place the databases on a high-performance drive if necessary.

Server downtime

Another consideration is how long the site will be unavailable during the move to the new server. If your entire business depends on the Web site, then you would probably prefer that there were no period of unavailability.

To be perfectly honest, when I performed my migration, I simply took the site down, copied my data to the predetermined location, and brought the site back up. Having my Web sites available is important to me, but because I have a high-speed network link between the old and new servers, I wasn't too concerned with the server being down while the data was migrated. It took less than five minutes to migrate each Web site.

In my situation, five minutes of downtime is no big deal, but I know that this kind of downtime is unacceptable for some. There are ways of substantially decreasing the downtime during the migration, however. One way of doing so is to have your Web site stored on a LUN on a storage area network. That way, if you want to switch the site to a different server, you can simply reassign the LUN and then make the necessary adjustments within IIS and be back online very quickly.

In some situations it might also be possible to join the new server to the old server as a cluster and then remove the old server so that the Web site is running on the new server. This is a zero-downtime way of accomplishing the migration, but it tends to be complex and isn't always feasible.

IIS consolidation basics

Now that I've discussed the physical migration, I want go over some of the migration basics from an IIS standpoint. After I show you the basics, I'll explain some of the more advanced techniques for safely running multiple Web sites on a single server.

As I'm sure you're aware, each Web site requires at least one unique IP address. What some people don't realize is that you can assign multiple IP addresses to a single NIC. After doing so, you can bind an IP address to each Web site.

One common problem with IIS migrations is that you can only have one instance of each IP address running on your network at a time. I've seen a lot of people copy the necessary files over to the new server, take the old server offline, then assign the old server's IP address to the new server and bring the site back up on the new server.

This technique does work, but if you are worried about downtime, this isn't the most efficient way of getting the job done. A better solution is to get the new server set up ahead of time, but to use a different set of IP addresses than are currently in use. This saves time because you won't have to set up IIS after copying all of the site's files. Instead, you can just change a DNS entry to point the site's visitors to the new location.

To assign multiple IP addresses to your server's NIC, right-click My Network Places and select the Properties command from the resulting shortcut menu. This will cause Windows to display all of the server's network connections. Right-click the connection that will be used to access the various Web sites from the Internet, and then select the Properties command from the resulting shortcut menu.

This will cause Windows to reveal the connection's properties sheet. Select Internet Protocol (TCP/IP) from the list of components on the properties sheet's General tab and click the Properties button to reveal the TCP/IP properties sheet. Finally, click the Advanced button to reveal the Advanced TCP/IP Settings properties sheet. As you can see in Figure A, the IP Settings tab allows you to assign multiple IP addresses to the NIC.

Figure A

You can assign multiple IP addresses to a NIC.

Once the new server has been assigned the necessary IP addresses, the next step is to set up the Web sites on it. I won't bore you with all of the gory details, because the process isn't much different from setting up any other site on IIS. To get the ball rolling, you'd simply open the Internet Services Manager, right-click the Web Sites container, and choose the New | Web site commands from the resulting shortcut menus. Then you'd just follow the prompts to set up the new Web site.

The process differs a bit, though, in configuring the site. The Web site configuration wizard will prompt you for everything that you need. One of the most important things that the wizard will prompt you for is the site's IP address. The default selection is All - Unassigned. However, you can use the dropdown list to select one of the IP addresses that you assigned to the server earlier, as shown in Figure B. The wizard's other prompts simply relate to the site's name, location, and permissions.

Figure B

Select one of the IP addresses that you assigned to the server earlier.

Performance and stability

So far I have shown you the minimum steps necessary to be able to migrate IIS from a stand-alone server onto a server that will host multiple Web sites. Getting the site up and running on the new server is one thing; getting the site to be stable and perform well is a completely different matter, though. After all, you don't want any of the Web sites on the server to cause performance or stability issues for the other sites on your server.

The first thing that you should do to help the server to perform adequately is to limit the bandwidth and the maximum number of connections of each site on the server to an acceptable level. To do so, open Internet Services Manager, right-click on the site that you want to modify, and select the Properties command from the resulting shortcut menu. When you do, you will see the site's properties sheet. Select the Performance tab and you will be able to limit the amount of bandwidth available to the site and the maximum number of simultaneous connections.

If the total number of Web sites hosted by the server isn't constantly changing, I recommend dividing the total available bandwidth by the number of sites hosted by the server and assigning that amount of bandwidth to each site. For example, if you have 1,000 kilobits of bandwidth available and you are hosting five sites, then you might give each site 200 kilobits of bandwidth. Of course, this technique isn't always practical because some sites get a lot more traffic than others. I suggest you use this formula to determine the average available bandwidth per site and then make adjustments by how much traffic each site typically receives.

Another thing that you can do to help guarantee performance and stability is to use application pools. Unfortunately, space limitations prevent me from giving a comprehensive discussion of application pools. You can find out more about application pools by reading the article "Stabilize Web servers by using application pools."

The main idea behind application pools is that one or more Web sites can be assigned to each one. Each application pool uses a separate set of resources. Therefore, if you have a Web site that consumes a lot of memory, it could potentially drain the application pool of all available memory, but it won't drain IIS or Windows of all available memory. Only the sites running within that application pool will be affected, and there is no reason why you can't create a separate application pool for each Web site.

Application pools are also helpful because they improve the overall stability of IIS. If a Web site were to cause a major crash, the crash could potentially knock the application pool offline, but no other application pools (or the Web sites running within them) would be affected. To make application pools even more stable, Microsoft has designed them to be recycled at specific intervals. Recycling an application pool is similar to rebooting a Web site, but takes only a fraction of a second. As you can see in Figure C, application pools can be recycled after a specific number of minutes or requests, or at predetermined times. Figure C also shows how you can limit the amount of memory and virtual memory used by an application pool.

Figure C

Application pools can be assigned specific resources and can be regularly recycled.

Memory isn't the only system resource that you can control at the application-pool level. The Performance tab allows you to monitor the application pool's CPU usage. You can specify the percentage of total CPU resources the application pool is allowed to use. You can even specify an action to take if this threshold value is exceeded.

Creating a new application pool is as simple as right-clicking on the Application Pools container in the Internet Services Manager and selecting the New | Application Pool commands from the shortcut. After creating an application pool, you can modify its threshold values by right-clicking on it and selecting the Properties command from the resulting shortcut menu. When you're done creating and configuring an application pool, the last step is to assign the application pool to one or more Web sites. This is done by right-clicking on a Web site, selecting the Properties command from the resulting shortcut menu, and then selecting the application pool from the dropdown list found on the Home Directory tab of the Web site's properties sheet.

Migration checklist

In this article, I have gone over a lot of different techniques with you. For the sake of clarity and to provide background information, though, not everything that I have shown you was presented in the order that you would use in performing a real-world server consolidation. Here is a list of the basic steps that you would use to migrate a Web site from one server to another. Simply repeat these steps for each additional Web site that you wish to migrate.

  1. Determine the location where you will place Web site and database files on the new server. You will want to make sure that the chosen location provides adequate performance and security. Don't move the files just yet, but go ahead and create the necessary folders and set the NTFS-level permissions.
  2. Determine how many sites the server will host. Pick a new IP address (that isn't already in use) for each site. Configure the server to use the new IP addresses.
  3. Use the Internet Services Manager to create the new Web sites. Point each new site at the empty folders that you created earlier. Assign each site to use the appropriate IP address and the appropriate set of IIS-level permissions.
  4. Create a dedicated application pool for each Web site and configure the application pool to match the desired level of performance.
  5. Use the Internet Services Manager to assign each Web site to the appropriate application pool. While you're at it, adjust each site's maximum bandwidth and maximum number of simultaneous connections.
  6. Shut down each site on the old server.
  7. Copy all Web site code and databases from the old server to the new server.
  8. Adjust your DNS server to point to the new IP address that has been assigned to each Web site. If the server exists in a DMZ, you might have to adjust your firewall as well.
  9. Test the Web sites to verify accessibility and functionality.