I'm having a problem with a MD3200i and our new T710 virtual server - it works, but performance is absolutely abysmal. Here's the details....
Server is a T710, 4 onboard nics + a 4 port Intel Server NIC. Its running the latest update of ESXi 4.1 - right now it has 6 hosts on it, going to be 10 total (most are lightly loaded special purpose servers). Server is connected to the SAN by 4 cables direct from the 4 port Intel Server NIC to the 4 ports on the management controller
We have 4 drives (2TB SAS) in the SAN - not my first choice - but what the customer wanted. Array is set up as a RAID-10. We have 3 logical volumes - 2 TB, 1 TB, and 750 GB. Each is formatted as a VMFS datastore.
I followed the instructions in the Dell whitepaper for setting up the MD3200 with ESX 4.1 and it doesn't appear we have multpathing working correctly. The VCenter Client is only showing 6 paths usable - should be 12 total (3x volumes * 4 network cards).
I've gone through the docs a handful of times, can't find anything that strikes me as an obvious problem. Below is the output of some of the commands in the documentation - if anything else would be helpful let me know. I feel like i'm running in to a brick wall here, any advice would be great!
Thanks in advance....
~ # esxcfg-nics -l Name PCI Driver Link Speed Duplex MAC Address MTU Description vmnic0 0000:01:00.00 bnx2 Up 1000Mbps Full 00:25:64:fe:51:c1 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T vmnic1 0000:01:00.01 bnx2 Down 0Mbps Half 00:25:64:fe:51:c3 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T vmnic2 0000:02:00.00 bnx2 Down 0Mbps Half 00:25:64:fe:51:c5 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T vmnic3 0000:02:00.01 bnx2 Down 0Mbps Half 00:25:64:fe:51:c7 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T vmnic4 0000:83:00.00 igb Up 1000Mbps Full 00:1b:21:77:3b:08 9000 Intel Corporation 82576 Gigabit Network Connection vmnic5 0000:83:00.01 igb Up 1000Mbps Full 00:1b:21:77:3b:09 9000 Intel Corporation 82576 Gigabit Network Connection vmnic6 0000:84:00.00 igb Up 1000Mbps Full 00:1b:21:77:3b:0c 9000 Intel Corporation 82576 Gigabit Network Connection vmnic7 0000:84:00.01 igb Up 1000Mbps Full 00:1b:21:77:3b:0d 9000 Intel Corporation 82576 Gigabit Network Connection
~ # esxcfg-swiscsi -q Software iSCSI is enabled
~ # esxcfg-scsidevs -a vmhba0 ata_piix link-n/a sata.vmhba0 (0:0:31.2) Intel Corporation 2 port SATA IDE Controller (ICH9) vmhba1 mptsas link-n/a sas.5842b2b04cd6af00 (0:3:0.0) LSI Logic / Symbios Logic Dell SAS 6/iR Integrated vmhba32 ata_piix link-n/a sata.vmhba32 (0:0:31.2) Intel Corporation 2 port SATA IDE Controller (ICH9) vmhba33 iscsi_vmk online iqn.1998-01.com.vmware:spag-261d8287 iSCSI Software Adapter
This is a very nice opening post as it provides the info that's needed to begin to figure this out. One thing that's missing is the "esxcli swiscsi nic list -d vmhba 33". This output confirms if the vmkernels were assigned to the iSCSI initiator.
Your problem is that you are using a single subnet for the whole iSCSI setup.
Each NIC (that you want to use for iSCSI) needs it's own subnet. If you cannot get (from your network group) more than the 10.10.102.0-255 range, just subnet it with a 27 bit subnet mask. Gateways are irrelevant as I doubt your server is going to try to connect to a SAN in a completely different network, so you don't have to worry about needing to make/create additional gateways on the switch(es).
Here is an example setup based on your IP ranges and modifying them with a 27 bit (255.255.255.224) subnet mask (to prevent needing to get more IP ranges):
SAN iSCSI ports:
Controller 0:
iSCSI port 0: 10.100.102.1
iSCSI port 1: 10.100.102.33
iSCSI port 2: 10.100.102.65
iSCSI port 3: 10.100.102.97
Controller 1:
iSCSI port 0: 10.100.102.2
iSCSI port 1: 10.100.102.34
iSCSI port 2: 10.100.102.66
iSCSI port 3: 10.100.102.98
Server iSCSI info (in a context that's hopefully understandable):
This isn't so much an MD3200i recommendation, but just a general storage recommendation for ESX/ESXi; limit your virtual disks (their sizes) to a size that can hold no more than 4 or 5 VMs. Optimal is a single virtual disk per VM even.
The reason for this is that when a VM wants to write to it's disk, the datastore where this VM is located gets locked (from being written to) to allow this one VM to write it's data. Therefor, if you have too many VMs on a single datastore, they'll end up having to wait for eachother to finish writing before they can write their own data.
This doesn't affect the general raid configuration concerns of course, as these recommendations are due to the VMFS filesystem limitations. So, you can definitely make a single raid set and carve it into multiple virtual disks if you think the drives and raid type can handle the total IO.
Yep, that was it, worked perfectly. As soon as I got everything set up on separate subnets, all the paths work fine. Odd thing is in the Dell documentation it shows it as being all in the same subnet - good thing to note for future reference.
Any other tips for performance tuning with ESXi 4.1 & a MD3200i?
This thread has a lot of excellent information, but I'm still left with a related question:
What if one is just direct-connecting two servers straight to the MD3220i over iSCSI? We're planning on cabling like this:
Each individual colour is a unique subnet. So if I take the above example, ports 0,1,2,3 on each MD3220i controller is in a unique subnet, but that means the Hyper-V host will only be able to access that subnet on a single controller.
Would it be recommended to us only 2 subnets in this configuration?
Actually, you can place a lot more vms on a datastore. I have some with 20+. I never spread volumes over multiple LUNs, so the 2TB limit per LUN keeps from having more.
IO from VMs does not require locks. It's IO that creates or removes stuff not from existing VMs that do... (Well, if you use sparse files then I/O from VMs could be an issue as they may need to grow, so my advice assumes storage is dedicated per VM).
Snapshots can cause changes, logs, creating and deleting vms, etc... So unless you add/remove VMs a lot, or have more than a couple of VMs with snapshots enabled, don't worry how many VMs you put in each.
Also, the locking is more an issue for the number of host servers, not the number of VMs. Vmware only locks out other hosts when changing the size of files. The VMs inside are already locked to the vm, and so don't slow down. It's just operations that add/remove/grow files outside the vm that are impacted (or inside if you use snapshots or don't preallocate the storage as that can cause growth).
If you do it right you can have a dozen VM hosts all with access to a single VMFS that has 30 vms on it on a single 2TB volume.
It doesn't matter that each host can connect to only 1 controller on a single subnet. As long as you setup all your iSCSI sessions correctly, you will be able to access your data redundantly. It might be easiest to set up your iSCSI sessions if you use 4 separate subnets. However, if you find it easier, 2 subnets will also work.
One thing to remember if you are using newer Linux releases like RHEL 5.5 and SLES 11.1... by default, all IO on a subnet will go out of only 1 port even if you have multiple NICs on the same subnet. So, for those scenarios, using 4 subnets would be required.
Apologies for re-opening this call. My setup is a Dell R610 connecting to an MD3200i.
I followed the same setup guide so assumed that both the iSCSI host ports and VMKernel should be on the same subnet. However, I've followed your example and split them into their own subnets.
Here's my current setup:
RAID Controller Module 0
iSCSI host port 0 : 10.20.0.1/29 iSCSI host port 1 : 10.20.0.8/29 iSCSI host port 2 : 10.20.0.15/29 iSCSI host port 3 : 10.20.0.22/29
RAID Controller Module 1
iSCSI host port 0 : 10.20.0.2/29 iSCSI host port 1 : 10.20.0.9/29 iSCSI host port 2 : 10.20.0.16/29 iSCSI host port 3 : 10.20.0.23/29
Thanks for the quick reply. So my vmware setup looks ok?
On the MDSM, as a test I setup 2x 500gbs in RAID0. I've assigned these to the host group rather than the server as we will be adding an additional vmware server in.
After you do the dynamic discovery, you do still need to register the server in the MDSM application, then create the diskgroup(s) and virtual disk(s), and assign them to the server.
NOTE: Keep in mind that virtual disks cannot be larger than "2TB minus 512 bytes" (see VMware's configuration maximums guide (direct link to the pdf, so I'm not sure how long this link will be good once a newer version than 4.1 comes out)).
Dev Mgr
6 Operator
•
9308 Posts
•
3 Points
1832
1
Posted October 28th, 2010 11:00
This is a very nice opening post as it provides the info that's needed to begin to figure this out. One thing that's missing is the "esxcli swiscsi nic list -d vmhba 33". This output confirms if the vmkernels were assigned to the iSCSI initiator.
Your problem is that you are using a single subnet for the whole iSCSI setup.
Each NIC (that you want to use for iSCSI) needs it's own subnet. If you cannot get (from your network group) more than the 10.10.102.0-255 range, just subnet it with a 27 bit subnet mask. Gateways are irrelevant as I doubt your server is going to try to connect to a SAN in a completely different network, so you don't have to worry about needing to make/create additional gateways on the switch(es).
Here is an example setup based on your IP ranges and modifying them with a 27 bit (255.255.255.224) subnet mask (to prevent needing to get more IP ranges):
SAN iSCSI ports:
Controller 0:
iSCSI port 0: 10.100.102.1
iSCSI port 1: 10.100.102.33
iSCSI port 2: 10.100.102.65
iSCSI port 3: 10.100.102.97
Controller 1:
iSCSI port 0: 10.100.102.2
iSCSI port 1: 10.100.102.34
iSCSI port 2: 10.100.102.66
iSCSI port 3: 10.100.102.98
Server iSCSI info (in a context that's hopefully understandable):
- vmnic7 -> iSCSI Network -> vmk1 -> 10.100.102.3
- vmnic6 -> iSCSI Network 2 -> vmk2 -> 10.100.102.35
- vmnic5 -> iSCSI Network 3 -> vmk3 -> 10.100.102.67
- vmnic4 -> iSCSI Network 4 -> vmk4 -> 10.100.102.99
Does this info make sense?