Management Networks and SAN Snapshotting

Thank you so much for your input, Don. I really appreciate it. Your answer regarding multiple volumes makes complete sense to me. Since I'm using multipathing (via VMware round robin) I'm assuming I need to balance my number of iSCSI connections to the SAN with the performance benefits offered by multiple volumes. I suspect this won't be as much of an issue with current firmware versus older (I know the iSCSI connection number limit was doubled in recent firmware).

I already have SanHQ 2.20 installed so I can use that to look at my current queue depths. I also did some poking around the forums and I see there is some LUN design talk as it relates to VMware. I understand there is no one-size-fits-all solution so I'll tackle all that next.

If I see in SANHQ 2.20 that my queue level never hits 32 do you imagine I would see less performance benefits to chopping my LUNs up into smaller pieces? I imagine more iSCSI connections at the same time is better, I just want to make sure that the pain of redesigning and copying all my VMs into additional smaller LUNs is going to be worth it.

Should I limit my redesign scope to focus on servers that use the most IOPS? It'd basically be my single Exchange 2010 box, two separate SQL servers, and my file server.

Thanks for all the great info, excellent post. I'm using vSphere 5 Standard. I did some testing with the iops value when I first got my SANs and setting it to 3 didn't improve my results with iometer (using settings to take advantage of the 1MB block size) so I didn't keep the change. I understand now why I didn't see improvement with iometer - I knew the results wouldn't be 'real world' but I didn't know how else to test. I'm glad the consensus is to set it to 3.

Now I've set my iops value to 3, disabled LRO, and turned delayed ACK off on all my hosts. The LRO thing was new to me so thanks for mentioning it! I know there is a lot of information out there about lun design and sql/exchange best practices so I'll read up on that stuff next.

Thanks again for taking the time to reply.

Those would actually create a support case via the Equallogic Website. Alerts from SANHQ do not.

Hey Don, can you confirm that this is still advisable in vSphere 5.0 when using Round Robin?  (I dug around some Dell / EQL docs, but it didn't mention it.  For some reason I thought this was no longer an issue.  You covered the LRO command line change, but what was the string needed for setting the IOPs to 3 (under vsphere 5)?  What have you found as the best way to monitor the balance of the RR?

Wow... I overlooked this somehow.  Thanks Don.  Having previously set each datastore to RR, I did execute the following on one of my datastores:

#esxcli storage nmp psp roundrobin deviceconfig set -d naa.6090a09860213c7843eb34e9380180de -I 3 -t iops

Looking at the details again via esxcli storage nmp device list, I see that the "iops=3" validated the change, but I also see the the string "policy=rr" was changed to "policy=iops"  Is this expected?

Also, is it advisable that this only be performed while in maintenance mode, or can it be changed while in production?

Perfect.  The test I had done was on a system in maintenance mode.  Just wanted to verify.  Thanks.

Thanks for the link to rinetd, Don. I plan on forwarding NTP and SMTP traffic from my isolated iscsi network onto my production network via my physical backup server. Seems like a better idea than routing that traffic...why make things more complicated than they need to be, right?

Interesting... observation.  I took a host into maint mode, and of the datastores it was connected to (already set to RR), I applied the "esxcli storage nmp psp roundrobin deviceconfig set -d naa.[idnumber] -I 3 -t iops".  Verified all of the changes.  Took it out of maintenance mode, threw a couple of VM's on it.  Ran Iometer on one of them.  Then I went into vcenter on the realtime monitoring of the Network, and isolated just the two NICs associated with my iSCSI vswitch.  And I still only see one of them being used.  Weird...

I know I'd probably solve all of this by just installing and using the MEM, but that looks fairly involved from what I can tell.

In each of the given vmkernel ports, in the NIC Teaming tab, where I have one "active" and one "unused", all of the "Policy Exceptions" do not have a tick next to any of them, but the Failback does have a grayed out "yes"  For the actual vmkernel ports, the "Override switch failover order" is ticked so that one can be set as active, and one as unused.

I'll have to experiment on one of my other hosts for the MEM.  I see the latest one just came out for 5.0, so that might give me a little inspiration (along with currently only utilizing one NIC).

Gotcha.  I did that (ticked the checkbox, setting it to no), rescanned the volumes for good measure, and ran another test.  still pulling off of just one vnic.  

Yeah, I'm all vsphere 5.0, so maybe I'll give that a try sometime soon.  It would be nice to figure this one out though.  Hmm...

Good idea.  Thanks for the good info Don.  Much appreciated.  Hopefully I can thank you in person at the DSF this year.

Well thats a shame.  ...Oh, as for the issue.  Tech support lead me down the right road to the cause.  The lack of the vmkernel port bindings under the iSCSI software adapter.  Fixed, and everything is fine now.