TeDomum

Samedi (25 juillet) nous nous réveillons sur les messages inquiétants laissés par les courageux de la veille :

23:32 Bon masto est cassé et l'API serveur aussi

Et malheureusement une nuit plus tard pas encore beaucoup d'explications crédibles. Nous avons communiqué rapidement sur notre compte de secours puis notre compte principal mais la résolution a dû attendre ce dimanche 16h environ, notamment en raison d'un (très) mauvais diagnostic, qu'on vous explique en dessous.

Déroulé et synthèse

• Depuis 2020 et l'inauguration de Kity notre cluster kubernetes à la maison, nous savons que l'apiserver (le serveur qui contrôle le cluster) est une faiblesse importante, non redondée, le nôtre se nomme mainecoon et a déjà subi 2 pannes notables pendant ces 6 ans.
• Depuis quelques mois, certains de nos noeuds historiques hébergés sur des connexions fibre Free, ont changé d'IP en raison d'une régionalisation du plan d'adressage de Free.
• Le 16/07 chartreux sur la zone kai-1 avait subi une extinction inexpliquée.
• Le 24/07 vers 19h30 le réseau de la zone kai-2 a subi une interruption d'1 minute environ.
• Le 24/07 vers 19h40 les noeuds bambino et dwelf sur la zone kai-2 sont marqués comme hors ligne car pointant vers les anciennes IPs des noeuds chez Free et ne parvenant donc pas à se reconnecter.
• Le 24/07 à 19h43 le monitoring détecte les noeuds indisponibles et les signale aux admins.
• Le 24/07 à 23h30 les premiers constats sont faits par les admins disponibles, certains services sont inaccessibles ainsi que l'apiserver, ne permettant pas d'investiguer plus en détails.
• Le 25/07 vers 6h20 le noeud chartreux sur la zone kai-1 cesse de fonctionner correctement.
• Le 25/07 à 7h03 le monitoring détecte l'indisponibilité de chartreux et la signale aux admins.
• Le 25/07 à 8h une première analyse de l'infrastructure observe l'indisponibilité de chartreux et de la machine physique qui l'héberge, conclut par erreur à l'indisponibilité de mainecoon, l'apiserver.
• Le 25/07 à 9h après épuisement des idées pour tenter (à tort) de relancer maineconn, nous concluons qu'un déplacement est nécessaire pour démarrer la machine, planifié au lendemain, nous communiquons en ce sens.
• Le 25/07 dans la matinée, nous observons une amélioration progressive de la situation alors que les premiers services sont relancés correctement et accessibles sur le cluster, l'apiserver étant toujours fonctionnel bien que nous l'ignorions.
• Le 25/07 à 15h nous constatons en complément que pour les mêmes raisons de régionalisation de plan d'adressage, les dernières exécutions de backups n'ont pas abouti.
• Le 26/07 à 12h nous constatons que l'apiserver est fonctionnel et revoyons progressivement notre analyse.
• Le 26/07 à 15h nous constatons une fois sur place que chartreux est effectivement arrêté, mais également que dwelf et bambino sont défaillants contrairement à l'apiserver, l'analyse est revue en conséquence.
• Le 26/07 à 15h30, dwelf et bambino sont redémarrés, les premiers services sont à nouveau fonctionnels.
• Le 26/07 à 16h, l'ensemble des services fonctionne à nouveau.
• Le 26/07 à 17h30, chartreux est redémarré et l'ensemble de l'infrastructure est revenu à la normale.

Mauvais diagnostic

L'événement déclencheur de l'incident est une panne réseau de quelques secondes à une minute sur la zone kai-2. Hors cette panne réseau a été trop courte pour être observée au monitoring.

Nos noeuds sont conçus pour se reconnecter automatiquement après des pannes de ce type, ils disposent pour cela d'une liste de 2 à 3 autres noeuds dont l'IP est connue et stable afin de rejoindre à nouveau le cluster. Malheureusement, dwelf et bambino les 2 noeuds de la zone kai-2 pointaient vers 2 IP de noeuds chez Free, qui étaient périmées en raison de changements d'IP dans le cadre d'une régionalisation du plan d'adressage de Free.

Les deux noeuds ne se sont donc pas reconnectés au reste du cluster. Les services hébergés dessus ont été automatiquement redémarrés sur d'autres noeuds après 10 minutes, et les données étant répliquées sur au moins 2 zones, les services ont techniquement continué de fonctionner. Toutefois, ces 2 noeuds hébergent également 2 parmi nos 4 reverse proxies d'accès pour les utilisateurices. Les noeuds étaient déconnectés, mais les proxies toujours actifs, et les clients continuaient d'y accéder et de recevoir des erreurs de type HTTP 503 50% du temps.

Le lendemain matin, pour une raison toujours méconnue mais plausiblement en conséquence de la surcharge pour le reste du cluster, un troisième noeud, chartreux, s'est éteint physiquement. chartreux héberge lui aussi un reverse proxy. A ce stade parmi 4 noeuds d'accès, 1 était indisponible, et 2 non fonctionnels, donc 66% des requêtes échouaient : les services étaient trop dégradés pour être utilisables.

Dans ce contexte, le premier constat a porté sur l'indisponibilité de chartreux, facile à placer puisque la machine ne répondait plus physiquement. L'indisponibilité de dwelf et bambino n'a pas été constatée car les noeuds étaient en apparence sains (machine démarrée, et agent kubernetes, kubelet bel et bien actif). Comme l'apiserver n'était pas joignable à travers Internet, nous avons trop rapidement conclu à son indisponibilité du fait de la colocalisation avec chartreux. Hors mainecoon n'est pas voisin de chartreux, mais de cyprus.

Un trajet pour (presque) rien

Cette erreur d'appréciation a elle seule nous a coûté 24h de retard sur le rétablissement des services.

En effet, personne n'était disponible sur kai-1 pour redémarrer chartreux qui était bien éteint. Il a donc fallu y retourner. Un admin a fait le trajet dimanche... depuis le lieu qui accueille kai-2, où le réseau coupé était la vraie cause de panne, et où dwelf et bambino étaient sortis du cluster depuis plus de 24h, à 2 mètres du fauteuil d'où il intervenait.

Ces constats n'ont été faits que sur le trajet, un petit peu tard pour faire demi-tour. Quelques 3h plus tard, les machines n'étant toutefois pas éteintes, dwelf et bambino ont pu être relancés à distance.

Les mesures pour la suite

Il va de soi, réviser nos procédures de diagnostic, à commencer par faire confiance à la supervision : elle était claire depuis le début, et une lecture attentive nous aurait immédiatement pointés dans la bonne direction. Nous ne disposons pas aujourd'hui de déroulé réflexe en cas d'incident majeur, et bien que chaque situation soit unique une partie des gestes devrait être systématisée.

Pour mieux absorber, nous devons revoir le mode de failover des reverse proxies. Ce type d'incident peut se reproduire, et un serveur où les requêtes ne peuvent plus être traitées correctement ne devrait plus en accepter. C'est probablement à portée d'une configuration et devons nous y intéresser rapidement. Sans ce défaut les services auraient été dégradés sur le plan des performances mais tous disponibles pendant l'incident.

Pour éviter les récidives, diagnostiquer chartreux en détails, puisqu'il est probablement sujet à un défaut matériel déclenchant son extinction de façon inopinée ou lorsqu'il est particulièrement chargé.

Pour limiter l'impact des changements, adapter le mécanisme d'ancres, qui est statique en configuration aujourd'hui. Par exemple en mémorisant les IP des noeuds connus récemment lors d'un redémarrage ou d'une reconnexion.

Enfin pour la synchronisation, mieux connecter nos comptes de secours. Chaque admin dispose d'un compte secondaire également présent sur nos salons de travail. Hors une partie d'entre nous n'y était pas connectée au moment de l'incident et n'a donc pas reçu les notifications car notre propre serveur Matrix était HS.

Eternel bonus, supprimer le spof sur l'apiserver nous éviterait un réel incident le jour où c'est lui qui flanche, ou bien de conclure à une incapacité totale lorsque nous croyons qu'il a flanché.