SQL Server Magazine

Imagine this scenario: A large healthcare service for a major city has a LAN and transfers data among 2 hospitals, 4 clinics, and 34 doctors. The network allows for input and retrieval of patient information from a hospital, clinic, or doctor's office. Patient information is confidential, so for security reasons, the database is stored and managed from a central file server.

The database server has failed, and the entire healthcare service has ground to a halt. You need a solution. The healthcare service obviously needs the capability to maintain duplicate, up-to-date information to ensure availability.

One common solution is to implement a hot backup to your primary systems and to mirror information from the primary system to the backup. With this topology, information on the primary, or source, system is mirrored and synchronized to the hot backup, or target, system. Mirroring is a complicated endeavor to undertake to ensure availability.

Seafood on the Menu
In August 1996, John Enck reviewed a powerful and sophisticated mirroring software package, Octopus 1.6, by Octopus Technologies. The company's newest product, Octopus Super Automatic Switch Over (SASO) 2.0, maintains the realtime mirroring capabilities and system options of 1.6 but now includes SASO.

SASO lets the target machine assume the identity of the source machine when SASO senses that the source machine has failed--all according to parameters the systems administrator sets. In my testing, the switchover occurred within 30 seconds and was transparent to the user.

I put Octopus SASO 2.0 through its paces on Intel-based systems running Windows NT 4.0. The 2.0 setup CD-ROM is self-installing, and the product supports all NT platforms (Intel, MIPS, Alpha, and PowerPC). Octopus can run over any protocol. You can specify that Octopus use the first available protocol according to a priority table you set, or you can select a specific protocol that Octopus will use exclusively. Like its predecessor, 2.0 is versatile because it can mirror data from one system to another, from many systems to one system, or from one system to many systems.

You install Octopus on the source system and the target system before you can configure and use it. You must reboot each system to activate Octopus, and then select Octopus from the Programs menu to configure it.

For the source system, the Forwarding and Mirroring options are automatically turned on. Mirroring is the process that lets the software capture updates to data in a user-specified file and save these updates in a log file on the source machine. Forwarding is the process that lets the software send updates from the log file on the source machine to the target machine.

The product's documentation does a good job of stepping you through installation and configuration. The documentation displays dialog boxes and defines each text box, an attribute I found helpful. For example, when confronted with the text box Auto File Unblock, I read the documentation to find out the box definition and options available.

To configure the source system, you can accept the defaults or change settings such as the interval (in number of seconds) at which the system will send an "alive" message to the target system. You can elect to forward the IP address for the source system's NIC to the target system. This configuration lets the current IP address remain an active IP address when the target assumes the identity as the source (SASO Option).

You can configure the target system with two backup options: Automatic Switch Over (ASO) and SASO. Both options automatically let the target take over for the source and let the target assume the identity (machine name and IP address) of the source system. ASO performs in an active/standby configuration, where only the primary server runs the application.

With SASO, the Administrator can specify that the target machine maintain its original identity while assuming the identity of the failed source machine. This scenario lets a target server maintain its legacy responsibilities while also taking on the functions of a failed source server. SASO performs in an active/active configuration, where both target and source can run different applications. (For a detailed definition of active/standby and active/active configurations, see Joel Sloss "Clustering Terms and Technologies," page 62.) In addition, SASO lets the target machine assume the identity of an unlimited number of source machines.

   Prev. page   [1] 2     next page