La continuità dei servizi IT è un requisito sempre più importante per le aziende che dipendono da server, database, applicazioni gestionali, sistemi di autenticazione e servizi di rete per svolgere le proprie attività quotidiane. Un guasto hardware, un problema del sistema operativo, un errore applicativo o un'interruzione dell'alimentazione possono rendere indisponibile un servizio e provocare conseguenze operative significative. Un'architettura di failover server permette di ridurre questo rischio predisponendo uno o più sistemi alternativi in grado di subentrare al nodo principale quando viene rilevato un malfunzionamento. Il failover non consiste semplicemente nell'avere due server, ma richiede una progettazione precisa dei meccanismi di rilevamento del guasto, sincronizzazione dei dati, gestione delle risorse, rete, storage e procedure necessarie per trasferire il servizio da un nodo all'altro.
Che cos'è il failover server
Il failover è il processo attraverso il quale un servizio viene trasferito automaticamente o manualmente da un server principale a un altro sistema quando il nodo attivo non è più in grado di garantire il corretto funzionamento del servizio. Il server secondario può essere già operativo e pronto a subentrare oppure può essere avviato e configurato durante la procedura di recovery, a seconda dell'architettura adottata.
In un ambiente ad alta disponibilità, l'obiettivo è ridurre il tempo durante il quale il servizio rimane indisponibile. Il sistema deve rilevare il problema, determinare che il nodo attivo non è più affidabile, verificare la disponibilità del nodo alternativo e trasferire le risorse necessarie. La velocità e l'affidabilità di questo processo dipendono direttamente dalla progettazione dell'infrastruttura.
Il failover può essere utilizzato per applicazioni web, database, servizi di autenticazione, file server, applicazioni gestionali e altri componenti critici dell'infrastruttura IT.
Alta disponibilità e failover
Failover e alta disponibilità sono concetti strettamente collegati ma non perfettamente equivalenti. L'alta disponibilità, spesso indicata come High Availability o HA, rappresenta l'insieme delle tecnologie e delle configurazioni utilizzate per mantenere operativo un servizio riducendo i punti di interruzione.
Il failover rappresenta invece uno dei meccanismi attraverso i quali viene ottenuta questa continuità. Un'architettura HA può prevedere più nodi, sistemi di replica, storage ridondato, alimentazione ridondata, rete ridondata e software in grado di coordinare il passaggio delle risorse.
L'obiettivo non è eliminare completamente la possibilità di un'interruzione, ma ridurre la probabilità che il guasto di un singolo componente provochi l'indisponibilità del servizio.
Architettura active-passive
Una delle configurazioni più comuni è quella active-passive. In questa architettura un server gestisce normalmente il servizio mentre il secondo rimane disponibile come nodo di standby.
Il nodo passivo monitora lo stato del server principale e mantiene le condizioni necessarie per subentrare in caso di guasto. Quando viene rilevato un problema, il sistema di clustering trasferisce le risorse dal nodo primario a quello secondario.
Questa configurazione è relativamente semplice da gestire e può essere adatta a servizi nei quali non è necessario distribuire il carico tra più server. Il limite principale è che una parte delle risorse hardware del nodo secondario può rimanere inutilizzata durante il normale funzionamento.
Architettura active-active
In una configurazione active-active entrambi i nodi possono elaborare richieste contemporaneamente. Il traffico viene distribuito tra più sistemi e, in caso di guasto di uno dei nodi, le richieste possono essere indirizzate verso quelli ancora disponibili.
Questa architettura può migliorare sia la disponibilità sia l'utilizzo delle risorse, ma richiede una progettazione più complessa. Le applicazioni devono essere compatibili con l'esecuzione su più nodi e i dati devono essere sincronizzati correttamente.
Per i servizi web, ad esempio, più server possono essere collegati a un load balancer che distribuisce le richieste. Se un nodo smette di rispondere, il bilanciatore può rimuoverlo dal pool e continuare a indirizzare il traffico verso i server disponibili.
Rilevamento dei guasti e heartbeat
Uno degli elementi fondamentali di un sistema di failover è il meccanismo utilizzato per determinare lo stato dei nodi. I cluster utilizzano normalmente sistemi di heartbeat attraverso i quali i server comunicano periodicamente la propria disponibilità.
Se un nodo smette di inviare correttamente gli heartbeat, il cluster deve determinare se il problema riguarda effettivamente il server oppure esclusivamente il collegamento di rete. Questa distinzione è importante perché una perdita di connettività non significa necessariamente che il server sia guasto.
Un sistema di failover progettato correttamente deve quindi utilizzare meccanismi di monitoraggio sufficientemente robusti per evitare falsi positivi e passaggi non necessari delle risorse.
Split-brain e quorum
Uno dei problemi più delicati nei cluster è rappresentato dallo split-brain. Questa condizione può verificarsi quando due nodi perdono la capacità di comunicare tra loro ma entrambi ritengono di essere autorizzati a gestire le risorse.
Se entrambi i server tentassero contemporaneamente di modificare gli stessi dati, potrebbero verificarsi corruzione, inconsistenza o conflitti difficili da recuperare.
Per ridurre questo rischio vengono utilizzati meccanismi di quorum e arbitraggio. Il cluster deve poter determinare quale nodo possiede il diritto di mantenere attive determinate risorse quando la comunicazione tra i sistemi viene interrotta.
In ambienti più complessi può essere presente anche un terzo elemento di arbitraggio o una configurazione specifica che consenta al cluster di raggiungere una decisione coerente.
Replica dei dati
Il failover del server non è sufficiente se i dati utilizzati dal servizio non sono disponibili sul nodo secondario. Per questo motivo la sincronizzazione dei dati rappresenta una componente fondamentale dell'architettura.
La replica può essere sincrona o asincrona. Nella replica sincrona, la conferma di una scrittura può dipendere dalla registrazione del dato su più nodi. Questo permette di ridurre il rischio di perdita delle informazioni, ma introduce maggiore latenza e richiede una rete adeguata.
Nella replica asincrona, il nodo principale può completare l'operazione senza attendere necessariamente che il dato sia stato replicato sul sistema secondario. Questa configurazione può offrire prestazioni migliori e funzionare anche su distanze maggiori, ma esiste la possibilità che le modifiche più recenti non siano ancora presenti sul nodo secondario al momento del failover.
La scelta deve quindi essere collegata agli obiettivi di continuità operativa e ai valori di RPO richiesti dal servizio.
Storage condiviso e failover
In alcune architetture i nodi del cluster utilizzano uno storage condiviso. SAN e sistemi di storage ridondati possono fornire ai server un accesso comune ai dati necessari per eseguire le applicazioni.
Questa configurazione permette di trasferire una risorsa da un nodo all'altro senza dover replicare necessariamente l'intero contenuto del disco tra server differenti. Tuttavia, lo storage condiviso diventa a sua volta un componente critico e deve essere progettato senza single point of failure.
Controller, alimentazione, collegamenti di rete e dischi devono essere adeguatamente ridondati. Una configurazione con due server altamente disponibili collegati a un unico storage privo di ridondanza non rappresenta infatti una vera architettura HA.
Failover del database
I database sono tra i servizi che più frequentemente richiedono sistemi di alta disponibilità. Un database non può essere semplicemente riavviato su un secondo server senza considerare la sincronizzazione delle informazioni e la consistenza delle transazioni.
Le tecnologie disponibili cambiano in funzione del database utilizzato. MySQL, MariaDB, PostgreSQL, SQL Server e altri sistemi dispongono di differenti meccanismi di replica, clustering e alta disponibilità.
In un ambiente di produzione è necessario stabilire quale nodo possa diventare primario, come vengono replicate le modifiche e come l'applicazione individua il database attivo. Anche la gestione delle connessioni è importante perché, dopo un failover, i client devono essere in grado di raggiungere il nuovo nodo senza richiedere necessariamente modifiche manuali.
Failover e load balancing
Failover e load balancing possono essere utilizzati insieme. Il load balancer distribuisce le richieste tra più server mentre il meccanismo di health check verifica la disponibilità dei nodi.
Quando un server non risponde correttamente, il load balancer può escluderlo temporaneamente dal pool. Il traffico viene quindi indirizzato verso gli altri nodi disponibili.
Questa architettura è particolarmente adatta ai servizi web perché permette di combinare distribuzione del carico e alta disponibilità. È comunque necessario progettare correttamente anche il bilanciatore, perché se viene utilizzato un singolo dispositivo senza ridondanza può diventare esso stesso un single point of failure.
RTO e RPO nel failover
La progettazione di un sistema di failover deve partire dagli obiettivi di Recovery Time Objective e Recovery Point Objective. L'RTO definisce quanto tempo può trascorrere prima che il servizio venga ripristinato, mentre l'RPO definisce quanta perdita di dati è accettabile in caso di incidente.
Un sistema con RTO molto basso richiede procedure di failover rapide e fortemente automatizzate. Un RPO vicino allo zero richiede invece una strategia di replica capace di mantenere i dati sincronizzati con una perdita minima o nulla delle transazioni.
Questi parametri influenzano direttamente costi, complessità e tecnologia utilizzata. Non esiste quindi un'architettura di failover universalmente valida: la soluzione deve essere dimensionata in base alla criticità del servizio.
Failover automatico e failover manuale
Il passaggio tra server può essere automatico oppure manuale. Nel failover automatico il sistema rileva il problema e trasferisce autonomamente le risorse sul nodo secondario. Questa configurazione permette di ridurre il tempo di intervento, ma richiede sistemi di rilevamento e decisione estremamente affidabili.
Nel failover manuale, invece, un amministratore verifica l'incidente e decide quando attivare il nodo secondario. Questa modalità può essere preferibile quando il rischio di un failover automatico errato è elevato o quando l'applicazione richiede una procedura controllata.
In determinati ambienti possono essere utilizzati meccanismi ibridi nei quali il sistema rileva automaticamente l'anomalia ma richiede una conferma prima di eseguire determinate operazioni.
Testare realmente il failover
Un'infrastruttura di failover non può essere considerata affidabile semplicemente perché il cluster risulta configurato correttamente. È necessario eseguire test periodici nei quali viene simulato il guasto di uno dei componenti.
È possibile simulare la perdita del nodo, l'interruzione della rete, il malfunzionamento di un servizio o la perdita di una risorsa. Durante il test devono essere verificati il tempo necessario per rilevare il problema, la durata del passaggio al nodo secondario e il corretto funzionamento dell'applicazione dopo il failover.
È inoltre importante verificare il failback, cioè il processo attraverso il quale il servizio viene riportato sul nodo originario dopo il ripristino. Un sistema che riesce a effettuare il failover ma non dispone di una procedura sicura di failback può generare problemi durante il ritorno alla configurazione normale.
Monitoraggio dell'infrastruttura
Il monitoraggio è indispensabile per mantenere affidabile un ambiente ad alta disponibilità. Devono essere controllati stato dei nodi, heartbeat, replica dei dati, latenza, utilizzo delle risorse, stato dello storage e disponibilità dei servizi.
Gli alert devono essere configurati per segnalare condizioni anomale prima che si trasformino in un'interruzione. Una replica ferma da diverse ore, ad esempio, potrebbe non produrre immediatamente un disservizio ma rendere inutilizzabile il nodo secondario nel momento in cui dovrebbe subentrare.
Per questo motivo il monitoraggio deve verificare non soltanto se il server è acceso, ma anche se tutti i componenti necessari al failover sono effettivamente operativi.
Failover e backup sono due cose diverse
Un errore frequente consiste nel considerare il failover come una sostituzione del backup. Le due tecnologie hanno obiettivi differenti.
Il failover serve principalmente a mantenere disponibile un servizio quando un componente si guasta. Il backup serve invece a permettere il recupero dei dati in seguito a cancellazioni accidentali, corruzione, errori applicativi, ransomware o altri eventi che possono compromettere anche i dati replicati.
Se un dato corrotto viene replicato automaticamente su tutti i nodi, la replica non permette necessariamente di recuperare la versione precedente. Per questo motivo un'infrastruttura ad alta disponibilità deve continuare a prevedere backup indipendenti e procedure di restore verificate.
Progettare un'architettura di failover server
Un'architettura di failover efficace nasce dall'analisi dei servizi realmente critici. Prima di scegliere server, storage o software di clustering è necessario determinare quali applicazioni devono rimanere disponibili, quale downtime è accettabile e quale perdita di dati può essere tollerata.
Da queste informazioni è possibile progettare la topologia dei nodi, la replica dei dati, la rete, lo storage, il sistema di monitoraggio e le procedure di failover e failback.
L'obiettivo non è semplicemente duplicare un server, ma eliminare progressivamente i single point of failure presenti nell'intera catena tecnologica. Se il server è ridondato ma l'alimentazione, la rete, lo storage o il sistema di autenticazione dipendono da un singolo componente, l'alta disponibilità rimane parziale.
Continuità operativa attraverso la ridondanza
Il failover server rappresenta uno degli elementi fondamentali per progettare infrastrutture IT capaci di continuare a erogare servizi anche in presenza di guasti. La sua efficacia dipende però dall'integrazione tra server, rete, storage, database, applicazioni, sistemi di monitoraggio e procedure di recovery.
Heartbeat, quorum, replica, clustering, load balancing e storage ridondato permettono di costruire architetture nelle quali il guasto di un singolo componente non determina automaticamente l'interruzione del servizio. La progettazione deve essere accompagnata da test periodici, monitoraggio continuo, backup indipendenti e procedure documentate di failover e failback.
Per un'azienda, investire in un'architettura di failover significa quindi progettare l'infrastruttura non soltanto per funzionare quando tutto è operativo, ma soprattutto per continuare a funzionare quando uno dei suoi componenti principali presenta un problema. È questa capacità di gestione controllata del guasto che permette di trasformare la semplice ridondanza hardware in una vera strategia di alta disponibilità e continuità dei servizi IT.
