Unsolved
This post is more than 5 years old
3 Posts
0
22361
August 15th, 2010 01:00
MD3000 Single Port Clustering with VMWare 4.0?
I'm currently running a 2 node VMWare cluster. Its a non-redundant 2 host setup with two raid controllers. Each node has a single cable to it's own single port raid controller on the MD3000. There is a shared LUN that both hosts use as common datastore. This configuration seems to be working fine, except I constantly receive notices about the 'Preferred Path' issue as each server tries to read or write to the drive.
Is this an acceptable use of the MD3000? Should I install the Single Port Clustering NVSRAM to suppress the preferred path errors? Or am I doing something unsafe? From my point of view the VM disks a thick provisioned and VMFS is a cluster filesystem, so it shouldn't be an issue. I was hoping someone who knows the guts of this hardware could chime in.


eek_ru
15 Posts
0
August 15th, 2010 09:00
As I know md3000 is not supported by vmware for shared storage and clustering. Only non shared storages. You can check it any time on vmware site in HCL list.
But if it does work in your configuration as shared storage, please do me a favor, write some details. (FW version, controllers and others). I have one in production and it dosen't do shared storage for vmware.
dopry
3 Posts
0
August 15th, 2010 13:00
Here is a quick overview of my setup.
What I have setup are two ESXi 4.0 hosts with SAS 5/e HBAs each cabled to one single port controller in a Dell MD3000. Right now they're just pointed at a 4 disk raid 1+0 with a 750GB VMFS virtual disk, and 3 60GB disks setup for RDM. Both ESX hosts are setup in a storage group on the controller. I just upgraded it to the second generation firmware.
We're running Vsphere Essentials, so we don't have a lot of VMware magic like VMotion and such. Our administrative VMs (Domain Controllers, SQL Server, Virtual Center/WhatsUp, Vyatta) are all clustered within the environment. There is a node on each physical host attached to local storage. These VMs should stay running in the even of a shared storage or individual host failure. Our development VMs live in the shared storage and are running on one ESX host at any given time. The remaining VM's are development environments and live on the shared VMFS pool. This way I can shut them down on one host and start them on another. It requires a little manual work., but is pretty easy to script. Each of our ESX Hosts are fully capable of running all of our VMs, but I wanted to be able to spread the load out when the environment isn't running in a degraded state, and bring get the VMs back online on the other other if a storage controller or physical hosts fails.
It's my ghetto cluster, but I don't have a single point of failure and I did it on a shoe string as proof of concept. I have to prove it's utility before I can get the budget for a proper deployment. The powers that be want to know that it will be 500K well spent.
I chose the MD3000 after reading up on a number of products. The constant reference to active/active controllers, mirrored cache, and VMWare support with second gen firmware gave me confidence that this deployment would work.
<ADMIN NOTE: Broken link has been removed / replaced from this post by Dell>
http://www.dell.com/downloads/global/products/pvaul/en/powervault_md30000_specs.pdf
http://www.vmware.com/resources/compatibility/detail.php?device_cat=san&device_id=4924
My reasoning for having faith in this configuration:
Given that VMHOSTA and VMHOSTB each have their own HBA connected to SP1 and SP2 on the MD3000 respectively and are sharing VDISKA, as long as the storage controllers maintain cache coherency VMFS, being a cluster file system, should prevent both hosts from trying to write the same blocks at the same time.
I'm starting to wonder whether the Single Port controllers actually provide the active/active environment support and mirrored cache. Currently it appears to be running in AVT mode with controllers fighting for control of the disk. This kills the performace. I watch VMs stall as I see the array state change in the MD Storage Manager Client.
I guess my actual query is can I safely disable AVT and go about my merry way? Is that what the Single Port Clustering NVSRAM provides or are there other toggles I should play with? I could also just take the easy route and upgrade to 2xdual port controllers and double cable everything so only one controller is active at a time... Which make the active/active and mirrored cache features that Dell advertises misleading at best and outright false advertising at worst.
troubadix
2 Posts
0
September 22nd, 2010 08:00
I found this post really helpful, because I also plan to do a similar setup and didn't find a lot of postings doing this with MD3000. Most people seem to use iSCSI, but as far as my research went I cannot use Multipathing and Jumbo frames features with the free ESXi license. This seems to be problematic for me from a performance point of view. At the moment I have no budget to buy a VMWare license, but we own a MD3000 that isn't used for any kind of clustering at the moment. As I found out from VMWare HCL it is supported to use MD3000 as a storage.
At the moment we only have one single port RAID Controller and I would like to buy an additional 2 port controller to get this working.
Does anyone have any hints if I run into problems with the free ESXi, when running a VM on shared storage and I want to manually (or by script) start it on a secondary host for maintenance of the primary ESXi host ?
JOHNADCO
2 Intern
•
847 Posts
0
September 22nd, 2010 10:00
Single port controllers have the write cache suspended by default.
If I remember correctly you need to disable mirror'd cache then enable write cache with battery for all virtual disks.
If this is not done, all single controller MD3000i's suck to be blunt.
We use quite a few single controller MD3000i's, not that they are awesome performers, but they are getting the job done even with ultra slow cruddy SATA drives.
dopry
3 Posts
0
September 22nd, 2010 10:00
After much work and testing I discovered that there is not way to actually disable the AVT mode and two controllers accessing the same lun will always be fighting for ownership. I tried customizing the NVSRAM many ways to get the desired functionality to no avail. You really need to be using the dual port controllers in passive/active if you're accessing the same LUN. If they're accessing different LUNS the active/active controller model works.
Dev Mgr
6 Operator
•
9.3K Posts
•
3 Points
0
September 22nd, 2010 11:00
One note about the free ESXi; it only supports a single processor (that processor can have multiple cores and those cores will be fully usable).
troubadix
2 Posts
0
September 22nd, 2010 11:00
Yes this seems to be true for ESXi 4.0. I recently installed one host with ESXi 4.1 and got a new licence key from VMWare. Now it shows "Licensed for 2 physical CPUs (1-6 cores per CPU).
JOHNADCO
2 Intern
•
847 Posts
0
September 22nd, 2010 14:00
Hmm even our 3.5esxi hosts used two procs and up to 6 cores each.