Solved!
Go to SolutionZoning Best Practice?
Just wondering how other folks are doing their zoning.
Is it better to use a single initiator/single target or single initiator/multiple target when creating a zone?
Example:
ESXi host has HBA1 and HBA2
Two Brocade 6520 FC switches (two fabrics): SW1 and SW2
EMC VMAX with eight FC ports (1-4 on SW1 and 5-8 on SW2)
Create four zones on SW1: one for each initiator/target pair
Create four zones on SW2: one for each initiator/target pair.
Total of eight zones.
Or
Create one zone on SW1: one initiator and four targets
Create one zone on SW2: one initiator and four targets
Total of two zones
For 30 hosts, that's 240 zones versus 60 zones.
Thanks in advance for any feedback.
One smart zoning blog post coming up! (tomorrow afternoon)
Watch out for it on http://www.50mu.net!
LeeGoodwin
19 Posts
16420
1
Posted October 24th, 2015 05:00
Always better
Single target single initiator
This will be best practice cuts down on rscn traffic
Sent through the clouds from EMC
In my experience, the biggest drawback of single initiator/multiple target zoning is that if you have any FC issues whatsoever it will be suggested as a possible cause, and it will side-track and slow down the proper diagnosis and correction of your real issue.
Which is like arriving at the emergency room with arterial bleeding and being handed a clipboard full of forms you need to fill out before they will treat you.
It is best to make single target single initiator zones from the start, and avoid the possibility of any future inconvenience.
jlgoodwin1
2 Posts
16430
0
Posted November 3rd, 2015 07:00
One issue with the single-initiator single target is that in a large environment with multiple arrays is that you might hit the maximum number of zones limit. 8000 per VSAN, or 8000 total for the MDS 9509/9513 switch if you have multiple VSANS. Multiple arrays can have many targets what with FAs or SP ports, and if you have hosts that need to hit all it your arrays then zones can add up fast.I was planning to upgrade from 7.2 to 7.4 in the near future, just to level up. But after reading your post I am now relatively excited about doing that.
I don't have a huge environment, but I do do have both storage that serves 30 or more hosts, and hosts that are attached to 10 or more storage units with the result that each of my two primary fabrics has ~1600 zones in it.
Peer zoning looks like it would drop that to around 120. I'd end up making one zone for each storage unit port, and assigning the appropriate hosts as peers. The storage end is far less volatile (I install and keep units for 5-6 years versus 2-4 years for hosts recently), so I will be modifying zones regularly, but only adding/subtracting them when storage units come and go.
I like that idea...a lot.
Smart zoning and Peer zoning should both work well. A couple of points:
1) From an Initiator's point of view, it will not be able to tell whether it's in multiple single initiator / single target zones or one single initiator / multiple target zone. When it queries the name server it will get back a list of FCIDs and there is no way for it to tell based on this list how the zoning was done.
2) From a Target's point of view, the target will notice a difference if SIST is used because when it is, the response to a NS query will contains fewer FCIDs. This means that each target will place less of a load on the NS (no queries about other targets) and overall this is good for fabric stability.
That having been said, given the average size of our customer's fabrics, either SIST or SIMT will work fine in the vast majority of cases.
The only downside to either Smart or Peer Zoning is that you still need to create the zones manually and this is where Target Driven Zoning will help.
If you're interested in more detail about zoning in general, see this blog post.
I played with peer zoning a bit, but ran into a significant downside:
From the FOS Administrators guide (pp 356)
Peer Zones are configured and managed using zone commands with the
--peerzone
option.
In the Peer Zone, devices must be identified as either WWN or D,I devices. Mixing WWN and D,I
device identification within a single Peer Zone is not allowed. Aliases are not supported as devices for
a Peer Zone.
..........
If you have a large and complex environment, then aliases are pretty much essential to keeping things clear and readable. Maintaining peer zones, when they are just a pile of WWNs, is going to be a difficult, and error prone, undertaking.
Allen Ward
6 Operator
•
2124 Posts
2346
2
Posted November 20th, 2015 13:00
Yet we are a fairly large Brocade shop and have never used aliases. We've never really needed them. Maybe that's cause I learned zoning old school in the McData days and have never known how it could be that much easier :-)
That being said I'm really looking forward to playing with Peer Zoning once we get to FOS 7.4.1. On our Brocade contact's recommendation we are waiting for the v7.4.1 before we upgrade from 7.3.1c (and earlier on some switches) so we don't have the functionality of 7.4 yet. I'm really happy about the Peer Zoning though... finally I can stop listening to the Cisco folks saying "but we have Smart Zoning" *lol*
Ed Schulte
2 Intern
•
151 Posts
16430
2
Posted October 28th, 2015 13:00
Hi,
In principle single hba / target zoning, for obvious reasons.
But you are using a DS-6520B, so you should be able to upgrade to FOS 7.4. And FOS 7.4 can use "peer zones". these are zones, with single initiator / multiple targets. This is all described on page 351 of the FOS 7.4 Administrator guide, downloadable from the EMC support site.
Quote:
"
Peer Zoning allows a "principal" device to communicate with the rest of the devices in the zone. The
principal device manages a Peer Zone. Other "non-principal" devices in the zone can communicate with
the principal device only; they cannot communicate with each other.
"
This will give you easier zoning and less RSCN, to the other devices in the zones.
I believe this is your best option.
Best Regards,
Ed