AccueilTechniqueInfrastucture V2 → Serveurs

    Serveurs

    Historique🔗

    • 7 février 2022 : Acquisition de Balearica et Antigone chez PulseHeberg, alors que notre infrastructure V1 était hébergée chez l’association Proxgroup qui procédait alors à sa dissolution et au transfert de ses serveurs actuels chez PulseHeberg. Notre but était alors de passer d’une infrastructure monolithique (tout sur un seul serveur) à une infrastructure plus flexible et modulaire (serveurs en duo calcul/stockage) pour faciliter l’expansion de nos machines par la suite.
    • 6 avril 2022 : Acquisition de Sarus, gracieusement offert par nos ami·es de Picasoft. Ce serveur, localisé sur une machine géographiquement distante des autres, a pour vocation d’héberger nos sauvegardes et de superviser l’état de nos services. Il remplace un serveur personnel utilisé dans l’infrastructure V1.
    • Février-Mai 2022 : Déménagement des services de l’infrastructure V1 vers l’infrastructure V2.
    • 15 février 2023 : Acquisition de Sialia auprès de PulseHeberg dans le but d’y déplacer notre service Nitter, qui consommait trop de ressources sur notre serveur principal (Balearica).
    • 15 novembre 2023 : Suppression de Sialia suite à la fermeture de notre instance Nitter.
    • 17 janvier 2024 : Acquisition de Griza auprès de PulseHeberg dans le but d’y déplacer notre service Mail, qui nécessite de plus en plus d’espace de stockage à mesure que nous accueillons de nouveaux comptes.
    • 14 juillet 2024 : Acquisition de Stanley auprès de PulseHeberg dans le but d’y installer notre service de mailing liste (mailing de masse), qui nécessite un serveur mail dédié pour éviter tout impact sur le service Mail principal.

    Serveurs🔗

    CaractéristiquesBalearicaAntigoneSialiaSarusGrizaStanley
    CPU8 vCPU2 vCPU2 vCPU2 vCPU2 vCPU2 vCPU
    RAM8 GB2 GB2 GB2 GB2 GB2 GB
    Swap2 GB2 GB2 GB2 GB2 GB2 GB
    Partitions/boot/efi, //boot/efi, //boot/efi, ///boot/efi, //boot/efi, /
    StockageSSD 50 GBHDD 250 GBSDD 30 GBHDD 70 GBHDD 250 GBHDD 250 GB
    HébergeurPulseHebergPulseHebergPulseHebergPicasoftPulseHebergPulseHeberg
    LieuNice*Nice*Nice*Compiègne**Nice*Paris***
    JuridictionFrançaiseFrançaiseFrançaiseFrançaiseFrançaiseFrançaise

    * Datacenter de Sophia Antipolis

    ** Dans une baie à l’Université de Technologie de Compiègne, maintenues par les associations étudiantes Picasoft et Rhizome.

    *** Datacenter de Saint-Denis

    Serveur désactivé/supprimé.

    Balearica🔗

    Le serveur Balearica est notre « serveur principal », il héberge la quasi-intégralité de nos services en utilisant le serveur NFS hébergé sur Antigone comme support de stockage. Tous nos services sont isolés dans des conteneurs Docker.

    Antigone🔗

    Antigone est notre serveur de stockage, il centralise les journaux de tous nos services (les journaux de connexion HTTP, de l’hôte et de Docker) et utilise un protocole de stockage en réseau (NFS) pour conserver les données des services hébergés sur nos autres serveurs.

    Ainsi, même si notre conteneur Nextcloud tourne sur Balearica, les données de ce service sont stockées sur Antigone.

    Enfin, c’est sur Antigone que les statistiques hedomadaires et mensuelles sont générées, avant d’être transmises à Balearica de manière périodique.

    Sialia🔗

    Serveur désactivé en novembre 2023.

    Le serveur Sialia est entièrement consacré au service Nitter, auparavant hébergé sur Balearica. Le service consommait 2.4 TB de trafic par semaine pour 40 000 utilisateur·ices uniques par jour, son activité dégradait fortement la performance des autres services en raison d’un manque de bande passante.

    Il est connecté au réseau WireGuard d’Antigone pour y envoyer les journaux du service et applique les règles de fail2ban, centralisées sur Antigone. Il ne stocke aucune autre donnée personnelle puisque Nitter ne nécessite pas de stockage.

    Sarus🔗

    Sarus est notre serveur dédié à la supervision de nos services (interne et externe). Il héberge également diun pour recevoir des notifications de mises à jour de nos images Docker, ainsi que Borg Backup pour nos sauvegardes.

    Il n’est pas connecté au réseau WireGuard d’Antigone et ne dispose ainsi que d’un accès extérieur à nos machines. Il héberge temporairement notre instance de Paheko (ex-Garradin) que nous utilisons pour notre comptabilité.

    Ce serveur nous est gracieusement mis à disposition par l’association étudiante Picasoft.

    Griza🔗

    Griza héberge notre service Mail ainsi que l’espace membre pour des raisons techniques.

    Il est connecté au réseau WireGuard d’Antigone et y transfère ses journaux.

    Stanley🔗

    Stanley héberge notre service de mailing de masse (mailing liste) ainsi que notre serveur mail secondaire.

    Installation🔗

    Tous nos serveurs utilisent Debian Stable.

    • Nos trois serveurs sont installés avec le script d’installation dans le dépôt Core : tools/setup/install.sh. Ce script spécifie notamment la liste des paquets que nous installons explicitement.
    • Une clé SSH de déploiement est générée pour chaque machine et ajoutée en lecture-écriture au dépôt Core.
    • Le fichier global-vars.sh est ajouté manuellement à chaque installation à la racine du dépôt Core.

    Évolutions envisagées🔗

    Autohébergement🔗

    Si l’association dispose un jour de locaux, il pourrait être envisagé d’y entreposer des serveurs (a priori du matériel de récupération). Ce mode d’hébergement permettrait également d’expérimenter le stockage RAID pour assurer la redondance des données sur plusieurs disques et dimimuer les risques de perte de données.

    Redondance des services🔗

    Selon le trafic sur nos serveurs, il pourrait être intéressant de redonder certains services sur plusieurs serveurs afin de garantir une meilleure disponibilité de service et de répartir la charge.

    Séparer la journalisation et le stockage🔗

    Actuellement, Antigone centralise les journaux avec syslog-ng et le stockage des données des services avec NFS. La journalisation consomme un débit non négligeable d’écriture disque et pourrait ralentir le serveur NFS, impactant ainsi la rapidité des services qui en dépendent.

    Pour cette raison, il pourrait être envisageable de séparer le stockage et la journalisation sur deux machines différentes.

    Utiliser un autre protocole de stockage🔗

    Nous utilisons NFS pour sa performance, sa consommation de ressources extrêmement faible et l’ancienneté de ce protocole qui en ont fait un standard de l’industrie. Toutefois, ce protocole a des inconvénients notables, notamment au niveau de la gestion des droits, de la sécurité ou des fonctionnalités. Plusieurs protocoles de stockage réseau alternatifs ont été mis à l’étude (ZFS, Ceph, GlusterFS, JuiceFS… mais tous consomment beaucoup plus de ressources que NFS. De futurs tests seront réalisés pour identifier d’autres alternatives.

    L’utilisation de supports de stockage basés sur le protocole S3 (avec Minio) est également envisagée afin d’améliorer la performance des services.