Most efficient way to move solo 4.4 to cluster 6.2?

[hefferbub]

I have a stand-alone server running v4.4 with ZFS and I would like to move it to 6.2 with minimal downtime, as well as set things up for easier future maintenance and upgrades. It has a number of VMs totaling less than 500 GB of storage, but my backup times (to a Synology NAS) are running close to 14 hours currently, so that makes a standard backup/restore awkward. This server has a dual 10Gbe interface, however it has not been in use so far, instead I have a 2x 1Gbe bond in use.

I have purchased a second server, less powerful, but enough to run my critical VMs when the big server is down. This server also has a dual 10Gbe interface and has all-SSD ZFS storage. I expect to connect this new server to the old over a private host-to-host 10GBe link, as I don’t yet have a 10Gbe switch.

I suspect it will be most useful going forward if I end up with a cluster of 6.2 machines. These could be HA or not, as I can tolerate offline migrations as long as they take less than an hour. I have a small low-power HP-620+ which I can use as a third cluster member to address quorum issues If HA makes the most sense.

Can anyone advise on the best way to get from here to there with minimal downtime on the current server?

Thanks!

 

[spirit]

Hi.

you can't create a cluster with v4 + v5, but it's possible with v5 + v6.

So, I think the easiest way, could be to upgrade your v4 to v5 (downtime = reboot time).

Then upgrade your v5 to corosync3 (like a v6 migration).

Then you can use zfs replication in your vms to migrate to new server. (I'll use zfs replication, so with incremental snapshot,but it require a little reboot of the vm to live migrate).

or you can upgrade your first node to v5 then v6. (so 2 reboots), then use zfs replication. (last proxmox6 can also migrate live vm + zfs replication)

 

[hefferbub]

Thanks. That makes a lot of sense, although I still need to shutdown and backup the VMs on the original server in case the update goes south.

If I have the new server up, non clustered, I could back up more quickly to it somehow. Perhaps using PVE-Zsync?

What makes sense to you?

 

[spirit]

Thanks. That makes a lot of sense, although I still need to shutdown and backup the VMs on the original server in case the update goes south.

If I have the new server up, non clustered, I could back up more quickly to it somehow. Perhaps using PVE-Zsync?

What makes sense to you?

I'm not sure you can use pve-zsync across 2 non clustered node, but it could be tested indeed.
https://pve.proxmox.com/wiki/PVE-zsync#PVE_Storage_Replication_and_PVE-zsync

"
Sync a VM or ZFS dataset one time
(N.B. this is also possible if a recurring job for that VM already exists, here you must have in mind that the naming in --name must be the same).

root@zfs1:~# pve-zsync sync --source 100 --dest 192.168.1.2:tank/backup --verbose --maxsnap 2 --name test1 --limit 512
"

 

[hefferbub]

Thanks Spirit. I was able to test your suggestion, and it does work to use pve-zsync outside of a cluster to a new 6.2 machine. Here is what I did:

1. Create a new Zvol (volume) in the default zpool on the target server: zfs create rpool/mybackups
2. On source server ensure that there is a password-less ssh capability with the target server. I first did an ssh login to the target server’s IP address (and verified I wanted to save the key in “known_hosts”). I then issued the command ssh-copy-id <Target-IP-address> from the source server. Then when I tried another ssh login, it worked without a password. Note that if there is a separate interface for host-to-host syncing, use that IP address for the target server.
3. I then performed a one-time sync pushing VM 130 from my source to my target server:
   pve-zsync sync --source 130 --dest 192.168.1.2:rpool/mybackups --verbose --maxsnap 1 --name test1. The first time I ran this it took about 12 minutes to copy. I was able to run it again a few hours later and it only took about a minute to update any changed blocks, so that makes it easy to update things quickly at the start of the downtime when I update the original server.
4. Once that completed, I could test the viability of the transfer by shutting down the VM on the source server and bringing it up on the target. In this case, I followed the procedure from https://pve.proxmox.com/wiki/PVE-zsync#Recovering_an_VM. The only difference was, when editing the conf file to update the storage, the line looked like this: scsi0: local-zfs:vm-130-disk-1,size=18G, where the default name for the ZFS volume holding the VMs is now “local-zfs” on 6.2 instead of what they say on that page.