Octopus SASO 2.0

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.