IIS – Notes on Site Load Balancing Across Servers Using DFSR and IIS Shared Configuration

I think I have put together a pretty good solution for load balancing websites across multiple instances of IIS 8.5. I am sure my ideas aren’t novel but I am documenting them here for future reference. This isn’t meant to be a full walkthrough but rather it is me keeping notes for personal use and may be a useful springboard for admins with similar needs.

A Quick Introduction to DFSR
DFSR (Distributed File System Replication) is a Role/Feature built into Windows Server – it can be used to keep folders in-sync across multiple servers. Caveats such as replication latency mean that it might not be ideal for all use cases. DFSR is based more or less on the same technology that replicates active directory information between domain controllers. DFSR does “block level replication” which means changes made to files on one end don’t require the entire file to be re-replicated but rather just the changes. This is extremely useful if you are dealing with large “non-static” files. DFSR, I think, was introduce circa Server 2003 so it has been around for quite a while, it just wasn’t something that had really been on my radar until very recently.

Requirements:

1. Load Balance a web application across two servers running Server 2012 R2 and IIS 8.5

2. Web Application dynamically generates locally stored files that need to be accessible to a user regardless of which server they are connected to.

3. Load balancing will be handled by a dedicated appliance sitting near the edge of the network

Solution/Notes:

1. IIS Shared Configuration can be used in conjunction with DFSR to keep IIS in-sync/identical across servers.

2. DFSR requires a domain.

3. DFSR will be used to sync the wwwroot folder between the two IIS servers in addition to one extra folder outside of the inetpub root folder which will hold the IIS Shared Configuration files.

4. In my particular situation, the load balancer can terminate SSL connections; if future scenarios don’t allow for this, SSL must be terminated on each IIS server which means the SSL certificates must be installed on each server independently or a shared SSL store must be setup. My preference is to install the SSL certificates separately because a shared store could potentially lead to another single point of failure.

DFSR is actually stupid-simple to setup for any competent windows server admin and simple instructions for getting started can be found here: http://www.techunboxed.com/2014/07/how-to-set-up-dfs-replication-in.html

This piece on DFSR explains some common pitfalls and made me realized I probably needed a larger Staging Area Quota among other things: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx

It is important that both servers be identically configured (aside from the obvious differences like IP addresses and server names) before implementing IIS Shared Configuration – which should probably be the last step in the process. So getting DFSR setup for the web application directory first is an important item to note.

This article was by far the most helpful on getting IIS Shared Configuration going: http://blogs.iis.net/rickbarber/keeping-multiple-iis-7-servers-in-sync-with-shared-configuration

I also found this technet article very helpful in providing a bit more specific instruction on setting up IIS shared configuration: https://technet.microsoft.com/en-us/library/cc771871%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

If you are doing SSL, you need to also have the SSL Central Store Feature installed before setting up IIS Shared Configuration – otherwise you will get errors during setup to the tune of “Object reference not set to the instance of an object”. That tidbit was found here: http://blogs.msdn.com/b/sroun/archive/2014/07/25/fixing-quot-object-reference-not-set-to-an-instance-of-an-object-quot-when-using-shared-configuration-in-iis8-x.aspx

I was a bit confused at first by how unique site IP bindings can work in an IIS shared config scenario. This discussion was incredibly helpful: http://forums.iis.net/t/1123439.aspx?How+to+do+IP+bindings+with+Shared+Configuration Simply put, the shared configuration will include all IP bindings for all servers and IIS will simply ignore non-existent IP’s in the config on the server it is running on.

If DFSR seems to be taking an inordinately long time to start replicating something might be broken or their might be some lag in the configuration replicating to all servers. Long story short, check the DFS Replication error log in Event Viewer. There are some powershell commands you can run to speed things up… For impatient folks like me, this article is extremely helpful (also for troubleshooting): http://social.technet.microsoft.com/wiki/contents/articles/1205.dfsr-event-5012-dfs-replication.aspx

That about covers it. I really didn’t feel like documenting my exact experience but all of the above should be enough to give most admins the ‘gist of what needs to be done.

The Result:
Two IIS servers which basically maintain an identical deployment of a web application. Any changes made to the IIS configuration of one server almost instantly occur on the other server, any changes to application folder in wwwroot also sync very quickly. A perfect setup for load-balancing that should require minimal manual intervention/administration overhead in the long term.

I will note that I was on a network with full-speed gigabit interconnects between the servers and dealing with ~5 GB of data. Your mileage and experience may vary. The beautiful thing is that your devs can more or less continue to deploy their applications as usual with little thought given to the load balancing.

Now that I am familiar with DFS and how easy it is to setup folder replication I have a lot of thoughts around other usage.