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 ceci n'est un comparatif entre backuppc et borg mais une courte réflexion. Je cherche à me débarrasser de backuppc pour les raisons suivantes:
Sous le capot c'est l'usine à gaz et c'est un enfer à installer surtout avec le webui quand votre distribution ne le propose pas ou pas complètement (genre FreeBSD).
Je n'aime pas du tout la planification des backup qu'on ne peut pas définir à des horaires (sauf avec des crons).
Il n'est pas disponible dans Nix alors que je migre vers NixOS (j'ai songé à le packager, mais cela me semble trop hardcore pour débuter).
Du coup j'examine les solutions alternatives de backup et tout le monde ne parle que de borg. Ce logiciel a l'air intéressant mais il semble plus adapté à la sauvegarde d'une machine individuelle qu'à l'utilisation dans un parc de centaines de serveurs. En effet les sauvegardes avec Borg se font en "push", il faut l'installer sur chaque serveur qui va ensuite pousser ses sauvegardes vers un repo distant. Avec Backuppc c'est du "pull", un unique serveur se charger d'aller chercher les données de vos serveurs distants.
Je pense que les deux solutions se défendent. L'avantage du pull (backuppc) c'est qu'on centralise la gestion, la surveillance et le stockage en un point, il n'y a rien à faire sur les serveurs. L'inconvénient est que votre serveur de sauvegarde doit disposer des accès root à l'intégralité de votre parc, ce qui peut constituer une faiblesse en terme de sécurité. Le push (Borg) est beaucoup plus sécurisé, par contre il faut l'installer et le gérer sur chaque machine ce qui ne doit pas être évident quand on en a des centaines.
La question est de savoir qui a raison. Faut-il faire ses sauvegardes en push et privilégier la sécurité ou en pull et privilégier la facilité de gestion ?
Il y a des gens qui préfèrent les distributions stable telles que debian et il y en a d'autres qui, au contraire, veulent du rolling release. Sur serveur j'ai toujours privilégié la stabilité, donc debian mais je n'ai pas toujours le choix.
Mon NAS tourne sous FreeNAS, et ayant besoin d'étendre ses possibilités j'ai ajouté quelques jails qui offrent donc du FreeBSD quasi upstream. Or FreeBSD a une base stable mais la plupart des ports/packages non. J'ai fait la configuration avec Ansible pour pouvoir tout réinstaller facilement sans me poser de question (voir Docker, Ansible, NixOS : le savoir (re)faire). Et justement le cas s'est présenté, suite au passage au chiffrement des disques j'ai du backuper/restaurer toutes les données et recréer mes jails. Le problème est qu'Ansible n'a pas pu jouer les playbook à cause de cet aspect rolling release qui fait que le comportement ou les fichiers de conf des logiciels à installer a changé. Je pense notamment à unbound, je parse le /usr/local/etc/unbound.conf à la recherche d'une ligne "listen 0.0.0.0" que je créé si elle n'existe pas. Or depuis peu elle est présente dans une autre contexte, cela induit donc mon playbook en erreur. Ce n'est pas trop grave, il m'a fallu moins de 1h pour tout corriger et tout installer.
J'étudie la possibilité de remplacer ces jails FreeBSD par des machines virtuelles debian, car FreeNAS supporte la virtualisation avec bhyve. Une grande stabilité est nécessaire pour orchestrer et automatiser les choses proprement.
