Microsoft Dynamics CRM 2013 Load Balancing

I was recently asked if something would work in a load balanced Dynamics CRM 2013 SP1 environment as part of the work that I do at TSG. So I thought I would set up an environment to test.

 

Of course high availability doesn’t just sit with two clustered CRM nodes, but with a clustered “Always On” SQL Server set up as well. The advantage of clustered servers is that you can take one node offline to install updates or other maintenance tasks.

 

What options do we have?

There are a number of different load balancers and ways to load balance, but the simplest is to use NLB. So what is NLB? Well NLB stands for Network Load Balancing, and something I first came across with Windows NT 4 back in 1998.

 

So how do we set NLB up with Dynamics CRM 2013?

To start off with we use Hyper-V, there are other options, but I find it a lot easier to use Hyper-V for mini virtual networks, plus it comes as standard on Windows 8.1 so why wouldn’t you use it?

 

We create a core Active Directory Server, we add SQL Server 2012 to the core virtual machine. Normally you wouldn’t install SQL Server on an Active Directory Domain Controller, but, we are trying to work smarter not harder and as this is just a test it makes sense to keep the number of virtual machines down. We then need two Base Windows Servers to put NLB on and to install CRM 2013. We can use our host as workstation to test out the cluster.

 

First we need to create a Virtual Switch by going to Hyper-V manager, and clicking on Virtual Switch Manager, and click on the Create Virtual switch.

 

We create the switch connected to the external network interface on the host machine.

 

Next we create three virtual machines, by clicking on New > Virtual Machine.

 

The exact hardware settings and location etc. will depend on your Hyper-V host, but generally I find the following a good set up for each server role:

 

Of course you do need a virtual host that can handle this, but a decent laptop with 32Gb RAM isn’t that expensive now.

 

Note: We could add two external network cards to each of the Cluster Nodes, and in some cases this would be the preferred option, but as we creating a simple cluster we will just use one network card in each.

 

On to each of the server roles you would install Windows Server 2012 R2, and give each virtual machine an appropriate computer name and an IP address, say as follows:

 

You can choose whatever IP range you like here, the key thing is that you have the DNS of the servers set to the Core AD Server, and that you have a unique Cluster IP on the same range. You also need to make sure you have internet connectivity for installing CRM in case you’ve missed some of the prerequisites! :)

 

Next we promote the Core AD Server to be a domain controller, by adding the Active Directory Domain Service feature through Server Manager, and using the promote server wizard after the installation has complete.

 

Now we can install SQL Server on the Core AD Server virtual machine. It is Microsoft’s best practice to have separate Data and Log file disk drives, so we would use the 146Gb VHDX drive we created for the SQL Data and the 72Gb VHDX drive for SQL Logs. The reason I chose these sizes was purely that that used to be the typical size of a HP Server Disks, and the ratio is about what you would want.

 

It’s always good practice to have the servers using the Windows firewall. So you would need to create the following firewall rules:

 

Now we add each of the CRM Servers to the AD Domain. Then we add the Application Server, Web Server (IIS) Roles, and the Network Load Balancing Feature to each of the servers.

 

Note: If like me you copy a base virtual machine, then you will need to run Sysprep via C:\Windows\System32\Sysprep\Sysprep.exe with the generalize option. The reason we need to do this, is because each installation of windows has a unique SID and we can’t join a virtual machine with the same SID to domain controller that has the same SID.

I have found the now is a good time to set up NLB, we could install CRM 2013 on Node 1 first, but I always find it best to work from the ground up, and getting the network layer right can save a lot of time later on.

We set up NLB by choosing Network Load Balancing Manager from the Server Manager > Tools Menu. 

  









Then we enter the cluster IP address and click next.

Then we enter the full internet address of the cluster in the Cluster Parameters and select Multicast. 

 

Note: The reason we select Multicast and not Unicast is because we only have one network card. If we selected Unicast we would not be able to see the other Node to add it to the cluster.

 

Finally we click Cluster and then add Host, and follow the steps we have followed previously to add the second node into the cluster. Once done we can see that both nodes says that they are converged and the cluster is now accessible.

 

One little trick that I have used over the years with load balanced clusters, is to create a HTML page with just the name of the current node in it on each of the cluster nodes, e.g. in the Default Site. Then we can browse to the cluster IP address and see which node is currently active, it also allows us to see that when we stop a node the node changes as we hop to the other cluster node.

 

We can now install Microsoft Dynamics CRM 2013 on the CRM Node 1 Application Server as we would do normally. We also need to install the CRM 2013 SSRS Connector on to the SQL Server virtual machine so that the reports run correctly.

 

In my experience it is better to put SSRS on a separate server or on the CRM Applications Server in a production environment, as when we come around to upgrading Microsoft Dynamics to a new version of CRM, we can use the same SQL Server with a different SQL instance, and of course we can only have one SSRS instance installed on a SQL Server. That said, having SSRS on the same server as SQL Server makes it easier to install for testing purposes.

 

As with the Core AD Server virtual machine, the key thing to note is that we also need to create some inbound firewall rules to allow everything to communicate correctly.

Note: Port 808 is needed for SSRS to communicate to the CRM Server Asynchronous and Sandbox Services, for some reporting scenarios.

 

Once we have installed the first node, we need to install the SSRS Data Connector on the Core AD Server as that is the server running SQL and SSRS.

 

Now we can install the second, but instead of creating a new deployment we choose to connect to an existing one. The key thing here is to make sure that the Web Site is on the same port otherwise you’ll find that clustering won’t work.

 

The last and probably most crucial part of the setup is to make CRM aware that it’s running in a clustered NLB environement. So we go to the deployment manager, and right-click properties on Microsoft Dynamics CRM, and change the urls to either the cluster IP address or a more friendly DNS entry which points to the cluster IP address.

 

As with any CRM 2013 installation we must make sure that the SPN’s are set correctly otherwise we won’t be able to access CRM on the cluster url from the CRM nodes themselves. A great blog on setting up SPN’s can be found here or another blog here discusses disabling the loopback check on Windows Servers which can also be useful sometimes.

Obviously this isn’t a definitive step-by-step instructional guide on how to set up a load balanced Dynamics CRM 2013 SP1 environment, but should give you a good understanding of the key elements and best practices.

 

I hope you found this blog useful!
 

@simonjen1