Private Isolated VSANs?

Ok, so this isn’t really UCS related.   Just a random thought I had today while working on a lab project… why don’t we have Private VSANs?   As in, the same type of technology as Private VLANs (PVLANs)?

First, some background.   Standard SAN best practice for access control is to use single-initiator/single-target zoning.   This means that there’s one zone for each combination of host and storage, tape, virtualization platform, etc port.    Some administrators think this is overkill, and create just a few zones of lots of initiators to single targets, but this is overall a bad idea.   The purpose of this post is not to argue for single-initiator zoning, since it’s accepted recommended practice.

Private VLANs provide a method for simplifying access control within a L2 Ethernet domain, restricting access between nodes.   Community PVLANs allow communication only between members of the same community, and the promiscuous port(s).   This is actually fairly close to the idea of a fibre channel zone, with the distinction that fibre channel doesn’t have promiscuous ports.   Isolated PVLANs allow communication only between each individual node and the promiscuous port(s).   In a way, you could compare this to having a lot of nodes (initiators) zoned only to a single target node (target) in fibre channel – but without the administrative overhead of zoning.

So, why not combine these approaches?   Having the concept of an Isolated Private VSAN would simplify some types of fibre channel deployments, by enforcing recommended practices around access control without the administrative overhead.  In a smaller environment, you could simply create an Isolated Private VSAN to contain the ports for a given fabric – set the storage ports as promiscuous, and all node ports would be restricted to connecting only to the storage ports – and prevented from communicating with each other.   In fact, I’d imagine that this would be enforced with standard FC zoning (since that’s the hosts are expecting when they query the name server anyway) – really we’d just be automating the creation of the zones.   Cisco already does something similar by automatically creating zones when doing Inter-VSAN Routing (IVR).

For slightly larger environments, I could even see adding in the idea of Community Private VSANs – whereby you group initiators and specify specific target (promiscuous) ports per community – without having to add additional VSANs.

Now that I’m thinking out-loud, why not have isolated zones instead?   Mark a zone as “isolated”, and tag any necessary WWNs/ports/etc as promiscuous, and enforce the traditional zoning behind the scenes.

True, this approach wouldn’t accomplish anything that traditional VSANs and zoning do not.  The implementation would likely have to use traditional zoning behind the scenes.   Just as PVLANs aren’t used in every situation, nor would PVSANs, but I could definitely see some use cases here.  So what do you think?   Am I completely insane?   Thoughts, comments, rebukes are all welcome.  🙂

5 thoughts on “Private Isolated VSANs?”

  1. Dave,

    Now that you’ve spelled it out this makes a lot more sense than you’re whacky IM 😉 I do like the idea of simplifying the process. To me there are two reasons for this:
    1) Zoning doesn’t do what we really think it does anymore and our zoning practices are outdated, expecially when virtualiztion is considered.
    2) With more and more virtualized environments we need a clean way to zone multiple hosts to a single target without presenting too many devices to the ‘SCSI bus’ the server thinks it sees. An isolated VSAN or zone as you stated above would accomplich this in a sleek fashion minimizing overhead and clarifying things during admin/troubleshooting operations.

    Great thoughts keep think out loud, next time brainstorm on ways to incorporate bacon, beer, and the shooting range without having to fly to Thailand to do it.

  2. Interesting idea, I like it. Would simply provisioning because you wouldn’t have to create aliases and zones for new SAN attached hosts.
    something I would add to it is to have a way for the aliases and zones that get auto-created to have a specific prefix name based on what FC port they are on. I am thinking this would help simplify troubleshooting or if you wanted to temporarily remove a zone from a zoneset. In the case of UCS server blades all initiators coming off of ports connected to the FI would have specific alias/zone prefixes.
    Maybe you should submit your idea to the Cisco FC team. 🙂

  3. Hi Dave,

    Interesting. I’m curious though about the problem that needs to be solved which zoning doesn’t solve?

    I’d also like to point out that SCSI (the application using Fibre Channel) isn’t designed the same as a TCP socket (which is often the application running on top of Ethernet). SCSI has a 1:Many, or Few:Many relationship. from initiator to targets and is a “master-slave” association. Should multiple initiators access the same target, who is the master? Get that wrong and you get data corruption. Hence, zoning best practices. And, as those of us who debugged switched Fibre Channel in the 90’s know, early inititators would log into everything in sight, including other initiators so bad things happened. Hence zoning best practices.

    That said, I’m not sure what the new problem is that we need to solve. Thanks for any illumination on that you can share.

  4. It wasn’t a new problem, simply a random musing. It doesn’t solve any problem that zoning doesn’t – in fact, in my post I even said that it would probably be implemented using zoning. Zoning solves the access control issue, the concept of a private VSAN would simply automate the creation of those zones.

    What got me thinking about this was some smaller environments where SAN administrators complain about the administrative overhead of single-initiator/single-target zoning. While I (a long-time FC guy) don’t think it’s a big deal, some people do.

Leave a Reply to Joe Onisick Cancel reply

Your email address will not be published. Required fields are marked *