Justin Vashisht Since the 7000’s came out I’ve noticed a lot of conflicting information on the way HP recommends zoning to be configured for virtualized environments. For instance, on page 5 in the HP 3PAR StoreServ Storage and VMware vSphere 5 best practices it is clearly written that on 3.1.2 HP supports both Single Initiator->Single Target and Single Initiator/Multiple Target. Now, before we go further lets take a look at the difference on a visual level. Below we have two pictures from the aforementioned document. Both pictures show a single host with two ports (Two Initiators), a set of Fabrics, and a dual node array with 2 ports each (two targets per node).
*Single Initiator/Single Target (RECOMMENDED)
*Single Initiator/Multiple Target (AVOID)
Now, looking at this and other HP documents out there one could quickly determine that Single Initiator->Multiple Targets would be the right configuration especially since a line on page 5 reads – “Single initiator to multiple targets per zone (zoning by HBA). This zoning configuration is recommended for HP 3PAR StoreServ Storage. Zoning by HBA is required for coexistence with other HP Storage arrays.” So, after creating my 7000 Installation post I received some interesting feedback on several people who thought that performing the Single Initiator/Single Target method was always the recommended way from 3Par. I verified the existence of confusion out there by looking a few 3Par installs and found it interesting that configuration methods were pretty much split 50/50 from Hp techs. Of course, this creates a bunch of confusion since you would believe that a published HP document on the VMware site would provide the iron clad answer. With the 7000 being approved for customers to self install I started to get more concerned about possible misconfigurations out in the field. At this point I engaged two incredibly smart 3Par guys, Ivan Iannacone (Worldwide 3Par Product Manager) and Jorge Mastre, one of New York’s top 3Par Specialist and all around larger than life guy (those who know him will not questions this statement).
Ivan and Jorge pretty much gave the same recommendations and acknowledged the confusion in the field from conflicting documents. They state HP will support Single Initiator –> Multiple Target but you should not have more than two targets attached to that Single Initiator. So, if I have a quad/octo controller arrays, zoning all nodes’ targets to a single initiator can cause severe performance issues in certain case when data is coming from many WWN’s. There are actually many performance related tickets that have been resolved due to this type of configuration. The consensus is to just use Single Initiator –> Single Target zoning which also reduces RSCN broadcasting that can occur when presenting/removing VLUNS/HOSTS. Sure, this process takes much longer since you will be creating more zones but this will be a pain to change once you are in production mode. I have seen configurations where arrays with 4+ controllers are zoned with Single Initiator –> Multiple Targets but staggered. So, Server 1 will be zoned to controllers 0 and 1 and Server 2 zoned to controllers 2 and 3 and so forth. This is an interesting concept and seems to work well since we are not going over the 2 target limit.
HP is working on cleaning up the inconsistencies on the article and in the meantime this document seems to be the best one to look at – http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA4-4545ENW&doctype=w
UPDATE – In the comments section a reader asked me on the standard naming convention used for zoning so I will add it here.
Blade Server Alias – a_blade01_port1
3Par Alias – a_CLIENTNAME_3PAR01_C0_S1_P1 (Controller, Slot, Port)
Zone – z_blade01_CLIENTNAME_3PAR01_c0_a
Zone Config – c_CLIENTNAME_a
I hope to receive more feedback from the field on this topic and will update accordingly.
-Justin Vashisht (3cVguy)
2 Comments
Hi Justin,
Nice article and I read it with interest and I am part of a team that perform storage integrations.
I have just a very small comment regarding your naming convention and obviously there is no right answer when it comes to naming conventions. But one thing I found very helpful for customers, today we mostly have Brocade customers, some with Cisco. What we find it that for usability and ease of administration when zoning we use typically most customers will use some GUI based tools for zoning either web tools/HP-NA. By listing the client first in a zone name the list sort order can cause entry hunting amongst large lists for the administrator. Typically the customer has fewer shared storage devices than clients.
By ordering using the storage device alias first and then the client name the lists from blocks centrically ordered around the shared device identifier and then the client name when viewed in the GUI. Most interfaces order on alphabetically left to right. We use similar naming conventions but we would use for a zone name “z_3PAR01_C0_CLIENTNAME_A” as when viewing hundreds of entries in a zone config you can firstly identify the storage component you are interested in and then the client attached on a list ordered in blocks around the shared storage name then the client which is much easier to read and to estimate where an entry is on a large list.
This makes the process much easier to track down a zone entry. Using the client first zoning naming a server such as “z_ACLIENT_3PAR01_C0_A” will have a completely different location on a list possibly pages away from “z_XCLIENT_3PAR01_C0_A”. This is just a quick thing that administrators in large environments find bothersome. In smaller configurations this may have no impact.
Two ways of peeling the same orange I know.
Regards,
Tony
Hi Tonjy,
Always love to see the different ways people set this up. I use the CLI, but I see your point. THat helps, especially when you get into the bigger deployments. Thank you for reading!
Comments are closed.