infrastructure osm28: perte connexion au reste du cluster OVH et conséquences multiples

Hier soir, la connexion entre osm28 et le reste du cluster OVH (osm26/osm27) a été perdue ~pour une raison inconnue~ à la suite d'un panne du switch OVH assurant l'interconnexion des vRack.

Un ticket a été ouvert au support OVH à ce sujet.

Conséquences:

perte du quorum pour osm28, ce qui n'a pas coupé les CT qui tournaient
le trafic provenant des proxy nginx d'osm26 et osm27 ne peut aboutir aux CT d'osm28 et inversement, les services sont donc accessibles aléatoirement en fonction du proxy nginx sur lequel on tombe
le partage NFS d'osm26 n'est plus accessible à osm28

Premières actions (Jocelyn et cquest):

modification par Jocelyn des entrées DNS de www, forum, umap pour pointer directement vers le host où se trouvent les CT et non pas le cluster-ovh
reboot après upgrade d'osm28 par cquest

Résultats:

umap bien accessible
au reboot, le proxy nginx d'osm28 refuse de démarrer car les config letsencrypt d'osm26 ne sont pas disponibles
les CT ne redémarrent pas, par manque de quorum

Secondes actions (cquest):

pvecm expected 1 sur osm28 règle le problème de quorum, les CT redémarrent automatiquement mais cela démarre aussi osm144 (umap configuré en haute-dispo) qu'il faut stopper manuellement
modification des entrées DNS: retrait d'osm18 de "cluster-ovh", ajout d'osmose, peertube, educosm et nextcloud en cname direct vers osm28
copie par rsync des configs letsencrypt d'osm26 vers osm28 pour permettre à nginx de démarrer

Résultats:

www, forum, peertube, educosm, nextcloud et osmose à nouveau UP

A améliorer:

[x] utiliser rsync pour recopier régulièrement les certificats letsencrypt pour nginx au lieu d'un accès NFS (à conserver pour le renouvellement des certificats) -> @jocelynj
[ ] vérifier que tout CT a ses services qui repartent suite à un reboot du CT (et donc aussi en cas de reboot du node ou suite à une migration entre nodes)
[ ] voir comment créer une redondance du lien vRack via la partie publique (tunnel GRE ?) ou revoir le principe des IP multiples pour le cluster afin de limiter le trafic des proxy passant par le vrack

Jun 14 '21 07:06 cquest

Bonjour,

j'ai toujours le 502 bad gateway, sur http://umap.openstreetmap.fr/.

Un dig sur les serveurs DNS Free et Google donne : umap.openstreetmap.fr. 9463 IN CNAME osm27.openstreetmap.fr. . Est-ce normal ?

Bon courage. Cordialement.

Jun 14 '21 08:06 hamlet

Le CNAME est correct, les CT d'osm26 et osm27 étaient eux aussi tombés, tout est à nouveau UP pour eux, dont umap. Pour osm28, une partie seulement des CT UP (osmose, forum et educosm down), toujours pas de quorum, pas de vrack, pas de news d'OVH...

J'ai pu remettre osm28 dans le vRack, car hier soir en voulant le retirer et le remettre via le manager web d'OVH, une fois retiré, il n'était plus sélectionnable. Donc là, en principe il devrait y être... sauf que ça ne fonctionne pas.

Il va falloir en appeler au vaudou.

Jun 14 '21 10:06 cquest

j'ai toujours le 502 bad gateway, sur http://umap.openstreetmap.fr/.

Ça marche pour moi désormais. Merci.

Jun 14 '21 10:06 hamlet

Merci pour les investigation, @cquest !

utiliser rsync pour recopier régulièrement les config nginx au lieu d'un accès NFS

J'avais mis un NFS surtout pour que les fichiers mis par acme dans .well-known/acme-challenge/ soient accessibles de tous les proxy lors du test fait par Letsencrypt. Par contre, c'est vrai que le certif généré pourrait être copié en local après génération. Je regarderais pour modifier le script.

Jun 14 '21 10:06 jocelynj

Bon... peu de progrès, mais une confirmation, c'est bien osm28 qui est hors vrack, je viens de vérifier et osm25 ping bien osm26 et osm27.

Support OVH en DM sur twitter... mais toujours pas de réponse à mon ticket d'hier soir.

Jun 14 '21 11:06 cquest

J'ai pu refaire fonctionner le cluster, en créant un ring redondant (c'est à dire une seconde adresse IP pour chaque noeud). Du coup quorum revenu à la normale et osm28 accepte de démarrer les CT donc sont UP à nouveau: forum, mastodon, peertube, educosm

Ce qui ne fonctionne toujours pas c'est la réplication qui passe par le vRack, ainsi que le trafic de proxy.

Toujours pas de news d'OVH... relancé par DM twitter...

Jun 14 '21 14:06 cquest

osmose UP... après avoir compris qu'osm153 n'était plus le CT du frontend osmose. Pourquoi tourne-t-il encore ?

overpass UP: il n'avait pas aimé le reboot de son host.

nginx n'était pas démarrage automatique, il l'est désormais
un fichier résiduel empêchait le dispatcher de démarrer

Jun 14 '21 15:06 cquest

osmose UP... après avoir compris qu'osm153 n'était plus le CT du frontend osmose. Pourquoi tourne-t-il encore ?

overpass UP: il n'avait pas aimé le reboot de son host. * un fichier résiduel empêchait le dispatcher de démarrer

tu as un extrait du log/journal à ce sujet ? car le journal dit qu'il était bloqué par dispatcher[2554]: File_Error No such file or directory 2 /osm3s_v0.7.54_osm_base Dispatcher_Client::1 le fichier socket que l'upstream conseillait (à tord à mon avis) de ne pas effacer automatiquement, ce qui bloque au reboot "qui n'arrive jamais"

Jun 14 '21 20:06 Marc-marc-marc

Le log dit aussi (ligne juste avant): juin 14 15:04:18 osm147 dispatcher[3072]: File_Error Address already in use 98 /data/project/overpass/database//osm3s_v0.7.54_osm_base Unix_Socket::4

En le supprimant, plus de "in use" et donc plus d'erreur et le service démarre. Le plus simple serait qu'il soit en /tmp ou /dev/shm donc supprimé au reboot, ou alors ajouter l'effacement dans un "pre" de systemd pour ce service.

Sinon, le vRack est de retour, la panne provenait d'un switch pour toute la baie: http://travaux.ovh.com/?do=details&id=51273& J'ai reçu un mail à 22h38 indiquant la cause. Comme un idiot j'étais tombé sur status.ovh.com (visiblement oublié)... et pas travaux.ovh.com

Jun 14 '21 21:06 cquest

Le bon côté des choses... les 3 serveurs du cluster ont été mis à jour en proxmox 6.4 :)

J'ai complété l'issue de départ avec 3 points à améliorer.

Jun 14 '21 21:06 cquest

Le log dit aussi (ligne juste avant): juin 14 15:04:18 osm147 dispatcher[3072]: File_Error Address already in use 98 /data/project/overpass/database//osm3s_v0.7.54_osm_base Unix_Socket::4

En le supprimant, plus de "in use" et donc plus d'erreur et le service démarre

oui c'est bien cela le soucis au reboot mais c'est le socket entre le dispatcher et les autres processus, pas le timestamp dont tu parles. J'ai viré le fichier socket du dispatcher area qui était tjs là pour faire redémarer le dispatcher correspondant pour son emplacement, c'est dans son ticket

Jun 14 '21 21:06 Marc-marc-marc

Le timestamp était une erreur de copier/coller, désolé.

Jun 15 '21 07:06 cquest

Le problème de certificat https est corrigé par https://github.com/osm-fr/ansible-scripts/commit/8cc0220b902ee3cbf7183d17ffbfa20c0020a927

Jul 10 '21 17:07 jocelynj