La mappa dei failure domain, e il test di passaggio di consegne che la dimostra

Ogni schema di piattaforma ha tre caselle di database, due load balancer e una coppia di cache, e ognuna è etichettata «ad alta disponibilità». Che lo sia davvero dipende da due documenti che la maggior parte delle costruzioni non produce mai: una mappa di quali cose fisiche ogni replica dipende, e un foglio di test che registra cosa è successo quando ciascuna è stata tolta. Ecco come scriviamo entrambi.

Il problema: tre repliche possono essere un solo guasto

La ridondanza conta le copie. La disponibilità dipende dal fatto che quelle copie possano guastarsi in modo indipendente. Tre nodi di database su tre macchine virtuali che lo scheduler ha per caso piazzato su due host sono, per un guasto di host, due nodi. Tre nodi su tre host i cui dischi vivono tutti su un solo array di storage sono, per un guasto di array, nessuno. Nulla nell'applicazione o nel dashboard ve lo dice. Dovete scriverlo.

Passo uno: elencate i failure domain

Per una piattaforma tipica, elencate almeno:

• Host: il server fisico o il blade.
• Chassis o enclosure: i blade condividono alimentazione, raffreddamento e interconnessioni.
• Array di storage: e, sotto di esso, il percorso del fabric di storage.
• Rete: la coppia di switch top of rack, gli uplink, l'edge.
• Sito: linea di alimentazione, raffreddamento, l'edificio stesso.

Poi decidete a quali la piattaforma deve sopravvivere. Sopravvivere alla perdita di un host qualsiasi e di un array qualsiasi è una baseline sensata; sopravvivere a un intero sito richiede un secondo sito ed è un design diverso.

Passo due: disegnate la mappa

Fate una tabella con una riga per membro di ogni livello ridondato e una colonna per failure domain:

Livello	Membro	Host	Chassis	Array
database	db-a	host 1	enclosure 1	array A
database	db-b	host 2	enclosure 2	array B
database	db-c	host 3	enclosure 1	array C
cache	cache-a	host 2	enclosure 2	array A
...

La regola è semplice: dentro un livello, nessun failure domain a cui avete scelto di sopravvivere può contenere una maggioranza dei membri. Leggete ogni colonna dall'alto in basso per ogni livello. Due membri di database su tre nell'enclosure 1 significa che un guasto dell'enclosure rompe il quorum. Correggete il piazzamento, o accettate il rischio per iscritto.

Passo tre: fate bene l'aritmetica del quorum

Se dovete sopravvivere a due guasti di host simultanei, come spesso dovrebbe fare un livello di storage, vi servono cinque membri in cinque domini separati, non quattro: un quarto membro aggiunge costo senza aggiungere tolleranza.

Passo quattro: fate imporre la mappa allo scheduler

Una mappa che dipende da qualcuno che piazza correttamente le macchine sarà sbagliata dopo la prima manutenzione. Fate in modo che sia la piattaforma a imporla.

Su un gestore di virtualizzazione come OLVM, create un gruppo di affinità negativo e vincolante per livello, così due membri non possono mai girare sullo stesso host, nemmeno dopo lo svuotamento di un host.

Su Kubernetes, usate la pod anti-affinity obbligatoria e un PodDisruptionBudget per ogni carico di lavoro a quorum:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      [ { labelSelector: { matchLabels: { app: galera } },
          topologyKey: kubernetes.io/hostname } ]

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: galera }
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: galera }

L'anti-affinity tiene i membri su nodi diversi; etichettate i nodi per chassis e aggiungete una seconda regola su quell'etichetta se gli enclosure sono un dominio. Il budget significa che un aggiornamento a rotazione dei nodi non potrà mai espellere un secondo membro mentre uno è già giù. Controllate il risultato, non l'intenzione:

kubectl get pods -l app=galera -o wide

Passo cinque: il foglio di test del passaggio di consegne

Ora dimostratelo. Per ogni livello, togliete un membro come farebbe un guasto reale, con l'applicazione connessa e traffico reale in corso, e registrate cosa è successo:

Azione	Atteso	Misurato	Cosa hanno visto i client
fermare il writer del database	il proxy sposta le scritture su un sopravvissuto	secondi alla ripresa delle scritture
fermare il primario della cache	Sentinel promuove una replica	secondi alla promozione
far guastare un nodo edge	l'indirizzo floating passa al peer	secondi, in ogni direzione
spegnere un host	i suoi membri si ricostruiscono altrove, il quorum regge
staccare un percorso verso l'array	il traffico di storage continua sull'altro percorso

Eseguite un probe con timestamp dall'esterno durante ogni test, così «cosa hanno visto i client» è una misurazione:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://app.example.com/health
  sleep 0.2
done | tee failover-$(date +%F).log

Poi ripristinate ogni membro e registrate che è rientrato in modo pulito, come replica del nuovo primario e non come suo rivale. Un test che finisce con due primari ha trovato il bug più importante del foglio.

Passo sei: fate verificare a qualcun altro

Chi ha costruito una piattaforma legge le note di costruzione quando la controlla, e le note di costruzione dicono cosa era previsto. Fate verificare la mappa a un secondo ingegnere, sulla piattaforma viva e da un'altra macchina: interrogate il gestore di virtualizzazione per il piazzamento reale, lo storage per la posizione reale dei dischi, il cluster per l'appartenenza reale. Le differenze tra la mappa e la realtà sono i riscontri che contano.

La vostra checklist

• I failure domain a cui sopravviverete, scritti.
• Una mappa di ogni membro di ogni livello contro quei domini, senza maggioranze in un solo dominio.
• Dimensioni del quorum scelte con l'aritmetica, solo numeri dispari.
• Anti-affinity e disruption budget imposti dalla piattaforma, e verificati.
• Un foglio di test del passaggio di consegne con tempi misurati e risultati lato client per ogni livello.
• Verifica indipendente sulla piattaforma viva, non sulle note.

Se volete una seconda opinione su quanto sia davvero indipendente la vostra ridondanza, saremo lieti di mapparla con voi.

Parla con un ingegnere

Related (rows[1])

Correlati: Costruzione di piattaforme ad alta disponibilità · Database in cluster con Percona XtraDB Cluster · Object caching con failover automatico