Disaster Concept: 2 SANs with same data

mgabriel

Renowned Member
Jul 28, 2011
120
15
83
Saarbrücken, Germany
www.inett.de
Hi,

I'm currently in a project with migrating two old XEN servers to two new proxmox machines. There are also two SANs available: One FC SAN - primary, for production - and one iSCSI SAN at a second building in case of fire or other disastrous events. All VMs will run from the FC SAN. The iSCSI SAN is just there waiting for a disaster. To shorten the time in case of a disaster, I'm thinking about the possibilities to be up and running again as early as possible. I had several plans:

1. A software (dm-)raid layer over both storages. This could be the worst thing as swraid kills IOPS performance from my experience. That's nothing I want to have in a production environment.

2. Mirrored LVM LVs. Hard to implement, as it must be done on a LV basis which means that you need to do it manually for every VM disk. Looked good at first, but LVM mirroring is not that easy and not that stable from a conceptual aspect.

3. DRBD. Would work, I guess. Even if it's designed for a totally different solution. In my scenario, I have two servers and two storages, but the servers use the same storage as the primary one and the second is just for disaster. DRBD would work, but doesn't feel right in that scenario.

4. Using ZFS as Filesystem on the storage. zfs send would be able to send incremental updates to the second storage. Not perfect, but should work. On the other side, ZFS is only available as a beta module and therefore not production ready in a linux kernel.

5. Sheepdog. Could be a solution, not sure about it. I've seen some work in proxmox regarding sheepdog, but I'm not sure how far the integration is.

6. Ceph. Look at Sheepdog. Same status, won't be integrated into proxmox, but debian packages available.

7. dd / ddrescue / other_block_based_backup nightly sync. Would work, but isn't the solution that I'm looking for as it involves a few hours downtime and it's not realtime.

8. any other hints?


I'd really appreciate any discussion. Anyone tried something like this? How did you do it?

br,
Marco
 
Hi Marco,
I suggest to move one VM after another. How many VMs do you want to migrate? How big are the disk-files and what format do they have? (raw-files, logical volumes...).

What's about rsync? First rsync during production, after that rsync again (to get an feeling about the downtime) - than stop the VM, another final rsync and start the VM on the new node (the config-file for the VM must setup seperatly). If the machines don't change too much data, this should be not too slow.

Udo
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!