Guide

Proxmox 5.x: cluster, HA, replica e Live Migration

Obiettivo di questo articolo

Familiarizzare con le funzionalità del cluster Proxmox VE come: l’HA, la Replica e la funzione di Live Migration

Software utilizzato

Proxmox VE ver. 5.0 (ma replicabile sulle versione 5.x)

Hardware utilizzato

3 A3Server ogniuno equipaggiato con 4 dischi SSD da 1TB e 128GB di RAM.
I nodi li abbiamo chiamati PVE5, PVE6, PVE7.

Introduzione

Prima di cominciare abbiamo creato un cluster Proxmox VE di 3 nodi (se non lo avete già fatto, consultate la nostra guida) e lanciato i seguenti comandi per aggiornarlo, e installare alcuni pacchetti base Debian che ci tornano utili per eventuali troubleshooting.

# apt updare
# apt upgrade
# apt install htop iotop

Replica

Il processo di Replica permette appunto di “replicare”, copiare una vm, da un nodo ad un altro nodo del Cluster, mentre la macchina è in run.
Il Job di Replica viene eseguito ad intervalli regolari, che è possibile programmare in base alle esigenze specifiche della vm in oggetto, e fa una replica completa nella prima esecuzione, e del solo differenziale nelle successive.

Con questa funzione è, dunque, possibile progettare dove far ripartire la vm in caso di fault del nodo in cui è in running.
La ripartenza della vm, in caso di fault del nodo in cui è in running, può essere automatica, l’HA, oppure manuale.

Questa funzione può essere utilizzata anche come backup della vm al posto del vzdump (che non fa i differenziali) ma, purtroppo, non c’è (al momento della stesura di questo articolo) un tasto di restore dalla replica.
Per utilizzare il file replicato come backup di una vm compromessa, si deve spostare manualmente sull’host anche il file di configurazione della vm.

Configurazione

Prerequisiti:

  • Proxmox 5.0 o superiore.
  • Filesistem ZFS
  • Cluster di 3 nodi.

La configurazione è molto semplice e si fa mediante interfaccia grafica.

Datacenter — Replication

CT/VM ID:          numero della VM o CT che voglio replicare.
Target:                 è la destinazione o contenitore delle mie repliche.
Schedule:           è la schedulazione dei task.

Per esempio:
*/1= una volta ogni minuto (praticamente continua).
*/5 = una volta ogni 5 minuti

Rate Limit (MB/s):          serve per limitare l’I/O durante il processo di replica. Questo parametro è molto utile durante la prima sincronizzazione, proprio per limitare l’I/O sul disco e ridurre eventuale I/O delay.

Comment:          Commento testuale al task.

Diamo ok e completiamo il processo di creazione del task. Per vedere se un task sta girando oppure no, andiamo sul nodo dove è residente la VM e clicchiamo su replication:

Lo stato del task ci informa su cosa sta succedendo sul singolo nodo. E’ permesso solo un task di replica alla vota per nodo. Quindi non è possibile lanciare task concorrenti di vm residenti sullo stesso host fisico.

Si può notare che le vm replicate sul nodo target PVE7 sono visibili fisicamente sullo storage locale:

Con la replica posso quindi ottenere i seguenti benefici:

  • Backup “incrementali” di vm su altri nodi.
  • Live migration delle vm tra un nodo e l’altro senza l’uso di storage condivisi (attesa dalla versione 5.1 in poi).

Replica + HA su storage locale

Per avere il vero beneficio occorre configurare sia la replica che l’HA.

La parte di guida che segue, mostra come è possibile configurare la parte di HA in un cluster Proxmox VE 5.x e definire delle “politiche” di migrazione (dette groups) tra i nodi del cluster, così da assegnare delle priorità.

Prerequisiti:

  • Proxmox 5.0 (o superiore)
  • Filesistem ZFS
  • Cluster di 3 nodi: PVE5 – PVE6 – PVE7
  • Replica di una vm (su storage local-zfs)

Nell’immagine seguente, la vm 1111 fisicamente in running sul nodo PVE6, viene replicata sul nodo target PVE7:

Procediamo quindi alla configurazione dell’HA.

L’obiettivo è configurare il cluster in modo che la vm 1111, residente sullo storage local-zfs, e replicata su PVE7, parta automaticamente in caso di fault del nodo PVE6.

Come prima cosa, clicchiamo su Datacenter – HAGroups

La vm 1111 ha come nodo prioritario in nodo PVE6 (cioè il nodo in cui si trova la vm in running normalmente), per questo mettiamo il parametro Priority a 1.
Come secondo nodo selezioniamo PVE7, che è il nodo target, e assegniamo la Priority a 2.

Restricted: se abilitato, impedisce alle vm assegnate al gruppo di essere eseguite su altri nodi. Se non esistono nodi attivi appartenenti al gruppo, la risorsa viane messa in stato stopped.
Se non abilitato, le vm possono essere eseguite su tutti i nodi di cluster. Se tutti i nodi del gruppo non sono in linea, ma migreranno indietro appena un membro del gruppo viene in linea.

Nofailback:  Se non abilitato, il Cluster Resource Manager tenta di eseguire le VM sul nodo con la massima priorità a prescindere da dove si trovi quella VM nel momento in cui attivo la regola. Se un nodo con priorità più alta va (o torna) in linea, il CRM migra la VM su quel nodo. Se abilitato impedisce tale comportamento.
A meno che non si sappia cosa si sta facendo, è consigliabile abilitarlo!!!

Priority: Questo parametro merita molta attenzione. Più il numero è alto e più la priorità è alta.

Nota: se sbaglio a definire la priorità sul gruppo, ed attivo una regola di HA, inizierà immediatamente una migrazione. Una volta creato il group posso creare l’HA.

Datacenter – HA –  compilo i campi come di seguito:

CT/VM ID: numero della VM o CT che voglio replicare.
Max. Restart: numero di volte che tenta di far partire la vm
Max. Relocate: numero di volte che tenta di ricollocare fisicamente la vm (con una move), seguendo l’ordine della policy di Groups definita.
Group: seleziono la politica di gruppo creata in precedenza.
Request state: stato in cui la vm viene forzata ad attivate la regola di HA.

Cliccando su Add, e creando le regole di HA per entrambe le vm, otterremo quanto mostrato in di seguito:

Simulazione di fault

Adesso che la configurazione di HA è terminata, possiamo scollegare fisicamente il nodo PVE6, e simulare quindi un fault improvviso del nodo per osservare cosa succede.

Fase 1: il cluster si accorge che il PVE6 è offline

Dopo circa un minuto, il sistema provvede a spostare l’esecuzione delle vm da PVE6 a PVE7:

Si noti che, per come è stata fatta la configurazione, anche quando il nodo PVE6 torna online ed il Cluster riconquista il Quorate YES, le due vm rimangono sul nodo PVE7 e non tornano sul PVE6.

Live Migration with Local ZFS area

Esempio di commando:

# qm migrate <ID_VM_NUMBER> <target_node_name> –online –with-local-disks

Per limitare la velocità di migrazione:

# qm set <vmid> [OPTIONS] 
–migrate_speed <integer> (0 – N) (default = 0) Set maximum speed (in MB/s) for migrations. Value 0 is no limit.

Esempio

# qm set 100 –migrate_speed 50

Nota: La Live migration funziona solo se la vm ha determinate caratteristiche. E’ necessario che ci siano i driver virtIO installati, le nic e i dischi siano virtIO (o scsi virtIO), e i qemu agent installati. In caso contrario la migration fallisce con una serie di errori.

L’informazione riportata è presa dal forum ufficiale di Proxmox VE.

Live migration da GUI

Le nostre VM di prova erano running sul nodo PVE6; provando ad eseguire la Live Migration ci restituisce il seguente errore:

2017-09-18 15:38:46 starting migration of VM 1111 to node ‘pve7’ (192.168.131.127)
2017-09-18 15:38:46 found local disk ‘local-zfs:vm-1111-disk-1’ (in current VM config)
2017-09-18 15:38:46 can’t migrate local disk ‘local-zfs:vm-1111-disk-1’: can’t live migrate attached local disks without with-local-disks option
2017-09-18 15:38:46 ERROR: Failed to sync data – can’t migrate VM – check log
2017-09-18 15:38:46 aborting phase 1 – cleanup resources
2017-09-18 15:38:46 ERROR: migration aborted (duration 00:00:00): Failed to sync data – can’t migrate VM – check log
TASK ERROR: migration aborted

C’è un bug che verrà risolto nelle future versioni, per ora è possibile ovviare al problema lanciando il comando da CLI. A tal proposito vedere il paragrafo più avanti Live Migration with Local ZFS.

  ti posso interessare anche