VMAX-masking question

Question

VMAX masking When I issue the below command I am seeing each HBA is masked to both the FAs on VMAX for all the hosts. is this normal on a VMAX if so Please expalin with a best practice or primus or white paper.

In SMC also masking view shows the same way. any explanation please.

symaccess -sid xx -dev 00F6 list assignment

Symmetrix ID : 00xxxxxxxxxx

Device Identifier Type Dir:P

------ ---------------- ----- ----------------

00F6 21000xxxxxxxxxx FIBRE FA-8G:0,FA-9G:0

21000xxxxxxxxxy FIBRE FA-8G:0,FA-9G:0

pete2c · Accepted Answer

Yes this is normal for VMAX. When adding an Initiator (IG), Port (PG) and Storage Group (SG) together into a masking view basically the VMAX says "The initiators in my IG now have access to the symdev's in my SG via the ports in my PG". Therefore, when looking at the masking it's normal to see a device is masked to both FA's and both initiators as follows:

Init 1 ---> FA 1

Init 1 ---> FA 2

Init 2 ---> FA 1

Init 2 ---> FA 2

Hope this helps!

KD8EWE · Answer

Any whitepaper or best practice to support this.. because we had a discussion about this in our environment..

16Drf4U50112525 · Answer

I actually don't like this, as it creates supurfluous, invalid masking entries for the initiators that are not masked to the ports. So what i did was "old style" masking, where each host has a FAB-A and a FAB-B masking view, and the port groups are split as well.

FAB-A view:

IG_SERVER_FAB-A + PG_PORTGROUP_FAB-A + SG_SERVER

FAB-B view:

IG_SERVER_FAB-B + PG_PORTGROUP_FAB-B + SG_SERVER

This results in each device having only the masking that it should. Granted it does make for more masking views. I vetted this design with our EMC symm architect when we deployed the array, and he had no issues with it so long as i don't mind doing the extra work, which i certainly dont.

All of the "Auto-provisioning" whitepapers i have read are non-commital on the issue--they say pick the "appropriate" initiators for the IG--never defining what that means. To me, it means if it ain't zoned to the port it don't get masked to the lun over that port--but i have a dmx background so this thinking may be outdated...But why would you mask a lun to a host over a port that the host physically can't access?

dynamox · Answer

ease of masking,  i see your point but we wanted consistent and simple way of masking.

16Drf4U50112525 · Answer

I getcha dynamox, and on the first vmax i worked on we did it that way and it worked fine.&#xa0; Irritated me though nonetheless &#xa0; I understand the movement toward making all of this stuff easier to do and less obtuse, but at the end of the day in my head it's wasteful to have those entries there.&#xa0; And really, once the MVs are created, adding or removing lun from a host or hosts is still super easy, as they use the common storage group.

dynamox · Answer

indeed, it is odd to look at masking entries to initiators that are not zoned to those FAs. Unisphere for VMAX will make things so much better (/sarcasm )

KD8EWE · Answer

Again it depends on how we look at.

symaccess -sid XX list logins -wwn xxxxxxxxxxx89cf

Symmetrix ID : xxxxxxxxx

Director Identification : FA-6F

Director Port : 0

User-generated Logged On

Identifier Type Node Name Port Name FCID In Fabric

---------------- ----- --------------------------------- ------ ------ ------

xxxxxxxxxx89cf Fibre aliasname xxxxxxxxxxx89cf 100000x Yes Yes

symaccess -sid xx list logins -wwn xxxxxxxxxxxxxx44sd4

Symmetrix ID : 0xxxxxxxxx

Director Identification : FA-11F

Director Port : 0

User-generated Logged On

Identifier Type Node Name Port Name FCID In Fabric

---------------- ----- --------------------------------- ------ ------ ------

xxxxxxxxxxxx44sd4 Fibre aliasname xxxxxxxxxxxxx44sd4 200000x Yes Yes

dynamox · Answer

i was actually referring to device masking

VMAX

VMAX-masking question

Was this post helpful?