SAN Data Tapping Becomes Reality

I am not sure how many people remember Cisco SANTap. About ten years ago, Cisco introduced a data tapping mechanism in the MD9000 fibre channel switches. The idea was to allow the data path to be “tapped” at-will. Tapping means to split the data – specifically, the data that is being written onto the storage via the switch — and to direct a copy of that data to some other destination. “SANTap” allowed a copy of the data to be seamlessly obtained by other applications for multiple purposes (especially for backup), and thereby facilitated real-time protection to critical data and provided advanced functions such as migration, snapshots, etc.

It might sound like a simple solution, but the details are exceedingly complicated. Two considerations immediately show how convoluted this seemingly simple idea can become:

1. Fibre channel SAN inevitably involves multipath. For a LUN to be protected, all paths involved must be tapped. None can be left out. When using high-availability, this means paths will also travel through another switch. Every bit of data from these paths through different switches must be tapped without missing a single command.

2. The application or appliance that receives the data must be fast enough to receive real-time tapping. The smallest hiccup in data cannot be tolerated, since the tapping mechanism will not wait for the receiving application or appliance to “catch up,” or client performance will be affected. When this happens, SANTap changes to error mode and tracks the changed data in a dirty data map. The appliance then has to perform recovery — meaning copy the missed data first — and get back in sync. Unfortunately, SANTap’s primary design intent was for use with backup storage, and organizations rarely implement their highest-performing servers and devices in the backup space. It wasn’t surprising then that these applications and devices struggled with data ingress off the “tap” when administrators tried out this new technology.

These two real-world scenarios are just the tip of the iceberg when it comes to tapping data from SAN. The scope and complexity cannot be exaggerated, and it could be the reason why SANTap was not adopted pervasively by many vendors for their applications. The most recent material referencing the technology is from 2007, when EMC announced SANTap with RecoveryPoint.

Years ago when SANTap was at its infancy, while I was still in my previous company, I met with the Cisco engineering team working on SANTap and tried to persuade them to adjust certain aspects of the feature so we could integrate it into our own data protection product, which was perfect for SANTap. In fact we had already demonstrated a functional version, but were running into issues when many paths were tapped.

However that was another era at another time. For various inexplicable and non-technical reasons, the project just faded into oblivion. There were no other well-known products publicized that used SANTap. Nearly a decade later, the Holy Grail of seamless live data tapping from SAN remained elusive. That is, until Cirrus Data Solutions came along. Using switches that support virtual SAN, such as most Cisco or Brocade switches, CDS can simply plug into the switch ports, and start tapping into the data links.

As described previously in various articles and publications, we have developed the patented technologies surrounding Transparent Data Intercept, or TDI. This technology allows live insertion of interception points into the data path of fibre channel links. In most of our materials, we normally describe the physical insertion as unplugging, then plugging into with cables. It works extremely well. Many petabytes of data have been migrated from very small to very large environments. Everyone that uses the product loves it. Our TDI products have been proven in the field and consistently receive effusive praise.

However, we also want to increase awareness that the CDS appliance can be inserted into the data paths without having to physically unplug cables. Using VSAN in Cisco, or Virtual Fabric in Brocade switches, we can actually insert without physically touching the cables. When using this method recently, it brought back the memory of SANTap. With TDI and virtual SAN, this is exactly what we do. We simply plug our appliances into the switches, then use virtual SAN to map into the links to be intercepted. The automatically discovered SAN environment is organized by the LUNs and hosts, with all detailed paths automatically identified, across switches. Of course by no means is the technology involved simple, but all the complexity is handled by the TDI driver and associated software.

The implication is quite significant, if not earth-shattering. This means using DMS, after plugging the appliances into the switches and creating a few small virtual SANs, selected storage or host ports can be intercepted seamlessly, and the entire SAN configuration is discovered and graphically illustrated in the CDS SAN Configuration Explorer. Individual LUNs can be selected and tapped, and the data can be migrated or backed up to another set of disks – local or remote — using the DMS product. The LUNs can also be cached using our DCS product.

CDS is considering opening up this tapping mechanism by providing the API to others to build their own intercept handlers, so they can also take advantage of this advanced technology which truly works as Cisco originally intended for SANTap. One can only imagine what other applications people can come up with once this is made available.

Come to think of it, maybe Cisco will be interested in a “SANTap, redux”…

An alternate version of this post appeared simultaneously in Cloud Expo Blog.