Another Look at SANs

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:

- Create a backup LUN.

- Attach it to the Exchange server.

- Use Ntbackup to do a disk-to-disk backup.

- Use the SAN to logically move the backup LUN to another host.

- Back up the Exchange data to tape. Of course, many administrators are primarily interested in SANs because of their potential use for point-in-time backups. Microsoft Volume Shadow Copy Service (VSS) is gaining traction as a supported, well-integrated way to combine your choice of SAN hardware and backup utilities, but many existing SAN deployments have hardware that supports only vendor-specific solutions. A couple of readers asked about the pros and cons of these solutions compared with VSS. The immediate answer is that if you can't run VSS on your hardware you can't enjoy a lot of its benefits. A more nuanced answer is that each SAN vendor has specified its own set of capabilities for point-in-time Exchange copies, and all the major products work within those specifications. Whether they work as well as a standardized, supported VSS solution depends on the vendor, as well as on the particulars of what you're actually trying to accomplish with the solution.

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.