This article can also be found in the Premium Editorial Download "Storage magazine: What are the real benefits of data storage management software?."
Download it now to read this article plus other related content.
|Integrating VSANs into your fabric|
An MDS switch can act exactly like a non-VSAN switch by using a single VSAN and using only E ports and ISLs to communicate with other switches. This single VSAN and its fabric would communicate with all the non-VSAN switches in exactly the same way they do and participate fully in whatever topology exists.
A VSAN switch could also have several VSANs and connect to multiple non-VSAN switches over multiple E ports and ISLs. It is possible that these non-VSAN switches could all have their own independent fabrics. In this case, the topology would look like a hub with spokes, where each spoke represented a unique fabric connection. It is conceivable that an MDS switch could be used to connect to several different fabrics and act as a centralized point for implementing changes to all attached fabrics. For example, an MDS switch connecting to four different non-MDS fabrics could be used to manage changes to zones in all four of these fabrics, relieving the administrator of managing zoning changes on four different administrative sessions.
The result is nothing less than a new way to plan, implement, operate and manage SANs. VSANs are destined to become one of the most important advances in SAN technology for many years.
VSANs shouldn't be confused with storage virtualization. Instead, VSANs are all about Fibre Channel (FC) network communications. While it's true that MDS switches have excellent IP integration options, the benefits of VSANs can be achieved in a homogeneous FC SAN.
The most powerful aspect of a FC fabric is the way it spans multiple network switches to create a consistent network context for all nodes in the SAN. In multiswitch--also called multielement--fabrics, fabric service information is relayed over interswitch links (ISLs) and aggregated in each participating switch to form a complete, replicated instance of the fabric.
With their port-level granularity, VSANs allow a single switch to have multiple fabrics. They also allow a fabric to combine some ports from several switches. Without VSANs, you can only add to a fabric by adding an entire switch. With this flexibility, VSANs could be assigned based on the management goals of the IT organization. For instance, different business units or server/application groups could be assigned to different VSANs and managed according to cost and service level targets.
With VSANs, IT organizations can architect storage networks with distinct SAN service groups and service levels. There's no reason to have a one-size-fits-all fabric for every node that connects to a switch or director when it's possible to have application- or server-specific fabrics for each group of communicating nodes. A fabric that's established for a specific purpose can operate without interruption from other changes made in the SAN.
Other VSANs operating in the same switch could be created, removed or have properties changed or be connected to remote SANs through FCIP gateways--all with minimal impact on the original transaction processing VSAN. To limit the scope of changes in the fabric, VSANs create a more stable environment for all SAN users.
Segregating traffic and services
VSANs go beyond FC's current traffic segregation mechanism--zoning--to include fabric services.
In the implementation in "VSANs enable more flexible fabric design" (this page), no traffic or fabric service information is exchanged for ports belonging to VSANs 1 and 2. Only one-third of the normal fabric service information is transferred over an enhanced interswitch link (more on that later). More bandwidth becomes available for storage I/O data transfers. In a local SAN this isn't so important, but in SANs connected over WANs, it could make a difference.
|VSANs enable a more flexible fabric design|
Here's how a SAN could be made from two 16-port switches that have three VSANs: VSAN 1, which is unique to switch A, VSAN 2, which is unique to switch B and VSAN 3, which has ports in both switches. The two switches are joined by an enhanced interswitch link (EISL), which carries traffic routed between the switches as well as all fabric service information needed to operate VSAN 3.
Current zoning technology is inadequate in an environment that doesn't tolerate errors well. Zoning is adequate as an optional connectivity service, but not robust enough to be an architectural element in SANs. It has no mandatory or default behaviors, which leads to confusing scenarios. For instance, a node that's not restricted by belonging to a zone should be able to communicate with all other nodes in the SAN, yet another node that does belong to a zone should supposedly only be able to communicate with other members of the same zone. This creates a rogue zone of non-zoned ports (the zombie zone) that's difficult to understand, troubleshoot and manage.
All ports in a SAN should be assigned to a zone to avoid confusion and configuration errors. In data management applications that depend on changing zone sets in a switch, the potential for confusion and error significantly increases. The burden of managing zones falls on administrators with relatively few tools to verify that zoning is applied correctly. Mistakes can happen, even with highly skilled staff.
In Cisco's implementation, every port must belong to a VSAN. All ports are assigned to a default VSAN unless they are explicitly assigned to another VSAN. There's no way to have undefined membership status.
Fabric service isolation
Each service in each VSAN fabric is a separate software process tracked individually by the switch's operating system. You can identify services that have stopped running and attempt to restart them, which makes it less likely that faults will ripple over to other fabrics and switches. Let's say a transaction processing system is connected to its storage through an MDS switch and isolated on its own VSAN. Now suppose that a service failure occurs with a zoning service in another VSAN fabric. The fabric that experiences the zoning service failure might encounter some difficulties, but the VSAN used for the transaction processing system continues to run without interruption or loss of functionality.
Each switch has at least one VSAN running and can actively participate in as many as 1024. The total number of possible VSAN IDs is 4096, starting at VSAN 0 and continuing to VSAN 4095. This fabric address space can simplify management in an enterprise SAN environment with many different entities using SANs. Each business entity could be assigned different VSAN IDs or ranges of IDs.
Consider two manufacturing plants located in different cities. Let's say they both create SANs and use the VSAN IDs 20 and 30 for their material requirements planning systems. A year later, they decide to mirror SAN data between the two locations. At this point, they could either establish a new VSAN ID for mirroring or change one of the VSAN IDs at one of the locations to create a common VSAN ID. With so many VSAN IDs available to the SAN administration team, there are many ways to get the job done with minimal impact on the operations of other VSANs running in the organization.
Each VSAN has its own zoning service that supports multiple zones and interchangeable zone sets. Nesting zones within VSANs give administrators a hierarchical method of creating safe methods for dynamic data access requirements. For instance, two servers could share a disk subsystem through mirroring and snapshot where one server writes the data to a subsystem and the other accesses it for testing a new application. Both servers could belong to the same VSAN and make use of changing zone sets to ensure no access mistakes occur when creating the snapshot or testing the data. Any problems would be contained to this VSAN and not affect the operations of other storage I/O processes in other VSANs.
This was first published in April 2003