Mon réseau

Publié dans : Blog

J’avais envie d’honorer une vieille tradition geek : présenter mon réseau, son architecture, son contenu, etc. Deux objectifs sont poursuivis : un objectif de mémoire - un jour, je relirai cet article avec nostalgie… - et un objectif d’échange - si vous trouvez des infos intéressantes ici, ou si vous avez des idées d’amélioration.

  • Il n’y a aucun lien d’affiliation dans mes articles, et celui-ci ne fait pas exception.
  • L’historique de cet article est consultable depuis ma forge logicielle

Généralités 🔗

Je suis client free depuis 2004. Malgré l’arrivée de la fibre dans ma commune, free ne figure pas encore dans les FAI disposant d’une offre commerciale, et je n’ai aucunement l’intention de changer juste pour avoir la fibre.

En conséquence, mon débit actuel est d’environ 13 Mbits/s en descendant et 1 Mbits/s en montant. Cela peut vous sembler peu si vous êtes habitués à la fibre, mais honnêtement, on n’en souffre pas.

On est deux à utiliser Internet : moi de toute façon, et mon épouse, avec beaucoup de visio-conférences. Nous n’avons aucun de problèmes de débits, de latences ou de lenteurs avec Internet ou avec le réseau en général. Évidemment, si on cherche à regarder une vidéo en même temps sur deux périphériques distincts, il y aura un peu de buffering mais rien de rédhibitoire.

Nous n’avons pas de téléphone fixe : mon épouse a le forfait mobile illimité et moi le forfait mobile gratuit (je n’utilise mon portable que pour recevoir des appels). Nous ne regardons pas la télévision « conventionnelle », exclusivement la VoD via Netflix, Amazon Prime et AppleTV+. Pour un replay occasionnel, on utilise Molotov.

Infrastructure 🔗

Freebox 🔗

Ma Freebox est une Révolution configurée en bridge (j’attends la fibre pour la renouveler). Je dispose d’une adresse IPv4 « full-stack », demandée dès que l’option était disponible, et de l’IPv6 natif.

Routeur 🔗

Mon routeur est un AWOW AK34. Il dispose d’un Celeron N3450, 6Go de DDR4, un SSD de 128Go et surtout, deux ports gigabit. Il est installé sous OpnSense.

L’un des ports est relié à la Freebox ; du point de vue de OpnSense, c’est l’interface WAN. L’autre port est relié au switch ; c’est l’interface LAN.

Détails

Particularités 🔗

IPv6 🔗

J’ai eu beaucoup de difficultés à disposer d’un réseau en IPv6 fonctionnel, et même maintenant, tout n’est pas parfait. Bien que tout a l’air de bien fonctionner côté client, je ne me suis toujours pas décidé à rendre disponibles mes sites et services sur IPv6. Je ne comprends pas encore comment ça fonctionne et j’ai peur de compromettre la sécurité du réseau.

En tous les cas, free fait plutôt bien les choses de ce côté puisqu’ils mettent à disposition huit préfixes IPv6. C’est six de plus que ce dont j’ai besoin pour mon réseau à l’heure actuelle, j’aime bien avoir de la marge.

Dans OpnSense, on va dans Interfaces, Overview, et on récupère l’IPv6 « link-local ».

Dans l' interface de configuration de la Freebox, on va dans Paramètres de la Freebox, puis Configuration IPv6. On colle cette IPv6 dans les deux premiers champs « Next Hop ». On déclare ainsi que la Freebox doit envoyer tous les paquets réseau à destination des adresses de ces préfixes à notre propre routeur. On en profite pour noter l’IPv6 de lien local de la Freebox.

De retour sous OpnSense, on va dans Interfaces, [WAN], pour y définir IPv6 Configuration Type à Static IPv6. Plus bas, dans Static IPv6 configuration, on définit l’adresse IPv6 qu’on souhaite attribuer à notre routeur, sachant que <prefixe_1>::1 correspond à l’adresse IPv6 de la Freebox et ne doit donc pas être utilisé. Traditionnellement, je lui attribue donc l’IPv6 <prefixe_1>::2. Il faut encore ajouter une IPv6 Upstream Gateway, qui pointera vers l’IPv6 de la Freebox sus-mentionnée (<prefixe_1>::1 donc).

Même procédure dans Interfaces, [LAN], sauf que cette fois, on utilisera le deuxième préfixe offert par la Freebox, que la Freebox ne dispose pas d’IPv6 sur ce deuxième préfixe, et qu’aucune passerelle n’est à créer. Donc, on va mettre <prefixe_2>::1 dans le champ IPv6 address, et laisser les autres valeurs par défaut.

Dernière étape, il faut aller dans Services, Router Advertisements. Pour chaque interface, [LAN] et [WAN], on configurera comme suit:

Pour le [LAN], on mettra <prefixe_2> dans Advertise Routes.

Il ne reste plus qu’à activer le serveur DHCPv6 sur le LAN.

Problèmes 🔗

Les périphériques clients sont incapables d’obtenir une adresse IPv6 fournie par le serveur DHCPv6 d’OpnSense dans la plage que j’ai défini, comprise entre <prefixe_2>::ffff:1 et <prefixe_2>::ffff:ffff, alors qu’ils récupèrent bien l’IPv6 du serveur DNS configuré. Évidemment, le serveur DHCPv6 est désactivé sur la Freebox, et il n’y a pas d’autre serveur DHCPv6 sur le réseau. Cela fait partie des nombreuses choses que je ne comprends pas encore sur l’IPv6…

Firewall 🔗

Si je n’ai qu’un seul conseil à donner par rapport à la gestion du firewall sur OpnSense, c’est d'utiliser massivement les alias. C’est simple à gérer, très puissant, et simplifie toute la configuration du firewall. En l’occurrence, je créé deux alias par serveur (un pour l’IPv4, un pour l’IPv6), plus un s’il est accessible depuis l’extérieur, contenant la liste des ports à rediriger.

En outre, je veux que toutes les machines du réseau (en particulier celles dans lesquelles je ne peux pas avoir confiance, telles que le Windows de travail de mon épouse, ou la SmartTV) utilisent mon serveur DNS (un Raspberry Pi) et mon serveur NTP (le routeur lui-même). Pour ce faire, il faut créer des règles de Port Forward dans la configuration du NAT, une pour l’IPv4 et une pour l’IPv6, donc deux par protocole. Ce sont les quatre dernières règles de la capture d’écran suivante.

Problèmes 🔗

Ces règles sont facilement outrepassées par DNS-over-TLS.

DNS 🔗

J’utilise unbound sur OpnSense, mais uniquement pour l’association entre le nom des machines et leur adresse attribuées par le serveur DHCP. Toutes les autres requêtes DNS sont envoyée au serveur DNS interne qu’on verra plus tard. Pour que le routeur lui-même utilise ce serveur, j’ai renseigné ses IP v4 et v6 dans System, Settings, General, et j’ai désactivé Allow DNS server list to be overridden by DHCP/PPP on WAN : je ne veux pas utiliser les serveurs DNS de mon FAI (ni « aucun » autre, en fait : on verra plus tard ce que j’entends par là).

Sauvegarde de la configuration 🔗

J’utilise un plugin très pratique, à installer depuis System, Firmware, Plugins : os-git-backup. Il fait exactement ce que son nom entend : il sauvegarde automatiquement toute la configuration d’OpnSense dans un dépôt git, dès qu’une modification survient et avant application de toute mise à jour.

IPS/IDS 🔗

J’ai activé l'IPS (Suricata), en mode IDS, mode dans lequel Suricata doit bloquer les intrusions qu’il détecte. Cependant, dans l’onglet Alerts, je ne vois pas de mention des paquets bloqués - seulement Allowed dans la colonne Action. Je ne sais pas si c’est normal.

Performances 🔗

Je dois dire que je suis agréablement surpris par les performances de cette machine, en particulier malgré l’activation de l’IDS. La charge moyenne est inférieure à 0.40, l’utilisation CPU reste sous les 5%, la consommation mémoire sous les 1.5Go, et l’espace disque utilisé est de 2.5G, de quoi assurer une durée de vie conséquente au SSD de 128Go (en théorie).

Switch 🔗

Je dispose d’un switch TP-Link TL-SG1016 de 16 ports.

Wifi 🔗

J’ai deux Synology MR2200ac configurés en mesh. Cela confère un certain nombre d’avantages :

  • toute la configuration de mon réseau sans-fil se fait depuis une seule interface (ce n’est pas spécifique à Synology)
  • je n’ai à configurer qu’un seul SSID sur toutes mes machines, qu’elles utilisent la bande de 5GHz, 2.4GHz, en wifi g, n ou ac
  • la connexion est stable, même en basculant d’un point d’accès à l’autre

Avant cela je disposais de deux RT1900ac et la configuration était pénible et instable à l’usage en l’absence du mode mesh.

En outre, j’ai mis en place un vieux TP-Link TL-WA801N en guise d’extension du réseau à l’usage quasi exclusif de la station météo située à l’extérieur.

Serveur DNS 🔗

Pour l’heure, c’est un Beelink T34, doté d’un Celeron N3450, de 4Go de mémoire vive et de 64Go de eMMC, sur lequel j’ai rajouté un SSD M.2 Transcend de 240Go pour des raisons de performances et de longévité.

J’y ai installé Pi-hole avec un upstream unbound, le tout sous docker.

Vu que le serveur se fait un peu chier (même un N3450 est overkill pour un serveur DNS avec une blacklist de 6 400 746 domaines…), j’y ai aussi installé drone-CI et un runner pour exécuter les tâches d’intégration continue. Concrètement, c’est cette machine qui récupère les commits git poussé sur ma forge Gitea (voir plus bas), et prépare les fichiers du site que vous êtes en train de consulter avant de les publier sur le serveur web.

Serveur domotique 🔗

C’est un Kodlix GN41. Processeur Celeron N4100, 8Go de DDR4. J’y ai installé un SSD Samsung 750 EVO de 120Go, afin d’économiser les 64Go d’eMMC intégrés (et pour une question évidente de rapidité).

J’utilise Home Assistant OS sur lequel j’ai installé quelques plugins :

  • dnsmasq
  • ESPHome pour piloter mes ESP8266 et ESP32 que j’ai un peu partout
  • InfluxDB et Grafana pour stocker à long terme et afficher les données des différents capteurs des ESP8266/32 sus-mentionnés
  • Node-RED pour piloter les lumières et les thermostats
  • motionEye pour les caméras de surveillance
  • VSCode pour modifier la configuration in-situ

J’ai voulu que cette machine, compte tenu de son affectation, soit la plus autonome possible : les bases de données sont stockées sur place, l’éditeur de configuration est sur place, et j’utilise désormais Node-RED pour piloter les lumières et les thermostats plutôt que d’utiliser un serveur CalDAV, très contraignant, très lent à charger dans Home Assistant.

J’ai intégralement conçu et manufacturé toute la domotique de mon logement. J’ai dessiné les circuits imprimés, et je les ai réalisés grâce à la bonne vieille méthode du bain au perchlorure de fer, apprise plus de vingt ans plus tôt en cours de technologie…

Ma domotique est donc constituée des éléments suivants, tous construits autour d' ESP8266 :

  • 1 station météo

Elle fait ma fierté, parce que j’ai passé beaucoup de temps à la concevoir et qu’elle fonctionne parfaitement bien et sans interruption depuis près de deux ans.

Elle dispose de son propre système de régulation de température et d’humidité, basé sur un contrôleur de ventilateurs PWM (et de deux ventilateurs Noctua, de 8cm en aspiration sur le dessous et 12cm en extraction sur le dessus), d’une résistance PTC de 80℃ (disposée sur un vieux radiateur de processeur afin de répartir la chaleur dans le boitier) et d’un capteur SHT31-D, afin de s’assurer que l’alimentation et l’électronique soient maintenues à des températures et humidité relative acceptables (c’est-à-dire, selon les normes de fonctionnement préconisées par les constructeurs des différents éléments constitutifs de l’électronique de la station). Le contrôleur de ventilateurs et la résistance sont pilotés par des MOSFET IRLZ34N (placés chacun sur un circuit imprimé, en haut à gauche de l’image ci-dessus)

Elle dispose d’un capteur de luminance TSL2561, d’un capteur de température, humidité relative et pression atmosphérique BME280, et d’un capteur d’orage MOD-1016.

Une alimentation de 12V 5A fourni le courant à l’ensemble des composants. J’ai choisi cette puissance pour tenir compte de la résistance chauffante et des ventilateurs. De plus, une alimentation capable de délivrer plus que ce dont elle a besoin signifie souvent qu’elle chauffe moins. À l’exception du BME280 et du MOD-1016, tous les composants de la station météo prennent place dans un boitier spécifique planqué sous la véranda. Le BME280 et le MOD-1016 sont placés dans un boitier de ma conception, basé sur des tuyaux de 10cm de diamètre : une section droite centrale contient un circuit imprimé sur lequel les capteurs sont enfichés, et une section coudée à 90 degrés de chaque côté, ouverture vers le bas. Ainsi, les capteurs sont à l’air libre, mais protégés des intempéries. Ils sont reliés à la station principale par un câble ethernet blindé, qui fait transiter le signal I2C et l’alimentation.

  • 5 thermostats

Ils disposent de deux modes, « Présent » et « Absent ». Les plages horaires de chaque mode sont définies dans un calendrier spécifique à chaque thermostat. L’ESP8266 présent dans chaque boitier mural contrôle simplement un relais, et capte la température et l’humidité de la pièce via un SHT31-D.

  • 7 lumières, dont 6 bandeaux de LEDs et une prise Sonoff S20

J’ai défini deux entrées dans Home Assistant, respectivement pour l’extinction et l’allumage « inconditionnel » de l’éclairage. Ainsi, quoiqu’il arrive, les lumières automatisées (certaines ne le sont pas parce que ce n’est pas nécessaire) ne s’allumeront jamais dans cette plage horaire (typiquement entre 2h30 et 5h45, soit entre l’heure à laquelle je me couche et celle à laquelle mon épouse se lève).

En outre, les lumières automatisées ne s’allument que si la luminance extérieure fournie par la station météo est en dessous d’un certain seuil que je peux définir pour chacune d’entre elles. Enfin, le calendrier me permet de définir les plages horaires pendant lesquelles elles doivent présenter une scène particulière. J’ai défini quatre types d’ambiance : heures de passage (pour un éclairage à pleine puissance), éclairage normal, éclairage tamisé, et éteint.

Un bandeau de LEDs est contrôlé par un capteur de mouvement de type PIR, dont la seule dépendance est la luminance extérieure : même en présence de mouvement, il ne s’allumera pas s’il fait encore jour. Un autre bandeau est uniquement contrôlé par un bouton poussoir. Un dernier ne peut être contrôlé que par Home Assistant.

Au niveau électronique, chaque contrôleur pilote simplement trois MOSFETs (également des IRLZ34n), et dispose de deux entrées (pour un bouton ou un capteur de mouvement). C’est mon premier projet électronique à usage réel.

  • 2 horloges

J’aime bien avoir l’heure partout où je suis. Si j’ai la date complète, et la température extérieure, c’est encore mieux… Alors j’ai conçu deux horloges dotées d’un écran LCD 16x2 piloté en I2C par un ESP8266. Rien de compliqué, rien qui nécessite un circuit imprimé, juste quelques câbles.

  • 1 bouton d’appel

Utilisé pour que mon épouse puisse me signifier sans hurler à travers toute la maison qu’elle va faire dodo quand je suis enfermé dans mon bureau… Quand elle appuie sur son bouton d’appel, j’ai une alerte sur mon tableau de bord. Un appui de ma part sur le tableau de bord éteint sa LED pour lui signifier que j’arrive.

  • 1 bouton « Linge »

Pour que mon épouse puisse m’indiquer s’il y a du linge à étendre ou à passer au lave-linge, je lui ai créé un petit boitier logé près de la machine à laver, dérivé du bouton d’appel, et doté de deux boutons et deux LEDs. Cela provoque l’affichage d’un avertissement sur mon tableau de bord.

Tous ces périphériques tournent sur des ESP8266. En conséquence, j’ai installé ESPHome qui gère tout ça via de simples fichiers de configuration yaml, et connecte le tout à Home Assistant. Ça rend tout le processus très agréable et facile à utiliser et maintenir au quotidien.

J’ai également installé une caméra sous motionEyeOS sur un Raspberry Pi 0W. Elle transmet le flux vidéo à Home Assistant via un container docker motionEye.

Les données de la station météo sont envoyées à un container InfluxDB, ce qui me permet d’utiliser ensuite Grafana afin de visualiser ces données à long terme.

Serveur principal 🔗

Mon serveur préféré (chut, ne le dites pas aux autres), c’est aussi celui qui m’a coûté le plus cher, mais c’est le plus polyvalent. C’est un miniforum U820. Son Core i5 8259U (4c/8t @2.30GHz) est accompagné de 16Go de DDR4 et d’un SSD NVMe Kingston de 240Go.

Il dispose de l’USB-C, plein de ports USB 3.0, deux ports gigabit, de HDMI et de Display-Port, ce qui me donnerait presqu’envie de le reconvertir en machine desktop plutôt que serveur si j’en avais l’utilité. Mais surtout, il offre deux baies pour SSD 2.5in, ce qui en fait le meilleur candidat au poste de serveur de stockage. Je lui ai donc collé mes deux Samsung 860 EVO de 500Go.

Sa puissance m’est très profitable, puisque j’y fais tourner :

  • ArchiveBox (pour sauvegarder localement une page web)
  • Caddy (en reverse-proxy ou serveur web direct pour mes applications disponibles depuis l’extérieur de mon réseau local, c’est notamment le cas de mon blog)
  • un runner pour Drone-CI
  • Gitea (ma fameuse forge logicielle)
  • Hedgedoc (pour éditer du Markdown à plusieurs)
  • PostgreSQL (stockage de toutes mes bases de données utilisées par les autres applications)
  • Redis
  • RoundCube (pour un accès occasionnel à mes mails)
  • Scrutiny (pour mes SSD)
  • Synapse (pour papoter sur Matrix, n’hésitez pas à me rejoindre via le bouton en haut à droite de mmon blog)
  • VaultWarden (pour stocker et partager mes mots de passe)
  • SyncThing (pour synchroniser mes fichiers sur le réseau local)
  • Samba (pour accéder à certains fichiers)

Outils communs 🔗

J’ai installé cockpit et dnsmasq sur le T34 et sur le U820.

Vous me reprocherez sûrement de ne pas être un vrai barbu, mais j’aime bien avoir une UI. Je dirai même, j’en ai besoin : j’ai un besoin primaire de « voir » mes machines, via des graphiques et des icônes, des tableaux et des couleurs. C’est un choix personnel et sensible, en aucun cas une prérogative au fonctionnement de mon réseau. C’est à ce besoin primaire que répond cockpit, qui me permet d’ailleurs d’accéder à l’ensemble des machines de mon réseau depuis la même interface, ainsi qu’à leur shell, et à différentes statistiques et fonctionnalités que j’aime bien avoir à portée de main.

Toutefois, je reproche à cockpit quelques manquements, en particulier l’état SMART des dispositifs de stockage qui le supportent, ou la température des composants. C’est la raison pour laquelle je fais aussi tourner un petit container qui me prévient en cas de pépin sur mes SSD : Scrutiny.

J’installe aussi dnsmasq afin de limiter les requêtes au serveur DNS principal. dnsmasq fait alors office de simple cache pour chaque machine. Le but est de limiter les connexions réseau et l’activité du serveur DNS.

Tableau de bord 🔗

Le tableau de bord que je mentionne depuis avant est une tablette Asus T100TA. Elle m’a coûté des peines infinies à faire fonctionner sous debian sid, en particulier à cause de l’UEFI 32 bits démarrant un système 64 bits, et du chipset wifi non supporté par défaut.

J’ai installé openbox et chromium dessus, en mode kiosk. Par contre, c’est très lourd, et la connexion réseau est très instable. Je suis obligé de la redémarrer au moins une fois par jour, et c’est évidemment très pénible. Mais quand elle fonctionne, elle fonctionne bien, alors je ne me risque pas à essayer d’installer autre chose.

Station de travail 🔗

Ma station de travail est un Mac mini M1. Là encore, vous allez sûrement me critiquer vertement. C’est Apple, c’est pas Libre, etc. Et je vous répondrai ceci.

Je suis passionné d’informatique depuis que j’ai cinq ans (j’en ai presque 40). J’ai touché à tout ou presque (grand bien m’en fasse, je n’ai jamais vu un AS400 de ma vie). J’ai passé un gros tiers de ma vie informatique à bidouiller des machines sous Windows, toutes versions depuis 3.1 jusqu’à Windows 10, en passant par Windows 2000, Server 2003, Home Server, etc. À la grande époque des versions pirates, j’ai touché à tout l’écosystème Microsoft, y compris ISA, Exchange, etc.

Suite à ça, je me suis laissé tenter par GNU-Linux. Pendant un deuxième gros tiers de ma vie informatique, j’ai bidouillé des Mandrake, des Knoppix, des RedHat, des Suse, pour finir par adopter définitivement debian. Je passais des heures à essayer de faire fonctionner un modem USB, à essayer et échouer à compiler le noyau, à desespérer devant mon incapacité à faire fonctionner correctement une carte graphique ou une carte son un peu exotique. Et bien que j’ai fini par pouvoir travailler confortablement avec debian et KDE, je ne pouvais me résoudre à supprimer purement et simplement Windows pour jouer (ce que je n’ai réussi à faire que récemment).

Tout ça, jusqu’au jour où j’ai acheté un iPhone à mon épouse. Puis son iPad. Puis mon iPad. Puis l’AppleTV 4. Puis mon MacBook Pro 13" Retina 2015. Puis une AppleTV 4K. Puis mon Mac mini M1. Mon amour pour cet écosystème n’a fait que grandir. Parce qu’enfin, après les deux premiers tiers de ma vie à bidouiller l’informatique, je pouvais enfin utiliser l’informatique. Tout fonctionne. Pas de hack, pas de configuration étrange, pas de bizarrerie que je dois exécuter sans comprendre. Pardonnez-moi l’expression, mais : « ça juste marche ». Le moment où je n’avais plus envie de bidouiller mais simplement utiliser est venu.

Et quand j’ai vu la conférence d’Apple annonçant sa première puce maison depuis… je ne sais pas combien d’années puisqu’avant l’iPhone de mon épouse, je n’avais cure d’Apple que je détestais presqu’encore plus que Microsoft, j’ai su qu’il me fallait le Mac mini M1, surtout considérant son prix. Si cette machine tenait ses promesses et qu’elle coutait bien ce qu’ils annonçaient, ça allait être énorme.

Et le fait est que c’est énorme. Cette puce est monstrueuse en termes de performances, comparativement à sa consommation électrique. C’est réellement la révolution qu’ils promettaient. Ce Mac mini M1 est probablement le meilleur investissement de toute ma vie, et vous pouvez me croire, j’en ai eu des ordinateurs (et j’en ai encore, bien plus que listé ici…).

Et même via la couche de compatibilité Rosetta 2, même avec plein d’applications lancées en même temps, tout va plus vite. Tout est quasi instantané. C’est magique. Ça fonctionne, c’est simple, intuitif, esthétique (même si c’est personnel). Mon double-écran en 2x 240Hz fonctionne sans problème, ma souris SteelSeries Rival 3 et mon clavier Corsair Strafe RGB fonctionnent sans soucis (même si c’était déjà le cas avec le MacBook Pro). J’ai enfin du plaisir à utiliser mon ordinateur. Contextuellement, ma station de travail doit m’aider, pas se mettre sur mon chemin. Un serveur, oui, ça se configure aux petits oignons, je prends mon temps pour l’installer et le paramétrer. Mais ma machine de travail doit fonctionner, tout de suite, et ne doit pas nécessiter mon attention toutes les deux secondes pour autre chose.

Station de jeu 🔗

Ma station de jeu est un Core i7 7700k, doté de 16Go de DDR3, de deux nVIDIA GT1070 8Go, et d’un Crucial MX500 de 1 To. Elle tourne sous debian stable, avec i3-wm, steam, firefox, et… c’est tout. Et tout fonctionne parfaitement bien. Le travail fait sur Proton par steam est excellent : tous mes jeux se lancent sans problème de compatibilité et avec d’excellentes performances. Je n’ai pas eu besoin de hack ou de configurations exotiques : tout fonctionne out-of-the-box.

Consommation électrique 🔗

Je dispose d’un onduleur Eaton Ellipse 1200 Pro qui présente la caractéristique intéressante de me fournir la consommation réelle de ce qui est branché dessus. Ainsi, je peux dire que mes quatre serveurs x86, un des deux MR2200ac, et le switch consomment au total de 32W à 50W en moyenne. Je trouve que c’est très satisfaisant. L’onduleur pourrait ainsi fonctionner pendant une heure à une heure-et-demi sur batterie si une coupure de courant devait survenir. Largement de quoi voir venir…

Modifications ultérieures 🔗

J’aimerais atteindre les objectifs suivants, à condition que cela ne me coûte rien d’autre qu’un peu de temps :

  • Ajouter un SSD M.2 à GN41 et l’un des SSD de 500Go de l’U820, et sortir le SSD de 120Go
  • Utiliser docker swarm : les trois serveurs GNU-Linux (le U820, le GN41 et le T34) aurait la même position de manager
  • Utiliser Ceph afin d’avoir une redondance du stockage entre U820 et GN41 sur les SSD de 500Go
  • Orchestrer les services pour qu’il y ait toujours au moins un réplicat lancé et disponible, de sorte à ce que même si U820 ou GN41 est down, cela n’ait aucun impact sur mon réseau (c’est quelque chose que je demande en particulier pour la stack Pi-hole + Unbound et le serveur Gitea)
  • Éventuellement, permettre la perte de deux serveurs sur trois, si c’est possible sans ajouter un troisième SSD de 500Go sur T34, sachant que je plafonne à 85Go de données stockées
  • Mettre tout ça dans un projet ansible ou, pourquoi pas, nix