Last week, Microsoft announced something that's been in the works for some time: Exchange Server 2003 now supports the Internet SCSI (iSCSI) standard for using Storage Area Networks (SANs) over TCP/IP networks (see http://www.microsoft.com/presspass/press/2004/mar04/03-12exchangesupportsstoragepr.asp for details). So why is this capability important for Exchange?
I well remember my first introduction to SAN technology. My employer delivered a 60" rack of disks and drives to my home office, and I had to build a SAN by using the employer's software. This turned out to be quite an adventure, as I struggled with various pieces of Fibre Channel hardware and firmware plus the software I was supposed to use. Eventually I tamed the beast and had a stable configuration, but it isn't an experience that I'd wish on any Exchange administrator.
Enter iSCSI, which takes its name from the original SCSI standard, then adds the trendy "i" prefix (at least they didn't call it "eSCSI"). iSCSI is a standard for taking SCSI commands and routing them over IP networks. If you think of iSCSI as a means to set up a SAN using ordinary Ethernet, you're not far wrong. iSCSI-based SANs are a significant step forward in the cost department; Fibre Channel hardware tends to be expensive by comparison. iSCSI-based SANs also offer a great deal of potential flexibility because they don't impose the distance limitations that the physical properties of optical Fibre Channel systems impose.
In theory, iSCSI should also be easier to set up and configure because it uses a more familiar interconnection architecture. Of course, this cost advantage is muted somewhat by the fact that iSCSI designs typically rely on using Gigabit Ethernet (after all, a SAN operating at 10Mbps wouldn't be such a hot performer), necessitating network upgrades in some environments. And you need iSCSI-capable hardware, such as the host bus adapter (HBA) that connects your servers to the iSCSI hardware and the disk arrays themselves. The HBA is more or less a Gigabit Ethernet card, although HBAs from SAN vendors such as QLogic and Alacritech incorporate various bells and whistles that improve iSCSI performance compared with ordinary NICs.
Microsoft has been supporting Fibre Channel SANs since Windows 2000. Last summer, Microsoft released iSCSI SAN support for Windows Server 2003, Windows XP, and Win2K. However, Windows' iSCSI support consists of a driver, and Microsoft hasn't officially supported iSCSI SANs for use with Exchange--until now. Therefore, until now, that configuration wasn't guaranteed to be supported by Microsoft Product Support Services (PSS) or engineering. (PSS won't tell you to go jump in the lake if you encounter a problem with an unsupported configuration, but it can't provide you the same level of support and problem resolution as you'd receive for supported configurations.)
So Microsoft's statement of support gets us over one hurdle, but a closer look at the Windows Catalog's Hardware tab reveals that none of the HBAs, tape drives, disk arrays, or other iSCSI paraphernalia listed can be used for Exchange right now. (Look in the Status column. If you see the "Designed for Windows XP" logo, the device isn't supported for use with Exchange. Only devices that display the newer, more stringent "Designed for Windows" logo are certified for use with Exchange.) The press release cleverly avoids mentioning specific products that are supported for Exchange, leaving it up to individual vendors to navigate the logo-approval process. This process is based entirely on technical requirements, which are publicly available; the sticky point in getting certified is submitting products to the Windows Hardware Quality Lab (WHQL) for acceptance testing. As far as I can tell, no current iSCSI devices have earned that new logo, although given Microsoft's announcement it's probably safe to expect them shortly.
When these devices do ship, of course, the addition of iSCSI to existing Exchange environments will bring a whole host of other concerns into play. For example, because iSCSI SANs are often built over the LAN backbone, what security measures need to be applied to keep random network users from seeing or interfering with iSCSI traffic? I'll explore these concerns in future UPDATEs. Until then, I'll be interested to see which vendors position themselves as Exchange leaders by getting their devices certified while the market is still shaking out.
