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.
During configuration, from the Specifications dialog box, you select which files and directories to mirror to a target machine (SASO will mirror network shares). From here, you define the source file specifications and can use wild cards to identify certain files or select all files in a directory. You can query the network to list all systems running Octopus, or you can enter the target system's name. Defined files and directories appear in the lower half of the dialog box.
Be careful: Mirroring does not imply that a file to be mirrored exists on the target machine. After you add or modify a mirroring specification, you must select Yes in the Copy to Trgt box so that the files you want mirrored are explicitly created on the target machine. If you don't initially provide a base copy of a file to be mirrored, updates to the file can result in an incomplete file on the target machine.
Testing the Waters
For testing purposes, I configured an NT server with a sample SQL Server database, which I defined to be mirrored on a target workstation on the network. On the target, I copied the SQL database to the same drive and directory as on the source machine. From other workstations, I then ran several queries and made simple to extreme modifications to the database.
I failed the NT server through a power down, and the target machine assumed the IP address of the NT server. The workstation screens froze for about 15 seconds and then the task in process continued working on the database now located on the target machine. The Mirroring and Forwarding features were extremely reliable and fast, and you can monitor the failover process from the Octopus View Message Log.
The configuration options available in Octopus SASO 2.0 are easy to understand and use. The User's Guide, online Help, and the Octopus Technologies' Web site answered the few questions I had about the software. And, Octopus answered all my email requests within a few hours.
Octopus supports ASO/SASO for three basic configurations: from Primary Domain Controller (PDC) to Backup Domain Controller (BDC), BDC to PDC, or standalone server or workstation to standalone. I recommend mirroring between a PDC and a BDC. For standalone machines, you must set up local user accounts on both the source and target system. The target server that is participating in an NT domain (and that is not the PDC or BDC) will not accept network-based logons. When the target assumes the identity of the source, the trust relationship between the target and the domain controller is violated, hence the local user accounts. John Enck identified this limitation with 1.6 in his August 1996 review, and Octopus plans to address this issue in release 3.0 due out this month.
Also in 3.0, Octopus plans to include the ability for the source system to forward more than one IP address to the target system. This feature is ideal for Web servers to forward all IP addresses to the target machine. Octopus plans for 3.0 to have the ability to fail over applications in addition to databases, greatly increasing the software's value to any network.
The limitations do not detract from Octopus SASO 2.0's features. The easy installation and configuration make it a viable keystone for an availability plan. Given the results I encountered, I think Octopus SASO 2.0 will provide a variety of data protection options. If you're an Administrator looking to ensure availability, consider this software package to complement your network.
