Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.
La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:
Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.
Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.
Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.
Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.
Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)
Article pense-bête. J'écris un petit rôle pour configurer firewalld, en gros je veux spécifier quelles interfaces et quels services il faut ajouter dans les zones. Mon idée c'est de définir tout ça dans un dictionnaire dans le playbook, et ensuite de récupérer les élements et sous-élements dans le rôle.
Mouais. C'est quand même loin d'être clair ou évident. Mais c'est le seul moyen que j'ai trouvé pour le moment. Si quelqu'un connaît une méthode plus propre/lisible je suis preneur.
Ceph fait du stockage distribué. Il permet de répartir des données sur plusieurs machines avec réplicas, assurant ainsi une certaine sécurité et résilience.
Sauf que ça c'est la théorie, en pratique mon expérience a été assez mauvaise et non seulement source d'interruptions de service mais aussi d'un niveau de stress très important (jusqu'à ne plus dormir la nuit). Parce que oui perdre un serveur de prod n'est déjà pas agréable, mais quand il s'agit du stockage c'est encore pire.
Un admin qui bosse avec Ceph
Problème 1: l'usine à gaz
Ceph est gros, très gros, pour le compiler prévoyez au minimum 8GB de ram (sous peine de faire exploser votre machine) et plusieurs heures.
Ensuite pour être à l'aise prévoyez des machines bien dimensionnées (Xeon), beaucoup de RAM (1GB par TB) et du stockage SSD pour la journalisation. A l'usage ne vous étonnez pas de voir la RAM et la swap proche de la saturation, c'est le rythme de croisière.
Et puis l'architecture n'est pas simple il y a les OSD, les PGs, les différents services, et les logs parfois pas très clairs qui vous disent que la reconstruction est bloquée sans vraiment donner de raison.
Problème 2: les bugs
Sur la version Kraken (11.2) il existe une fuite de mémoire avec le service ceph-mgr. La solution est donc de le couper. Sauf que son rôle est justement de contrôler l'utilisation de la mémoire, donc le serveur va naturellement gonfler au fil des mois jusqu'à finir par exploser en vol. Il faut donc régulièrement lancer ceph-mgr puis le couper.
Le hic, c'est que dans le cas où votre serveur est déjà bien chargé (RAM + swap), le lancement de ceph-mgr ajoute un poids supplémentaire ce qui peut amener des lag sur le cluster le temps que la mémoire baisse... et ça c'est très mauvais. Dans mon cas cela a fait basculer plusieurs machines virtuelles en readonly.
Problème 3: ceph-deploy
Avec la mouvance devops il est de plus en plus courant de vouloir installer les choses sans devoir mettre les mains dans le cambouis, faire du sysadmin sans rien connaître en sysadmin quoi. Et c'est problématique. Certes c'est rapide et facile, mais en cas de panne on ne sait pas quoi faire car on ne sait pas comment marche le système.
Ceph-deploy fait le boulot à votre place, et dans le cas où ce n'est pas vous qui avez monté l'infra, si vous ne disposez pas du répertoire contenant les clés et la configuration, bon courage pour manipuler le cluster (ajout ou retrait de nodes). De plus ceph-deploy réserve des surprises en installant pas forcément la version qu'on lui demande...
Problème 4: les performances
Même avec un setup assez costaud (plein de RAM et de SSD) les I/O des VM qui sont stockées dessus sont décevantes. C'est un ressenti, mais à l'aire du SSD et/ou du stockage en RAID10, une installation d'une VM debian stockée sur cluster Ceph parait interminable.
Problème 5: résilience
Dans un cluster de 3 nodes on se dit qu'on est tranquilles car on peut en perdre 2 et continuer à fonctionner, un peu comme avec un RAID1 de 3 disques. Sauf qu'en pratique, il faut au minimum 2 nodes actives... Et oui, j'ai testé sur un cluster Ceph 0.96 et 11.2, dans les deux cas les données ne sont plus accessibles s'il ne reste qu'une seule node en vie.
Problème 6: targetcli
C'est le daemon iscsi de Ceph. Le problème ? Il perd sa conf partiellement ou totalement à chaque reboot. Prévoyez un targetctl restore systématique et un downtime possible si vous devez effectuer cette opération.
Conclusion: abandon
Alors que Ceph est censé apporter une continuité de service et donc un sérénité pour les admin, j'ai expérimenté le contraire. Les nombreux downtimes et les fois où j'ai été à deux doigts de perdre l'intégralité du stockage (et donc des machines virtuelles) m'ont causé des nuits blanches d'angoisse.
Les VM sont en cours de migration vers un SAN artisanal à base de Debian + iscsitarget. Il n'est peut-être redondé mais il est fiable, il n'y a pas de fuite de RAM, et s'il y a le moindre pépin nous connaissons les couches de A à Z pour pouvoir diagnostiquer.
En ce qui me concerne Ceph est une usine à gaz qui n'est pas production ready et j'espère ne plus avoir à y toucher de ma vie.
Attention ce titre est volontairement putaclick. Je voulais réagir à ce journal Linuxfr qui m'a beaucoup inspiré : BTRFS ne serait plus le futur. On y apprend que Red Hat laisse tomber le support de Btrfs et il ne sera plus présent dans les futures versions.
Ce n'est pas très rassurant, car sans aller jusqu'à dire que Red Hat fait figure d'autorité dans le libre, leur rayonnement en terme de contribution est tellement important que la grande majorité des distributions décident souvent de faire les mêmes choix. Et c'est compréhensible, c'est une forme "d'union du libre" que certains réclament depuis des années et qui permet de mutualiser les correctifs et évolutions chez les mainteneurs.
Vous allez me rétorquer qu'avec Btrfs c'est différent car c'est un composant upstream de Linux et qu'il n'y a rien à faire en particulier pour l'utiliser, oui sauf que le problème se situe pour le support et le backport des correctifs. Red Hat supporte ses versions 10 ans, cela veut dire qu'il y a un énorme boulot pour intégrer du code récent et changeant dans un kernel stable figé. Beaucoup se reposent sur Red Hat / CentOS, donc si le premier lâche l'affaire, ils suivront.
L'abandon du support de Btrfs est aussi un message fort, en effet Red Hat doit répondre aux attentes de ses clients et c'est notamment ce qui a provoqué le retour en force de xfs que je pensais obsolète depuis des années. Donc il semble qu'il n'y a pas de demande sur le marché et dans les datacenter pour Btrfs. Pourquoi ? Je vais proposer quelques idées.
Personnellement, plus le temps passe et moins je vois d'intérêt à Btrfs. Présenté comme un super système de fichiers moderne de la mort qui tue, son développement semble interminable puisqu'il a débuté en 2007 ! Et non seulement il n'est toujours pas stable, mais en plus toutes les fonctionnalités ne sont pas encore présentes. Sans rentrer dans le détail des possibilités du fs, on se rend compte que presque tout est déjà faisable aujourd'hui avec mdraid et lvm. Et je ne parle même pas de ZFS qui est à des années-lumière devant sur tous les points, qui est stable, éprouvé, et qui rencontre un certain succès. J'en veux pour preuve qu'il est entré dans les dépôts Debian, Ubuntu, et qu'il était déjà présent depuis longtemps chez Archlinux. Même avec les problèmes de licence les distributions choisissent de le supporter !
Ma réflexion me mène donc à une question : Btrfs est-il déjà mort ? Ce projet interminable qui veut concurrencer ZFS sans en avoir les épaules a-t-il une chance de se faire une place ? Étant un convaincu et un fanatique de ZFS je ne pense pas. Les gens qui n'ont pas besoin de fonctionnalités avancées resteront sur ext4, fiable et performant, tandis que les autres se tourneront vers ZFS qui n'est pas si gourmand qu'on le dit et qui offre une souplesse inégalée en terme de gestion des disques, pool et données. Nous verrons ce que l'avenir nous réserve, peut-être qu'une autre distribution réussira à lancer Btrfs.
