Mirroring VMFS Volumes?

[jbaxter714]

Basic question: Is there a way with ESX 3.x to "mirror" your VMFS volume onto two different iSCSI LUNs?

In other words, for high-availability, I would like to have two entirely separate storage arrays each have a 300GB LUN, and present it to the ESX server using iSCSI, then put one 300GB VMFS volume mirrored across the two 300GB LUNs. So that if either storage array (or path to it, or whatever) goes down, the VMFS and virtual servers hosted on it will keep humming along with no problems.

I believe this can be done natively on Windows Server 2003, for example (and if not, I know you could do it with Symantec Veritas Volume Manager).

Just to be clear - I am not talking about MPIO, which I believe is just about multiple-paths to the same LUN. I'm talking about two different LUNs presented from two different arrays. I looked at the ESX VMFS extent option, but that seems to be about extending a VMFS across disks, not mirroring it.

I'm also aware I could do this with an external software or hardware-based storage virtualization platform, but then that becomes a single-point-of-failure (or at the very least, ends up costing me more money). I really want to do this host-based (ie on the ESX server).

Thanks in advance.

[dominic7]

Basic Answer: no

There are many ways of getting what you want done, but they all involve some more complexity, cost or both. There are a number of products that will allow you to mirror at the storage level, or at the VM level but VMware has not provided any included ability to mirror a VMFS.

[cmanucy]

You could easily do this with the OS's built-in mirroring... just create the 2nd LUN, setup another 300G drive, attach it to the guest, set both disks for dynamic (in the case of Windows), and mirror.

Many SANs offer volume/array mirroring, but it normally does cost more money. There are other software options like Double-Take as well.

----

Carter Manucy

[dmorgan]

I think both answers are correct. Yes AND No...

The reason I say this is the first reply is correct, No, you cannot mirror a VMFS volume the way you want to.

However, YES, you can set up two differernt LUNS to host two different .vmdk volumes, and use Windows mirroring like the second response indicated. Which would, in theory, since I haven't tried this, give you the redundancy you are looking for.

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[ctfoster]

Not really. To get the LUNS to mirror across your storage arrays you'll need something like MirrorView on the CX range or some other propriety mechanisms used other storage vendors. Then you have the problem of getting your ESX to switch across which is not going to be automatic. As you probably realise you may need to invest in some SAN virtualisation software to pull this off such as DataCore. There are others ways to replicate data but not in the seamless way you describe.

[jbaxter714]

Carter -

Sure I could do it in the guest for the guest's data, but for the actual VMDK on the VMFS, there doesn't appear to be a way to mirror.

I'm just a bit surprised that ESX on the server-side itself doesn't let us do the mirroring like Windows does. I know most high-end storage arrays are supposed to be very highly-available with clustered controllers, etc, etc, but it sure would be nice to be able to mirror my VMFS onto two totally separate storage arrays without the need for any third-party software/hardware in between (that could also potentially be a single point of failure).

[dmorgan]

But, if you have two seperate datastores located on two seperate LUN's, and each .vmdk on each LUN is mirrored in the OS to the other, doesn't that accomplisht what you are looking for? If one .vmdk was down, the other would continue to run, would it not?

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[Rodos]

I'm just a bit surprised that ESX on the server-side itself doesn't let us do the mirroring like Windows does. I know most high-end storage arrays are supposed to be very highly-available with clustered controllers, etc, etc, but it sure would be nice to be able to mirror my VMFS onto two totally separate storage arrays without the need for any third-party software/hardware in between (that could also potentially be a single point of failure).

Um .. I wonder if VMWare are working on this already ... would make senses .... lets wait and see. Write a VMDK file to two locations (different storage) for HA.

Considering awarding points if this is of use

[cmanucy]

I can think of a few reasons why they wouldn't do this. Probably the biggest reason is that there's better ways to handle replication (on a hardware level) than at the software level (like how VMWare would be doing it).

Since so many vendors provide this, and it's generally something you do pay for, I'm sure there's some kind of pressure on VMWare to not provide these services as well... and oh yeah, what's the name of that company? EMC? They might have something to say about it as well

One other thought, however - you COULD present the volume via NFS and replicate at that host level. A poor man's replicated SAN

----

Carter Manucy

[dominic7]

But, if you have two seperate datastores located on two seperate LUN's, and each .vmdk on each LUN is mirrored in the OS to the other, doesn't that accomplisht what you are looking for? If one .vmdk was down, the other would continue to run, would it not?

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

I haven't tried this since VI3 came out, but it used to be "sort of" in the 2.5 days. IIRC The VM would continue to run, but VMware ESX ( at least in 2.5.x ) wasn't designed to deal with virtual hardware failure. Once you lost one of your virtual disks, I don't think it would ever come back online. Also, once the VMFS was lost the VMs all had to be editied to remove the failed virtual disk, which of course requires you to reboot the VM. In the end it wasn't a workable solution. Feel free to test it out and prove me wrong =).