La carte des domaines de panne, et le test de remise qui la prouve

Chaque schéma de plateforme a trois boîtes de base de données, deux load balancers et une paire de caches, et chacune est étiquetée « haute disponibilité ». Qu'elle le soit dépend de deux documents que la plupart des constructions ne produisent jamais : une carte des choses physiques dont chaque réplica dépend, et une feuille de test qui consigne ce qui s'est passé quand chacune a été retirée. Voici comment nous écrivons les deux.

Le problème : trois réplicas peuvent être une seule panne

La redondance compte les copies. La disponibilité dépend de la capacité de ces copies à tomber indépendamment. Trois nœuds de base de données sur trois machines virtuelles que l'ordonnanceur a placées par hasard sur deux hôtes sont, pour une panne d'hôte, deux nœuds. Trois nœuds sur trois hôtes dont les disques vivent tous sur une seule baie de stockage sont, pour une panne de baie, zéro. Rien dans l'application ni dans le tableau de bord ne vous le dit. Il faut l'écrire.

Première étape : listez les domaines de panne

Pour une plateforme typique, listez au moins :

• Hôte : le serveur physique ou la lame.
• Châssis ou enclosure : les lames partagent alimentation, refroidissement et interconnexions.
• Baie de stockage : et, en dessous, le chemin du fabric de stockage.
• Réseau : paire de switches top of rack, uplinks, la bordure.
• Site : alimentation électrique, refroidissement, le bâtiment lui-même.

Puis décidez auxquels la plateforme doit survivre. Survivre à la perte de n'importe quel hôte et de n'importe quelle baie est un socle raisonnable ; survivre à un site entier exige un second site et c'est une autre conception.

Deuxième étape : dessinez la carte

Faites un tableau avec une ligne par membre de chaque niveau redondant et une colonne par domaine de panne :

Niveau	Membre	Hôte	Châssis	Baie
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 règle est simple : au sein d'un niveau, aucun domaine de panne auquel vous avez choisi de survivre ne peut détenir une majorité des membres. Lisez chaque colonne de haut en bas pour chaque niveau. Deux des trois membres de la base de données dans enclosure 1 signifie qu'une panne de châssis brise le quorum. Corrigez le placement, ou acceptez le risque par écrit.

Troisième étape : faites juste l'arithmétique du quorum

Si vous devez survivre à deux pannes d'hôtes simultanées, comme une couche de stockage le devrait souvent, il vous faut cinq membres dans cinq domaines distincts, pas quatre : un quatrième membre ajoute du coût sans ajouter de tolérance.

Quatrième étape : faites appliquer la carte par l'ordonnanceur

Une carte qui dépend de quelqu'un plaçant correctement les machines sera fausse après la première maintenance. Faites-la appliquer par la plateforme.

Sur un gestionnaire de virtualisation tel qu'OLVM, créez un groupe d'affinité négatif et contraignant par niveau, pour que deux membres ne puissent jamais tourner sur le même hôte, même après qu'un hôte a été vidé.

Sur Kubernetes, utilisez une anti-affinité de pods requise et un PodDisruptionBudget pour chaque charge à 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-affinité garde les membres sur des nœuds différents ; étiquetez les nœuds par châssis et ajoutez une seconde règle sur cette étiquette si les châssis sont un domaine. Le budget signifie qu'une mise à jour glissante des nœuds ne peut jamais évincer un second membre pendant qu'un est déjà hors service. Vérifiez le résultat, pas l'intention :

kubectl get pods -l app=galera -o wide

Cinquième étape : la feuille de test de remise

Maintenant, prouvez-le. Pour chaque niveau, retirez un membre comme le ferait une vraie panne, avec l'application connectée et du vrai trafic en cours, et consignez ce qui s'est passé :

Action	Attendu	Mesuré	Ce que les clients ont vu
arrêter le writer de la base de données	le proxy déplace les écritures vers un survivant	secondes avant la reprise des écritures
arrêter le primaire du cache	Sentinel promeut un réplica	secondes avant la promotion
faire tomber un nœud de bordure	l'adresse flottante passe au pair	secondes, dans chaque direction
éteindre un hôte	ses membres se reconstruisent ailleurs, le quorum tient
détacher un chemin de baie	le trafic de stockage continue sur l'autre chemin

Lancez une sonde horodatée depuis l'extérieur pendant chaque test, pour que « ce que les clients ont vu » soit une mesure :

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

Puis restaurez chaque membre et consignez qu'il a rejoint proprement, comme réplica du nouveau primaire et non comme son rival. Un test qui se termine avec deux primaires a trouvé le bug le plus important de la feuille.

Sixième étape : faites-le vérifier par quelqu'un d'autre

La personne qui a construit une plateforme lit les notes de construction en la vérifiant, et les notes de construction disent ce qui était prévu. Faites vérifier la carte par un second ingénieur face à la plateforme en production depuis une autre machine : interrogez le gestionnaire de virtualisation sur le placement réel, le stockage sur l'emplacement réel des disques, le cluster sur l'appartenance réelle. Les différences entre la carte et la réalité sont les trouvailles qui comptent.

Votre liste de contrôle

• Les domaines de panne auxquels vous survivrez, écrits.
• Une carte de chaque membre de chaque niveau face à ces domaines, sans majorité dans un seul domaine.
• Des tailles de quorum choisies par arithmétique, nombres impairs seulement.
• Anti-affinité et budgets de perturbation appliqués par la plateforme, et vérifiés.
• Une feuille de test de remise avec des temps mesurés et des résultats côté client pour chaque niveau.
• Une vérification indépendante face à la plateforme en production, pas face aux notes.

Si vous souhaitez un second avis sur l'indépendance réelle de votre redondance, nous serons heureux de la cartographier avec vous.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Constructions de plateformes à haute disponibilité · Bases de données en cluster avec Percona XtraDB Cluster · Cache objet avec basculement automatique