Alright, so I want to start leveraging my SAN a little more than I have been, and at the same time, take advantage of ESXi.
Currently, I've got an array of Dell PowerEdge 1955 blades connected to a single-enclosure EMC AX4-5 FC storage array. I'm essentially using the SAN as DAS. I've got LUNs on the SAN that are pointing at specific physical machines, and those machines utilize the LUNs for whatever (mostly databases and Samba/NFS shares, depending on the target server).
I've got multiple physical file servers, and each one has a samba config setup to serve the appropriate shares. Since I never got RHCS to work, only one of the file servers has the LUNs mounted at a time. In the event that a fileserver dies, I fence it manually (either by unmounting and unpresenting the drive, using the navisphere utility, or by killing the power via DRAC) then use the navisphere utility to bring up the presented LUNs on the next contender (after which, start apache and the other daemons). All by hand, right now.
I feel sort off like Ferris Bueller playing the clarinet. Never had a lesson!
Anyway, I'm trying to improve. What I want to do is install ESXi on the physical hosts, then create LUNs to hold two fileserver images (in case one gets corrupt/fubar), one of which will be the active, the other will be the standby. At least this way, I don't improve the automation (although I'll get around to writing a script to switch the "active" server at some point soon), but I feel like I'm adding flexibility, plus I can use the ESXi hosts to hold other VMs, and the hardware won't be wasted, like it is now.
My questions are:
1) How stupid is my plan?
2) When it comes to the actual implementation, should I create a normal vmdk image on the LUN, or should I give it a "raw" partition (if that's even possible with ESXi?)
3) Is there a "good" way to use non-clustered fileservers?
Best Answer
Your plan is not nuts. As usual, there's more than a few ways to attack this based on what you're trying to achieve and how to protect your data.
First up, you can present a raw LUN to a VM using a "Raw Device Mapping". To do this:
Upside: fast to set up, fast to use, easy, can represent the disk to physical host if you find yourself needing to V2P down the track
Downside: you may lose some VMware-based snapshot/rollback options, depending on if you use physical or virtual compatibility mode
An alternate option is to create VMFS on the LUN to create a datastore, then add a VMDK disk to the VM living on that datastore.
In both cases, you're in a similar risk position should VMware or your VM eat the filesystem during a failure; one is not drastically better than the other although what recovery options will be available will be quite different.
I don't deploy RDM's unless I have to; I've found they don't buy me much flexibility as a VMDK (and I've been bitten by bugs that made them impractical when performing other storage operations (since fixed - see RDM section in that link))
As for your VM, your best bet for flexibility is to store your fileserver's boot disk as a VMDK on the SAN so that you can have other hosts boot it in the case of a host failure. Using VMware's HA functionality, booting your VM on another host is automatic (the VM will boot on the second host as if the power had been pulled; expect to perform the usual fsck's and magic to bring it up as in the case of a normal server). Note, HA is a licensed feature.
To mitigate against a VM failure, you can build a light clone of your fileserver, containing the bare minimum required to boot and have SAMBA start in a configured state and store this on each host's local disk, awaiting you to add the data drive from the failed VM and power it on.
This may or may not buy you extra options in the case of a SAN failure; best case scenario, your data storage will require a fsck or other repair, but at least you don't have to fix, rebuild or configure the VM on top. Worst case, you've lost the data and need to go back to tape... but you were already in that state anyway.