Novell is now a part of Micro Focus

Failover for Novell Identity Manager (DirXML) Drivers on Windows

Novell Cool Solutions: Feature
By Michel Bluteau

Digg This - Slashdot This

Posted: 17 Mar 2005

Simple Failover Solution for Nsure Identity Manager (DirXML) Drivers on Windows

Michel Bluteau, Novell

This article describes a simple configuration for the failover of a DirXML driver on Windows 2000/2003, and it compares this configuration with the options available for UNIX and Linux. Also, it briefly discusses more advanced solutions and provides links to other sources of information.

Failover configuration for Windows 2000/2003

Here are the basic elements of the failover configuration:

  • Two Windows servers, A and B, will execute drivers and the DirXML engine. The two servers are active - they both execute different drivers simultaneously.
  • One driver, let's say the driver for Active Directory (AD), will run on Server B.
  • The same driver for AD is installed on Server A, but it is not started/active.

Scenario: Server B crashes, and we want the AD driver to be started automatically on Server A, which is already running other drivers. We want the AD driver to failover to Server A.

While there are many ways to obtain automatic failover for drivers between servers on the Windows platform, e.g. through leveraging Cluster services, and external disks, I will describe below a simple configuration that allows for simplistic failover for drivers.

What is required:

  • A mechanism for monitoring the state for Server B (heartbeat, watchdog).
  • A mechanism that can trigger an action, based on the state for Server B. For example, if the state for Server B is not responding, we want the AD driver to be started on Server A.

So let's start putting together the required mechanisms by leveraging facilities in the Windows Server OS and tools included with Nsure Identity Manager.

Figure 1: Windows tasks scheduler calls a script called heartbeatB

Figure 2: The script heartbeatB runs at an interval of one (1) minute

The script heartbeatB calls another script called startADonA (Start AD On Server A) that is responsible for starting the AD driver on Server A.

Figure 3: The startADonA script

We want to call startADonA when Server B does not respond to a ping request. In order to avoid communication issues, we could use a cross-over cable between Server A and Server B, or a dedicated switch/hub. We could also improve the script to trigger the startADonA script only after three consecutive failed pings, etc.

The scripts for starting/stopping drivers on either Server A or Server B leverage the multi-platform tool/script dxcmd, included with Nsure Identity Manager.

Figure 4: The dxcmd script

We can execute dxcmd with /? to get information about the arguments. We could also create a special account for these scripts instead of using admin, and place these scripts in a secure partition on the server.

Figure 5: Options and arguments available for dxcmd

The above example is very simplistic, but it illustrates the two basic mechanisms that are required for failover, heartbeat, and triggered action. Windows 2003 Cluster or other mechanisms can be leveraged to improve the solution, but the idea remains pretty much the same.

For example, Windows 2003 Cluster services can be used to failover the whole package, including the eDirectory instance and DirXML, and all the drivers associated with this eDirectory/DirXML instance, all at once. The characteristics for such a configuration are described below.

Advantages and Disadvantages

Here are the advantages for failover for eDirectory/DirXML/drivers with Windows Cluster:

  • The same driver, not a copy of the original running driver, is started on the other server through a failover event.
  • The asssociations between eDirectory objects (e.g., User) and mapped objects in integrated systems are preserved.
  • The Identity Manager/driver cache is not lost, because it resides on shared storage.

And the disadvantages:

  • An external disk unit is required (e.g., SAN with SCSI or iSCSI, etc.).
  • A standby server is required. Server A and Server B cannot be active simultaneously.

If Server B fails, then the instance of eDirectory/DirXML/drivers that was running on Server B is moved to Server A. Windows does not allow for more than one instance of eDirectory/DirXML/drivers to run simultaneously. This limitation comes from the fact that Windows does not allow partitioning or virtualization of resources like UNIX or Linux.

Failover configuration for UNIX or Linux

The second failover disadvantage described above (standby server required) can be overcome by UNIX or Linux. Both UNIX and Linux both provide partitioning and virtualization for resources and can isolate multiple instances through concepts like virtual servers. Also, the upcoming eDirectory 8.8, for which there is a Public Beta available at the time this article is written, natively supports multiple instances for eDirectory on the same UNIX or Linux server. That support is not available for Windows or NetWare.

For more information on High Availability configurations for Linux or UNIX, you can go to these links:

DirXML Administration Guide, look under High-Availability:

Novell Nsure Identity Manager High Availability Cluster on SUSE Linux

Novell eDirectory 8.8 Open Beta Documentation

Novell eDirectory 8.8 - Public Beta


Four configurations have been discussed in this article:

  • Simplistic failover for a driver between two active servers, via dxcmd and Windows Tasks Scheduler, for Windows 2000/2003
  • Improved failover for a driver between two active servers via Windows Cluster, for Windows 2000/2003
  • Complete failover for eDirectory/DirXML/drivers between an active server and a standby server, via Windows Cluster, for Windows 2000/2003
  • Complete failover for eDirectory/DirXML/drivers, between an active and a standby server, or between two active servers, either through OS facilities for UNIX/Linux, or the upcoming eDirectory 8.8.

The choice between these options depends on several factors, including the cost of downtime. For example. downtime cost is greater in a mission-critical environment like online banking transactions than in the provisioning of e-mail accounts for students. Solutions without the complete failover for the eDirectory/DirXML/drivers instance can still require some manual steps after a failure, because associations are not preserved, and the DirXML cache is lost. Without any failover mecanisms in place, manual intervention is required to re-start the driver on another server and re-sync the objects. A simple failover scenario like the one described in this article can still be useful, but it does not eliminate the need for manual interventions in order to re-sync objects and recreate associations.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates