We just got a SAN, and I will be assisting in installing it and configuring it, I asked someone to explain to me what we will gain using SAN zoning, but he was unable to answer my question, could some one here explain to me what are some of the advantages we will get from using SAN zoning using Brocade.
Thanks
Do you mean FC zoning? if so then it's basically something akin to a VLAN in that it allows you to hard-limit connections between devices.
With only one big zone essentially all points can talk to all other points, this sounds good, especially when you have a proper switch which will help with bandwidth management (there used to be FC hubs bitd, showing my age there) but it's often nice/required that you have more control.
For instance in our environment, entirely Cisco based I have to say, everything is very much firmly tied down by definition. So for example any given HBA port can only talk to the ports it's design to talk to on our arrays - and nothing else at all. Yes it's harder work but in-life it means we can troubleshoot more easily and our security nazi's love it and never throw anything back at us.
So it comes down to ease vs. control.
SAN zoning is VERY important, and you should definitely do it. Conceptually, it's similar to a VLAN - but don' t be mislead. There are different reasons governing it's usage and purpose. A zone is a container, into which you place a set of SCSI initiators (the host bus adapters on your client) and a set of SCSI targets (the port(s) on your array). Each thing within a zone may communicate with other things in the zone - and you will typically find that each initiator performs a port login (PLOGI) to each target within the zone. This - in effect - creates an arbitrated loop of devices.
This is important - for starters, there may be a limit on number of port logins that the array supports. On more modern arrays, this is quite a large number. But bear in mind you have a geometric growth problem - why build in scalability problems when you don't have to.
But the important reason to use zoning is because when something leaves or joins a zone, every other member must re log in to the ports. If you've small zones, then one device joining or leaving is not significant - there's notionally a service interruption, but it's insignificantly small. However if you have a lot of devices, then the number of devices that must re-arbitrate grows as does the frequency of PLOGI events.
Even worse if you have a faulty HBA that's flapping - if you don't zone, it can create a denial of service condition across your fabric.
http://en.wikipedia.org/wiki/Registered_State_Change_Notification
The best way to think about zones is "software-defining your SCSI bus". In effect, you are coupling the SCSI bus of some servers and some storage ports together. As others have raised, it can help fault-tolerance, or access-control, or reduce the domain of state-change notifications.
If your storage target triggers a bus-reset, do you want all your servers to see it, or just a few?
Zoning is also like laying out the roads on a map: it defines where traffic is permitted to flow. That doesn't mean your servers will use it, but it does restrict them to certain paths. you can use this to enforce balanced access to storage ports, or to reserve some storage ports for your more critical applications. This seems like a fairly good reason to get into zoning, but -- as others have raised before me -- be deliberate, have a plan.
Some will recommend zoning one server HBA to one-or-more storage ports; others will recommend one storage port to many servers. Still, some will balance a lot of servers and a lot of storage ports in the same zone. Each rule-of-thumb has those who would tell you not to. I tend to recommend choosing a rule, have a reason for it, and stick to it; the fewer devices per zone reduces the domain of state-changes, but is more logistical burden, so be careful what workload you're giving yourself.
Tools like BNA / CMCNE / DCNM tend to help, and OCI tends to help you keep your sanity, but the rules and conventions you choose can help keep consistency across your group. (Caveat: I don't work for the providers of BNA, CMCNE, OCI, nor DCNM, but I do fibrechannel daily)
As already mentioned above, setting up "zones" in SAN fabrics is done to promote fault isolation of devices from other devices on the same switch. Below are a couple of links to the Brocade documents which I find helpful on this subject of zoning.
For a quick overview and tips, I'd look at pages 10 and 11 in the SAN Admin Best Practices guide: http://www.brocade.com/downloads/documents/best_practice_guides/san-admin-best-practices-bp.pdf
For a more detailed description as well as implementation steps, check out the zoning section in the FOS Admin Guide. The link below is to the FOS v7.2.0 version: http://www.brocade.com/downloads/documents/html_product_manuals/FOS_AG_720/wwhelp/wwhimpl/js/html/wwhelp.htm#href=zone.18.01.html
It's mostly a security thing, I think.
It allows you to segregate traffic, in the sense that HOSTA can only talk to STORAGEA, much like a VLAN in the networking world.
It's akin to using VLAN's in your network switches. I'll say the same as I do when speaking about VLAN's: Don't implement zoning just because you can or because someone else tells you that you should. Make sure that you have clear and defined needs for doing so.
