/********************************************************* END OF STYLE RULES *********************************************************/

Friday, August 18, 2006

iSCSI is good - for now

iSCSI is a good transitional technology. The common perception is that it offers a low-cost way to build a SAN on commodity ethernet components and will be successful in the SMB market. This is true but I actually see the biggest benefits in large datacenters that have hundreds and even thousands of nodes on their storage networks.

The problem with Fibre Channel is that it was never finished. The industry built a physical and a data link layer and then never went any higher in the stack (think back to the seven-layer ISO protocol stack). So, with FC you can build small SANs but, once you go beyond a few dozen nodes, and want to do things like reprovisioning and application migration, it becomes a nightmare. Administrators have to work across three or more different namespaces that have to be administered at separate UIs for app servers, switches, and storage servers. Users and applications care about file system and data and server names. Then that has to be mapped to mount points (e.g. /dev/...) and LUNs. Finally, what the poor SAN administrator has to work with are physical node WWIDs that have to be recorded and copied across the management UIs for hosts, switches and servers.

One of the benefits of moving to an IP SAN is you can leverage all the automated and centralized services such as DHCP, LDAP, SLP, etc. These aren't just aids to help manage the complexity like SAN management SW (which doesn't scale beyond a hundred nodes or so), these truly automate the complexity through central services. With iSCSI you can plug-in a new compute blade and it can query a DHCP server to not only get an IP address, but also get the location of it's boot LUN. Then, it can query an LDAP server to get the list of LUNs to mount. No scanning of LUNs, or zoning to restrict the set of visible LUNs. The DHCP and LDAP servers automated the process, are managed centrally, and are configured based on human-readable names.

The increased scaleability of IP SANs is especially beneficial for data centers that are moving to scaleable rack servers. In addition, many of these blade/rack servers have enough IP ports built-in that they are ready to connect right out of the box. The Sun/AMD blades come with four ethernet ports. There is no need to buy and install a separate SAN adapter. For server vendors, the percent of users who attached to FC has never justified putting FC HBAs on the motherboard they way they do with SCSI(SAS) and ethernet.

A benefit of using iSCSI on this IP SAN is it requires the minimum servers changes from what is used on today's SANs. SAN admins can still run their favorite local filesystem, volume manager, and multipath driver. Admins can get comfortable with the changes in the transport before making these changes in the server stack. BUT, eventually the benefits of new versions of NFS, and the ability to perform critical data management in the centralized storage servers become too compelling. This is why iSCSI is an important technology, a big improvement over Fibre Channel, but still another step in technology evolution and anyone moving to iSCSI should do so as part of a long-term plan towards NAS.