As organizations continue to move away from the use of physical servers, a frequent question arises: Is it a good idea to virtualize WSUS servers? Short answer: yes. Read on to find out how to run WSUS in a Hyper-V machine.
Will WSUS run in a virtual machine?
In a word, yes. If you plan on hosting a WSUS virtual machine on Hyper-V, it is generally recommended that you run WSUS on top of the Windows Server 2008 R2 operating system. In order to do that, you will have to deploy WSUS 3 SP2. Until SP2, WSUS did not work properly with Windows Server 2008 R2, and it did not support the management of Windows 7 clients.
What is the easiest way to virtualize a WSUS server?
If you are currently running WSUS 3 on a physical server then I would recommend doing a migration upgrade. To do so, set up a virtualized WSUS server and then configure it to be a replica of your physical WSUS server and then perform synchronization. Once the sync process completes reconfigure the virtual WSUS server to be autonomous. Then, you can decommission your physical WSUS server.
This technique offers two main advantages. First, it makes it easy to upgrade the WSUS server’s operating system if necessary. The other advantage is that this method offers far less down time than a standard P2V conversion because your physical WSUS server continues to service users while your virtual WSUS server is being put into place.
What kind of capacity can I get from a virtualized WSUS server?
A single WSUS server should be able to handle up to 25,000 clients. However, this assumes that sufficient resources have been provisioned and that SQL Server is running on a separate server (physical or virtual). Some organizations have been able to achieve higher capacities by using multiple front-end servers.
What are the options for making WSUS fault-tolerant?
In a physical server environment, WSUS is made fault-tolerant by eliminating any single points of failure. Normally you would create a Network Load Balancing (NLB) cluster to provide high availability for your WSUS servers. Of course WSUS is dependent on SQL Server and the preferred method for making SQL Server fault-tolerant is to build a failover SQL Server cluster.
While it is possible to recreate this high-availability architecture in a Hyper-V infrastructure, it is usually considered to be a better practice to build a Hyper-V cluster instead. If your host servers are clustered then clustering your WSUS servers and your SQL servers becomes unnecessary (at least from a fault tolerance standpoint).
If Hyper-V hosts are not clustered (and building a Hyper-V cluster is not an option for whatever reason) then I would recommend going ahead and creating a clustered architecture for the virtualized WSUS and SQL servers. However, you should make sure not to place multiple WSUS or SQL servers onto a common Hyper-V server because doing so will undermine the benefits of clustering WSUS and SQL Server.
What do I need in terms of network bandwidth?
There are no predetermined rules for providing network bandwidth to a virtualized WSUS server. Keep in mind, however, that there are a number of different issues that can occur as a result of insufficient bandwidth. If at all possible, I would recommend dedicating a physical network adapter to your virtual WSUS server. If you are forced to share a network adapter across multiple virtual servers then use network monitoring tools to verify that the physical network connection isn’t saturated.
If saturation becomes an issue, remember that WSUS can be throttled either at the server itself or at the client level through the use of group policy settings. You can find client throttling policies in the Group Policy Object Editor at Computer Configuration> Administrative Templates > Network > Background Intelligent Transfer Service.
Are there any special considerations for the SQL database?
It is generally recommended to run SQL Server on a separate machine (physical or virtual) so that you can allocate resources directly to the database server. I also recommend running the Cleanup Wizard and defragmenting the database every couple of months. Doing so will help the database to run optimally, which is important in a virtualized environment.
Another thing to keep in mind is that SQL Servers tend to be I/O intensive. Therefore, if you are planning to virtualize your SQL server then you might consider using dedicated physical storage so that the I/O load generated by SQL does not impact other virtual machines.
Filed under: TUTORIALS
