My two most recent columns about using SANs with Exchange generated a fair amount of reader mail, which I can generally lump into two camps: people who wish they had SANs and people who wish they didn't. Almost all the readers who contacted me either asked excellent questions or pointed out one or more specific problems they'd run into. I thought one more SAN-related column exploring these concerns and answering some of the questions I received might be worthwhile.
One reader said that his company had adopted a SAN to use clustering but that he hadn't seen "many of the benefits that we should have expected" because the company was still doing tape-based backups directly from the Exchange cluster nodes. If you dedicate a SAN for Exchange use, you'll lose some of the provisioning and cost-reduction benefits that come from sharing SAN space across multiple applications and servers. At the same time, however, you don't have to deal with the hassle of figuring out which application is sucking up all your I/O Processors (IOPs) or how to squeeze one more large SQL Server instance into the LUN that you wanted to reserve for Exchange.
Speaking of backups, several readers mentioned SAN-based backup. Most, like the reader above, were searching for a way to move away from their tape-only systems and toward a solution that would take advantage of their SAN hardware. The simplest way to do this is with the humble Ntbackup utility, which is perfectly capable of doing disk-to-disk backups over the SAN. The scenario for implementing this is simple and doesn't require additional software:
One reader praised iSCSI SANs because of their cost-to-value ratio. He made an excellent point. If you're looking for a lot of IOPs, you can get more IOPs per dollar from iSCSI SANs that you can from either direct-attached storage or Fibre Channel SANs. Of course, there are other factors to consider when you're designing a SAN, but the flexibility and low acquisition costs of iSCSI equipment--combined with the fact that 10Gbps Ethernet equipment is dropping in price--is stirring a lot of interest in iSCSI as a primary SAN implementation method. (Later this year I'll take a more in-depth look at what a production iSCSI SAN looks like and how it works).
Of course, not everyone has or wants a SAN. A few readers wrote to let me know that they had had reliability and data-access problems with their SANs. Some of these problems were caused by administrator error, but an equal number were caused by hardware failure or vendor misconfiguration, not by the customer. This area is clearly one to watch out for so that your SAN doesn't end up lowering your availability instead of raising it.