As you know, you can provide some semblance of fault tolerance on your network by using mirrored hard drives. This is usually accomplished with SCSI drive arrays. But did you know that you can also provide fault tolerance with IDE drives? You can, but it may not be a good idea. In this article, I’ll tell you why.
Both Windows NT and NetWare support mirrored drives to ensure that you have two copies of your data available on two hard drives (in case one should fail). Data written to one hard drive is written simultaneously to the second hard drive. Ideally, should one hard drive fail, the operating system continues to run by switching to the secondary drive for all writes. The system continues using only one drive until you replace the mirrored drive. At least, that’s the way it works on SCSI systems.
Theoretically, it should work that way on IDE systems, too. However, due to architectural differences in the IDE standard, it doesn’t necessarily work the same way. As you know, IDE drives work in a master/slave relationship when you link two of them to your computer’s host adapter. The secondary slave drive responds to commands given to it by the primary master drive.
This is where the weakness in mirroring IDE drives appears. If the master drive fails for any reason, the computer will also be unable to communicate with the slave drive. This is true even if the slave drive is otherwise in perfect working order.
This problem doesn’t occur with SCSI drives because the drive controller for an SCSI drive resides on the SCSI adapter card, not on the hard drive. In contrast, an IDE host adapter only provides a connection between the computer’s motherboard and the hard drive. If an SCSI drive fails in a mirrored environment, the operating system can still communicate with the other good drive through the SCSI adapter. An IDE host adapter is virtually useless, should the master IDE drive fail.
So what do I do?
Because of the architectural limitations involved in IDE drives, you should try to avoid using them for an environment where you must provide redundancy. Instead, you should use SCSI adapters and hard drives.
However, if for budgetary reasons, you’re forced to use IDE drives in your server and want to provide redundancy, you may be able get around the limitation by using two IDE host adapters in your server. In this configuration, you’ll put one IDE drive on each adapter. Both of the IDE drives would then be configured as a master drive. If one drive fails, then the operating system will still be able to communicate with the second master drive on its own host adapter.
You should remember not to place slave drives onto these master drives, at least not if you want to ensure that the slave drives have any sort of redundancy. If you do install slave drives, you’ll be back to the original problem where the secondary drive will have no effective redundancy. The slave drive will still rely on the master to operate.
The only protection you can hope for in this scenario is to mirror the primary master to the secondary master and the primary slave with the secondary slave. In this case, let’s assume the primary master fails. This will also cause the primary slave to fail. However, because of the mirroring that's taking place at the host adapter level, the secondary master will continue to run and process data. Likewise, the secondary slave will also continue to run.
The most you’ll have to worry about is the possible corruption that can occur if the primary slave fails during a write. This may cause garbage to be written to the drive. It’s possible that the interruption may cause garbage to write to the secondary slave as well.
Many new motherboards come with two IDE host adapters built in. If not, you may be able to purchase a secondary IDE host adapter and install it into an available PCI slot in your server.
Be aware that when you install a secondary IDE host adapter or enable a pre-existing secondary IDE host adapter, you’ll consume an additional hardware IRQ. If you have many devices already installed in your server, you may not have an available IRQ. In that case, you may be forced to remove a device and reorder your server’s IRQs.
John Sheesley has been supporting networks since 1986, when he got his hands on NetWare 2.2. Since then, he’s worked with the Jefferson County Police Department in Louisville, KY and the Genlyte-Thomas Group. John’s been a technical writer for several leading publishers, including TechRepublic, The Cobb Group, and ZDJournals. If you’d like to contact John, send him an e-mail .The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.