HPE EVA Storage
1755332 Members
3817 Online
108831 Solutions
New Discussion юеВ

zone granularity - aim to reduce complexity

 
johnCatBE
Advisor

zone granularity - aim to reduce complexity

What are current best practice recs on zone granularity?

I've inherited a system with 200 zones in each of two fabrics and the complexity doesn't seem to justify the tasks in hand.

Is it recommended to zone using WWN by function - ie putting all aliases relating to clustered server hba's EVA storage and tape drives into a single zone that relates to the functional group - for example a unix cluster and it storage and tape units or a Polyserve Matrix wintel cluster with EVA storage and tape units.

Hope this question makes sense!

rgds
13 REPLIES 13
Stephen Kebbell
Honored Contributor

Re: zone granularity - aim to reduce complexity

Hi,

best practice from Brocade is to use Single-Initiator Zoning. Using WWN-Aliases is good, too.
We have a zone for each server, whether it is clustered or not. In the zone is one Server HBA WWN and all disk target ports (the WWNs of them).
We use a separate zone for tape devices.

So, for example, if we have a server called "Bob"
Alias: "Bob" - WWN of HBA
Zone: "Bob_Disk_A" - contains alias of "Bob" and aliases of all Storage Devices to be zoned (each storage port has its own alias)
Zone: "Bob_Tape_A" - contains alias of "Bob" and aliases of all Tape Devices to be zoned
In the other Fabric the zones would be called "Bob_Disk_B" and "Bob_Tape_B"

Each of our fabrics currently have around 470 used ports, and ca. 460 zones are defined. But the zoning DB is only 21% full. There are only 2 of us managing it all, and I think we have it pretty much under control.

Hope this answer makes sense :-)

Regards,
Stephen
PP BIJU KRISHNAN
Trusted Contributor

Re: zone granularity - aim to reduce complexity

Some examples from the brocade zoning implementation guide

www.brocade.com/san/white_papers/pdf/Zoning_Imp_WP_00.pdf

├в ┬в SRV_MAILSERVER_SLT5:A server with hostname ├в mailserver├в in PCI slot 5
├в ┬в TPA_LTO9_SNG:A tape with LTO drive number 9, single-attached
├в ┬в STO_DSK3456_5C:A storage unit with serial ID 3456 on the fifth card in port C
Rob Leadbeater
Honored Contributor

Re: zone granularity - aim to reduce complexity

Hi,

I usually follow the recommendations in the SAN Design Reference Guide, which you can find here:

http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00403562/c00403562.pdf

In addition to the comments above, I would ensure that tape devices and storage devices are in different zones. So if Server A needed to have access to both an EVA and a tape drive, then I'd have "ServerA_EVA_Zone" AND "ServerA_Tape_Zone".

Hope this helps,

Regards,

Rob
johnCatBE
Advisor

Re: zone granularity - aim to reduce complexity

Thanks Gents... i believe we've got some work to do!

I'm also wondering whether it's sensible to develop stephen's point about having eg a zone for bob and data and bob and tape - rather to have a cluster zone with
bob, tom, dick and harry and all their data storage aliases
... and ditto for tape connections.

This seems to me to me a much more pragmatic approach than having - eg - a numerical zone A1 containing a single server hba and a single storage hba - what is the point of this level of granularity?
raadek
Honored Contributor

Re: zone granularity - aim to reduce complexity

It's about security.

Think about Windows (or mixed) environment.

If a LUN is not properly fenced from a Windows host & 'accidentally' that host gets access to it, as soon as Windows OS 'see' a LUN, it will just write its signature on it, effectively corrupting the volume (if that volume was not empty & meant to be associated with another host).

Quite scary.

Rgds.
Don't panic! [THGTTG]
Uwe Zessin
Honored Contributor

Re: zone granularity - aim to reduce complexity

In most SANs it is about isolating the Fibre Channel adapters from each other to minimize state change notifications.

Zoning does almost never help if you have a mix of servers/operating systems that access a single storage array. In that case you need LUN masking (the Compaq/HP term is: Selective Storage Presentation - SSP) on the storage array to make sure a server does not have access to disks it has no business with.

Many years ago I've heard that (some) switches can alter the Fibre Channel frames and filter LUNs or prevent write access, but I have never seen it in real life.
.
johnCatBE
Advisor

Re: zone granularity - aim to reduce complexity

ok i've read the HP SAN Guide and i can see the reasoning for having initiator based named zones for cluster host members ie and use one name for each HBA for tape and data.
Would anyone care to dissuade me from extending this to having a single zone for a functional cluster - ie with all the cluster member host hba's and storage aliases forming a single zone based on function(and ditto for tape).

sounds like a great idea at present!

all within a dual-fabric configuration
many thanks
Rob Leadbeater
Honored Contributor

Re: zone granularity - aim to reduce complexity

Hi,

That sounds OK to me... indeed I've done that in the past.

Just make sure that if you have more than one storage system that the cluster will talk to, that they each have their own zone.

Cheers,

Rob

P.S. Don't forget to assign points...
Vasiliy Karpov
Trusted Contributor

Re: zone granularity - aim to reduce complexity

Despite many recommendations secure way to do zoning is to place only one target and one initiator in a zone.

This means zone "EVA8K_server1" will include only 2 aliases - "EVA8K" and "server1". Each alias may have several WWNs associated with them, e.g. EVA8K storage have 4 ports connected to each fabric, so 4 WWNs will be specified in 1 alias "EVA8K" on 1 fabric. Host server1 have 2 HBAs with 1 connection to each fabric respectively.

Generally speaking secure way is to isolate 1 target and 1 initiator into one zone, with as many wwns as necessary.