Turn on suggestions
![]() Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
|
01-08-2014 11:05 AM
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..
Solved! Go to Solution.
01-08-2014 09:59 PM
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.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
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.
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?
Lastly, they screwed up on ISL licenses too, so the two pairs of switches are just cascaded (E ports).
01-09-2014 08:42 AM
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..
01-10-2014 06:34 AM - edited 01-10-2014 06:35 AM
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.
01-10-2014 08:05 AM
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.) (
01-10-2014 10:50 AM
01-13-2014 10:18 AM
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.
01-13-2014 12:45 PM
cfgdisable will disable the zoneset and should restore te defzone all access mode
01-14-2014 07:27 AM
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.
01-14-2014 11:29 AM
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.