RSS
  Safeguarding Network Data: This Is A RAID Once you've dealt with redundant components for fault tolerance, think about cache on the controller. This is not as easy a decision as you may think. Before you decide how large a cache to get, you must determine whether you need cache at all. On the pro-cache side, you can get some real performance gains with a large cache. If you can cache an entire stripe of data, you can then write it to disk without having to read and do the parity calculation on the existing data stripe. On the other hand, the more cache you have, the harder it is to retain coherency--and the more data you risk losing should t he controller fail. Some folks don't like cache controllers. They argue that the controller will fail sooner or later, and data will be lost. You can get battery backup on the cache, but don't assume that will simplify your life. If the server crashes, you'll need someone to take the controller out of the failed serve r, install it into a new one and bring the system up so the cached information can be written to disk. What if the controller fails? You need a controller card like the ones made by Tricord Systems or Compaq Computer Corp. that lets you take the cache off the controller card and move it to a new card. In any case, if you do have cache on the controller, be sure you have error-correcting code (ECC) memory so that you can get prefailure alerts from your management software. One other thing to remember: If you have to change the controller card, you'll need to have your array configuration stored on the drives or it will be lost. Your best bet is to store it on all the drives so you won't lose it if one drive fails. Location, Location, Location One of the tougher questions you'll face when selecting a RAID system is where the RAID intelligence should reside. Should the controller be in the array enclosure or on the Peripheral Component Interconnect (PCI) bus in the server? If you put the controller in the enclosure, you'll be able to hot swap controllers. Additionally, you can chain more drives off a single SCSI card if each SCSI ID is a controller card rather than a disk drive. The down side to having the controller in the enclosure is reduced performance. If the controller is in the server, data from the drives is streamed to the controller card simultaneously, then it goes out onto the PCI bus, which has a maximum rated burst speed of 132 MB per second. If the controller is in the enclosure, the data goes from the drives to the controller and then across the SCSI-to-SCSI connection at about 32 MB per second. With a PCI-based controller, you have an electronic SCSI-t o-host interface embedded in the host, direct memory cache, and the controller is designed to be on the host bus. But this method has its drawbacks as well. Many server manufacturers did not fully comply with the PCI standard when they built their servers. This is readily apparent when installing a bridged controller card. The ca rd's driver doesn't need to be updated. The server's BIOS must be rewritten. In a system with the controller on the PCI bus, that controller becomes a single point of failure. At some point, you will need redundant controllers. Although the controller can reside in the server, the drives do not have to as well. In a RAID system, the drives spin continuously. A server's power supply and cooling systems are designed to cool the system itself, not a rack of drives. Filling the server with drives compromises both the server and the drives. Two more things to consider when deciding where to put the controller: Ultra-SCSI drives and Ultra-SCSI controllers. As SCSI speeds have incr eased, the total allowable length of the SCSI cable has dropped. SCSI 1 had a total length of 6 meters; SCSI 2, 3 meters. With Ultra-SCSI, an impedance problem arises when the cable between the controller and the drives has a total length of more than 1.5 meters. This will happen whenever the controller in the server is connected to drives in an array enclosure. If you have an Ultra-SCSI connection of more than 1.5 meters, you must manually force the drives down to Fast SCSI speed. This also can occur when the controller is in the array enclosure. The rigid backplane in most enclosures is rated at .9 meters. Some cable length is taken up by connectors and terminators. The result is a SCSI cable that can't be longer than 18 inches. Systems to Grow Old With When designing your system, leave room for growth. Never buy a system that will start out running at or near capacity. If you think you'll need to expand your system's capacity in the future, get an array controller that allows for dynamic expansion of the array without your having to bring down the server. I always add at least 50 percent to what I figure will be my starting storage needs. For example, if I need 16 GB now, I purchase a system with 24 GB that can be expanded to 32 GB, which is twice my current requirement. Some other things to consider: The cost to go from a 2-GB to a 4-GB drive is low, so it's worth it to put in the larger drives to allow for growth. Drives now run one million hours between failures. Most drives don't see the end of their warranty in their original configuration--usually, drives are moved into another machine before then. Remember, just because you can create a half-terabyte array doesn't mean you should. Segment the data first. It's more reliable to have multiple servers and enclosures than one huge drive array. Bootable arrays are also important. If the array isn't bootable, you'll need a separate drive for the NOS, and that becomes yet another point of failure. Scott Mason is an analyst with a major energy corporation on the West Coast. He is a member of the Silicon Valley chapter of the NPA. He can be reached at smason@nwc.com. |
|
Updated June 6, 1997 |
