Hi NetApp Community! This is more of a VMware question, but I thought I would post it here too in case there were NetApp specific answers that I might not get from the VMware forums...
I've just recently aquired a NetApp FAS2240-2 (HA) for my datacenter. I have had an engineer come out and install it and do some knowledge transfer, and now I'm ready to hit the ground running. My first priority is to get my VMs off of local storage and onto the NetApp so I can really start getting the most out of vCenter. I just have 2 quick questions:
First, I have a questions about LUNs, and how they work across ESXi clusters. In my environment, I will have 2 ESXi clusters of 3 machines each. This is because Dell recommends not putting processors of significant difference into clusters together, even if you're using EVC, etc. So, I will have 2 initiator groups, 1 per cluster, and I will also have several LUNs for use as datastores divided amongst my OS versions for maximum deduplication. My question is whether to associate the 2 igroups with the same LUNs or to create separate LUNs per cluster using 1 igroup per. I am aware that I cannot vMotion between clusters/igroups just like I can't vMotion across 2 stand alone hosts that are not clustered. I would have to shut down the guest and migrate both host/cluster and datastore. For the sake of simplicity and storage efficiency (avoiding the additional snapshot overhead, etc), I would prefer to point both igroups at the same LUNs. Does anyone see any reason not to do this?
Secondly, I have questions about offloading the the VMs swap space in each cluster. The idea is to create datastores where ESXi swap will take place rather than having a swap file inside the VM itself so that the swap datastores won't be deduped or mirrored, thus saving space in my DR filer. My NetApp engineer showed me where to configure these settings in vCenter, but the way he explained it working does not appear to be a best practice according to the other articles I've read. If I understood him correctly, he would have me create a swap LUN per host and link that LUN to the given host ONLY (through a separate igroup I think). However, in the NetApp documentation and several forums I have read, the best practice appears to be to create a swap LUN that all hosts in a cluster share just like any other datastore. NetApp doc TR-3749 seems to indicate that isolating the swap datastores per host (using local storage or otherwise I guess) negatively impacts vMotion times, even though it still works. Is this how you guys are doing swap?
I'm using vCenter 4.1 and ESXi 4.1u2 (Dell) on all of the relavent hosts...
To illustrate my question, I want my environment to look like this...
According to the SAN best practices TR which I will attach a link to it states the following:
When provisioning LUNs for access via FC or iSCSI, the LUNs must be masked so that only the
appropriate hosts can connect to the LUNs. With a NetApp FAS system, LUN masking is
handled by the creation of initiator groups. NetApp recommends creating an igroup for each
VMware cluster. NetApp also recommends including in the name of the igroup the name of the
cluster and the protocol type (for example, DC1_FCP and DC1_iSCSI). This naming convention
and method simplify the management of igroups by reducing the total number created. It also
means that all ESX Servers in the cluster see each LUN at the same ID. Each initiator group
includes all of the FCP worldwide port names (WWPNs) or iSCSI qualified names (IQNs) of the
ESX Servers in the VMware cluster.
As far as your second question that one may more tricky simply due to the paging and how much you are doing and how hard that might hit the filer, that one I may not be the best person to answer but it will require some testing most likely to see.
Thanks for responding Brian, but this really doesn't answer my question. I already know how initiator groups work. I have read the the document that you sent, and I have read the VMware document that it references, but neither addresses either of my questions directly. The VMware document talks about higher level concepts rather than actual practical design, but there is a section on VMFS which discusses how that file system segregates and protects VM files, so that's encouraging. I really don't see any reason why this wouldn't work, I just hate to put it into production without some kind of reassurance...