Dans cet article, on compile quelques articles écrits sur le wiki dans le cadre de notre cassiopée “ha”.
Concernant le nouveau système de stockage:
Concernant les VMs pour la HA:
Concernant les serveurs:
Le réseau:
On a bien entendu modifié plusieurs autres articles pour tenir compte des modifications qu'on a effectuées à MiNET. (remplacer les noeuds de calcul et réinstaller tous les noeuds de stockage, ça laisse pas mal de trucs à modifier dans le Wiki)
Sinon, il y a le lien avec tous nos livrables cassiopée disponible dans le dossier /MiNET/Projet/2018-cassiopee_high_availability de Nextcloud. Vous pourrez y lire nos motivations, le cahier des charges du cassiopée et comprendre un peu comment et quand le projet a avancé.
Voici un court résumé des péripéties rencontrées pendant la cassiopée HA (2017-2018).
Ils sont arrivés en juillet-août 2017, en provenance du stage d'insolentbacon (d'ailleurs chaque année ils proposent des stages et ont eu plusieurs années des Minetiens comme stagiaires, grâce à qui on a pu récupérer du matériel)
Ils sont arrivés remplis de RAM, mais il n'y en avait qu'un qui bootait sur les quatres. On a donc essayé de chercher le problème, on a pas vraiment identifié le problème, on a pensé au CPU, qu'on a intervertis, à la RAM, à la carte mère, bref un peu tout. Juste avant le Cassiopée nous avions réussi à les faire booter tous de façon stable (plusieurs fois de suite).
Évidemment au moment où il a fallu les utiliser, on a eu le problème. Donc on a changé par un autre serveur, détordu des PINs sur les connecteurs entre la carte CPU-RAM et la carte mère.
Et évidemment au moment de la migration du calcul, vers 2h du mat, l'un des serveurs ne veut plus boot. Le lendemain, changement de barettes de RAM : et c'est reparti, cependant on est toujours pas sûr que c'était ça.
Le serveur DELL reboot de façon inopinée pendant la migration du stockage…dommage ça éteint tous les noeuds quand le cluster ceph n'en compte que 2 (la majorité à deux c'est deux).
Evidemment il fallait qu'il fasse un truc chelou pendant la migration du stockage : le processeur monte à 100% puis plus rien. Il n'a pas rebooté, mais a empêché les différents noeuds de se contacter, résultat : les clusters de stockage et de calcul rebootent.
Après avoir migré les serveurs de calcul, les anciens noeuds apparaissaient toujours, en voulant les supprimer, Nicolas a restart le deamon du quorum, sauf que 3 noeuds quand il y en a 7, pas il n'y en a pas, ça éteint toutes les VMs et CTs.
Le transfert des backups a pris plus de 72h, et oui, quand on transfère des snapshots qui sont compressées, il faut décompresser et recompresser donc au total sur les 7To transférés, il a dû en passer beaucoup plus sur le réseau.
Un matin le cluster Ceph est en HEALTH_ERR, après recherche c'est un disque qui avait laché, ça a pris une bonne après-midi à remplacer (découverte de Ceph), c'est à ce moment là qu'on a rédigé Remplacer un disque sur le cluster Ceph.
Un jeudi, on met un onduleur au wifi U2, le lendemain coupure d'électricité. On va dans la salle ça sent un peu chelou, on flippe, on espère qu'on a pas endommagé le switch et l'injecteur POE.
On croise Patrick, on lui dit qu'on a plus d'élec, il nous dit qu'il y a eu une coupure d'électricité cet après-midi là, mais qu'ils ont tout remis normalement, en plus les horaires ont l'air de coller. On cherche avec lui, dans le deuxième étage, etc. Puis on revient en bas du U2, au passage on a remarqué que les lumière de l'ascenseur ne s'allument plus. On cherche avec Patrick dans l'armoire électrique et on voit un disjoncteur qui avait sauté, on l'a remis et c'est reparti. On ne sait toujours pas si c'est la faute de l'onduleur ou quoi, mais depuis ça tourne.
Dans ce cassiopée, on a beaucoup porté de serveurs et même des baies, allez je vous mets un extrait ici :