Serveurs

Historique🔗

• Le 25 janvier 2019, le premier VPS hébergeant les serveurs de l’association est acquis auprès d’OVH pour une durée de 6 mois, avec le nom de domaine 42l.fr.
• Le 7 mars 2019, le site web 42l.fr ouvre ses portes.
• Le 10 mai 2019, le premier service de l’association est inauguré (le service mail) avec l’ouverture des adhésions.
• Le 25 juillet 2019, l’association Proxgroup nous offre gracieusement un serveur VPS en échange d’une mention de leur site sur notre page d’accueil : un serveur avec 4 cœurs virtuels, 4 Go de RAM et 40 Go HDD (accéléré avec un cache SSD inclus). Le serveur est hébergé dans un datacenter à Nanterre. Nous quittons OVH et déménageons notre infrastructure vers ce nouveau serveur.
• Le 9 janvier 2021, Neil loue un serveur à titre personnel (Gamme Stardust chez Scaleway, 1 cœur virtuel, 1 Go RAM, 10 Go SSD) et l’utilise pour réaliser les sauvegardes de l’association et y installer un outil de supervision externe. Avant cette date, les sauvegardes étaient réalisées manuellement sur nos ordinateurs personnels.
• Le 7 février 2021, nous hébergeons un serveur secondaire chez FirstHeberg, notamment afin d’y héberger une instance Collabora. Gamme GP-2, 2 cœurs virtuels, 2GB de RAM, 20GB SSD. Nous serons déçu·es par les performances disque de cet hébergeur par la suite (données corrompues régulièrement, système qui passe en read-only sans raison).
• Le 3 mai 2021, nous faisons le choix délibéré de payer le prix de l’hébergement de notre serveur auprès de l’association Proxgroup car notre association dispose alors des moyens financiers suffisants.
• Le 1er juillet 2021, l’association Proxgroup annonce la fermeture de ses services et confie la gestion de ses serveurs à l’entreprise PulseHeberg, qui semble par ailleurs partager leur gouvernance avec Proxgroup au moment de l’acquisition des serveurs.
• Le 7 février 2022, nous déménageons l’intégralité de nos serveurs vers de nouvelles machines auprès de PulseHeberg et déployons notre infrastructure V2.
• Le 9 mars 2022, notre serveur chez FirstHeberg arrive à expiration. Les services qu’il hébergeait ont été migrés au préalable vers l’infrastructure V2.
• Le 6 avril 2022, nous faisons l’acquisition du serveur Sarus, gracieusement offert par nos ami·es de l’association Picasoft, membre CHATONS, mettant un terme à l’hébergement des sauvegardes et de la supervision sur le serveur personnel de Neil chez Scaleway.
• Le 3 mai 2022, notre serveur principal chez Proxgroup arrive à expiration, mettant un terme définitif au fonctionnement de l’infrastructure V1. Tous les services ont été migrés au préalable.

Serveurs🔗

Serveur principal🔗

Notre serveur principal (que nous avions élégamment nommé « piaf ») hébergeait l’intégralité de nos conteneurs, à l’exception de nos sauvegardes et du monitoring externe.

À prtir de février 2021, nous louons un serveur secondaire pour héberger une instance du logiciel Collabora afin de proposer l’édition collaborative à nos utilisateur·ices. En effet, ce logiciel consommant 700 Mo de RAM à vide, nous ne pouvions nous permettre de l’héberger sur notre serveur principal sans risquer une saturation de notre RAM.

Serveur secondaire🔗

Ce serveur était essentiellement dédié à l’hébergement de Collabora.

Serveur de sauvegardes🔗

Ce serveur n’était pas pris en charge par l’association, mais loué à titre personnel par Neil. Il était utilisé dans la perspective de constituer des sauvegardes de données et d’assurer la supervision externe de nos serveurs.

Installation🔗

Tous nos serveurs utilisent Debian Stable et fonctionnaient à travers le dépôt Core, qui héberge nos Dockerfiles et nos fichiers de déploiement docker-compose.

Analyse🔗

Cette section présente sommairement les avantages et inconvénients de cette configuration.

Avantages🔗

• Simplicité d’administration : la quasi-totalité de nos services étaient hébergés sur un seul serveur, facilitant grandement la maintenance : pas besoin de protocoles de stockage par le réseau, pas besoin de réseau privé virtuel, un seul serveur à sauvegarder…
• Meilleures performances : les données étant stockées localement (plutôt que par NFS dans l’infrastructure V2), la latence est diminuée lors de l’accès aux données stockées sur disque, aussi bien en lecture qu’en écriture.

Inconvénients🔗

• Point de défaillance unique : naturellement, la centralisation de l’infrastructure a de grandes conséquences lorsque le serveur tombe en panne.
• Peu de flexibilité : en cas de montée en charge d’un service suite à son utilisation, il est difficilement possible d’augmenter rapidement la capacité d’un service, là où l’infrastructure V2 permet d’ajouter de nouveaux serveurs de calcul et de les connecter au stockage distant.

Sauvegardes🔗

Les sauvegardes étaient réalisées avec Borg en mode append-only, dans une configuration similaire à celle de l’infrastructure V2.

Avec toutefois une différence majeure : puisque nous ne disposions pas assez d’espace disque sur cette machine (10 Go) pour effectuer les sauvegardes de l’association, nous avons essayé de faire usage des 75 Go gratuits proposés par Scaleway en stockage objet, à travers l’utilisation de s3fs-fuse pour monter le stockage objet comme un système de fichiers classique.

Cette manipulation s’est révélée être une grave erreur : le stockage objet n’est pas du tout adapté pour être utilisé de cette manière et les transactions étaient extrêmement lentes. La maintenance de ce dispositif nous a coûté plus de temps que nous le pensions, faute de méconnaître les spécificités du protocole S3 à cette époque.