I am not sure how many people remember Cisco SANTap. About ten years ago, Cisco introduced a data tapping mechanism in the MDS 9000 fibre channel switches. The idea was to allow the data path to be "tapped" at-will. Tapping in this case meant using a mechanism in the switch to split the data being written from client hosts to the storage, allowing the identical "split" data to be routed through a second, separate path.

SANTap therefore allowed a copy of the data to be seamlessly "mirrored" through the switch and subsequently used by other applications for multiple purposes (especially for backup). It facilitated real-time protection of critical data, and allowed advanced functions such as migration, snapshots, etc.

It was a great idea. However while it might sound like a simple solution, the details were exceedingly complicated. Two considerations immediately reveal how convoluted such a seemingly simple proposition could 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 switches 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 to see these applications and devices struggle 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 was from 2007, where 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 now. Newly available technologies allow third parties to build SANTap-like mechanisms.

Appliances which can tap live data with a Transparent Data Intercept technique have been developed that allow live insertion of interception points into the data path of fibre channel links. This technique is normally described as physical insertion by unplugging the storage or host ports, plugging that connection into the tapping appliances, and then connecting the appliance ports back to the switches. By doing this one link at a time, the data path can be intercepted transparently without downtime, and without any changes to the SAN environment.

This works extremely well. However, the same appliance can be inserted into the data paths without having to physically unplug cables. Using switches that support virtual SAN, such as most Cisco (vSAN) or Brocade (Virtual Fabric) switches, appliances with the Transparent Data Intercept capability can be simply plug into the switch ports, and tap into the data links. No changes to the original cable configuration are necessary.

This technique brought back the memory of SANTap. With an appliance and virtual SAN, this is exactly what it is - simply plug the appliances into the switches, then use virtual SAN to map into the links to be intercepted. Once inserted, the SAN environment is automatically discovered and organized by LUNs and hosts, and all detailed paths can be clearly identified, even across switches. All the related complexity can be hidden by clever software.

The implication is quite significant, if not earth-shattering. This means using this type of technology, after plugging the appliances into the switches and creating a few small virtual SANs, selected storage or host ports can be intercepted seamlessly. The entire SAN configuration can potentially be graphically illustrated. Individual LUNs can be selected and tapped, and the data can be migrated, or backed up for disaster recovery, periodically or continuously, local or remote. In addition, this process can enable cache, anti-virus, or even just SAN system health and performance analysis.

Through advanced Transparent Datapath Intercept technology, this tapping mechanism may soon be opened up via APIs for all storage solution developers to build their own applications - fulfilling the promise originally proposed by SANTap. One can only imagine what other great innovative products people can come up with once this interface is made available.

Come to think of it, maybe Cisco should adopt this and consider it as a "SANTap, redux"...