Test di failover: un flusso TCP stabilito sopravvive?

Due esiti si nascondono nella frase « la riserva funziona ». Una richiesta nuova riesce, ed è il ripristino. Un trasferimento già in corso continua, ed è la continuità. Sono promesse diverse, e la maggior parte dei progetti di failover consegna la prima mentre la seconda scade in silenzio. Decidete quale vi serve prima di scegliere un meccanismo, e scrivete il test in modo che sappia distinguerle.

Due esiti che sembrano un solo successo

Immaginate un client a 10.90.0.42 con una connessione verso 198.51.100.20:443. L'uscita primaria la traduce in un indirizzo e una porta pubblici, e l'uscita di riserva in un altro. L'indirizzo interno del client non cambia mai, ed è per questo che si aspetta che la connessione sopravviva.

Il server non vede un indirizzo interno. Vede l'estremità tradotta, e quell'estremità è diversa dopo il cambio.

Così il flusso vecchio scade mentre una connessione nuova allo stesso servizio funziona subito. Entrambe le osservazioni sono vere contemporaneamente.

Cosa vede il server quando cambia l'uscita

Una connessione TCP si identifica con la sua quadrupla, e cambiare l'indirizzo o la porta di origine crea una connessione diversa dal punto di vista dell'host che riceve. I pacchetti che arrivano da una nuova origine su una connessione che il server non conosce vengono scartati o ricevono un reset come risposta. Nulla nell'indirizzo del client VPN preserva l'associazione attraverso quel cambiamento.

Il failover con stato esiste proprio per evitarlo, e funziona scambiando lo stato di traduzione e lo stato delle connessioni fra i dispositivi di inoltro. È una proprietà della coppia, non del tunnel, e va progettata e provata invece che presunta.

Verificate se la coppia conserva davvero lo stato prima di promettere continuità a qualcuno. I comandi qui sotto mostrano lo stato attuale da entrambi i lati.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Perché lo stesso indirizzo pubblico non basta

Mantenere un solo indirizzo pubblico su entrambi i percorsi è un buon inizio, perché così il server vede la stessa estremità di origine. Da solo però non basta. Il dispositivo di inoltro ha ancora bisogno dello stato di traduzione, dello stato del firewall e di un percorso di ritorno utilizzabile, e questi devono esistere sul dispositivo che porta il traffico dopo il cambio.

La RFC 3022 descrive la traduzione degli indirizzi e considera lo scambio di stato fra dispositivi che traducono come parte di un progetto di riserva. Un indirizzo mobile o un profilo copiato sposta la configurazione senza spostare lo stato.

Per questo un test che fa solo ping attraverso la riserva dimostra molto poco. Il ping non ha stato di connessione da perdere.

Decidete quanto è forte il requisito

Se gli utenti possono riconnettersi dopo un guasto, il progetto è di ripristino e il test di accettazione è una richiesta nuova. Se un trasferimento di file deve sopravvivere, il progetto ha bisogno di sincronizzazione dello stato e di un test molto più accurato. Se una sessione remota deve sopravvivere, il requisito è ancora più forte e può richiedere un meccanismo a livello applicativo invece che a livello di rete.

Scrivete il requisito come una frase con un esito misurabile, per esempio il caricamento si completa senza riavvio oppure l'operatore si riconnette entro un minuto. Poi scegliete il meccanismo meno costoso che lo soddisfa, e spesso è il progetto di ripristino.

Dite esplicitamente cosa succede quando torna il primario, perché un ritorno automatico può interrompere una connessione che si era appena ripresa sulla riserva. Quel caso appartiene al piano di test, non a una nota a piè di pagina.

Verificate il flusso vecchio e la richiesta nuova

Avviate un trasferimento lungo e innocuo attraverso il primario, poi una richiesta nuova separata verso lo stesso servizio. Registrate il contesto applicativo, l'indirizzo di uscita osservato e l'ora. Interrompete il primario in un modo approvato e continuate a osservare il trasferimento originale mentre inviate la richiesta nuova attraverso la riserva.

Riportate tre valori: se il flusso vecchio è continuato, è stato reimpostato o è scaduto; quando la nuova operazione ha funzionato per la prima volta; e se il ritorno ha interrotto qualcosa. Quelle tre righe sono il verbale di accettazione.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Se il carico di lavoro scrive dati, non ripetete alla cieca un'operazione incerta dopo un timeout. La scrittura può essere arrivata prima che la risposta andasse persa. Chiedete il risultato all'applicazione, oppure riprovate solo dove l'operazione è idempotente. Poi scrivete la dichiarazione di accettazione in tre parti: le operazioni nuove si riprendono secondo la politica di uscita, i flussi esistenti hanno il comportamento di interruzione documentato, e l'applicazione riprende in sicurezza. Quella dichiarazione è verificabile ed è onesta su ciò che il progetto non promette.