Passa al contenuto principale

Tuning di Corosync su WAN e Ripristino "Safe" del Cluster

Questa guida illustra come diagnosticare i riavvii improvvisi (Fencing) e come configurare un cluster Proxmox per operare correttamente quando i nodi sono distribuiti su reti geografiche (WAN).

1. Comprendere il problema: Il meccanismo di "Fencing"​

In un cluster Proxmox con HA attivo, i nodi devono essere in costante comunicazione. Se un nodo perde il contatto con gli altri, interviene un protocollo di sicurezza chiamato Fencing.

Il sistema ipotizza che il nodo isolato possa causare corruzioni dei dati. Per prevenire questo rischio, un timer di sicurezza (Watchdog) riavvia forzatamente la macchina. Non è un errore, ma un'azione protettiva per garantire l'integrità del cluster.

Diagnosi rapida​

Per capire se un riavvio è stato causato dal Fencing, analizziamo i log del boot precedente:

journalctl -b -1 -e --no-pager | grep -v audit

Cosa cercare: Messaggi come [TOTEM] Token has not been received o watchdog-mux: client watchdog expired. Se presenti, il problema è la stabilità della rete.

2. La Soluzione: Adattare il Cluster alla Rete (WAN Tuning)​

Le impostazioni standard di Proxmox sono fatte per nodi che viaggiano sulla stessa rete locale (LAN) e quindi non hanno latenze. Se i server comunicano via Internet, è necessario aumentare la tolleranza ai ritardi dal momento che si possono manifestare con maggiore frequenza.

Modifica della configurazione​

La modifica va fatta solo su un nodo nel file del cluster filesystem. Incrementare sempre il config_version per forzare l'aggiornamento.

nano /etc/pve/corosync.conf

Parametri consigliati per WAN:

totem {
  ...
  config_version: 10  # Incrementare di 1 rispetto al valore attuale
  
  token: 10000        # Aspetta 10 secondi prima di dichiarare un nodo "down"
  consensus: 12000    # Tempo per la decisione collettiva (deve essere > token)
  join: 60            # Tempo massimo per l'ingresso di un nuovo nodo
  
  knet_pmtud_interval: 0  # Disabilita il ricalcolo continuo dell'MTU (evita micro-interruzioni)
  ...
}

Proxmox utilizza il filesystem pmxcfs (cartella /etc/pve/) come "unica fonte di verità". Tutti i nodi leggono da lì. Il file /etc/corosync/corosync.conf deve essere solo un collegamento simbolico (Symlink) che punta al file condiviso.

Verifica dell'integrità​

Controllare su ogni nodo lo stato del file:

ls -la /etc/corosync/corosync.conf
  • OK: lrwxrwxrwx ... /etc/corosync/corosync.conf -> /etc/pve/corosync.conf
  • ERRORE: -rw-r--r-- ... /etc/corosync/corosync.conf (Indica che il nodo è scollegato dal "cervello" del cluster).

4. Procedura di ripristino in sicurezza (Zero Downtime)​

Se trovi un file fisico al posto del collegamento, devi ripristinare il link. Per evitare che il server rimanga senza istruzioni anche solo per un istante (rischiando un riavvio), usa la sostituzione atomica:

  1. Crea il nuovo collegamento temporaneo:

    ln -s /etc/pve/corosync.conf /etc/corosync/corosync.conf.new

  2. Sostituisci il file istantaneamente:

    mv /etc/corosync/corosync.conf.new /etc/corosync/corosync.conf

Con il comando mv, lo scambio avviene in un microsecondo: il servizio Corosync non percepirà alcuna interruzione.

5. Verifica Finale​

Una volta sistemati i collegamenti su tutti i nodi, controlla che il cluster sia sincronizzato e che tutti i nodi vedano la stessa versione della configurazione:

pvecm status

Risultato atteso: * Quorate: Yes

  • Config Version: (Il numero impostato al punto 2)
  • Tutti i nodi elencati come attivi nella Membership information.

Regola d'oro: Da questo momento in poi, ogni modifica alla rete del cluster deve essere effettuata esclusivamente editando il file in /etc/pve/corosync.conf.