Maintaining duplicates of up-to-date information is a key capability for a fault-tolerant (or fault-resilient) environment. One way to implement this capability is to designate a system as a hot backup to one or more primary systems and to mirror information from the primary system to the target system. If a primary system fails, the target system can replace it without losing data because an exact copy of the primary system's crucial information is on the backup.
Mirroring is a powerful and sophisticated capability that you don't expect to find on a couple of diskettes in a shrink-wrapped box. And that capability is what makes Octopus such an interesting, and in many ways, unique product.
Octopus is a realtime data mirroring software product that Octopus Technologies developed and markets. The product runs on all NT platforms (Intel, MIPS, Alpha, and PowerPC), operates under both NT Server and Workstation (and Windows 95), with any type of network connection--even wide-area RAS links--to carry the mirrored information from one system to another. Octopus can mirror data from one system to another, from several systems to one system, or from one system to several. Two systems can even mirror and thus back up each other. All these features make Octopus a flexible product for a variety of mirroring strategies.
Speed is the feature that makes Octopus impressive. It tracks updates as they occur and then mirrors just the updated information across the network. The result is blazingly fast data delivery; the software delivers updated data to a target system before you can swivel your head to look. You won't, for example, get the same speed over a RAS link as over a LAN link--but you can expect Octopus to perform well in any LAN environment.
Another benefit is that this product lets you mirror information structures ranging from simple flat files to sophisticated databases such as Microsoft's SQL Server. In fact, the only type of file access that Octopus Technologies admits to not being able to handle is the update access that the Microsoft Write accessory program uses. Fortunately, Write is a minor application that doesn't often find its way into the heart of an enterprisewide business solution.
An Octopus Among Us
I tested Octopus 1.6 (build 147f) on Intel-based systems: a Dell and a
Micron configured with NT Server 3.51 and a Toshiba laptop running NT
Workstation 4.0 beta 2. A garden-variety 10Mbit-per-second Ethernet network
interconnected all the systems; I used no switching hubs or other
speed-enhancing devices.
Installing Octopus is easy, but you have to reboot to activate it. You must install Octopus on both the primary (source) system and backup (target) system before you can configure and use it. With other products, you need to configure only the primary system; the target system receives the configuration information from the primary system.
At a minimum, you must identify the primary system's files and directories that you want to mirror to the target. The product's term for these file and directory specifications is data vaults. Screen 1 shows the dialog for entering this information. When you add the information about the target system, you can have Octopus query the network to sniff out all the systems running Octopus software, or you can enter the target system's name. If you have a medium or large LAN, having Octopus query the network can be time consuming, so enter the target system name manually; Octopus will validate the connection after you enter the name.
You can configure multiple specifications to enable one-to-many mirroring or to mirror multiple file sets to one target system. All the data vaults you define appear in the lower half of the configuration dialog. You can modify or delete those specifications. You can also select the network protocol (TCP/IP, NetBEUI, or Internet Packet eXchange--IPX) for transporting mirrored information. By default, Octopus uses the system's primary network transport.
After configuration, you're ready to go. When you add a new specification, select the Synchronize option under the Vault pulldown menu. Octopus will verify that the files on the primary and target system are identical and copy files that need refreshing.
| Octopus 1.6 |
|
Octopus Technologies * 215-321-8750 or 800-919-1009 Web: http://www.octopustech.com Price: $999 Octopus Server, $249 ASO option |
After Octopus synchronizes the two systems, the settings of the Mirroring and Forwarding options on the Functions pulldown menu let you determine how to process subsequent updates. The Mirroring option must be on if you want Octopus to track information changes in the primary system. The Forwarding option determines whether information changes will immediately go to the target system (Forwarding on) or remain in a local log file (Forwarding off). If you set Forwarding off, changes will not go until you turn on the Forwarding on option. Then, all logged changes will go to the target system.
Mirroring and forwarding are completely reliable and extremely fast. When Octopus was running, I perceived no performance degradation on either the primary or target system. The mirroring and forwarding capabilities are impressive.
For NT Server and NT Workstation, Octopus has two types of packaging and licensing. The basic package provides only mirroring capabilities. If something happens to the primary system, you must manually restart the target system under the identity of the primary system, or your users must manually switch their file and print connections to the target server. The advanced package includes an Automatic Switch Over (ASO) capability that lets the backup system automatically restart and assume the primary system's identity.
The ASO capabilities didn't impress me as much as the mirroring and forwarding. To use ASO, you configure the target system to assume the primary system's identity (and optionally the IP address) in case of a primary system failure. When you enable ASO, the primary system sends "I'm alive" messages to the target system at regular intervals (usually every 15 seconds). If the target system fails to receive an "I'm alive" message, it queries the primary system. If that query fails, the target system performs a partial restart so it can assume the identity (the system name) of the primary system.
The problem with this approach is that if the target system is a workstation or server participating in an NT domain (and not the Primary Domain Controller--PDC--or Backup Domain Controller--BDC), the trust relationship between the backup system and the domain controller is violated: The domain controller knows that the system assuming the failed system's identity isn't really the failed system, so the domain controller won't allow any network-based logons to that system. You can get around this limitation by setting up local logon accounts on the target system, but that pretty much defeats the purpose of a domain controller in the first place. Octopus claims to have addressed this limitation in the forthcoming 2.0 release, but I was unable to test that release before press time.
This limitation does not, however, totally invalidate the current ASO option. ASO is good if you operate in a workgroup environment, if you want to implement failover from a PDC to a BDC, or if you want to provide a hot backup for a Web server (in this case the backup system assumes the IP address of the primary Web server). The bottom line is that you have to analyze your fail-over needs in light of capabilities and limitations in Octopus and--even more important--test your failover procedure before a real failure occurs.
Octopus comes with a printed manual that forms the basis for most of the online help information. This manual explains reasonably well how to configure and use the mirroring capabilities, but it falls short in explaining how to effectively deploy the Octopus ASO option.
An Octopus in Your Network?
Aside from the issues with the ASO option, the benefits of Octopus for data
mirroring are enormous. In addition to facilitating one-to-one, one-to-many,
many-to-one, or many-to-many mirroring, the product has multiplatform
capabilities that let you mirror across hardware architectures. You can, for
example, mirror data on an Intel-based system to an Alpha-based system (and vice
versa). This capability sheds new light on how you can deploy and engage
different hardware platforms.
Beyond hardware compatibility, the ability of Octopus to mirror many kinds of data structures opens up a variety of backup and recovery options. You can use Octopus to mirror a live SQL database and then create tape archives from the target system instead of the live, primary system. Octopus can mirror shared file areas that your end users access, and it can protect these areas from data loss. You can mirror a Web system to reflect all production changes on a target server. Octopus even lets you mirror a server to a remote location (via a wide-area link) as part of a disaster recovery plan. In short, Octopus can solve quite a variety of data protection problems.
