TX n°5681 - Administration de l'infrastructure Picasoft

La TX n° 5681 s’axe autour de deux objectifs :

• La sauvegarde : Étude critique de la solution actuelle, propositions et réalisation d’améliorations
• Le monitoring : Déploiement d’une solution complète

Le travail réalisé a donc été dissocié au cours du semestre A17 en deux parties, la première étant focalisée sur les sauvegardes, et la seconde sur le monitoring

L’organisation était construite autour de réunions hebdomadaires avec les responsables de la TX (Stéphane Crozat et Kyâne Pichou) auquel venait se compléter un pad, permettant de faire part des avancés réalisés chaques semaines, ainsi que des questions à l’ordre du jour, construisant ainsi une trace de l’évolution de la TX. Un channel sur le Mattermost de Picasoft a aussi été ouvert, offrant la possibilité de discuter en dehors des réunions.

Aussi, cette TX n’a pas été réalisée en binôme (bien qu’elle l’ait été initialement), supprimant ainsi les difficultées liées à l’organisation du travail en groupe.

Il existe deux types de sauvegardes distincts au sein de l’infrastructure de Picasoft: les sauvegardes de VM et les sauvegardes SQL. Dans un premier temps, un travail d'étude visant se questionner le système de sauvegarde SQL actuel a été réalisé. Pour résumer, les différentes approches sont :

• Sauvegarde logique
• Sauvegarde physique standalone
• Sauvegarde physique PITR (Point In Time Recovery)

La sauvegarde logique (à base de fichiers SQL) étant la plus adaptée à nos besoins, elle a été conservée (car des solutions de sauvegarde logique avaient déjà été mises en place). Cependant plusieurs améliorations ont été apportées :

• Image Docker de sauvegarde unique, permettant de sauvegarder plusieurs bases de données MySQL et PostgreSQL
• Scripts et Image Docker de rotation des sauvegardes, afin de réduire le nombre de sauvegardes au cours du temps

Les images Docker résultantes sont aujourd’hui utilisées en production sur les serveurs de Picasoft.

La mise en place de la solution de monitoring a constitué la seconde partie de cette TX (Novembre et Décembre). Tout d’abord, une analyse non-exhaustive des solutions existantes a été réalisée. De celle-ci a découlé le choix de Check_MK comme solution appropriée. Une documentation a part ailleurs été réalisée, résumant l’analyse des différentes solutions, et détaillant la mise en place du serveur Check_MK et des agents.

Aujourd’hui, une instance de Check_MK est déployée en production sur la VM de monitoring. Elle effectue le monitoring des machines et VM qui composent l’infrastructure. Il est par exemple possible d’y voir l’état du CPU, du réseau, et de nombreuses autres métriques sur différentes échelles de temps.

Aussi l’ensemble des communications entre le serveur Check_MK et les différents agents (installés sur chaque machine et renvoyant les métriques) a été chiffré, en utilisant des connexions SSH. Cela répondait à un besoin de sécurité, dans la mesure ou les informations sont de base transmises en clair.

Les machines virtuelles de Picasoft sont sauvegardées chaque jour vers 3h00 par les hyperviseurs (Alice et Bob) dans le dossier /SAVE. La gestion de ces sauvegardes pourrait à ce jour (14/01/2018) être améliorée sur les points suivant :

• Chiffrement et exportation des sauvegardes sur un espace de stockage externe, afin de pouvoir rétablir l’infrastructure en cas d’incident important (ex : perte/corruption des données des disques)
• Rotation des sauvegardes : Un système de rotation similaire à celui-ci mis en place pour les sauvegardes SQL permettrait sélectionner plus intelligemment les sauvegardes à conserver/exporter sur le court et long terme. Actuellement, les sauvegardes de plus de 8 jours sont supprimées (voir cette page).

• Système d’alerte Check_MK : le système d’alertes n’a pas pu être mis en place, notamment du au fait que Picasoft ne dispose pas encore de son serveur mail.

Voici d’autres pistes d’amélioration évoquées pendant la TX :

• L’utilisation du langage Bash pour la rotation de sauvegarde, bien que s’avérant initialement pertinente, n’est pas recommandée. Il serait judicieux de faire un état de l’art des solutions existantes ou une réécriture en Python, qui serait appréciable pour plusieurs raisons :
  • Prise en main du code plus rapide
  • Gestion simplifiée des dates, tableaux, et autres structures
• Sauvegarde supplémentaire du dossier /DATA des VMs : ce dossier contient les sauvegardes SQL, ainsi que les configurations et volumes partagés par les services docker. Il serait donc possiblement intéressant de le sauvegarder aussi sous forme d’archive (bien que ce dossier soit déjà contenu dans les sauvegardes de VM)
• Vérification de l’espace disponible avant sauvegarde : utile à mettre en place pour tout type de sauvegarde.
• Alertes de sauvegarde : Il est possible d’imaginer l’envoi d’un email sur une mailing-list d’administration lorsque la place vient à manquer, ou pour tout autre erreur.

Cette TX a été très enrichissante dans le cadre de mon parcours (Génie Informatique - Filière SRI)

D’abord quant au sujet, j’ai eu l’occasion de découvrir les différents types de sauvegarde qui existent, et ainsi de saisir les enjeux qui en découlent dans le monde de l’administration d’infrastructures. Aussi sur la seconde partie du sujet, à savoir le monitoring, j’ai de la même manière appris à comparer différentes solutions, et a fortiori à comprendre les enjeux d’un tel service.

Ensuite, sur le plan plus technique, l’utilisation de Docker étant permanente, j’ai donc beaucoup progressé dans la maîtrise de cette technologie, que nous avons très peu le temps de voir dans le cadre des autres UVs et notamment dans la filière SRI. Par ailleurs l’écriture de scripts liés au sauvegardes m’a permis de beaucoup progresser en Bash.

Enfin, l’un des points essentiels de mon travail a été la documentation de ce dernier. L’ensemble du travail de recherche ainsi que les réalisation techniques ont été documentées, afin d’une part de capitaliser les connaissances et d’autre part de permettre la maintenabilité et l’amélioration du travail accompli. Il s’agit en somme d’un très bon exercice, qu’il n’est pas courant de pratiquer dans le cadre des études.