Novell's NetWare SFT III provides effective fault-tolerance for mission-critical servers, but its requirements are uncompromising. If you have to safeguard data and can sacrifice some downtime after a system failure, SFT III isn't the only game in town; there are less restrictive and less expensive choices.
We tested three such products. Vinca's Standby Server is good for true drive mirroring in real-time at the transaction level, but requires up to an hour of downtime to switch to a secondary server.
Horizons Technology's LANshadow automates file copying between two (or more) servers, using free time slots. It's not a real-time update, but it backs up your data files. You can access the duplicated files by simply mapping to the proper directory and executing the application.
Nonstop Networks' No*Stop Network is a workstation-based product that duplicates all file writes to two (or more) servers. While this provides accurate, real-time updates, users can circumvent the process. And it can effectively double network traffic. It's primarily workable in smaller LANs with well-controlled menuing and access systems.
Novell's SFT III and Vinca's Standby Server provide transaction or write duplication between drives for nearly real-time duplication. LANshadow works like a standard backup operation: It is file, not transaction, oriented. The backup is as current as the last full copy of the file. The copy process is based on a predetermined schedule. You can schedule the copy process frequently, but since it's an NLM, you'll pay a bit performance penalty at the server.
The LANSHADO NLM runs in the source server, and you manage it from a Windows application that serves as the LANshadow console. This console doesn't need to be active during operation, just for setup and monitoring.
You can browse source server volumes and directories, and identify those to be mirrored. Similarly, you can browse the destination server for suitable locations for source file copies. The server directory structures need not be identical. This flexibility lets a single destination server service multiple source servers and still provide file services.
The Bindery Phase copies NetWare bindery information from source to destination server. If your destination server is an active file server, you may not want to do this, however. The Delete Phase looks for items that have been removed from the source server and removes them from the destination server. The Copy Phase simply copies the selected files and directories from the source to the destination server.
The Family Phase locks a defined set of files (for example, a database file and its indices), and copies them together. This can become unworkable where the database is large and the copy process time-consuming, rendering the entire database unusable during the process. Where SFT III, Standby Server and NO*Stop duplicate the individual disk writes, LANshadow depends on copying the whole file.
The LANshadow approach can work well in a network where the main applications manipulate whole files as opposed to transactions, namely, word processing, spreadsheet and other office automation applications. LANshadow does allow for a No-lock File Family that ignores lock flags.
Since the entire process occurs across LAN segments, it can also introduce added network traffic.
When we tested LANshadow by turning off the primary server, our login was maintained on the secondary server. We were able to access the duplicated files by simply mapping to the proper directory and executing the application. A big plus is the speed of a tape back up using the secondary server. No network traffic ! Local bus speed !
LANshadow 4.7: starts at $798. Horizons Technology, 3990 Ruffin Rd. San Diego, Calif.
mailto:LANshadow
It consists of two proprietary network interface cards (available in ISA, EISA and MCA as a matched set), a length of fiber-optic cable and software.
The software includes an NLM for the interface cards and a DOS application that runs on the backup server that turns the whole system into a set of mirrored drives.
Once the components are installed, the secondary server's drives appear as available drives under the NetWare Install utility as if they were physically installed in the primary machine.
The Standby Server DOS application is a completely dedicated function, so it ties up a PC. The changeover isn't instantaneous and is not automatic, as with SFT III. It requires a few steps and enough time to bring up a NetWare server. On the other hand, since the secondary server is only running a DOS application, it doesn't require a second NetWare license -- a cost savings.
We tested instead on a pair of systems with ASPI-compliant SCSI controllers with three 2-GB drives each. Although our systems were identical, they don't have to be, as long as there is adequate drive space in the Standby Server to support the volumes you want mirrored.
Because Standby Server uses NetWare's built-in mirroring facility, there's nothing new to learn. The big difference is the speed of the mirroring process. In a standard NetWare configuration, all mirrored drives are within the same system and connected to the same bus; possibly to the same controller. While Vinca's fiber optic interface cards run at 80 Mbps, that's nowhere near the speed of an internal transfer.
But once the slow initial mirroring process is complete (6 GB took more than six hours), Standby Server makes subsequent updates by duplicating every write operation between the primary and secondary server drives, so transfer speed is barely a factor. Ongoing mirroring activities don't affect network performance, since the mirroring traffic traverses the dedicated connection, and updates are only the actual file write activities, not full file copies.
We checked the data files that were active when the primary server went down. One database file required indexing, since it apparently was in the process of updating the index when the system shut down. All other files were fine. In contrast, because SFT III duplicates the CPU, it wouldn't have had a problem with the indexing scenario.
Standby Server/EISA Version: $1,995; ISA Version: $1,795; MCA Version: $2,195. Vinca Corp. 4000 Central Park East, 1815 South State St., Orem, Utah 84058; (801) 223-3100, fax (801) 223-3107.
No*Stop setup assumes you have two or more servers with enough disk capacity to hold the duplicated data. The application is installed on the server but executed on the workstation. Since it is a TSR, execution and consistency are a matter of maintaining and limiting access to login or application start-up batch files. There is no Mac or other workstation support.
You set up drive pairs at the command line or in batch files. You can only establish the pairing for active drives, so under NetWare you have to execute the appropriate MAP commands to attach the two servers and map the designated drives first.
Workstation dependence makes this approach very flexible but also error-prone. It assumes all workstations have executed the mirroring function. Users able to execute applications without first establishing the mirror pair will write to only the primary drive, causing a mismatch that may go undetected. This can be critical in a transaction-based environment, but not where whole files are rewritten.
The TSR requires 10 KB to 15 KB of RAM, and can be loaded high. It can be bypassed by applications that make direct calls to BIOS or NETBIOS. Because duplication takes place in the workstation and each write instruction is duplicated, applications that write to disk frequently may increase network traffic.
But there is some flexibility that server-based products don't have. For instance, there is a version that lets file updates be written to more than two drives, thus providing more redundancy. You can set up the drive pairing to duplicate to a network drive and to a local drive, providing local backup of network files. Most important, it will work with any network operating system.
We tested No*Stop Network on two NetWare file servers with five attached workstations. The drive pairing was set to duplicate all writes to the USER volume. We set up a batch file that repeatedly copied and deleted files between primary server directories. When we disconnected the secondary server, a notification appeared on the workstation asking if we wanted to abort the process or drop the drive. After instructing the TSR to drop the drive, the batch file copy function resumed. This is good recovery and notification, in contrast to server-based products that only notify the console of a drive failure. If you don't want to invoke user panic, you can redirect the messages to a log file, and you can designate default actions (such as "drop the failed drive and continue"). No e-mail or pager notification is supported.
Scott Koegler is vice president of information systems for Hospital Staffing Services, a home health-care provider operating 70 branch offices throughout the United States. He can be reached on CompuServe at 76424,1345.
by Scott Koegler, copyright Network Computing Magazine