Anyone for Target Driven Zoning

The Fibre Channel world is dying with nothing new or interesting in the pipe right.  Well, not quite.  While its definitely not the melting pot that is cloud  and it doesn’t have software defined in it’s name, cool stuff is still happening – at least cool in my opinion – and Target Driven Zoning is one of those cool things currently being worked on…..

 

Anyway, I was reading Erik Smiths blog and was really interested in his posts on Peer Zoning, and what he is currently calling Target Driven Zoning (TDZ).  If you like your storage then I highly recommend you follow what Erik does and writes, and that you familiarise yourselves with these two technologies.

The idea behind Target Driven Zoning is to do away with the requirement to manually perform zoning tasks in an FC SAN, and instead have the storage array do it for you.  Think about it, fabric zoning and array LUN Masking are so similar they could be twins separated at birth.  Both are effectively Access Control Lists that contain Host HBA/CNA WWPNs and storage array port WWPNs.   Ordinarily things work like this:  You add a new server to the SAN and you zone its WWPN with the storage array WWPNs that you want your new host to use.  Then you pretty much repeat the same operation on the storage array where you take the same host HBA/CNA WWPNs and add them to an ACL on the same storage ports that you just included in your new zones – while we call this masking but we could just as easily have called it time wasting, as we are manually performing two tasks that could be done once and applied in two places.

Anyway, the idea behind TDZ is to perform the masking on the storage array, and then have the array go talk to the SAN fabric services and automagically create the required zones.  It’s not rocket science and it’s not going to change the world, but it’s cool and it’s simple – enter a hosts WWPN on a particular storage array port, commit the configuration, and go make a cup of tea while the array creates the SAN zones for you.

And for those of us with fat fingers who prefer not to manually enter WWPNs, TDZ can make use of the unzoned name server so that WWPNs that have performed a FLOGI and a PLOGI to the name server – but are not zoned with anything – can be selected from a drop down list in the storage array GUI.  Seriously, even though a device isn’t zoned in with your storage array, you can select it’s WWPN from a drop down list using the arrays management tools.  Pretty cool IMO.

NOTE:  The unzoned name server is defined in FC-GS-3 and allows management applications unrestricted access to the contents of the name server.  A key enabler to something like TDZ.

Once you create the masking on the array, the array then issues an AAPZ (Add Active Peer Zone) command to the fabric, which duly creates the new peer zone.  As zoning has changed, an RSCN is issued to affected devices, which could/should then re-query the name server, notice they have a new visible devices, and duly PLOGI to those devices.  Net net, end-to-end connectivity with less effort from yourself.  What’s not to like about it?  In fact, it’s so damn simple I cant believe we haven’t been doing it for years.

NOTE:  Quick note on Peer Zoning.  A Peer Zone is newish type of zone that has the concept of a single principal member and x number of peer members.  The idea being that peer members can communicate with the principal member, but not with other peer members.  This way you can potentially have a zone with multiple initiators –shock horror – without those initiators being allowed to communicate with each other.  Sounds scary, but the again so do Google Self Driving Cars, and I’m sure we’ll all be driving going around in them in a few years time!

On the point of saying it’s so damn simple, Im not taking away from the hard work time, energy, and effort, that Erik and others have put in to this (I acknowledge that Erik and others are doing a great job with this, but I refuse to call it hard work, as things like this are more like fun than hard work, especially when you are working with the who’s who of the FC world).  Anyway, it’s a sterling piece of work so far, and a piece of work I would like to see pursued by the standards guys and the vendors.  To me it makes sense and would make life simpler.

 Peer Zoning is already a standard, but Target Driven Zoning is not…. at least not yet.  And in order for TDZ to stand any chance of making it in to the real world, Erik needs positive feedback, so I encourage you to visits Eriks site and register your support.

5 comments for “Anyone for Target Driven Zoning

  1. AcheronHades
    May 14, 2013 at 6:02 am

    As for our 3PAR-Arrays, this idea is realized the other way round: You zone a host to the array, and tell the 3PAR to export a volume to this host. The actual "masking" is done automatically by the 3PAR based on the ports the host is zoned to.

  2. May 15, 2013 at 5:39 pm

    @AcheronHades

    Thanks for commenting.  However, I do not agree with what you are saying.

    I understand what you are saying and know how the 3PAR does this.  However, in reality what the 3PAR does is no different to how every half-decent array works – you have to define hosts or hostgroups on the 3PAR and manually populate these objects with the WWPNs.  In my opinion, this is not the same as Target Driven Zoning realised the other way around.

    Unless of course 3PAR does something new in 3.1.2 that I am not aware of….?

  3. john
    May 24, 2013 at 1:09 pm

    Not necesarily with 3PAR you can also use Host Explorer which will prepoulate the array with the correct host name, O/S, patch level, WWN's etc to save you the efffort. However I do agree LUN masking once this has ocurred is pretty much the same as on most modern systems, at least for single servers. For multiples we offer autonomic groups to simplify and provide rapid provisioning of multiple volumes across multiple hosts. I'm sure others have similar, but this can really speed up provisioning massively whilst avoiding mistakes through repetition, especially across large cluster farms.

  4. john
    May 24, 2013 at 1:16 pm

    Be careful if you make this fibre channel voodoo too easy, then no one will want to use NFS / iSCSI ;-)

Leave a Reply

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


*

You can add images to your comment by clicking here.