I’m going to do something in this Musing that my wife predicted she would never live to see.  That is, admit to being wrong about something.  Well, at least partially wrong.  Or maybe right in a slightly flawed way.  Hmmm, maybe my wife is right.  Jeez, there I go again. 

Almost a year ago (August and September 2002) I wrote a series of Musings questioning the market validity of iSCSI.  Since then, I have come across a couple of legitimate and compelling applications for iSCSI that I believe may open the door for some deployment. 

My first glimpse of an application for iSCSI came from working with a storage management start-up company called MonoSphere.  Part of their story is to provide SAN-like value propositions to Direct-Attached Storage (DAS) environments, enabling an interesting SAN purchase deferral strategy.   They do this by putting a software driver on each server that inspects - and when put into “active” mode - redirects the local block level requests within that server.  With this as an I/O direction point, they can create virtual volumes (“MonoSphere Adaptive Volumes”) that consist of storage sectors not only on the locally attached disks, but on other servers.  What you get out of this is the SAN-like characteristic of “liquid storage” that can be assigned to applications according to need, without needing to over-provision storage individually on each DAS server.  In fact, the software has the smarts to automatically migrate only the “cold” data blocks based on the provisioning policies that the administrator sets up.  If you are uncomfortable using storage on one server to support an application on another server, a different way to leverage this capability is to create one or more additional DAS “spill over” servers, i.e. low cost servers or storage arrays whose sole purpose in life is to provide storage that can be logically carved and allocated to different DAS servers as they exhaust their local storage resources.  Companies like Rackable Systems, Intransa, and others provide very low cost options for this “spill over” storage.  Four to five thousand dollars per TByte gets my attention. 

No matter how you leverage the capability, implementation requires that block level signaling traverse a network between servers.  It could be achieved by deploying a separate Fiber Channel network, but that requires a lot of expense and training many users don’t want to plunge into.  That leaves iSCSI, which means the block level commands can traverse the same Ethernet network clients use to gain access to the application servers (see the diagram below); this is OK if you only need access to occasionally used “cold” storage.  If you need to access the spilled over information more often or are otherwise concerned about the resulting performance when mixing LAN traffic with remote disk access traffic, for a small incremental cost you can create a separate Ethernet network solely for the spill-over storage access.

This is a very interesting application, with iSCSI being a necessary – almost accidental - component rather than a value in and of itself.

Another way to leverage the combination of MonoSphere smarts and storage array economics is to maintain back-up copies of the DAS data on the Spill-Over server.  A variety of policies could be executed that vary how often the back-up and primary data are synchronized, including replicating every block transaction to the Spill-Over server to maintain almost instantaneous replication as well as the ability to back-up and restore any previous state desired (i.e. back-up to the state at 11:37pm last night, before the power spike corrupted a bunch of files). 

If you’ve gone this far, you might want to take one more step and unify your back-up and restore operations with your NAS systems.  This can be done by carving out some of the storage behind the NAS to support pieces of the MonoSphere Adaptive Volumes.  

The NAS box doesn’t do much with the arriving iSCSI packets sourced from the DAS servers, it just unwraps the iSCSI/TCP headers and services the underlying SCSI requests across a segment of its storage that has been allocated for this function.

Now all of the DAS and NAS files are stored in one storage system, which allows you to unleash one set of common data management tools across all of your Enterprise data, even though you are maintaining much of your data on DAS systems for security and performance reasons. 

In both of the cases discussed above, iSCSI is either required or preferred.  But in neither case is any characteristic of iSCSI the driving force.  Instead, the driving forces are the desire for simplified data management, leverage of common data management tools and procedures, and better utilization of storage resources.  If you’ll recall, one of the tenets of my previous dubious position on iSCSI was the claimed management advantages were irrelevant.  It’s not about network or device management. It’s about data management.  But then here comes a couple of applications where iSCSI is a derived necessity to improve data management.  That’s something I can get behind. 

My mistake in my previous analysis of iSCSI was I focused on the “back door” – what was traditionally the Fiber Channel or SCSI interface.  (I still don’t think people are ready to rush and build traditional SANs with Ethernet technology). What I didn’t pay enough attention to was the “front door” – the traditional Ethernet interface into servers, and more importantly concepts that leverage that network to provide incrementally better storage architecture and management options in a manner where supporting block mode transfers over Ethernet becomes a derived necessity.  In general, people don’t buy technology; they buy solutions and then adopt whatever technology is required to achieve that solution. 

Now that some solutions like the ones above are opening the door, driving Enterprises to adopt and get comfortable with iSCSI, who knows where it can go from there.  I know MonoSphere and others are developing a roadmap of capability to leverage this basic connectivity and provide an ever increasing number of options for storage architectures and services.  The use of iSCSI will get more and more popular as these new services and options hit the market.

(volume 6, number 6)