As far as i know it doesnt work that way.

I have opened a case with EMC here is their answer:

You must connect a host to a Storage Group so that the host can perform I/O to the LUNs in the Storage Group. This host can access only the LUNs in the Storage Group to which it is connected.

"A host can connect to only one Storage Group per storage system at a time. If you connect a host that already connects to a Storage Group to another Storage Group, the host will disconnect from the first Storage Group. When you disconnect a host from a Storage Group, and then connect it to a different Storage Group, the host can no longer perform I/O to the first Storage Group.

 

I cant believe that is true. This is possible with IBM SANs.

Can't the LUNs be assigned to multiple hosts/groups - so the one host could see others even if the one host is not in multiple storage groups. 

But you don't need the one server to have access to all the storage groups, you need it to have access to all (some) of the LUNs within thos storage groups. LUNs could be assigned to multiple storage groups, their main group and then this aggrgated group. As soon a LUN has multiple data sources then contention, cluster files systems, etc. come in to play. 

If you have a server that needs access to some luns from the ESX servers, but also needs access to other luns;

- create a storage group for the VCB server
- put in the luns that are also in the ESX storage group (depending on the version of Navisphere it may be worded differently, but there's an option to show all luns, and not just the unassigned luns)
- then also put the other needed luns in the storage group

Remember: NTFS doesn't handle sharing the partition between multiple servers that aren't clustered. VMFS (in combination with VM cluster/HA/DRS) or (Red Hat) GFS are obviously completely different.

You are totally right. One of my hosts needs access to all LUNs.

I am not that confident with Navisphere that i can do it straightaway. Would you be so kind to confirm that creating a new storage groups containing all LUNs and add my host to it will not mess, create any conflicts with the current storage groups?

I mean a LUN can be in multiple Storage Groups?

 

BTW i would have loved to test it with Navisphere Simulator but i cant download it. Is that only for partners?

 

Thank you.

As long as it's NOT an NTFS formatted LUN, you can do it.

If it's NTFS formatted, I'd suggest considering looking at snapshots.

I've never seen a Navisphere Simulator.

I'd suggest to create a dummy lun and 2 storage groups (that don't have hosts in it) and try assigning the dummy lun to both storage groups.

I used Navisphere Simulation during my Dell training.

 

I have tried to create a new SG to assign all the LUNs my host need access to, but Navisphere won't allow me to doo so. I can only see theLUNs that have not been assigned to any SG.

In my system's Navisphere I can go to a storage group and then "add LUN to storage group". By default it only lists those that are currently not allocated, but through a pull down I can choose to see all LUNs - and it warns me that multiple allocations is not recommended (contention, corruption etc.)

Yes you are right, I couldnt do in test but in my Prod SAN i can do as John said.
Despite the alert when doing so, can someone confirm that creating a new SG to contain all the LUNs so a central backup server can access all LUNs is an OK config, at least to backup VMFS datastores?

 

DevMgr we are using Legato Networker as a central backup. I believe if the backup server has access to the LUNS, then we can create jobs for Windows Server so i dont understand exactly the NTFS restriction you are talking about.

 

 

I'm no storage expert - but as you can see you can do this with the LUNs. The immediate issue is always contention as to who owns the LUN, if two write to it at once you don't know where you'll end up.

Second is a general backup question, made worse by having an external backup mechanism. Is the data in a consistant state when it is backed up - particularly an issue for databases where you can't simply take a snapshot at any old time or you could get it in an inconsistant state.