Isolation zone question

[lpphiggp]

I'll try to explain our setup as clearly as possible.

We recently migrated to a new SAN, though still have some connections to the old for backups.

Old SAN:  Discrete Servers, McData switches, default zoning access none;  all connections had unqiue zones.

On the old SAN still is our ADIC Scalari2000 tape library...

New SAN:  Hosts are on a Dell M1000 chassis, equipped with two M5424 fabric switches, which in turn have two connections each to a pair of Brocade 5100s, for two , redundant fabrics with failover.  (When we ordered all this, I didn't know about the M5424s, they were added later without my knowledge by the admin for these servers, and as far as I'm concerned, they're unnecessary because we have 48 ports each on the 5100s).

Anyway, here's the thing.  For sake of simplicity, I left our Brocades in a zoning configuation of "Access All", as opposed to the way it worked with the McDatas;  security is physical, plus LUN and host mapping.    Most hosts have double HBAs, and they use dm-multipath for this.

So far so good.. but now I need to move our Scalar i2000 tape library over to the new SAN fabric, and the problem is,  I'm trying to avoid the hosts from seeing duplicates of their LUN mapped tape drive due to the redundant paths;  since the hosts have two HBAs, and will go through both pairs of  m5424 switches (even if I just plug into only one Brocade).

How do I isolate the Scalar's connections for the hosts?  If I create an explicit zone for each host, one HBA port to one port on the Scalar, will the other ports ignore it?  Or do I need to make an Isolation Zone?  

I really don't want to have to change the default zoning configuration if I don't have to.

Lastly, they screwed up on ISL licenses too, so the two pairs of switches are just cascaded (E ports).

Hope that makes sense..

[Anonymous]

---

New SAN:  Hosts are on a Dell M1000 chassis, equipped with two M5424 fabric switches, which in turn have two connections each to a pair of Brocade 5100s, for two , redundant fabrics with failover.  (When we ordered all this, I didn't know about the M5424s, they were added later without my knowledge by the admin for these servers, and as far as I'm concerned, they're unnecessary because we have 48 ports each on the 5100s).

---

Perhaps not on basis of ports available on the 5100, but unless Dell offers something similar as HP Virtual Connact, you would be using passthrough modules and run 2 FC cables per blade to get them to the 5100. Now you are using less. So less cables, the 5100 could be licensed for less ports, so you could end up with reduced CAPEX and OPEX.

---

Anyway, here's the thing.  For sake of simplicity, I left our Brocades in a zoning configuation of "Access All", as opposed to the way it worked with the McDatas;  security is physical, plus LUN and host mapping.    Most hosts have double HBAs, and they use dm-multipath for this.

---

This is not according the best pratices and really put you in a bad position to implement zoning for the tapelibrary.

It's bad practice because with zoning you try to mimic a classic SCSI bus as closely as possible, 99% of the time this means ONE initiator ONE or MULTIPLE targets. In your case we have a couple of blades (say 9) in your chassis, with defzone all access you have 9 initiator who can see each other, producing unnecessary chatter. It's bad starting point because the moment you implement your first zoneset, only those devices which are zoned are able to talk to their targets. If you missed something, too bad, the device will lose connection to whatever it was suppose to talk to.

---

How do I isolate the Scalar's connections for the hosts? If I create an explicit zone for each host, one HBA port to one port on the Scalar, will the other ports ignore it? Or do I need to make an Isolation Zone? I really don't want to have to change the default zoning configuration if I don't have to.

---

I don't know the iscalar at all to give you an answer. Something that might point you in a direction though, in general tapelibraries do understand the concept of LUN masking. Sometimes you may need an additional license to enable the feature, read the admin manual for your system to find out if the feature is there and then try it. On the part of zoning, regardless of what yourtapelibrary will support, I strongly advise you to implement zoning. Here's Brocades view on the subject, pag 9 is of interest to you http://www.brocade.com/downloads/documents/white_papers/Zoning_Best_Practices_WP-00.pdf

---

Lastly, they screwed up on ISL licenses too, so the two pairs of switches are just cascaded (E ports).

---

What's the screwup with ISL licenses? All switches can produce E ports, or so I understood from your text, so license wise you should be good. Can you draw a schema of how it currently is and how you expected it to be and attach it pls?

[lpphiggp]

Perhaps not on basis of ports available on the 5100, but unless Dell offers something similar as HP Virtual Connact, you would be using passthrough modules and run 2 FC cables per blade to get them to the 5100. Now you are using less.

I agree.  They decided to minimze the number of cable run for clutter's sake I guess, but they really reduced their bandwidth and increased the complexity of the setup.

This is not according the best pratices and really put you in a bad position to implement zoning for the tapelibrary.

It's bad practice because with zoning you try to mimic a classic SCSI bus as closely as possible, 99% of the time this means ONE initiator ONE or MULTIPLE targets. In your case we have a couple of blades (say 9) in your chassis, with defzone all access you have 9 initiator who can see each other, producing unnecessary chatter. It's bad starting point because the moment you implement your first zoneset, only those devices which are zoned are able to talk to their targets. If you missed something, too bad, the device will lose connection to whatever it was suppose to talk to.

I realize it's not optimal, but being as I'm stretched between so many duties and specialties, I'm forced to be a jack of all trades and master of none.  That's State employment for you. 

The hosts are managed by a unit other than my own (I'm the SAN admin yet oddly my own unit's servers are not on the SAN);  they were hooking things up and wanted LUNs quickly as possible, so I did what I could with the time I had.

On the plus side, it's not a particularly large SAN, there are maybe 9 servers on it, not that many more to be added.  (Famous last words, right?)

But.. I can create the zones "off to the side" so to speak,  while the switches still run in default open mode in the meantime, then switch over to the new configuration all at once, correct?  

So, it won't create outages to switch the default config? A s there's not that many connections yet, I'm not likely to miss any.  This is still pretty new.

I don't know the iscalar at all to give you an answer. Something that might point you in a direction though, in general tape libraries do understand the concept of LUN masking. Sometimes you may need an additional license to enable the feature, read the admin manual for your system to find out if the feature is there and then try it.

D'oh!  Yes, I overlooked that.  I can LUN map the Scalar to a single WWN, not a single host.  Non-issue then, from that perspective. Okay, for now, that gets me around the zoning/dupe issue.

What's the screwup with ISL licenses? All switches can produce E ports, or so I understood from your text, so license wise you should be good. Can you draw a schema of how it currently is and how you expected it to be and attach it pls?

I'm not very versed in ISL, but I understood that was the proper way to link multiple switches, which leads to improved bandwidth..

as it is, everything is now choked through one 8GB port per switch..

[Anonymous · Accepted solution]

But.. I can create the zones "off to the side" so to speak,  while the switches still run in default open mode in the meantime, then switch over to the new configuration all at once, correct?  

So, it won't create outages to switch the default config? A s there's not that many connections yet, I'm not likely to miss any.  This is still pretty new.

Yes you should be able to create zones(et) as long you don't cfgenable a config.

Once you are done cfgenable the complete zoneset, still any errors might brake something, so better check carefully before you proceed.

I'm not very versed in ISL, but I understood that was the proper way to link multiple switches, which leads to improved bandwidth..

as it is, everything is now choked through one 8GB port per switch

Ok so if you suspect a bottleneck then add additional ISL's (perhaps even trunk them (requires a license)).

Better still start measuring the switches to make sure you have a bottleneck some were, and what kind of bottleneck it is.

Bandwitdh, bb credits etc, once that has been determined add resources were they are needed.

[lpphiggp]

Ok so if you suspect a bottleneck then add additional ISL's (perhaps even trunk them (requires a license)).

Better still start measuring the switches to make sure you have a bottleneck some were, and what kind of bottleneck it is.

Bandwitdh, bb credits etc, once that has been determined add resources were they are needed.

I don't really suspect a bottleneck at this point, but I prefer maximum bandwidth and throughput when possible on general principle  :manhappy:

But I think you just explained something to me.  The license we don't  have is to trunk multiple ISL ports; as is, we have just the one.

I think we're okay for now at least, there have been errors or warnings, no complaints of poor performance either.. and our F port connections are 4GB.. I think the ISL E port is 8GB.. but as I'm not in today, I'll have to double check that Monday.

Or..   someone told me that 8GB means 4 GB receive, 4GB transmit.. I didn't think that was right though.) (

[Anonymous]

8Gb means simultaneous rx and tx 8Gb, ie full duplex

[lpphiggp]

Yes you should be able to create zones(et) as long you don't cfgenable a config.

Once you are done cfgenable the complete zoneset, still any errors might brake something, so better check carefully before you proceed.

Lastly,  In the odd event I somehow miss something bad, going back to the default config (I assume this terminology is the same as "zone set")  -which is "all access"-   should be an option...until I create the error... yes?

Sorry I'm inundating you with questions. I wish I had a development environ to test on but that'll never happen. 

[Anonymous]

cfgdisable will disable the zoneset and should restore te defzone all access  mode

[lpphiggp]

I forgot one other thing.. I'm fairly certain that if I create the zones in the 5100s, the m5424s will pick them up automatically  (master - surrogate), but since I never conf'd the M5424 I'm not 100% sure. The M5424s were bought by the unit who own the servers, for which I have no to limited access.  They're most likely at whatever the default settings would be.  (another reason it irked me that they went and  bought them without consulting me)

In the Switch Explorer console for the 5100s, the m5424s do in fact show up as part of the fabric, but I can't get to their web console .. it appears that other unit either did actually put an IP on them but it's one that is an inaccessible VLAN (not routed), or, it's a default IP from Dell (10.8.192.x), that either way, is currently inaccessible.

[Anonymous]

As they are part of the fabric zones propagate to them without any problem.

As they are part of the fabric YOU need access to those switches.

It's not good practice (IMHO) to divide reasonsibiltities over one common thing (being the fabrics) without either one having access to all gear  comprising said fabrics.

So if the other unit is unwilling to give you access, force them into using the AG mode, in which the switch is no longer participating in the fabric. Or other way around, hand them over management of the other FC switches.