Back in August 2003 an AppNote1 was written about Virtual IP address support in NetWare. Part of the AppNote contained information on deploying Virtual IP in a Novell Business Continuity Cluster on NetWare. While the AppNote contains great information, the section on deploying Virtual IP in a Novell Business Continuity Cluster environment is not as accurate as it should have been (my apologies since I wrote that section). This short article is meant to remedy that situation and provide accurate and correct information.
The Business Case
With the amount of mission critical information being stored electronically, businesses can no longer afford to lose access to their data. Doing so could lead to the failure of their business. Because of this, many IT managers are being required to implement a disaster recovery solution. Using Novell Cluster Services, an IT department can build a highly available disaster recovery solution using commodity hardware. Novell’s Business Continuity Cluster is a group of two or more independent, geographically dispersed clusters. Figure 1 shows the essentials of a Business Continuity Cluster.
Figure 1: Business Continuity Cluster
As an example, consider a fictitious company called Acme Data Services. Because of the mission critical nature of Acme’s data, they have chosen to build a disaster recovery solution using a Novell Business Continuity Cluster. The primary cluster and data center is in New York, while the secondary cluster and data center is in New Jersey. As the figure shows, the data is replicated between the two data centers using the SAN hardware. Furthermore, clients have connectivity to all the nodes in both clusters. In the unfortunate event that some form of disaster destroys Acme’s primary data center in New York, services can quickly and easily be restarted on the cluster nodes in the secondary location in New Jersey.
In any network environment one of the first obstacles that must be tackled is how clients resolve and connect to the services. Business Continuity Clustering exacerbates this problem because services can migrate to nodes in a completely different network segment. While there are many potential solutions to this problem, such as DNS and SLP, none of them offer the simplicity and elegance of Virtual IP Addresses. With Virtual IP Addresses, the IP address of the service can follow the service from node to node in a single cluster as well as from node to node in separate, distinct clusters. This makes client reconnection trivial – the client only has to wait for the new route information to be propagated to the routers on the network. There are no manual steps required, such as modifying a DNS server.
Deploying Virtual IP in a Business Continuity Cluster
To use a Virtual IP Address in a Business Continuity Cluster, the use of a host mask is recommended. To see why this is, consider the fact that each service in a clustered environment must have its own unique IP address, or in this case, a unique Virtual IP Address. Furthermore, consider that each Virtual IP Address belongs to a Virtual IP Network, whose route is being advertised by a single node within a cluster. Since Novell Cluster Services can migrate a service, and therefore the service’s Virtual IP Address, from one node to another, it follows that the Virtual IP Network must migrate to the same node as the service. If multiple Virtual IP Addresses belong to a given Virtual IP Network, then one of two events must occur: 1) all services associated with the Virtual IP Addresses on a given Virtual IP Network must failover together, and 2) the Virtual IP Addresses on a given Virtual IP Network must go unused, thereby wasting a portion of the available address space. Neither of these situations is desirable. Fortunately host masks remedy both.
As stated earlier in this article, the routers in a Virtual IP configuration must be running the RIP I or RIP II protocols. For a Business Continuity Cluster, RIP II is the preferred protocol and should be used whenever possible. In NetWare, this can be accomplished by configuring the NetWare RIP Bind Options to use RIPI & RIPII or RIPII only. Also, the command SET RIP2 AGGREGATION OVERRIDE=ON must be added to the autoexec.ncf file of any NetWare routers in this configuration.
Once the appropriate Virtual IP Addresses and host masks have been determined Virtual IP Addresses can be enabled in a Business Continuity Cluster via a four step process. First, the autoexec.ncf file on each node in both clusters must be modified. The following two lines should be added to the autoexec.ncf file.
LOAD VNIC NAME=VNIC SET RIP2 AGGREGATION OVERRIDE=ON
The first line loads the Virtual Driver and creates a Virtual Board named VNIC. The second line disables RIP2 route aggregation on the cluster nodes.
Second, the command to bind a Virtual IP Address for the service must be added to the cluster resource load script. The following is an example of a cluster resource load script for a standard NetWare volume called Homes. This example uses host masks and assumes the Virtual Board has been named VNIC. Notice the usual command to add a secondary IP address has been replaced with the BIND IP VNIC Mask=255.255.255.255 Address=10.1.1.1 command, which binds the Virtual IP Address 10.1.1.1 to the Virtual Board.
nss /poolactivate=HOMES mount HOMES VOLID=254 CLUSTER CVSBIND ADD BCC_HOMES_SERVER 10.1.1.1 NUDP ADD BCC_HOMES_SERVER 10.1.1.1 BIND IP VNIC Mask=255.255.255.255 Address=10.1.1.1
Third, the command to unbind the Virtual IP Address must be added to the cluster resource unload script. The following is the matching cluster resource unload script for the same NetWare volume discussed in the previous paragraph. Notice the default command to delete the secondary IP address has been replaced with the UNBIND IP VNIC Address=10.1.1.1 command, which unbinds the Virtual IP Address 10.1.1.1 from the Virtual Board.
UNBIND IP VNIC Address=10.1.1.1 CLUSTER CVSBIND DEL BCC_HOMES_SERVER 10.1.1.1 NUDP DEL BCC_HOMES_SERVER 10.1.1.1 nss /pooldeactivate=HOMES /overridetype=question
Finally, if the cluster resource happens to be a clustered volume, then the IP address of the resource itself needs to be changed to the Virtual IP Address. This can be done in the usual way using iManager, ConsoleOne, or Novell Remote Manager. This change is not needed for any non-volume cluster resources (e.g. DHCP).
One exciting development since the original August 2003 AppNote is the addition of OSPF as a supported routing protocol in a Virtual IP environment. OSPF support was added to NetWare 6.5 SP6 and later. Contact Novell Technical Support for the utilities needed to manage OSPF in a Virtual IP and Novell Business Continuity Cluster environment.
If you follow the steps in this article, you will have solved the client reconnectivity problem described in the Business Case section of this article. You will have done this in a way that requires no intervention from you as an administrator or from your end users. Now you can sit back and relax and know that your are covered in the event of a disaster.
1The original August 2003 AppNote can be found at https://support.novell.com/techcenter/articles/ana20030803.html
More information on the Novell Business Continuity Cluster can be found at https://www.novell.com/products/businesscontinuity/