Tip

Forget Atkins: Effective SAN extension strategies need CARBS

What you will learn from this tip: How to create a SAN extension strategy that protects your data.


The protection of data is no longer a matter of choice for many companies, but one of necessity. Between regulatory mandates in some business sectors and common sense business requirements in most others, data protection has become a front-burner issue that most companies have begun to take very seriously. That said, it is still important to watch your budgetary "diet" closely and to select a data protection scheme that considers both time-to-data requirements and corporate purse strings.

The mantra of the storage industry is to "put all storage in a network" as an architectural prerequisite for safeguarding data. You read it everywhere: SANs enable new disk arrays to be positioned in a SAN as "surrogate tape" targets.

The thinking goes that, initially at least, disk-as-tape products can be installed in a Fibre Channel fabric to leverage the existing installed base of tape backup users, while at the same time facilitating back-end, off-LAN data copying, which is what data protection is all about. Such a strategy, vendors hope, will capitalize on the existing investments in (and familiarity with) tape backup technology.

The appeal of this architecture was validated, in fact, by the early adoption of Fibre Channel fabric SANs. Only a year or two ago, the most common reason given by SAN buyers for adopting the topology was to share a large

Requires Free Membership to View

tape library among many open systems servers. Subsequently, disk-to-disk-to-tape (DDT) was introduced as an augment to the data protection value proposition of early SANs: targeting surrogate disk across a SAN would speed up the performance of backup streaming writes, thereby allowing backups to be completed within production windows.

The thinking of the industry is that these "disk-as-tape" solutions will evolve into "disk-as-disk" solutions. With the help of SAN virtualization, data copies (disk writes) will be made between different disk targets in a SAN simultaneously, a sort of mirroring writ large, relegating tape to a strictly archival role.

We see the beginnings of such architecture in snapshot caching products like those from Network Appliance. The extreme version is Revivio's Time Addressable Storage, which extends the metaphor of continuous data protection by replacing array based point-in-time mirror-splitting with an off-array block-level change journal. So much for Timefinder and similar value-add features in leading big iron arrays!

But don't go selling your tape libraries on eBay just yet. There continue to be more than a few problems with data protection in a FC SAN.

For one, Fibre Channel isn't a terribly effective mechanism for data streaming. DDT across FC is slower, for example, than data streaming across Gigabit Ethernet with Jumbo Frames. This explains why so many surrogate disk-as-tape solutions have not delivered the earth-shattering improvements over the performance of traditional tape solutions promised by their vendors.

Another problem with SAN-based DDT is the expense (and technical challenge) of extending a solution over distance. For data protection to be real, the copy of the data that you are making needs to be placed outside of the location where the production data is stored.

Traditionally, you move your data copy out of harm's way by delivering backup tapes to an off-site storage facility. With a SAN, the thinking goes, you extend the SAN fabric over distance and place your target devices (tape or disk) at a remote site. Sounds simple enough, but doing this requires some significant improvements in current WAN support for FC fabrics. Forget your Atkins diet, effective SAN extension strategies require plenty of "CARBS:"

  • Channel multiplexing: The best solutions for data replication over distance tend to leverage fiber optic connections between the primary and backup sites. Given the expense of such connections, technologies like wave division multiplexing (WDM) that enable multiple "conversations" to be conducted over a single pipe are worth exploring.
  • Alternate pathing: Whenever a network path is used to do something critical, it needs to be redundant, and backup is no exception. Most SAN vendors today recommend redundant fabric topologies inside the data center and this same logic must certainly apply to remote data copy as well. You need to make sure that all of your backup traffic does not flow through a single physical conduit if you want to be confident that your backup center will always have a complete copy of data. Ideally, your network connections will derive self-healing properties through redundancy. By properly designing your backup network, you can move data around the line break through another pipe if your primary communications channel is interrupted.
  • Resource replication: For expeditious recovery, you need resource replication. You need to take periodic "full volume" copies of your data in addition to any "journaling" or "snap shotting" or other incremental data copies that you are making. These full copies should be placed both on-site, providing failover protection against certain types of disaster potentials, and off-site, to protect against the smoke-and-rubble scenario. This is a potentially expensive architecture, though SATA arrays may take away some of the sticker shock.
  • Bandwidth management: You will need to manage the connections that are used in conjunction with remote data streaming or copying very closely. For one thing, bandwidth isn't cheap and you will want to ensure that you are getting the most bang for your buck. For another, you need visibility into the process to ensure that copies are being made correctly. Many Fibre Channel SAN extension schemes, for example, leverage tunneling protocols like FCIP to leverage cheaper IP connections for remote data replication. Problems with such connections often arise from the fact that pipes are shared and FCIP is "starved" of the bandwidth it needs to do its work. Worse yet, nothing in the Fibre Channel SAN will automatically notify you about problems on an FCIP connection or their root causes: The SAN doesn't realize that some of its traffic is traversing an IP connection, but views the FCIP interconnect as just another FC pipe. Management tools must be purchased and deployed if your strategy includes this protocol.
  • Security: Last but not least, don't neglect the security requirements incumbent in remote data copy and streaming. If you are subject to any regulatory mandates on data privacy, you already know about this one: Virtually any company that is doing data protection across a WAN should give careful consideration to how their data is being protected as it traverses the external network. You need to provision external data movements with at least the same level of security protection as in you do in your internal networks, and probably much more, to ensure that the data itself is not disclosed or corrupted.
The bottom line is that SANs have not magically converted data protection into child's play. The issues discussed above only scratch the surface of the myriad complexities that are often masked by vendors when they preach about the inherent protection afforded to your data by their favored topology.

Like so many fad diets, there are many inherent challenges and hazards -- and no one size fits all solution. So, consider your CARBS when you review SAN-based data protection schemes proffered by your vendors.

For more information:

Tip: No one-size-fits-all data protection solution

Tip: Visualizing data flow: Managing storage over distance

Tip: Considerations for SAN extension


About the author: Jon William Toigo has authored hundreds of articles on storage and technology along with his monthly SearchStorage.com "Toigo's Take on Storage" expert column and backup/recovery feature. He is also a frequent site contributor on the subjects of storage management, disaster recovery and enterprise storage. Toigo has authored a number of storage books, including Disaster recovery planning: Preparing for the unthinkable, 3/e. For detailed information on the nine parts of a full-fledged DR plan, see Jon's Web site.

This was first published in July 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.