Virtual SANs bring order to chaos


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.

Work that still needs to be done

Requires Free Membership to View

While VSAN technology offers significant management capabilities that haven't been available before, there's still room for improvement in the future. One area that needs to be addressed is VSAN membership by port, as opposed to by some other identifier, such as Fibre Channel (FC) worldwide names (WWNs) that identify the SAN node uniquely. Another area to be developed is administrative restrictions based on VSANs.
The most obvious holes in the first edition of VSANs is that membership is based on the physical port used and allows membership based on WWN or other possible identifiers. The situation is reminiscent of the development of Ethernet VLANs, where membership by port was introduced prior to other methods that could recognize the end node such as Ethernet MAC (media access control) addresses.
The problem with port-based membership is cables can be moved from one port to another, potentially changing the VSAN that the node belongs to and circumventing the isolation scheme. Clearly, VSANs will need to have the ability to recognize WWNs in order to reach their potential. I expect Cisco will address this shortcoming soon and it is undoubtedly aware of the requirement, having done virtually the same thing in the Ethernet/IP world previously.
MDS switches have multilevel role-based security enabling a master administrator to restrict the actions and views of other administrators. However, in the initial release of the product this doesn't include restricting administrators according to the VSANs they control. In other words, an administrator may be able to start and stop specific services in the switch, but there's nothing preventing them from doing so for any of the VSANs. This isn't quite the level of isolation that some SAN users demand--such as DBAs--who might feel exposed if an administrator from another department could impact their operations. This doesn't seem like the sort of improvement that should be very far out of reach for Cisco, but it's something that needs to be addressed for the technology to thrive.
The concepts embodied in FC's class of service haven't panned out because it's so expensive to provide the delivery guarantees specified in Class 1 service. FC SANs have generally defaulted to using Class 3 service--a best effort datagram service without any delivery guarantees.
However, just because class of service hasn't materialized, it doesn't mean that QoS in SANs isn't needed. Cisco plans to release VSAN QoS prioritization soon after the initial availability of the product. Like the rest of VSAN technology, the VSAN prioritization scheme was borrowed from the 802.1p standard used in Ethernet VLANs where a three-bit field determines priority.

VSAN routing
In most SAN switches, there's a single routing table shared by all ports in the switch. With VSANs, there are individual fabric shortest path first (FSPF) routing tables for each VSAN. The routing tables in SANs are small, but with enterprise SANs they grow and could affect switch latency.

One of the advantages of VSANs is they can each have their own weighting schemes applied to them for route selection. FC's FSPF routing mechanism provides a way to influence the route used by assigning different weights to different network routes. This provides a mechanism for failing over to a secondary route if the first route fails. By virtue of having their own independent routing tables, different VSANs in a switch can be directed to use different routes that may have different characteristics. The usefulness of VSAN weighted routing becomes more obvious when combined with MDS port channeling.

Port channeling in MDS switches
Port channeling is a technology for aggregating ISLs in MDS switches. It isn't a part of VSAN technology, per se, but VSANs take advantage of it. With port channeling, several ISLs can be combined to form a virtual link with much higher bandwidth and better reliability than a single link. For instance, a port channel made up of three ISLs has approximately three times the bandwidth and reliability of a single ISL.

Port channels have their FSPF weighting automatically adjusted to reflect the higher bandwidth available. Without establishing special weight values, routes with port channels in them will be selected over routes without them by the FSPF.

By changing weighting for VSANs you can assign weights to servers and applications that give them preferential route selection over less-important or time-sensitive applications and servers. A company could have separate VSANs for their transaction processing applications, all of them weighted to use a port channel comprised of four physical ISLs.

Less time-critical application servers could be placed in VSANs that are weighted in the opposite fashion to avoid using the port channel and offer more economical single link ISLs. If their ISLs failed, they could be switched over to use the port channel ISL.

Port channels can be formed from any combination of ports in an MDS switch and don't have to be formed from ports belonging to the same communication module. This adds an element of reliability as the port channel doesn't have to depend on the availability of any single module for functionality.

VSAN trunking
VSAN communications between switches using frames with VSAN tags are transmitted over links called enhanced ISLs, or EISLs. In Cisco's nomenclature, EISL links are considered trunking links. A single trunking EISL can be used as part of a SAN route or multiple trunking EISLs can be combined to form a port channel.

As FC has well-defined port types, Cisco had to invent a new type of E port, called a trunking E port (TE) to carry VSAN tagged frames. A TE port only communicates with other TE ports. For use with other vendors' switches, an MDS port can be configured to operate as a standard E port. MDS switches have a number of ways to configure port functions in a switch, including auto-detection--TE-only, E-only and F-only--to ensure mistakes don't occur when connecting switches to other switches, servers and storage subsystems.

An MDS switch can have both TE and E ports running simultaneously. An EISL can support multiple VSANs simultaneously because the TE ports have the ability to interpret VSAN tags. However, an ISL link doesn't carry VSAN tags, so it's not possible to have VSAN trunking. That means an MDS switch is restricted to mapping a single VSAN over a non-trunking ISL. The fabric for this VSAN becomes part of the fabric running in the other switch.

It will be interesting to see if Cisco attempts to create a standard around their VSAN technology, as they have with so many other networking technologies. I assume they will, but that assumption is based purely on wishful thinking for the SAN industry. The sooner VSANs are made into an industry standard, the better off the whole industry will be, including all the other FC switch vendors. The adoption of Cisco's VSAN is the shortest, most efficient path to moving to a new level of functionality.

This was first published in April 2003

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: