This post is more than 5 years old
10 Posts
0
23121
Zoning 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.
Ed Schulte
143 Posts
2
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
LeeGoodwin
19 Posts
1
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
ZaphodB
195 Posts
1
October 28th, 2015 12:00
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.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
2
October 30th, 2015 11:00
The same functionaly that Ed describes for Brocade exists on Cisco too. It's called Smart Zoning, it can be enabled on the fly on per VSAN bases. Something to consider for shops running MDS (not available on Nexus).
jlgoodwin1
2 Posts
0
November 3rd, 2015 07:00
RRR
5.7K Posts
1
November 4th, 2015 13:00
One smart zoning blog post coming up! (tomorrow afternoon)
Watch out for it on http://www.50mu.net!
ZaphodB
195 Posts
1
November 5th, 2015 07:00
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.
ErikS1
18 Posts
2
November 5th, 2015 07:00
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.
ZaphodB
195 Posts
0
November 19th, 2015 06:00
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
2.1K Posts
2
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*
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
1
November 20th, 2015 13:00
if i were a Brocade shop that would be a show stopper, i can't imagine managing systems without fcalias/device names in Cisco world.
Ed Schulte
143 Posts
0
November 23rd, 2015 00:00
Hi Zaphod,
You can open a Service Request, for peer zoning not being able to use aliases, (make sure to update the supportsaves and the test results), if you want.
And let me know the SR number.
You can put it for my attention, and I can test and open a Request for Enhancement with Brocade.
I can see this to be a bit of a problem all right.
Regards,
Ed
ErikS1
18 Posts
0
November 23rd, 2015 04:00
Hi Zaphod, I agree with Ed. An enhancement request would be the best way to go as it would allow us to point to a specific end user request when we raise this issue with Brocade.
Thanks, Erik
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
November 23rd, 2015 05:00
Allen,
I still have McData ED-140M directors in production (i know, i know ..i am planning on donating them to the smithsonian when they get retired in the next 5 years). Even in 10 year old Connectrix Manager you could use nicknames, i am surpsied you survived without aliases for this long
Allen Ward
2.1K Posts
1
November 24th, 2015 07:00
Well, considering we just got the last of our fabrics out of McData Interop mode alst week I don't have much room to mock your aging infrastructure... But even in the old days we found it was often more trouble than it was worth to use the nicknames on ports. Some people would use them and some wouldn't. Then when someone who didn't bother updating nicknames repurposed a port originally used by someone who did you end up with the wrong label. I know Aliases are a bit better than that but the practice never took hold and has never seemed like it was worth the effort in the "newer" world..