iManager and Windows 2003 NLB (Network Load Balancing)
Novell Cool Solutions: Feature
By Michel Bluteau
Digg This -
Posted: 19 Jan 2005
iManager and Windows 2003 NLB (Network Load Balancing)
This article covers some experimentation I have done with iManager 2.02, eDirectory 8.73, and Nsure Identity Manager 2.01, on a Windows 2003 platform. More specifically, it deals with the high-availability/clustering feature included in Windows 2003, known as Network Load Balancing, or NLB.
Here is a short list of questions I wanted to answer regarding iManager and NLB:
- Is iManager compatible with NLB?
- Out of the 3 modes of operation for NLB, Affinity None, Affinity Single, and Affinity Class C, which ones are supported by iManager?
- What happens in a failover scenario when a user has an active session against iManager?
Here is the configuration I was using, leveraging 3 servers, actually 3 Vmware virtual machines, with only one physical network adapter, all running on the same host:
- Win2003DC: Windows 2003 Server Domain Controler
- Win2003A: Windows 2003 Server, member of the domain, with IIS(Internet Information Server), NLB, and running eDirectory 8.7.3, Nsure Identity Manager 2.01, and iManager 2.02(with IIS and Tomcat)
- Win2003B: Windows 2003 Server, member of the domain, with IIS(Internet Information Server), NLB, and running eDirectory 8.7.3, Nsure Identity Manager 2.01, and iManager 2.02(with IIS and Tomcat)
NLB is part of Windows 2003 Server, and a Console is available for setting up and managing NLB:
Figure 1: Network Load Balancing Manager
Because I was using a very simplified hardware configuration, with Vmware and just one physical machine and one physical NIC, NLB Manager was not the tool I used for setting up my NLB cluster. In the Microsoft documentation for NLB, it mentions that NLB Manager cannot be used in that kind of scenario. The alternative is simply to use the Network Control Panel, from which a NLB cluster can be put together in minutes:
Figure 2: Network Connections Control Panel
Figure 3: Network Load Balancing Properties
When configuring the NLB Cluster from the Network Control Panel, you must set the same Cluster IP address for each member of the cluster (Win2003A and Win2003B in my example) in the clustered application (iManager, which is 192.168.1.33 in my example). You must also provide the same full Internet name for all members of the NLB cluster. In my example of cluster.novl.ca, novl.ca is my Windows 2003 Active Directory domain.
NLB requires the presence of a Windows 2003 AD domain in order to store the configuration for the cluster. Every time a NLB cluster member points to the same cluster configuration (cluster.novl.ca), it automatically receives the same Network address. This is like a virtual MAC address that is used by the cluster for load balancing requests (for iManager in our example) between the cluster members. It is also used to handle failover.
Multicast has been selected here because we have only one physical NIC per cluster member, and without a second NIC, servers wouldn't be able to see each other and communicate. Refer to Microsoft online documentation for NLB.
Figure 4: Host Parameters configuration for Win2003A
Each member of the NLB cluster must have its own identity and Host Parameters. For example, for Win2003A I used an IP address of 192.168.2.25, on a different subnet from the cluster IP address. A unique priority for each NLB cluster member needs to be selected manually, so I left the default of 1 for Win2003A, but used 2 for Win2003B (see below).
Figure 5: Host Parameters for Win2003B
Figure 6: Port Rules
Figure 7: Port Rule details
It is possible for NLB to setup a single port rule for all clustered applications, or select multiple port rules for each application, by limiting the scope for the rule through the IP address and/or port range. For each rule, one can select if the rule applies to TCP, UDP or both. And also, the type of NLB clustering used, identified by the Filtering mode, for which the 3 options for Multiple host are Affinity None, Affinity Single, and Affinity Class C. A definition for each mode can be found through context sensitive help, or the on-line documentation.
If we go back to the three questions posed at the beginning of the article, through the test environment described above, I was able to provide the following answers:
1. Is iManager compatible with NLB?
Answer: Yes, iManager is compatible with NLB. NLB is specifically designed to handle HTTP/s applications, so iManager does not require anything special in order to work with NLB.
2. Of the three modes of operation for NLB, Affinity None, Affinity Single, and Affinity Class C, which ones are supported by iManager?
Answer: Affinity none is not supported, since iManager sessions are machine-specific. A session cannot be transported from one machine running iManager to another, and an iManager session cannot occur against multiple instances of iManager simultaneously (multi-threading). So if the mode is set to Affinity None, iManager does not work properly. However, if Affinity is set to Single or Class C, iManager works just fine.
3. What happens in a failover scenario when a user has an active session against iManager?
Answer: If a user happens to have an active iManager session on a server that is part of a NLB cluster, and that server fails, then the connection for the user is transitioned (failover) in a transparent and rapid fashion to another member of the cluster running iManager. However, since the session cannot be transported, the user is returned to the iManager login page:
Figure 8: iManager login page accessed through the shared Cluster IP address (192.168.1.33) and not the Host dedicated address
Since a transaction in iManager is a short operation, such as creating or modifying a user object, an incomplete transaction is lost throught the failover process, and must be re-started from the beginning by the user. The cost to the user is measured in terms of minutes in a worst- case scenario, since iManager transactions are short by nature. When the iManager server where the user was performing a transaction becomes unavailable, the incomplete transaction/form is replaced by the iManager login page (see figure 8). So the iManager service is not interrupted, but the incomplete transaction is lost.
iManager and Windows 2003 NLB (Network Load Balancing) are compatible. The combination of the two can provide a robust and redundant solution that prevents interruption of services, while also distributing the load on two or more instances of iManager for iManager connection requests. Setting up iManager and NLB is a quick and easy task through the Network Control Panel. The only limitation is that the mode Affinity None is not supported by iManager, which prevents multithreading of individual sessions against multiple iManager servers, and the failover of an active session/transaction in case of a server failure.
You can submit questions and comments, or provide feedback to me regarding this article, through my e-mail address: mbluteauTAKETHISOUT@novell.com
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com