2 port groups vs 8 port groups

This customer currently has 29+ VNXs (all of them RAID 1/0) and NetApp arrays. They have wisely invested in Isilon and VMAX3.

Just the facts:

• 80% virtualized
• VmWare RHEL, Windows 2008/2012, Oracle, AS400
  
• 6200 LUNS across the environment, over 500 hosts (physical plus virtual)
  
• Fewer than 20 hosts exceed 200MB/s. 
  
• All host based multipathing, no powerpath.
• Single initiator/multiple target zoning now.

Currently, the customer is in the install phase of the engagement, and has questions about the design. They are using an EMC architect during the implementation. The EMC architect proposes that the host systems be spread over 8 port groups. The customer storage admin wants to make 2 port groups and use zoning to control access. 

Typically host access would be controlled through a combination of masking views, using the software on the array.  The customer currently uses a single initiator/multiple target zoning strategy right now, which is different than the single initiator/single target type of type of zoning strategy typically recommended by the OEM. The current SAN is VNX based on single initiator/multiple target zoning.

The customer storage team has been to some form of VMAX3 training with EMC education, and has a high level experience with VNX.

The design case they present is compelling,  and they would like the environment to test drive some daily administration tasks in an environment set up in the same way as the current  environment, single initiator/multiple target zoning.

Removing or adding a port group to a host is disruptive to the data path, and are rarely moved after implementation. They want the best decision the first time around.

• EMC Proposes:
  • single initiator/single target architecture
  • requirement for the servers to be spread over eight port groups
  • customer has around 6200 luns, each of those luns taking up one of the around 4000 addresses available on every port.  Each port has a limit of how many numerical identifiers can be attached to LUNS,  scaling challenges are presented.
• The customer proposes
  • single initiator/multiple target zoning
  • half of the servers on one port group, half of the servers on the other port group, for a total of two port groups
  • wants to optimize the efficiency of management by integrating the new system into the current design of the existing system

The customer makes a compelling argument and reasoning for their type of architecture design, and would like to test drive the proposed architecture in an operational VMAX3 environment complete with hosts, so they can evaluate the design choices. The design that they propose takes advantage of the VMAX3s new features around the fact that the CPU cores on the  director blades are free to float to the port that needs the power the most, instead of one set of cores being dedicated to one set of ports on the FA.

Is there a compelling reason to choose one design over the other? (besides the scaling difficulties)?

Some of the base functionality of the array (like SLO based movements of LUNS between SLO defined groups) have certain working around port groups and visibility. See below…what is the impact of the two design given the wording of this command from the CLI guide?

Look at the wording here from CLI: Will the operation of this command be impacted if there are only 2 port groups? 8 groups?

Changing SLO On Existing Storage Groups

Changing Service Level Objective to Platinum and Workload to OLTP_REP for a storage group test:

symsg –sg test -sid 123 set –slo Platinum -wl OLTP_REP

Solutions Enabler 8.X also allows for moving devices between groups non-disruptively

• Moving devices between child storage groups of a parent storage group when the masking view uses the parent group.

• Moving devices between storage groups when a view is on each storage group and both the initiator group (IG) and the port group (PG) elements are common to the views (initiators and ports from the source group must be present in the target).

• Moving devices from a storage group with no masking view or service level to one in a masking view. This is useful as you can now create devices and automatically add to storage group from CLI, so a staging group may exist. Command is:

symsg –test –sid 123 –sg staging_sg move dev 345 gold_sg