I have a moment to get the final post of this series finished (see my author page for parts 1-5). We went through the basic process of creating Windows Failover Clusters and adding SQL or other Generic Services to a Windows Failover Cluster. Everything that we did in the series so far was done in a lab environment as it was being written, and all of the screenshots have been from those exercises.
This final installment will be no different. Everything presented in this installment is out of the lab and has been built just as it is described. The Windows Failover Cluster is useful for protecting more dynamic forms of data, like SQL or email applications, but there is another type of cluster available in Windows which is more suitable for static forms of data like web services. That is the Network Load Balancing (NLB) cluster. The Failover Cluster will allow the completion of unfinished transactions if a node fails and a different node takes over. NLB does not behave this way. NLB is intended to distribute the load across multiple servers. One thing you will notice about the NLB setup as you run through this blog is that there is no requirement for shared storage. Therefore, the NLB cluster nodes need to be set up the same way, and the setup should remain static. If there was changing data housed on the nodes there would be no fault tolerance since there is no shared storage to handle fail over.
People cluster web front ends in different ways, and many people use dedicated hardware devices such as Kemp’s LoadMaster, F5’s Big-IP, or Cisco’s CSS/ACE devices. A network engineer should determine the suitability of the load balancing methods of each device as it pertains to the application/web service you are working with, and I can’t claim to be an expert in this area.
This blog will outline how to install the Microsoft Network Load Balancing feature in Windows Server 2012. The machine names for the nodes in this cluster will be NLBNODE1 and NLBNODE2, with a Network Load Balancing name of NLBCL.
The prospective NLB nodes must be configured as follows:
- All nodes must be on the same subnet
- All network adapters must use the same mode, multicast or unicast
- If using unicast network adapters must support changes to their MAC addresses
- Network adapters must be configured to use TCP/IP exclusively. No other protocols can be added.
- IP addresses assigned to the network adapters must be static. DHCP is not supported.
Now we can begin testing. The URL https://nlbcl/cltest was entered in a browser and the page came up as expected, showing the name of the cluster node that is serving the content.
I closed the browser several times, but it just kept hitting the same cluster node, NLBNODE2. If you review the settings that we made while configuring the cluster there was a setting on the Port Rules screen named Affinity. It is set to Single by default, and we selected the default settings on the page.
Single Affinity directs subsequent requests from the same host to the same cluster node. This is the setting that must be used when applications need to maintain user state information, such as when your cluster nodes are hosting HTTPS traffic. If your application is stateless then you can use the Affinity setting of None. This will allow the cluster to randomly select the node that will serve the content.
Right click the cluster name in the NLB Manager console and select Cluster Properties from the context menu. In the cluster properties dialog select the Port Rules tab, select the rule that was created when you set up the cluster, and click Edit. Here you can select None from the Multiple Host frame of the Filtering section. Save your changes and try accessing the page multiple times as we did before. Now you should notice that you are directed randomly to different nodes.
That is the basic setup of a Microsoft NLB cluster. As I said at the beginning, NLB clusters are not used for applications that handle dynamic data like database transactions or email. The Failover Clusters that we looked at earlier are better suited to those types of applications. The NLB cluster is meant for web based content that is more static in nature.
I hope that this series has been helpful to someone out there. I wanted to try to collect information and present it in one place. I thought that might make it easier for people to start with some clustering exercises to see how the technology might work in their environments.
Until next time, happy trails to you all 🙂