Commentary

Howard Marks
 

How To Kill Array Vendor Lock-In? An iSCSI Replication RFC

A few years ago it was easy to divide IT organizations into haves and have nots. The haves used Fibre Channel SANs and array replication to dedicated disaster recovery sites over high bandwidth dedicated links or dark fiber. The have-nots used SCSI DAS (Direct Attached Storage) on their servers and, if they did real time replication at all, used server-based replication solutions like Double-Take or CA's WANsync.

A few years ago it was easy to divide IT organizations into haves and have nots. The haves used Fibre Channel SANs and array replication to dedicated disaster recovery sites over high bandwidth dedicated links or dark fiber. The have-nots used SCSI DAS (Direct Attached Storage) on their servers and, if they did real time replication at all, used server-based replication solutions like Double-Take or CA's WANsync.As they started replacing DAS for the more technically savvy have-nots, they also started using array based replication since it's a lot easier to manage replication between a pair of disk arrays than between 10 or 30 pairs of servers. This introduced them to the storage industry's dirty little secret -- not only do the arrays you're replicating between have to be from the same vendor; they have to be from the same product family.

Vendors love this idea since it means that once you start replicating data between EMC, NetApp, HP, or even EqualLogic arrays, you'll keep buying additional storage in the same family because anything else you buy will mean a new replication scheme.


More Storage Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

As a customer advocate, let me say the time has come for this to stop. The IETF can help by developing an extension of the iSCSI protocol to define standard replication messages that multiple array vendors could be forced, by market pressure if nothing else, to adopt.

Conceptually, it's pretty simple. You set up a logical unit number (virtual disk) on a secondary array at your disaster recovery site and, using CHAP and/or IP address masking, limit access to that LUN to your primary array. The primary array then connects to the secondary array as an initiator and synchronously or asynchronously duplicates disk writes to the secondary. If we just had standard PDUs (Protocol Data Units) for the replication traffic, you could have a Wasabi-based array in one site replicating to a LeftHand array in the other.

Given that RFCs are typically written by vendors nowadays, I'm asking one of the many vendors that develop iSCSI targets to run on standard PC server hardware, including my example vendors above, to be a mensch and offer it up to the market at large.

I'll do my part and heap praise on the first, and second, since it's not really a standard till two vendors support it. Vendors, step to the plate.

In fact, my new technical analysis firm, DeepStorage.Net, will test the first multivendor replication products anyone can get to our labs free of charge and produce a glossy validation report your marketing dweebs can use to their heart's content.

Any open source guys want to pick up the gauntlet?

Any EMC, HDS, or other entrenched vendors want to tell me why it's a bad idea?


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links