Cisco SANTap is one of the Intelligent Storage Services features supported on the Storage Services Module (SSM), MDS 9222i Multiservice Modular Switch and MDS 9000 18/4-Port Multiservice Module (MSM-18/4). These three SANTap enabling platforms will be referred to with the general term Services Nodes (SNs). The Storage Services Module (SSM) supports SANTap in Cisco MDS SAN-OS Release 3.0(2a), 3.0(2b), 3.1(1), 3.1(2), 3.1(2a), 3.1(2b), 3.1(3a), and 3.2(2c) or higher, and in Cisco NX-OS 4.1(x) and NX-OS 4.2(3i). The MDS 9222i Multiservice Modular Switch and MDS 9000 18/4-Port Multiservice Module (MSM-18/4) support SANTap only starting from Cisco NX-OS Release 4.1(x).
The Cisco MDS 9000 SANTap service enables customers to deploy third-party appliance-based storage applications without compromising the integrity, availability, or performance of a data path between the server and disk.
This chapter includes the following sections:
•Concepts and Terminology
•Features and Capabilities
•Requirements and Prerequisites
The Cisco SANTap service can run on the following modules and switches:
•The Cisco Storage Services Module (SSM) and 18/4-Port Multiservice Module (MSM-18/4) which can be installed into any Cisco MDS 9500 Series switch or Cisco MDS 9200 Series multilayer intelligent storage switch
•The MDS 9222i Multiservice Modular Switch
The architecture of these Services Nodes enables SANTap to service devices connected directly to the ports on the module, or devices connected anywhere in the fabric, including devices attached to legacy switches.
The SANTap feature allows third-party data storage applications, such as long distance replication and continuous backup, to be integrated into the SAN.
SANTap provides several advantages such as high performance, low cost of ownership, high availability, ease of deployment, and high interoperability.
The protocol-based interface that is offered by SANTap allows easy and rapid integration of the data storage service application because it delivers a loose connection between the application and an SSM, which reduces the effort needed to integrate applications with the core services being offered by the SSM. See Figure 1-1 for integrating third-party storage applications in a SAN.
Figure 1-1 Integrating Third-Party Storage Applications in a SAN
SANTap Control and Data Path
SANTap has a control path and a data path. The control path handles requests that create and manipulate replication sessions sent by an appliance. The control path is implemented using an SCSI-based protocol. An appliance sends requests to a Control Virtual Target (CVT), which the SANTap process creates and monitors. Responses are sent to the control logical unit number (LUN) on the appliance. SANTap also allows LUN mapping to Appliance Virtual Targets (AVTs). You can have a maximum of 512 target LUNs.
SANTap does not require reconfiguration of either the host or target when introducing SANTap-based applications. Also, neither the host initiator nor the target is required to be directly connected to an SSM. The configuration is accomplished by assigning Cisco-specific WWNs to the virtual initiators (VIs) and Data Virtual Targets (DVTs). A host initiator or a target can be connected directly to an SSM. However, you must partition the SAN using VSANs.
You must configure the host initiator and the DVT in one VSAN and configure the VI and the target in another VSAN.
You can use SANTap to remove your appliance-based storage applications from the primary data path in a SAN. Removing these applications from the primary data path prevents them from compromising the security, availability, and performance of the SAN. SANTap copies the data at line speed and makes it available to other storage applications; these storage applications are prevented from affecting the SAN while maintaining the integrity of the data that storage applications need.
Dynamic LUNs is a feature introduced in Cisco SAN-OS Release 3.2(1). When one or more LUNs are removed or added on the backend target during the periodic scan, SANTap automatically uninstalls the deleted DVT LUNs and installs any additional LUNs. Uninstallation of the deleted DVT LUNs occurs even if the total number of LUNs remains the same.
In previous releases, when the set of LUNs changed on the target, the original LUN list was displayed on the DVT. The new and changed LUNs were not reflected on the DVT. However, if the total number of LUNs increases, then the additional LUNs are installed and displayed on the host.
Before Cisco SAN-OS Release 3.2(1), a user had the following options for displaying the LUN list on the DVT:
•Shut down the host interface- Purge the DVT LUNs for the IT pair. All the LUNs for the existing IT pair were removed, and the correct set of LUNs is recreated when the host logs in.
•Reload the SSM.
In Cisco SAN-OS Release 3.2(1) or NX-OS Release 4.1(x) and, NX-OS Release 4.2(3i), SANTap supports 32-bit LUNs on the target.
SANTap Proxy Mode
SANTap proxy mode is designed to provide SANTap functionality to devices connected anywhere in the fabric, whether using modern SANTap-capable switches or legacy switches. Proxy mode allows SANTap to be enabled in a fabric with minimal downtime and minimal reconfiguration and recabling. The keys to SANTap functioning in this mode are the ability to segment fabrics using VSANs and the virtual interfaces that the SSM presents to the fabric. These virtual interfaces can be added into any VSAN and present a virtual initiator to the target in one VSAN and present a virtual target to a host in another VSAN.
SANTap proxy mode offers the following advantages:
•The ports to which the storage devices and hosts are attached are not moved.
•Devices can remain attached to a legacy switch rather than be migrated to a modern SANTap-capable switch.
•More than four hosts can use the same data path processor (DPP).
•The SANTap service is not coupled to a physical port.
See Figure 1-2 for a SANTap proxy mode-2 example.
Figure 1-2 SANTap Proxy Mode-2 Example
Concepts and Terminology
Table 1-1includes brief definitions of some of the common SANTap acronyms and terms.
Table 1-1 SANTap Acronyms
Appliance virtual target. The portal through which an appliance can complete its synchronization with the target LUN. AVT can be thought of as a host proxy for the appliance.
Control virtual target. The portal through which an appliance communicates with SANTap. An initiator port on the appliance sends out SANTap Control Protocol requests to the SANTap process. When the request is processed, the response is sent back by the Cisco VI (virtual initiator) to a target port on the appliance.
Data virtual target. A DVT is created for every port on a multi-ported target that is included in SANTap-based services. The DVT is created in the host VSAN. Once a DVT is created and a host logs into the DVT, SANTap installs a DVTLUN for every configured LUN on the target for this host.
Intelligent Line Card. Line card module available with the MDS family of switches that has hardware assist that facilitate exchange management and SCSI header inspection. Many switch-based storage service applications run on this card.
Initiator/target/LUN tuple. Uniquely identifies a LUN on a target.
A record/object that is created for every ITL whose WRITE I/Os the appliance is interested in. A session can be thought of as a target LUN that requires SANTap-based services.
Services Node. A generic term that can refer to either a system (Cisco MDS 9222i switch) or a line card (Cisco MDS SSM or MSM-18/4 module) capable of offering intelligent services.
Virtual initiator. SANTap creates 9 VIs in the appliance and target VSANs. In the appliance, VIs are used to send responses to SANTap CP requests and also to send copies of WRITE I/Os. In the target, VIs are used when the appliance is down and one of the SANTap recovery tools (ARL, PWL-BPR) is enabled.
Note If the appliance implementation chooses not to use these recovery tools, the VIs are not used.
Features and Capabilities
Cisco SANTap has the following features and capabilities:
Configuration Using CLI and Cisco Fabric Manager
SANTap provides a set of CLI commands for configuration. It can be configured using the Cisco Fabric Manager, which is a GUI-based application.
High Performance and Scalability
The ASIC-based innovation provides high-throughput IOPS. SANTap offloads the replication tasks from the initiators and appliance. A host software, driver, license, and agent are not required.
The SANTap appliance does not reside on the primary data path. The primary IOs are not impacted if the appliance becomes unavailable. The solution takes advantage of dual-fabric redundancy.
The appliances are in a highly available cluster.
There is no need to reconfigure end devices. SANTap works with heterogeneous hosts and targets. The hosts and storage can be added on-demand.
Ease of Deployment
There is no rewiring required for SANTap. The hosts and targets do not have to be connected to the SSM. You do not need to reconfigure the hosts and targets.
Leveraging the SAN Investment
The SSM can be deployed in the following switches:
•MDS 9216 or MDS 9216i Multilayer Fabric Switches
•MDS 9222i Multiservice Modular Switch
•MDS 9506 Director
•MDS 9509 Director
•MDS 9513 Director
In addition, SANTap also works with Supervisor-1 and Supervisor-2 modules. The hosts and storage can be connected to the existing 1-/2-/4-/10-Gbps Fibre Channel switching modules.
The protocol-based interface offered by SANTap allows easy and rapid integration of the data storage service application because it delivers a loose coupling between the application and the Intelligent Line Card (ILC), which reduces the effort needed to integrate applications with the core services being offered by the ILC.
Requirements and Prerequisites
The following prerequisites are required to set up SANTap:
•Software Licensing Requirements
Software Licensing Requirements
SANTap has the following software license requirement:
The MSM-18/4 module and the MDS 9222i Switch require the following licenses:
SANTap has the following hardware requirements:
•MDS 9222i: DS-X9222I-K9