Alta disponibilità con Pacemaker/Corosync: gruppi di risorse, STONITH e prevenzione dello split‑brain

Chi vuole gestire servizi produttivi veramente in alta disponibilità sotto Linux spesso punta su alta disponibilità con Pacemaker/Corosync. Pacemaker è il gestore delle risorse, Corosync fornisce messaging, membership e informazioni sul quorum. Questa guida integra le basi con aspetti operativi più approfonditi: configurazioni STONITH concrete, impiego di SBD, tuning di Corosync, integrazione del monitoraggio, procedure di verifica per i test di fencing e strategie di rollback — il tutto con attenzione all’esercizio, all’integrità dei dati e a migrazioni sicure di soluzioni software a contatto di processo.

Rischi avanzati: quando lo Split‑Brain è particolarmente probabile

Lo Split‑Brain si verifica quando due partizioni del cluster attivano risorse in modo indipendente. Sono particolarmente a rischio le configurazioni con Single‑Writer‑Storage (p.es. LVM/LUN classici senza filesystem cluster), reti di cluster instabili o assenza/malfunzionamento del fencing. Una separazione di rete combinata a un timeout dello storage è uno scenario tipico: una partizione perde la comunicazione Corosync, l’altra continua a vedere il LUN accessibile — entrambe possono diventare Primary.

SBD (STONITH Block Device): quando ha senso e come iniziare

SBD è un meccanismo di fencing che utilizza un dispositivo a blocchi dedicato come token. L’idea: solo il nodo che può detenere il token è autorizzato a eseguire accessi in scrittura. SBD è particolarmente utile quando è disponibile uno SAN esterno o può essere fornito al cluster un piccolo dispositivo a blocchi rapidamente raggiungibile (p.es. un LUN iSCSI).

Configurazione SBD: esempio /etc/sbd.conf

# Minimalbeispiel /etc/sbd.conf
SBD_DEVICE=/dev/sdb
SBD_WATCHDOG=yes
SBD_PACEMAKER=yes
SBD_TIMEOUT=120
SBD_STARTMODE=dual
SBD_OPTS="-p 30"

Spiegazione: SBD_DEVICE è il device condiviso; SBD_WATCHDOG utilizza un watchdog hardware, SBD_PACEMAKER consente l’integrazione con Pacemaker; SBD_TIMEOUT è il tempo di attesa prima del fencing. SBD_STARTMODE=dual permette a due nodi di usare SBD. Testare le modifiche sempre fuori dall’orario operativo.

Installare e avviare SBD (Debian/Ubuntu, simile per varianti RHEL)

# Debian/Ubuntu
apt-get update && apt-get install -y sbd
# RHEL/CentOS
yum install -y sbd

# Starten und prüfen
systemctl enable --now sbd
journalctl -u sbd --no-pager --since "-5m"

Importante: SBD richiede un device condiviso affidabile. Se il device sparisce in modo intermittente, SBD può generare false operazioni di fencing. Testare la persistenza del percorso del device e i percorsi di failover prima della messa in produzione.

STONITH via BMC: esempi IPMI / Redfish e insidie

Il power‑fencing tramite BMC è diffuso perché consente un vero reset hardware. Tuttavia i BMC spesso richiedono configurazioni separate e introducono rischi di sicurezza propri (password di default, reti di management non cifrate).

Esempio: STONITH con fence_ipmilan tramite pcs

# Beispiel: Gerät für „node1“ anlegen (Platzhalter verwenden!)
pcs stonith create fence-node1 fence_ipmilan 
  ipaddr=192.0.2.120 login=ADMIN passwd='SECRET' 
  pcmk_host_list=node1 op monitor interval=60s

# Prüfen
pcs stonith show

Nota: usare credenziali sicure, restrizioni di accesso per la rete di management e controlli a base di ruoli sul BMC. Testare sempre il power‑cycle in modo controllato e documentato.

Redfish: API più moderna

# Beispiel: fence_redfish mit Token (Platzhalter)
pcs stonith create fence-node1-redfish fence_redfish 
  ip=192.0.2.121 user=admin password='SECRET' 
  pcmk_host_list=node1 op monitor interval=60s

Redfish offre API chiare e migliori possibilità di audit. Rimane però la regola fondamentale: accesso al BMC solo tramite una rete di management dedicata, cambiare le credenziali e impostare limiti di accesso.

Corosync‑Tuning: Parameter, die Stabilität bringen

Corosync comunica tramite un Ring; ritardi o perdite di pacchetti causano modifiche ripetute del membership. Tre regolazioni sensate:

• token: tempo massimo che un nodo attende per il suo turno. Un token maggiore riduce la sensibilità a split‑brain in presenza di latenza, ma aumenta la latenza di failover.
• consensus: numero di messaggi necessari per le modifiche di membership; aumenta la protezione contro perdite di pacchetti transitorie.
• join‑timeout / rrp_mode (bei mehreren Ringen): quanto rapidamente sono previste le riconnessioni.

Le modifiche richiedono test in una rete di prova. Piccoli aumenti del token sono spesso preferibili a timeout aggressivi sulle risorse.

Pacemaker Resource‑Meta und Failure‑Handling

Pacemaker offre Meta‑Attribute come migration‑threshold, failure‑timeout oder resource‑stickiness. Questi determinano quante volte e con quale rapidità una risorsa viene migrata o sottoposta a nuovi tentativi dopo un errore.

# Beispiel: Metaparameter setzen
pcs resource meta grp_app migration-threshold=3 failure-timeout=10m 
  resource-stickiness=100

Raccomandazione: resource‑stickiness evita spostamenti inutili avanti e indietro. migration‑threshold limita il numero di tentativi automatici di migrazione, failure‑timeout definisce la finestra temporale per le conte.

Monitoring und Alerting: End‑to‑End statt nur Clusterstatus

Le metriche del cluster da sole non sono sufficienti. Integrate i Prometheus‑Exporter (z. B. crm_exporter oder native pacemaker exporter) con probe end‑to‑end che verifichino la funzionalità del servizio (HTTP‑Healthchecks, DB‑Write/Read). Gli alert dovrebbero fornire indicazioni chiare: Fencing‑Fehler, failover ripetuti, long‑running recovery.

Fencing‑Tests: Sicher, reproduzierbar und auditorisch

Un test di fencing deve soddisfare i seguenti criteri: essere controllabile, riproducibile e documentato. Procedura:

1. Impostare il Maintenance‑Mode (in ambienti di test può essere eseguito anche senza, ma solo con chiara autorizzazione)
2. Backup: pcs config export e salvataggio dei Logs
3. Simulazione di guasto del nodo (z. B. Netzwerk disconnect) e osservazione se il Fencing interviene
4. Verifica: il LUN/FS è realmente offline? Sono stati eseguiti comandi Power‑Off/Reset sul BMC?
5. Documentazione di tutti i passaggi e dei timestamp

# Beispiel: Logs prüfen (Pacemaker, Corosync, SBD)
journalctl -u pacemaker -u corosync -u sbd --since "-30m" --no-pager
# Corosync Quorum Status
corosync-quorumtool -s

Evitare i test durante le ore di punta. Se il Fencing fallisce, un Power‑Off può terminare bruscamente una VM in produzione o rendere inaccessibile un percorso di storage.

Upgrade- und Migrationsstrategie für bestehende Cluster

Gli upgrade del cluster sono rischiosi, perché modifiche allo Messaging‑Stack o ai Resource‑Agents possono alterarne il comportamento. Passi consigliati:

• Piano di rollback e backup della configurazione prima di ogni intervento
• Rolling Upgrade, sofern vom Distributor unterstützt: aggiornare i nodi uno alla volta e verificare il funzionamento del cluster
• Replica dell’ambiente di test: stessa configurazione di storage e condizioni di rete comparabili
• Dopo l’upgrade: periodo di osservazione prolungato, sensibilità di monitoraggio aumentata

Betriebscheckliste: Vor einem produktiven Go‑Live

• Documentazione: diagramma architetturale con Failure Domains, metodi di fencing e finestre di manutenzione
• Controlli end-to-end: VIPs, NS/ARPs, Service‑Bind, DB‑Writes
• Test di fencing: riprodotto con successo almeno una volta e documentato
• Monitoraggio: alert per fencing, failure ripetuti, conteggi di errore elevati
• Backup: snapshot di configurazione e Recovery‑Runbook disponibili

Esempi pratici: insidie tipiche e contromisure

Insidia: i BMC sono nello stesso Management‑VLAN dei client di produzione

Problema: se la rete di produzione cade, anche il BMC non è raggiungibile e il fencing fallisce. Contromisura: spostare i BMC in una rete di management separata o prevedere accessi Out‑of‑Band ridondanti.

Insidia: intervalli di monitoraggio errati

Problema: monitor troppo aggressivi in periodi di alta latenza IO causano flapping. Contromisura: adattare gli intervalli di monitoraggio alle reali condizioni IO, aumentare la resource‑stickiness.

Conclusione: infrastruttura disciplinata anziché la magia della configurazione

High‑Availability con Pacemaker/Corosync funziona in modo affidabile se architettura, fencing e quorum sono progettati come sistema integrato. STONITH non è un «nice to have», ma è imprescindibile per setup Single‑Writer e DRBD. SBD offre un’alternativa robusta quando è disponibile un dispositivo a blocchi condiviso, mentre il BMC‑fencing fornisce una reale isolazione dell’alimentazione. Cruciale è: testare, documentare, integrare il monitoraggio e predisporre piani di rollback. In questo modo lo split‑brain è evitabile e l’operatività diventa pianificabile.

Risorse avanzate: comandi di verifica utili

# Quick‑Checks im Betrieb
pcs status --full
pcs stonith show
corosync-cfgtool -s
corosync-quorumtool -s
# Logs zusammenführen
journalctl -u pacemaker -u corosync -u sbd --since "-2h" --no-pager

FAQ

• STONITH è sempre necessario? Nei Shared‑Storage‑Setups senza Multi‑Writer‑Cluster‑FS e nel caso di DRBD, STONITH è obbligatorio. In architetture con storage completamente distribuito e coerenza integrata può a volte essere evitato, ma la decisione richiede una comprensione precisa della semantica dello storage.
• Come testo SBD senza mettere a rischio i dati di produzione? Utilizzi una Test‑LUN con struttura di percorsi identica, simuli guasti dei nodi e verifichi se il trasferimento del token e il fencing funzionano come previsto. Documenti le differenze rispetto all’ambiente di produzione.
• E se il fencing fallisce? Modalità di maintenance immediata, analisi della raggiungibilità di BMC/Storage ed esecuzione del piano di recovery. In situazioni critiche il funzionamento controllato a singolo nodo è spesso più sicuro di azioni automatiche non affidabili.

High‑Availability con Pacemaker/Corosync: qdevice, vincoli di risorse e Recovery‑Runbook

In aggiunta a STONITH e SBD vale la pena considerare tre ambiti operativi spesso trascurati ma che influenzano significativamente la stabilità: l’impiego di un Quorum‑Witness esterno (qdevice/qnetd), vincoli di risorse ben definiti (Order/Colocation) e un Recovery‑Runbook pragmatico per casi reali di split‑brain. Questi aspetti riguardano architettura, automazione e il ritorno sicuro alla normale operatività – rilevanti per l’esercizio di soluzioni software prossime al processo con storage condiviso o VIP‑Failover.

qdevice (Quorum Witness) vs. SBD: quando utilizzare quale pattern?

qdevice (auch qnetd genannt) offre un piccolo servizio witness esterno che fornisce voti in situazioni di quorum ridotto. Vantaggio: non richiede dispositivi a blocchi condivisi, basso overhead, più semplice nelle configurazioni Cloud/VM. Svantaggio: il witness deve essere raggiungibile e performante; in caso di partizioni di rete offre vantaggio solo se rimane chiaramente raggiungibile.

SBD è basato su hardware o storage e protegge a livello di block device. Scegliete qdevice se non potete fornire LUNs condivise o in ambienti virtualizzati con una piccola VM witness esterna. Scegliete SBD per ambienti fisici con un SAN‑Path affidabile e quando è necessaria una garanzia di fencing basata su token.

Note pratiche per il funzionamento di qdevice

• Posizione del witness: preferibilmente in una terza sede o in un segmento di rete separato, in modo che non falsi la decisione in caso di split a due nodi.
• Resilienza: gestite qdevice in HA (sono possibili due istanze witness pronte con Floating‑IP) oppure utilizzate un witness ospitato in cloud se le connessioni di rete sono stabili.
• Monitoring: monitorate la liveness e la RTT verso il witness; latenze variabili possono causare Membership‑Flapping.

Ressourcen‑Constraints: Reihenfolge und Kollokation richtig modellieren

Molti problemi di failover nascono perché i servizi vengono avviati nell’ordine sbagliato o posizionati su nodi diversi. Usate consapevolmente Order‑ e Colocation‑Constraints per imporre le dipendenze:

# Beispiel: sicherstellen, dass das Filesystem zuerst startet, dann die Applikation
pcs constraint order start fs_resource then app_resource
# Beispiel: Applikation muss auf dem selben Knoten wie das gemountete Filesystem laufen
pcs constraint colocation add app_resource with fs_resource INFINITY

Spiegazione: l’Order‑Constraint previene problemi di timing (p.es. l’app si avvia prima che il FS sia pronto). La Colocation‑Constraint impedisce che l’applicazione giri su un nodo che non ha accesso allo storage.

Multipath und Device‑Persistenz

Le dipendenze da dispositivi a blocchi condivisi richiedono nomi di device stabili. Utilizzate WWIDs persistenti, configurate multipathd in modo appropriato e preservate le regole udev. Se cambi di percorso o eventi di timeout rendono il LUN temporaneamente invisibile, il cluster lo interpreta rapidamente come un Node‑Failure – con potenziale fencing errato.

Recovery‑Runbook: sichere Schritte bei vermutetem Split‑Brain

Un runbook chiaro e testato evita azioni avventate. Esempio di procedura prima di intervenire:

1. Informate gli stakeholder e aprite una finestra di manutenzione. Attivate, se necessario, un livello di allarme globale, in modo che script automatici non intervengano ulteriormente.
2. Salvate configurazione e log: pcs config export > /root/pcs-config-$(date +%F).xml e raccogliete le uscite di journalctl.
3. Isolate i nodi: fermate Pacemaker su almeno un nodo se volete verificare l’integrità di un supporto (systemctl stop pacemaker).
4. Identificate il dataset con l’autorità più alta (p.es. quale replica aveva per ultima i diritti di scrittura, per DRBD: Primary). Documentate timestamp e metriche IO.
5. Se è chiaro quale sia il nodo autorevole: replicate i dati (in base alla tecnologia di storage), riportate l’altro nodo in uno stato pulito e reinseritelo nel cluster in modo controllato.
6. Dopo il ripristino: fase di monitoraggio prolungata, allarmi più sensibili e verifica manuale dei controlli end‑to‑end (VIP, DB‑Writes, log applicativi).

Importante: evitate il „force‑join“ automatico senza verifica della consistenza dei dati. Documentate ogni passaggio in modo che eventuali analisi forensi siano possibili.

Automazione, controllo delle configurazioni e strategia di test

Mantenete le configurazioni del cluster versionate (Git) e automatizzate tramite playbook verificati. Testate automaticamente scenari di fencing e quorum in laboratori in stile CI/CD (p.es. staging basato su Vagrant/VM). Solo playbook verificati e ripetibili possono eseguire modifiche a Pacemaker/Corosync in produzione.

Queste integrazioni aiutano a ridurre i rischi architetturali e operativi: un witness adeguato, vincoli chiari e un runbook di ripristino testato fanno la differenza tra failover occasionali e un’operatività pianificabile e auditabile.

Per questo tema sono inoltre importanti i cluster Pacemaker e lo Stonith Fencing. Il contributo contestualizza questi aspetti in modo comprensibile e mostra su cosa concentrarsi nella pratica quotidiana.