Proxmox ve HA Cluster

Postato il

logoIn questo post  vedremo come realizzare un HA Failover Cluster utilizzando due nodi di proxmox ve 3.4.
Con l’implementazione di un cluster, si è in grado di bilanciare il carico di lavoro su diversi host, ed è generalmente consigliato per essere distribuito su almeno tre nodi per aumentare la disponibilità delle macchine virtuali (HA).
All’interno del cluster
è possibile eseguire la migrazione in tempo reale (live) delle macchine virtuali, anche se non si dispone di storage condiviso ed in  caso di manutenzione hardware, è possibile spostare “al volo” le macchine virtuali su un altro nodo, senza tempi di inattività (o downtime limitato), infatti se una macchina virtuale o contenitore (VM o CT) è configurato come HA e un host fisico va in failure la VM viene riavviata automaticamente su uno degli altri nodi che compone il cluster.
Prima di tutto occorre aggiornare tutti i nodi che faranno parte del cluster proxmox ve che nell’esempio sono proxmox01 e proxmox02.
Dalla versione 3 di proxmox sono state modificati i repository degli aggiornamenti e se non si dispone di una subscription occorre modificare i sorgenti per poter aggiornare i sistemi:


nano
/etc/apt/sources.list.d/pve-enterprise.list

modificare:

deb https://enterprise.proxmox.com/debian wheezy pve-enterprise

in:

deb http://download.proxmox.com/debian wheezy pve-no-subscription

 Dopo aver salvato il file occorre aggiornare il sistema e fare un riavvio:

apt-get update && apt-get upgrade -y && reboot

Ora che i nodi sono aggiornati per creare un Cluster HA occorre, sul nodo primario, definire il nome della risorsa Cluster da console con il comando:

pvecm create YOUR-CLUSTER-NAME (nell’esempio Cluster-HA)

pve01

verificare lo stato del cluster:

pvecm status

pve02

Occorre ora fare login via SSH sul nodo secondario e digitare il comando:

pvecm add IP-CLUSTER  (del nodo primario che nell’esempio 192.168.64.130)

pve03

poi si riverifica lo stato del cluster sempre sul nodo secondario:

pve03-1

Per verificare i membri del cluster digitare il comando

pvecm nodes

pve04

Ora basta collegarsi all’interfaccia web di uno qualunque dei nodi per gestire tutto il cluster:

pve05

Tramite il tab “HA” verifichiamo da interfaccia web la configurazione del cluster:

pve06

Ora per testare la funzionalità del cluster aggiungiamo allo stesso per semplicità uno storage NFS condiviso:

pve07

pve08

Verifichiamo che lo storage sia correttamente visto da entrambi i nodi che compongono il cluster:

pve09

 

Dopo aver creato una macchina virtuale possiamo verificare la corretta live migration da un nodo del cluster all’altro, nell ‘esempio una vm ubuntu (100):

pve10

Con il tasto destro del mouse selezionare “Migrate” per avviare la migrazione a caldo della vm dal nodo primario proxmox01 al nodo secondario proxmox02:

pve11

pve12

Dal live log è possibile monitorare la migrazione della vm e lo stato del task:

pve13

Ed ecco la vm accesa sul nodo secondario del cluster:

pve14

Altra funzione fondamentale del cluster è l’alta affidabilità (HA) delle macchine virtuali, ovvero la possibilità di averle sempre on line anche se un nodo del cluster dovesse andare failover.
Dal menù “Datacenter” nel tab “HA” occorre definire quali sono le risorse che vogliamo siano protette in alta affidabilità.

pve15

Aggiungiamo la macchina di test con ID 100 e con “Activate” confermo:

pve16

Come si vede ora la vm 100 è gestita dall’ HA ed in carico al nodo proxmox02:

pve17
Per verificare l’alta affidabilità del cluster spegniamo  il nodo secondario e verifichiamo che la macchina virtuale sia migrata in automatico sul nodo primario proxmox01:

pve19

Ed ecco la vm accesa e funzionante sul nodo prxmox01 avendo perso solo qualche ping.

pve20

Come abbiamo potuto verificare il processo di creazione del cluster non è complesso ma chiaramente in un ambiente di produzione è necessario configurare adeguatamente il fencing, il networking ovvero creare delle vlan separate specifiche per il traffico dell’heartbeat del cluster, del live migration per le macchine virtuali, etc e utilizzare almeno 3 nodi per gestire al meglio il funzionamento del cluster in termini di quorum e alta affidabilità dell’intera infrastruttura.

IZ

10 pensieri riguardo “Proxmox ve HA Cluster

    Martino Chiro ha detto:
    14/07/2015 alle 20:34

    Interessante, mi chiedo se e’ sensato confrontare la soluzione HA di PROXMOX con quella di VMWARE. Cosa si perde/guadagna con l’una o l’altra ?

    wassy ha detto:
    04/11/2015 alle 17:26

    Ciao grandissimo articolo, sto cercando piu informazioni possibili sull’argomento prima di mettere su un nuovo impianto, quindi vorrei porti 3 quesiti e scusami se ti sembo banale, magari saprai consigliarmi dove riempire le mie lacune:
    – mi sembra di capire che la soluzione ottimale sia quella di avere uno shared device alla base del cluster, invece in questo articolo migri le macchine senza disporre di alcun dispositivo di questo tipo, quale è la differenza? Ipotizzo sia un questione di tempi nella migrazione.. quanto tempo ci mette in piu a migrare senza shared device?
    – non sono riuscito a capire il perchè siano necessari 3 nodi per rendere il cluster affidabile, cioè cosa vuol dire affidabile? o funziona o non funziona no? potresti spiegarmi in che termini usare un cluster HA con soli 2 nodi possa essere compromettente in un sistema magari messo in produzione?
    – se uso uno shared device alla base del cluster, ipotizziamo che sia rappresentato ad esempio da un server che offre il servizio iSCSI, non credi che perdo automaticamente il concetto di HA? nel senso che se va giu il server che condivide il disco poi mi va giu anche tutto il cluster no?
    grazie mille

      Ivan ha risposto:
      05/11/2015 alle 12:43

      Ciao wass🙂
      ti rispondo per punti:
      1) Nell’articolo, che vuole solo mostrare la funzionalità, è utilizzato si uno storage NFS (per mia comodità) condiviso, che viene aggiunto al cluster e quindi visto da entrambi i nodi.
      Lo storage su cui sono le vm, in un ambiente di produzione, deve essere ridondato come un cluster a sua volta o su una san.
      2)Il cluster funziona non è questo il punto ma di capacità e di distribuzione del carico di ogni singolo nodo.
      Ti faccio un esempio: hai due nodi in cluster e su ognuno hai 5 macchine virtuali. In caso di failover ogni server deve poter prendersi in carico le vm dell’altro nodo quindi nell’esempio ogni nodo deve poter sopportare il carico di 10 vm e non di 5 in termini di cpu e ram.
      Ecco perchè avere piu nodi ti permette di distribuire su più server le vm dei nodi che vanno in failure e di non averne di non utilizzati.
      Questo può essere d’aiuto:
      https://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations
      3) come dicevo al punto 1 anche lo storage va ridondato oppure puoi utilizzare lo storage locale dei nodi che compongono il cluster utilizzando sistemi distribuiti come DRBD.

      IZ

        wassy ha detto:
        10/11/2015 alle 10:07

        io ti ringrazio tantissimo, purtroppo non mi è arrivata la notifica e ho letto solo adesso, rubo un minuto del tuo preziosissimo tempo per un ultima domanda. Allora sono riuscito a mettere su i 2 nodi in ha con uno storage DRBD hostato sui 2 stessi nodi come da tuo consiglio, questa è sicuramente per me una soluzione comoda e considerando che si tratta di 2 macchine virtuali semplici(un server di posta per 50 utenze e server my sql per un massimo di una 20ina di query per volta)non ho necessità di prestazioni onerose. Ma non capisco un concetto: se spengo o riavvio uno dei nodi è vero che automaticamente le macchine virtuali migrano sull’altro nodo, però questo avviene proprio perchè nella fase di arresto o riavvio intervengono i processi che si occupano di migrare le macchine, ma se io spengo malomodo il nodo(per intederci stacco la spina)questi processi non hanno il tempo di inizializzarsi e le macchine vanno giu.. ecco ma che alta disponibilità è se le macchine le devo spegnere io per far intervenire la gestione delle migrazioni? si suppone che dovrebbe proteggermi da un guasto non da un mio reboot.. tra l’altro io cosi non sono nemmeno tanto protetto perchè le macchine virtuali(intese come file di configurazione)risiedono solo sul nodo che le hosta in quel momento e non su entrambi, quindi se è un nodo muore le perdo per sempre. mi dai qualche consiglio su questo argomento? grazie mille

    wassy ha detto:
    10/11/2015 alle 15:17

    forse mi sono perso un pezzo anche se il fencing sulle interfacce iLo lo avevo configurato, proverò a seguire la guida che hai riportato.. per quanto riguarda le macchine non credo siano condivise.. io vedo che la cartella /etc/pve è condivisa ma la cartella /etc/pve/qemu-server non lo è, nel senso che se do ls su una macchina non è uguale per l’altra.. me lo puoi confermare?
    a proposito di fencing mi sembra di capire che la V4 includa degli automatismi sull’argomento e volevo provarla ma leggo anche che per fare un cluster HA è obbligatorio con la V4 avere 3 nodi quindi è da abbandonare almeno nel mio caso.. Vabbè provo a seguire la guida postata e ti riporto il risulta in questi giorni. Grazie lo stesso.
    PS:wass mi chiamano gli amici di sempre eheheh ci hai beccatto

      Ivan ha risposto:
      11/11/2015 alle 14:15

      Caro wass🙂
      tutto il contenuto della cartella /etc/pve deve essere condiviso altrimenti l’HA non funzionerà correttamente.

      Ivan

    claudio p ha detto:
    13/07/2016 alle 16:51

    Ciao grazie per la guida molto utile,

    anche io ho uno storage NFS condiviso , al momento e’ collegato a piu nodi alla principale interfaccia eth0 dove anche vmbr0 e’ definito , noto che le prestazioni di una VM sullo storage NFS e’ decisamente piu scarsa , secondo te potrebbe migliorare se provo a collego lo storgare NFS sulla seconda eth1 creando una VLAN separata settando su eth1 / switch porta / NFS con un MTU a 9000 ?

      Ivan ha risposto:
      18/07/2016 alle 19:40

      Ciao Claudio,

      come regola generale è sempre meglio avere un’interfaccia di rete dedicata ad una funzione es una al management, una o piu (aggregate) allo storage, una per il live migration, una per le iso, etc..male di sicuro non farà!😉

      IZ

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...