Ceph Squid atteint sa fin de vie aujourd’hui, alors qu’Umbrella 21.2.0 sort tout juste
Le 31 octobre 2026, Ceph Squid (19.x) atteint sa fin de vie estimée, deux jours après la sortie d’Umbrella 21.2.0, la 21e version stable. Le chemin de migration n’est pas direct : Ceph impose une montée de version majeure à la fois, et Umbrella exige une base Rocky Linux 10 et des CPU x86-64-v3.
31 octobre 2026. Ceph Squid (19.x) atteint sa fin de vie estimée. 28 octobre 2026. La version 21.2.0, baptisée Umbrella, est publiée — c’est la 21e version stable du projet. Entre les deux, une contrainte qui structure toute migration : Ceph n’autorise qu’une montée de version majeure à la fois, et Umbrella change de socle système.
Squid s’arrête aujourd’hui, Tentacle reste le chemin de sortie
Le tableau des versions actives, publié par la documentation officielle, est sans ambiguïté. Squid (19.x), sorti le 26 septembre 2024 et poussé jusqu’à 19.2.7 le 12 octobre 2026, voit sa fin de vie estimée fixée au 31 octobre 2026 — aujourd’hui. À partir de là, plus de correctifs de sécurité ni de backports pour la branche.
Tentacle (20.x), sorti le 18 novembre 2025 et porté à 20.2.4 le 19 août 2026, reste la branche stable de référence, avec une fin de vie au 1er juin 2027. Umbrella (21.x), tout juste publié, court jusqu’au 28 octobre 2028. La mécanique est donc limpide : un cluster en Squid doit d’abord passer par Tentacle, puis, s’il le souhaite, par Umbrella. Il n’existe pas de raccourci Squid → Umbrella — Ceph impose une version majeure à la fois, et c’est une règle de conception, pas une préférence d’équipe.
Cette règle a une conséquence opérationnelle immédiate. Attendre trop longtemps sur Squid, c’est accumuler deux sauts de version à effectuer en séquence, chacun avec son lot de vérifications de santé, de scrubs et de basculements de démons. La sortie d’Umbrella ne raccourcit pas ce chemin ; elle rend l’attente plus coûteuse.
Umbrella 21.2.0 : ce qui change sous le capot
Umbrella n’est pas une version cosmétique. La note de version liste des changements qui touchent le cœur du stockage.
D’abord, l’erasure coding optimisé (« Fast EC »), un nouveau chemin d’E/S qui inclut des lectures directes EC, le support CLS pour les lectures EC, le support OMAP et une vérification CRC accélérée des données et de la première parité. Pour les clusters qui encodent des données volumineuses en EC, c’est un gain de performance potentiel — et une raison de plus de tester avant de généraliser.
Ensuite, le durcissement de l’authentification CephX. Umbrella introduit le chiffrement AES256KRB5 comme nouveau défaut, en remplacement de types de clés historiques plus faibles, ainsi que la rotation de clés en ligne pour les démons mon, OSD et MDS pendant les montées de version. La version corrige au passage CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 et CVE-2026-54330 — dont une mauvaise utilisation d’AES-CBC permettant un contournement d’authentification. Pour un cluster exposé, c’est l’argument sécurité le plus fort du lot.
Enfin, des évolutions plus larges : le PG autoscaler relève ses plafonds par défaut (mon_target_pg_per_osd de 100 à 200, mon_max_pg_per_osd de 250 à 500), ce qui peut amener des pools existants à se redécouper en plus de PG après la mise à niveau ; Crimson/Seastore continue sa montée en puissance avec le support EC ; le RGW gagne la déduplication d’objets (en tech preview) et le chiffrement AES-256-GCM ; et le dashboard migre vers le design system IBM Carbon.
La mécanique d’une montée de version Ceph, en pratique
Concrètement, une montée de version majeure sur Ceph se pilote via cephadm : on commence par mettre à jour les démons monitor et manager, puis les OSD, puis les MDS et le RGW, en laissant le cluster se stabiliser entre chaque étape. Ceph orchestre ce rolling upgrade sans interrompre le service — les données restent servies pendant la migration — mais chaque étape suppose un cluster sain au départ. C’est pourquoi la consigne de la documentation est toujours la même : vérifier ceph -s, résoudre les avertissements, puis monter une version majeure à la fois, sans jamais sauter d’échelon ni tenter de redescendre. Un cluster en Squid qui vise Umbrella doit donc passer par Tentacle, laisser le cluster se stabiliser, puis enchaîner. C’est un marathon en deux étapes, pas un sprint.
La falaise cachée : Rocky Linux 10 et x86-64-v3
Le point que la plupart des opérateurs découvriront au moment de la montée de version n’est pas une fonctionnalité — c’est le socle. Les images de conteneurs Umbrella reposent sur Rocky Linux 10 (el10), qui exige un CPU supportant le niveau de microarchitecture x86-64-v3. Les hôtes équipés de processeurs plus anciens ne pourront pas exécuter les démons conteneurisés d’Umbrella.
En clair : un cluster Squid qui tourne sur du matériel daté peut migrer vers Tentacle sans encombre — Tentacle reste sur un socle plus ancien — mais se heurtera au mur x86-64-v3 le jour où il voudra franchir le pas vers Umbrella. C’est une vérification à faire avant de planifier, pas pendant la fenêtre de maintenance.
La seconde exigence est plus douce : Python 3.9 ou plus est requis sur tous les hôtes pour cephadm. Là encore, un hôte figé sur une distribution ancienne peut bloquer la montée de version pour une raison qui n’a rien à voir avec Ceph lui-même.
# 1. Vérifier la version actuelle du cluster
ceph versions
# 2. Vérifier le support x86-64-v3 (niveau de microarchitecture CPU)
lscpu | grep -E 'Model name|Flags' | head -2
# x86-64-v3 requiert AVX2 ; chercher avx2 dans les flags :
lscpu | grep -o 'avx2' || echo "avx2 absent — Umbrella en conteneur est bloqué"
# 3. Vérifier la version de Python pour cephadm
python3 --version
# 4. Avant de monter : vérifier la santé du cluster
ceph -sUne cadence de publication qui s’accélère
Le calendrier des versions raconte une histoire en creux. Squid a tenu un peu plus de deux ans (septembre 2024 → octobre 2026). Tentacle court sur un horizon similaire (novembre 2025 → juin 2027). Umbrella pousse l’échéance à deux ans et demi. Mais la sortie d’Umbrella arrive trois jours seulement avant la fin de vie de Squid — un chevauchement court, qui laisse peu de temps à un exploitant en Squid pour valider Tentacle avant que sa branche ne devienne orpheline.
Ce n’est pas une critique de la communauté Ceph ; c’est une contrainte de fait pour les équipes qui gèrent le stockage distribué sans y consacrer une personne à plein temps. Le stockage, on le met à jour quand il le faut, pas quand on en a envie — et la fenêtre entre deux versions majeures se resserre. Pour une équipe réduite, cela se traduit par une règle simple : ne jamais laisser un cluster en fin de vie, car chaque mois de retard ajoute une montée de version majeure supplémentaire au chemin critique. Le stockage récompense la discipline ennuyeuse de rester à jour, et punit le sprint excitant du rattrapage.
Verdict
Si vous exploitez un cluster Ceph Squid, lancez la montée vers Tentacle maintenant : votre branche est en fin de vie aujourd’hui, et la seule sortie passe par une version majeure à la fois. Ne sautez pas directement vers Umbrella : la règle séquentielle de Ceph l’interdit de toute façon, et Umbrella change de socle système — vérifiez d’abord que vos hôtes supportent x86-64-v3 et Python 3.9+ avant même de planifier. Et si vous êtes déjà en Tentacle, restez-y pour l’instant : c’est la branche stable, maintenue jusqu’au 1er juin 2027, et Umbrella n’a que trois jours — laissez-lui le temps de prouver sa stabilité en production avant de l’adopter. Ceph Squid ne disparaît pas d’un coup de baguette : il devient simplement un cluster sans filet, et dans le stockage distribué, la seule chose qui compte plus que la capacité, c’est la version sur laquelle elle repose.