Progettare reti ad alta disponibilità per server sempre online

Obiettivo della rete alta disponibilità

Per tenere un servizio sempre online non basta avere due server. La disponibilità reale si gioca sulla rete: collegamenti, switch, gateway, DNS, bilanciatori, storage e percorsi di fallback devono fallire in modo prevedibile senza interrompere il traffico.

La regola pratica è semplice: eliminare i punti singoli di guasto, ridurre il tempo di rilevazione del problema e automatizzare il passaggio al nodo o al percorso alternativo. Se uno di questi tre elementi manca, la rete non è davvero ad alta disponibilità.

Il punto di partenza è definire il livello di servizio atteso: quanta interruzione è accettabile, quali componenti devono restare attivi in caso di guasto e quale perdita di sessioni è tollerata. Senza questi vincoli, si rischia di progettare ridondanza costosa ma inutile.

Disegno base: nessun componente critico deve stare da solo

La topologia minima per un ambiente serio prevede almeno due percorsi indipendenti dal server verso la rete esterna. Questo significa, in pratica, due NIC, due switch se possibile, due uplink, due gateway o un meccanismo equivalente e alimentazioni separate per i componenti di rete.

Se i server sono virtualizzati, la ridondanza va spostata anche sull’hypervisor e sul fabric sottostante. Un host con due schede ma collegato allo stesso switch fisico degli altri non elimina il guasto di dominio. La vera domanda è: quale evento spegne contemporaneamente il maggior numero di percorsi?

Un buon disegno separa i piani:

• piano dati: traffico applicativo e utenti;
• piano gestione: accesso amministrativo, monitoraggio, backup;
• piano storage: replica, accesso a SAN, NFS, iSCSI o object storage;
• piano identity: DNS, directory, autenticazione, certificati.

Se questi piani condividono lo stesso switch o lo stesso gateway, il guasto di rete diventa rapidamente un guasto di piattaforma.

Ridondanza di link e interfacce

Le tecniche più comuni per rendere robusto il collegamento di rete sono bonding, teaming, LACP e multipath a livello di trasporto o storage. La scelta dipende dal tipo di traffico e dal comportamento richiesto in failover.

Per il traffico server standard, l’approccio più comune è una coppia di interfacce con bonding in modalità adatta alla piattaforma. In ambienti Linux, il bonding può servire sia per continuità sia per aggregazione. Ma non tutte le modalità offrono lo stesso comportamento: alcune bilanciano, altre fanno solo failover. Serve distinguere tra aumento di banda e alta disponibilità.

Per lo storage, la logica è simile ma i vincoli sono più stretti. Se il database o il filesystem distribuito dipendono da una rete dedicata, quella rete deve avere percorsi fisici separati, MTU coerente, latenza stabile e monitoraggio specifico. La perdita del percorso storage spesso si traduce in blocco applicativo prima ancora che in errore visibile al client.

La verifica minima su Linux è controllare stato interfacce, bonding e route. Esempi utili:

ip link show
ip addr show
cat /proc/net/bonding/bond0
ip route show

Quello che vuoi vedere è che il link secondario sia realmente pronto, che il bond continui a passare traffico quando una porta viene rimossa e che il gateway alternativo sia raggiungibile senza intervento manuale.

Due switch non bastano se condividono lo stesso dominio di errore

Molti ambienti dichiarano ridondanza perché usano due switch, ma poi li alimentano dalla stessa PDU, li montano nello stesso rack o li collegano agli stessi uplink. In quel caso il rischio resta concentrato. La ridondanza utile separa fisicamente i guasti probabili: alimentazione, cavi, modulo ottico, chassis, percorso verso il core.

In pratica, il percorso corretto è spesso questo:

1. ogni server ha almeno due NIC;
2. le NIC terminano su switch diversi;
3. gli switch hanno alimentazioni separate;
4. gli switch salgono verso core o router diversi;
5. il routing di uscita tollera la perdita di uno dei due percorsi.

Se il budget è limitato, conviene proteggere prima il collo di bottiglia: un solo switch d’accesso ben monitorato e con alimentazione separata spesso è più utile di una ridondanza parziale distribuita male.

Gateway, routing e failover del primo hop

Quando un server perde il gateway, è offline anche se tutto il resto funziona. Per questo il primo hop va progettato con attenzione. Le opzioni tipiche sono VRRP, HSRP, routing dinamico o una coppia di gateway con health check e failover automatico.

In ambienti Linux o virtualizzati, VRRP è spesso la soluzione più semplice per garantire una IP virtuale che si sposta tra due nodi. Il criterio non è solo la presenza dell’IP, ma la capacità del nodo attivo di raggiungere davvero upstream e servizi critici. Se il failover si basa solo sul link locale, si rischia di mantenere attivo un gateway isolato.

La verifica minima è semplice: il gateway virtuale deve cambiare proprietario quando il nodo primario perde connettività o servizio. Il test va fatto anche in caso di guasto parziale, non solo di spegnimento netto. Un buon setup deve reagire a:

• link down;
• perdita di route verso upstream;
• assenza di risposta dal monitor esterno;
• saturazione o errore del processo di routing.

Se usi routing dinamico, la parte importante è il tuning dei timer e delle policy. Timer troppo lenti rendono il failover percepibile; timer troppo aggressivi fanno oscillare la rete al primo disturbo.

Bilanciamento del traffico e distribuzione del carico

Per i servizi esposti a utenti, il bilanciamento è la parte visibile della disponibilità. Un load balancer ben progettato non distribuisce solo richieste, ma rimuove automaticamente i backend non sani e preserva il più possibile le sessioni in corso.

Il bilanciamento può essere fatto a livello 4 o 7. Il livello 4 è più semplice e spesso più robusto per servizi TCP; il livello 7 permette controlli applicativi, header, path e policy più fini. La scelta dipende dal servizio: HTTP, API, mail submission, proxy TCP, database proxy, streaming.

Il punto critico è il controllo di salute. Un backend può rispondere alla porta ma essere comunque inutile perché il database è bloccato, il filesystem è pieno o l’applicazione è in deadlock. Il check deve misurare lo stato reale del servizio, non solo la reachability del socket.

Un bilanciatore affidabile deve anche gestire la transizione durante il failover. Se un nodo torna online, non va rimesso subito in rotazione senza verifica. Meglio un rientro graduale, con soglia di salute stabile e osservazione del tasso di errore.

DNS: il punto di ingresso che spesso viene dimenticato

Anche con una rete impeccabile, un DNS mal progettato può rendere irraggiungibile il servizio. Per alta disponibilità servono almeno due resolver autorevoli indipendenti, TTL coerenti con il tempo di failover e una strategia chiara per record principali, servizi secondari e disaster recovery.

Il DNS non fa failover in tempo reale da solo, a meno di meccanismi specifici. Il TTL deve essere abbastanza basso da permettere un cambio rapido, ma non così basso da aumentare il carico o peggiorare la cache distribuita. La scelta va fatta in base al profilo del servizio: per siti pubblici il TTL può essere più corto; per servizi interni o mail, bisogna considerare anche la propagazione e i comportamenti dei resolver intermedi.

È utile separare il nome pubblico del servizio dal nome dei singoli nodi. Il client deve puntare al bilanciatore o all’endpoint stabile, non al server fisico. Se ogni nodo ha il proprio record e viene usato direttamente in produzione, il failover diventa manuale e fragile.

Verifiche utili:

dig +trace esempio.tld
dig A esempio.tld
dig AAAA esempio.tld
dig NS esempio.tld

Controlla che i record siano coerenti, che i nameserver siano raggiungibili da più reti e che l’eventuale failover del record sia compatibile con il TTL reale osservato dai resolver dei clienti.

Storage e rete: la disponibilità dell’app dipende spesso dal disco

Molti incidenti attribuiti alla rete sono in realtà effetti di storage non raggiungibile. Se il database usa un volume condiviso, un filesystem distribuito o un backend iSCSI, la rete di storage deve essere trattata come componente critico separato.

Le regole pratiche sono queste:

• rete storage separata dalla rete utenti;
• latenza bassa e stabile;
• percorsi ridondanti verso i target;
• multipath dove supportato;
• monitoraggio di errori, timeout e reset.

In caso di storage remoto, il failover di rete deve evitare split brain e corruzione. Non basta “ripartire sul secondo link”: bisogna capire se il backend mantiene coerenza, se il lock manager funziona e se il filesystem o il cluster supportano davvero il passaggio automatico.

Se il servizio usa database, il checkpoint e la replica vanno pianificati insieme alla rete. Una replica sincrona su link instabile può degradare tutto il cluster. Una replica asincrona può mantenere online il servizio ma introduce RPO non nullo. La scelta va fatta esplicitamente, non lasciata al default.

Monitoraggio: senza telemetria la ridondanza è solo teoria

Alta disponibilità significa poter rilevare il problema prima che se ne accorga l’utente o almeno nello stesso istante. Il monitoraggio deve coprire link, switch, gateway, bilanciatori, server, storage e applicazione. Se vedi solo il ping del nodo, stai misurando troppo poco.

Le metriche minime da raccogliere sono:

• stato delle interfacce e errori fisici;
• packet loss, jitter e latenza;
• stato dei peer di routing o VRRP;
• health check dei backend;
• error rate e latenza p95 del servizio;
• spazio disco e code I/O;
• eventi di failover e rientro in servizio.

Il monitoraggio deve essere esterno rispetto al dominio che sta controllando. Se il sistema di alert vive sullo stesso segmento che può fallire, rischi di perdere sia il servizio sia l’allarme.

Un buon alert è specifico: non “server down”, ma “backend HTTP non sano su nodo X da 2 minuti”, “gateway virtuale non risponde”, “uplink primario down e secondario in uso”, “latenza storage oltre soglia”. Questo riduce i falsi positivi e accelera la diagnosi.

Testing del failover: il progetto vale solo se lo rompi in modo controllato

La verifica più importante non è il collaudo iniziale, ma il test periodico del guasto. Se non hai mai scollegato un cavo, spento un nodo o simulato un errore di routing, non sai davvero come si comporta la rete.

Il test deve essere graduale e reversibile. Prima si verifica il failover di un link, poi di un nodo, poi di un percorso upstream, poi del bilanciatore, infine del sito o del datacenter secondario. Ogni prova deve avere una finestra, un responsabile, un criterio di successo e un rollback chiaro.

Un esempio di sequenza utile:

1. verificare lo stato iniziale dei link e dei percorsi;
2. disconnettere un solo uplink alla volta;
3. osservare se il traffico continua senza reset massivi;
4. simulare la perdita del bilanciatore primario;
5. confermare che i backend restino raggiungibili dal percorso alternativo;
6. ripristinare e controllare il rientro in modo ordinato.

Durante il test osserva tre cose: perdita di pacchetti, tempo di failover e impatto sulle sessioni. Se il failover è rapido ma rompe le sessioni critiche, la soluzione non è accettabile per quel servizio.

Errori di progettazione ricorrenti

Ci sono alcuni errori che si ripetono quasi sempre quando si parla di rete HA:

• due link ma stesso switch e stessa alimentazione;
• bilanciatore ridondante ma health check troppo superficiale;
• DNS con TTL incoerenti e record puntati ai nodi fisici;
• storage condiviso senza multipath o senza separazione del traffico;
• monitoraggio interno al dominio guasto;
• failover non testato con traffico reale;
• assenza di documentazione operativa e rollback.

Il difetto principale non è tecnico ma architetturale: si confonde la ridondanza con la disponibilità. La ridondanza è solo un pezzo del problema; la disponibilità nasce da ridondanza, rilevazione rapida, transizione ordinata e verifica continua.

Schema pratico per un ambiente piccolo ma serio

Se devi progettare una rete HA per pochi server, una configurazione ragionevole può essere questa: due switch di accesso, due uplink per host, bonding o failover sulle interfacce, un paio di gateway con IP virtuale, bilanciatore davanti ai servizi, DNS con TTL controllato, monitoraggio esterno e backup dei parametri di rete.

Per l’infrastruttura a monte, separa almeno:

• rete pubblica;
• rete management;
• rete storage;
• rete replica o backup.

Se il budget non consente separazioni complete, il criterio è prioritizzare in base al rischio: prima il percorso verso gli utenti, poi il management, poi lo storage. Il backup non deve mai condividere lo stesso identico percorso del traffico che sta proteggendo, altrimenti un guasto di rete blocca sia produzione sia ripristino.

Decisione architetturale finale

Una rete ad alta disponibilità non si misura dal numero di dispositivi, ma da quanto bene assorbe il guasto più probabile senza intervento manuale. Se il failover richiede login, ticket o modifiche urgenti sotto pressione, la progettazione è incompleta.

Il criterio operativo corretto è questo: ogni componente critico deve avere un sostituto già attivo o immediatamente pronto, il percorso alternativo deve essere realmente diverso, e la perdita di un elemento non deve trascinare con sé più di un dominio di guasto alla volta. Questo vale per link, switch, gateway, DNS, bilanciatori e storage.

Quando il progetto è fatto bene, il guasto diventa un evento osservabile e contenuto, non un’interruzione percepita dall’utente. È lì che una rete passa da “ridondante” a davvero disponibile.