Des serveurs et des ra

Jeudi 6 avril 2017, notre serveur principal a eu un problème et a redémarré automatiquement, mais pas très bien. Nous avons perdu l’accès aux divers éléments du site jusqu’à samedi 8 avril. Durant ces longues heures, les trois sysadmins se sont relayés pour tenter de trouver qu’est-ce qui avait mis le bazar et surtout, comment arriver à redémarrer correctement le tout.

C’est dans ce genre de moment que la fragilité de notre infrastructure apparaît. Nous avons la chance d’avoir des passionnés, mais aucun de nous n’est payé pour gérer ce genre d’urgence, et nous sommes donc obligés de faire passer d’autres priorités avant le serveur de Khaganat (études, travail rémunéré…). La réparation de cette panne a donc pris un certain temps, d’autant plus que le problème était assez technique (des histoires d’iptable, de grub, de snapshot plein, le tout bien emmêlé). À côté de ça, nos besoins ont évolué, jusqu’à nous amener à gérer quelque chose de complexe. Certes, nous ne sommes pas obligés de nous inscrire dans une logique de dégooglisation en hébergeant nous-mêmes les services qui nous sont utiles ; nous pourrions embêter Framasoft en squattant leurs etherpad et gitlab, par exemple. Nous pourrions aussi continuer d’utiliser des VPS pour le shard du jeu, au lieu de monter une infrastructure à base de VM basées sur Xen. Pour faire simple : nous pourrions nous simplifier la partie sysadmin en faisant d’autres choix. Si nous n’avons pas fait ces choix, c’est parce que nous considérons qu’un projet avec l’ambition de Khaganat doit pouvoir gérer ses propres outils.

Nous créons un MMORPG, entre autres choses. Rien que la partie MMORPG est déjà un sacré morceau. Ce genre de chose demande généralement un studio avec de l’argent, et au moins une quarantaine de gens formés et à plein temps, comme l’était Ryzom à l’origine (chez Dofus, ils sont 500…). Comme si cela ne suffisait pas, nous aimons le transmedia, nous voulons encourager et aider au développement d’autres univers sous licences libres. Nous sommes une dizaine de bénévoles, jamais à plein temps et pas toujours dans notre domaine de compétence. Cela ne nous arrête pas, nous prenons plaisir au chemin que nous suivons, même si cela prend parfois du temps… et, quand on rencontre ce genre de problème, un peu d’énervement !

Aujourd’hui, c’est dimanche, donc les trois sysadmins avaient un peu plus de temps. Nous avons pris le temps de faire un point. Nous avons amélioré les rustines que nous avions collées sur le serveur, puis redémarré ce dernier afin d’être sûrs que tout se relance proprement. C’est le cas, ouf. Nous pouvons clôturer cet incident.

Mais cela a aussi permis de nous mettre un bon coup de pied au derrière sur certains points.

Nous avons actuellement un système de sauvegarde à base de script et de rsync. C’était adapté au début : peu de données, surtout des CMS et leurs données à restaurer en cas de souci. Aujourd’hui, nous avons beaucoup de gigaoctets de données à sauvegarder, mais aussi plus de bazars à remettre en place si le serveur principal crashait sans possibilité de récupération. De plus, les scripts n’ont pas toujours été tenus suffisamment à jour ; avant l’incident de jeudi, par exemple, nous aurions perdu les tickets de Gitlab et les dépôts auraient dû être renvoyés depuis les connexions de chacun, ce qui veut dire quelques jours pour ceux dont la connexion ADSL est faiblarde. Depuis le retour du serveur, tout ça a été mis à jour, pas d’inquiétude ! Aujourd’hui, restaurer notre instance gitlab de zéro serait relativement rapide.

Même si les scripts sont à jour, il est évident que nous devons passer à une gestion des sauvegardes plus complète, en utilisant un outil dédié. La documentation d’Ubuntu liste un certain nombre de solutions ; Shepeng ayant déjà testé Bacula, nous allons probablement commencer par expérimenter ce dernier.

Pour information, les sauvegardes ont lieu tous les jours, dans la nuit ; nous perdons, au pire, un jour de travail. Il est rare qu’une journée seule soit très productive, donc on ne devrait jamais trop perdre.

Nous avons actuellement un serveur principal, baptisé Groska, sur lequel nous avons différentes VM (géré par Xen et LVM). Chacune de ces VM est un serveur à part entière. Par exemple, le serveur de jeu (Lirria) a ses propres paquets, et les personnes qui le gèrent sont Deed, Siela et Yann ; Shepeng, Rollniak et Zatalyz vont rarement y mettre les pieds. Cela permet à Deed et Siela de tester, voir casser des choses, sans mettre en péril le site web ou gitlab.

Ce système sous forme de VM convient bien à notre projet, cela permet de déléguer les pouvoirs sans mettre en péril l’ensemble de la structure et permet aussi à chacun de se concentrer sur une problématique. Par exemple, Zatalyz adore s’amuser avec l’aspect web, aidée de temps à autre par Osquallo ; ils ont tous deux accès à Jukni, la VM qui héberge les wikis et le forum, et savent que ce qu’ils font dedans ne va pas faire planter les autres services. Et quand Gitlab décide de ne plus gérer correctement la mémoire et de planter tout seul (oui ça lui arrive, il n’a besoin de personne pour ça), il peut faire tomber sa VM sans déloger Pendorid d’IRC. Ce découpage des ressources en VM peut être critiqué, il y a d’autres façons de faire, mais depuis qu’il est en place, nous en sommes assez satisfaits. Cela permet de gérer les soucis un par un, de façon séparée, et de bien distribuer les rôles. Par contre, quand c’est Groska qui tombe, on est bien embêté…

Nous avons un second serveur, Nuxru, qui sert uniquement à la sauvegarde actuellement. Il est aussi censé pouvoir héberger des VM pour des tests spécifiques sans pomper les ressources de Groska (VM dupliquant la partie web pour faire des tests ; VM dupliquant lirria pour d’autres tests…), mais ça n’est pas vraiment en place.

Lors du gros plantage, nous avons pris conscience qu’il nous serait utile d’avoir une VPS ou un petit serveur à part, hébergeant quelques services actuellement sur Groska : Zabbix et Teampass en particulier. Zabbix sert au monitoring, en étant sur une machine séparée, il pourra nous alerter par mail et SMS en cas de plantage, mais aussi nous donner les premières informations sur “pourquoi ça plante”. Teampass permet de partager des mots de passe de façon collaborative ; le souci c’est qu’il a besoin d’être accessible par le web. Donc, actuellement, quand Groska tombe, si nous voulons les mots de passe, il faut se créer en local un service Teampass et importer la database. Pas très pratique… Le wiki des admin serait peut-être intéressant à mettre aussi sur cette VPS. Évidemment, si c’est la VPS qui tombe, nous ne serons pas plus avancés, mais comme elle aura très peu de service et aucune incidence sur le reste de l’infrastructure, nous pourrons lancer les services en duplicata sur nuxru, le temps de remettre la VPS en place. Cela va nous occasionner un petit surcoût à l’année, de l’ordre de 60 € environ.

Nous avons aussi discuté des principes d’ip failover et de load balancing ; le problème de ces technologies, c’est qu’il nous faudrait des serveurs en plus, assez couteux, donc… ce n’est pas pour tout de suite. Mais nous allons faire évoluer la partie DNS, pour pouvoir rediriger plus rapidement d’un serveur à un autre si nous avons un plantage qui semble durer, comme ce fut le cas pour le dernier.

Dans un futur plus ou moins proche, dépendant des disponibilités de chacun, nous allons probablement modifier l’infrastructure sur le serveur, pour passer à un hyperviseur basé sur AlpineLinux, plus à jour que Debian sur des paquets comme Xen, tout en continuant à fonctionner avec des VM. Nous allons aussi sans doute changer d’hébergement. Nous sommes actuellement avec des Kimsufi, qui ne sont pas chers… mais qui ont pas mal de limitations. Online.net propose des serveurs attractifs pour un prix similaire : en fait, nous gagnerions de la puissance et quelques services pour le même prix. Shepeng ayant actuellement besoin d’un serveur pour ses propres besoins, il va tester le service d’Online.net et voir si ça peut marcher pour nous.

Nous allons mettre en place un journal de bord pour les administrateurs. Lors de l’incident, comme nous n’étions pas disponibles au même moment, nous avons travaillé les uns après les autres. Certaines informations n’ont pas été transmises, ce qui a fait perdre du temps (“Mais où a-t-il rangé ce script ?”) ou a été contre productif en amenant des actions à s’annuler (bidouiller le réseau interne réglait certains soucis et en créait d’autres).

Ce journal de bord devant être accessible en console (parce que quand ça plante, nous n'avons plus l’interface web), il y a deux possibilités :

• Utiliser le wiki des admin, vu qu’il est en mode texte, et faire un dossier spécial, où les différentes pages seront stockées,
• Se contenter d’écrire directement dans un dossier les divers fichiers.

Chaque “page” du journal de bord aura comme nom Année_Mois_Jour (par exemple 2017_04_05 pour aujourd’hui), ce qui facilite le tri. Chaque administrateur s’engage à mettre dans la page du jour ce qu’il vient de réaliser, sans entrer dans les détails : une simple copie du bash_history, avec un développement si des fichiers sont modifiés, et à la limite une note sur “pourquoi ça” si ça semble s’imposer. Le but n’est pas d’être didactique, mais de garder trace de ce qui a été modifié sur les serveurs. Ne pas oublier de signer à la fin…

Nous avons mis en place un mail destiné à ramasser diverses informations : annonces des mises à jour et des failles sur les logiciels que nous utilisons, envoi des infos de monitoring. Ce mail est actuellement destiné aux administrateurs. Cela va permettre de mieux ordonner la veille technologique et d’avoir les mêmes informations.

Il faut aussi que nous configurions plus finement le monitoring pour recevoir les informations des divers services. Actuellement, il n’y a que le mail en interne, ce qui veut dire qu’il faut se connecter aux VM et avec le bon utilisateur pour avoir les infos…

La réunion a été l’occasion d’aborder beaucoup de questions techniques ; nous avons de bons projets pour la suite, malheureusement la grosse difficulté va être de trouver le temps de les mettre en place. N’oubliez pas de soutenir l’équipe par des encouragements sur IRC et des sous sur Liberapay !