Nouveau IBM FlashSystem 2026 – 5600, 7600 et 9600

10 février, 2026/dans Informations/par albamart

📑 Sommaire

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans
Les trois modèles : 5600, 7600 et 9600
FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)
FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité
Détection de ransomware en 60 secondes : les données et les astérisques
L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement
Pure Storage, Dell, NetApp… et maintenant ?
À qui s’adresse-t-il ?
Conclusions

IBM vient de dévoiler à Varsovie la nouvelle génération d’IBM FlashSystem. Trois nouveaux modèles (5600, 7600 et 9600), un moteur d’IA intégré baptisé FlashSystem.ai, la cinquième génération de son unité flash propriétaire et un message qui sonne très bien en keynote : « stockage autonome co-piloté par l’IA agentique ».

Nous travaillons avec les baies FlashSystem au quotidien. Mais c’est justement pour cette raison qu’une analyse sérieuse s’impose ;) Décortiquons ensemble ce qui se cache derrière chaque chiffre et où se trouve la vraie valeur ajoutée.

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans

IBM n’exagère pas en affirmant que c’est son lancement le plus important depuis 2020. Ce n’est pas un simple rafraîchissement cosmétique : ce sont trois baies simultanées, une refonte complète de l’unité flash et une couche d’IA qui va bien au-delà de ce que proposait la génération précédente.

L’idée de fond est que la baie de stockage cesse d’être « une armoire qui stocke des données » et devienne un système qui analyse, optimise et se protège de manière autonome.

Sam Werner, Directeur Général d’IBM Storage, a été assez clair lors de la présentation : il ne s’agit pas de remplacer l’administrateur, mais de le libérer des tâches répétitives pour qu’il puisse consacrer son temps à l’architecture et à la planification.

Ça ressemble à un slide de keynote ? Un peu. Mais les chiffres matériels qui se cachent derrière sont réels et, dans certains cas, véritablement impressionnants.

Les trois modèles FlashSystem de 2026 : FlashSystem 5600, 7600 et 9600

La nouvelle gamme remplace les FlashSystem 5300, 7300 et 9500 avec des améliorations substantielles en capacité, densité et efficacité. Les trois modèles adoptent le format d’unités NVMe EDSFF (Enterprise and Data Center SSD Form Factor), le standard de l’industrie pour une densité et un refroidissement optimaux en environnement de centre de données :

	FlashSystem 5600	FlashSystem 7600	FlashSystem 9600
Format	1U · 12 disques	2U · 32 disques	2U · 32 disques (avant 4U)
CPU	2×12 cœurs Intel Xeon · PCIe Gen 4	2×16 cœurs AMD EPYC · PCIe Gen 5	2×48 cœurs AMD EPYC · PCIe Gen 5
Capacité brute	633 To	1,68 Po	3,37 Po (vs 1,8 Po du 9500)
Capacité utilisable	400 Tou	1,2 Pou	2,4 Pou
Capacité effective	Jusqu’à 2,4 Poe	Jusqu’à 7,2 Poe	Jusqu’à 11,8 Poe
IOPS	2,6 millions	4,3 millions	6,3 millions
Débit lecture	30 Go/s	55 Go/s	86 Go/s (vs 100 Go/s du 9500)
Ports	16× FC ou 20× Ethernet	32× FC ou Ethernet	32× FC ou Ethernet (vs 48 du 9500)
Cas d’usage	Edge, sites distants, petits DC	Virtualisation, analytique	Banque, ERP, charges IA

Un saut générationnel intéressant : les 7600 et 9600 embarquent AMD EPYC avec PCIe Gen 5, tandis que le 5600 reste sur Intel Xeon et PCIe Gen 4. C’est logique par segment — le PCIe Gen 5 double la bande passante par lane, mais pour le cas d’usage edge du 5600, le Gen 4 est plus que suffisant et contribue probablement à maintenir le prix contenu.

Le chiffre le plus frappant est le FlashSystem 5600 qui loge 2,4 Poe dans 1U. Pour les environnements edge ou les centres de données avec des contraintes d’espace, cela change la donne. Et le 9600 passe de 4U à 2U tout en doublant quasiment la capacité brute (de 1,8 Po à 3,37 Po). C’est du progrès réel, pas du marketing.

Cela dit, une nuance importante : les capacités « effectives » (Poe) supposent des taux de déduplication et de compression qui dépendent énormément du type de données. Avec des données déjà compressées ou chiffrées, les 11,8 Poe du 9600 se réduisent à ses 2,4 Pou (utilisables) ou 3,37 Po bruts. C’est de la physique, pas de la magie. IBM le précise en notes de bas de page, mais il convient de le garder bien à l’esprit.

Un autre détail intéressant passé largement inaperçu : le 9600 passe de 48 à 32 ports d’E/S et son débit de lecture maximal passe de 100 Go/s à 86 Go/s par rapport au 9500. C’est un compromis de conception : plus de densité au prix d’un peu de connectivité brute. Selon votre architecture, cela peut compter ou non, mais il vaut mieux le savoir.

Les modèles 7600 et 9600 intègrent des façades LED interactives pour visualiser l’état du système. Cela semble être un détail mineur, mais tout administrateur qui a dû identifier un châssis à 3 heures du matin dans un datacenter l’appréciera.

Famille nouveau IBM FlashSystem 2026 modèles 5600 7600 9600 vue frontale avec façades LED interactives

Nouveaux IBM FlashSystem 2026 — modèles 5600, 7600 et 9600

FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)

C’est ici qu’IBM dispose d’un avantage concurrentiel qui n’est pas du vent : ils conçoivent et fabriquent leurs propres unités flash. Et dans le nouveau FlashCore Module de cinquième génération (FCM5), cela se traduit par quelque chose de très concret.

Le FCM5 est disponible en capacités de 6,6 / 13,2 / 26,4 / 52,8 et 105,6 To au nouveau format NVMe EDSFF. Ce dernier chiffre, 105 To par unité, est le plus élevé de l’industrie pour les charges de travail entreprise. Comment y parviennent-ils ? En utilisant du NAND QLC avec une propriété intellectuelle propriétaire qui performe comme du TLC.

Pour ceux qui ne vivent pas le stockage au quotidien : le QLC (Quad-Level Cell) est plus dense et moins cher que le TLC (Triple-Level Cell), mais offre normalement une endurance en écriture moindre et des performances inférieures. Les concurrents utilisant du QLC standard le limitent aux charges en lecture intensive. IBM, en contrôlant la conception de l’unité de bout en bout, a réussi à surmonter cette limitation. De fait, selon les propres chiffres d’IBM, les FCM obtiennent 5,5 fois plus de cycles d’écriture que les unités QLC standard du marché.

Alistair Symon, VP du développement des systèmes de stockage, l’a expliqué lors du briefing pré-lancement : d’autres fabricants proposent des unités QLC de plus grande capacité, mais étant du QLC standard, elles ne supportent pas les charges d’écriture intensives sur la durée d’amortissement du matériel. Les FCM5 d’IBM, si.

Qu’intègre encore le FCM5 directement dans le matériel ?

Chiffrement quantum-safe pour toutes les données, directement sur l’unité
Compression accélérée par le matériel
Déduplication embarquée (nouveauté de cette génération), permettant des taux de réduction de 5:1
Analyse des E/S accélérée par le matériel : statistiques complexes sur chaque opération sans impact sur les performances

En déchargeant ces opérations sur le module flash au lieu de les exécuter sur les contrôleurs de la baie, IBM libère de la puissance de calcul pour les charges de travail des clients. C’est la même philosophie appliquée avec les générations précédentes de FCM pour la détection d’anomalies, mais poussée un cran plus loin avec la déduplication intégrée.

FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité

FlashSystem.ai est la nouvelle couche de services de données alimentée par l’IA agentique (nous aussi, nous déployons des agents IA en entreprise, au passage). Selon IBM, elle a été entraînée sur des dizaines de milliards de points de télémétrie et des années de données opérationnelles réelles. Le système exécute des milliers de décisions automatisées par jour qui nécessitaient auparavant une supervision humaine.

Les capacités les plus intéressantes :

S’adapte au comportement des applications en quelques heures, et non en semaines comme les systèmes basés sur des modèles
Recommande des optimisations de performance en expliquant son raisonnement (cela permet d’auditer les décisions de l’IA, crucial pour la conformité)
Intègre le retour d’expérience de l’administrateur pour affiner ses recommandations dans le temps
Placement intelligent des charges de travail avec mobilité des données non disruptive, y compris vers des baies tierces
Réduit de moitié le temps de documentation pour les audits et la conformité

Et bien sûr, le chiffre phare : réduction de 90 % de l’effort de gestion manuel. C’est un chiffre spectaculaire, mais qui s’accompagne d’une note de bas de page qui mérite une lecture attentive. IBM le mesure en comparant des tâches routinières spécifiques (provisionnement de volumes avec politiques de copie protégée et DR) sur la nouvelle génération avec FlashSystem.ai vs. la même génération sans FlashSystem.ai. C’est une comparaison interne, en laboratoire, sur des opérations sélectionnées.

Cela signifie-t-il que les 90 % sont inventés ? Non. Cela signifie que c’est le meilleur scénario sur des tâches précises. En exploitation réelle, avec ses intégrations, ses particularités et l’entropie naturelle de toute infrastructure, le bénéfice sera moindre. Il restera probablement significatif — l’automatisation des tâches répétitives apporte une valeur réelle — mais n’attendez pas que votre admin stockage ne travaille plus qu’un jour par semaine.

Il y a quelque chose que nous trouvons véritablement utile : le raisonnement opérationnel explicable. Le système ne se contente pas d’agir — il explique pourquoi. Pour les audits et la conformité (qui pèsent de plus en plus dans les secteurs régulés, comme l’exige la CNIL et les réglementations européennes), disposer d’un journal généré par l’IA des décisions opérationnelles est un avantage réel face à la concurrence.

Détection de ransomware en 60 secondes : les données et les astérisques

Un autre chiffre accrocheur : le FCM5 détecte les ransomware en moins d’une minute. Regardons cela de plus près.

Le système analyse chaque opération d’E/S directement dans le matériel, recherchant des schémas anormaux associés au chiffrement malveillant. Le modèle de détection (version 3.3, lancé au T4 2025) cumule 24 mois d’entraînement avec de la télémétrie de production et maintient un taux de faux positifs inférieur à 1 %, mesuré sur 3 mois.

Combiné à Safeguarded Copy (des copies avec un air gap logique, immuables et invisibles depuis toute connexion externe), IBM affirme qu’il est possible de récupérer d’une attaque en moins d’une minute.

Maintenant, les astérisques qu’IBM met en notes de bas de page :

Le test original de détection sub-minute a été réalisé sur un FlashSystem 5200 (génération précédente) avec un simulateur de ransomware propriétaire d’IBM baptisé WannaLaugh. Oui, il s’appelle vraiment comme ça. Points bonus pour le nom.
La détection porte sur le début du processus de chiffrement, et non sur l’intrusion initiale dans le système.
Un ransomware suffisamment sophistiqué qui chiffre lentement et imite des schémas d’écriture normaux pourrait potentiellement échapper à la détection.

Cela étant dit — et c’est important — disposer d’une détection au niveau matériel avec moins de 1 % de faux positifs est objectivement excellent. La plupart des solutions de détection de ransomware du marché opèrent au niveau du système de fichiers ou du réseau, avec des latences supérieures et des taux d’erreur plus élevés. IBM opère une couche plus bas, directement au niveau des E/S du stockage. En tant que couche supplémentaire dans une stratégie de défense en profondeur, cela apporte une valeur réelle que la concurrence ne peut pas facilement reproduire car elle ne contrôle pas le matériel de ses unités flash.

L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement

Un angle qui peut être plus pertinent que n’importe quel benchmark pour de nombreux responsables informatiques en 2026 : la crise d’approvisionnement en stockage. La demande de capacité pour l’entraînement de modèles d’IA génère des pénuries et des hausses de prix sur les SSD à l’échelle mondiale.

Werner a été direct à ce sujet : IBM est mieux positionné que la plupart des concurrents car il fabrique ses propres unités flash.

Si vous planifiez une extension de capacité sur les 12 à 18 prochains mois et que vous faites face à des délais de 6 mois sur des SSD standard, avoir un fournisseur qui contrôle la fabrication de ses unités est un argument qui n’apparaît dans aucun comparateur Gartner mais qui peut définir un projet.

Pure Storage, Dell, NetApp et les autres — et maintenant ?

Le marché des baies all-flash entreprise est très disputé. Comparons ce qui différencie réellement le nouveau FlashSystem du reste :

Aspect	IBM FlashSystem (nouveau)	Pure Storage FlashArray	Dell PowerStore	NetApp AFF
Unités propriétaires	✅ FlashCore Module (QLC→TLC)	✅ DirectFlash (150 To)	❌ SSD standard	❌ SSD standard
IA de gestion	FlashSystem.ai (agentique)	Pure1 Meta	CloudIQ	BlueXP / AIOps
Détection ransomware HW	✅ Sur l’unité flash	❌ Logiciel	❌ Logiciel	❌ Logiciel (ONTAP)
Support baies tierces	✅ +500 fabricants	❌ Écosystème fermé	Partiel	Partiel (FabricPool)
Chiffrement quantum-safe HW	✅	❌	❌	❌
Modèle de licence	Traditionnel IBM	Evergreen (très transparent)	APEX / traditionnel	Keystone / traditionnel

Là où IBM prend clairement l’avantage :

Le FlashCore Module est un avantage réel et difficile à reproduire. Contrôler la conception de l’unité flash permet d’intégrer des fonctionnalités au niveau matériel (détection de ransomware, chiffrement quantum-safe, déduplication) que la concurrence ne peut faire qu’en logiciel. Pure Storage conçoit également ses propres unités (DirectFlash), mais à ce jour n’intègre ni la détection de ransomware ni le chiffrement post-quantique dans le matériel.

La compatibilité avec plus de 500 fabricants de stockage tiers via FlashSystem Grid est un choix judicieux. En conditions réelles, personne ne dispose d’un environnement homogène, et pouvoir déplacer des données de manière non disruptive entre des baies IBM et celles d’autres fabricants résout un vrai problème de consolidation et de migration.

Là où la concurrence résiste :

Pure Storage obtient systématiquement de meilleures évaluations en termes d’expérience utilisateur et son modèle Evergreen est difficile à battre en transparence de licences. Si le prix et la simplicité contractuelle sont vos priorités, Pure reste un rival redoutable.
NetApp dispose d’ONTAP, un système d’exploitation de stockage d’une maturité remarquable dans les environnements hybrides avec une base installée considérable. Pour ceux qui sont déjà dans l’écosystème NetApp, migrer est difficile à justifier uniquement par de nouvelles fonctionnalités.
Dell PowerStore est compétitif en prix et dispose d’une intégration profonde avec l’écosystème VMware (désormais Broadcom), qui reste l’hyperviseur dominant dans de nombreuses organisations.

En résumé : IBM ne balaie pas la concurrence, mais avec cette génération, il se positionne avec des arguments techniques solides qui vont au-delà du marketing, en particulier sur la sécurité au niveau matériel et la flexibilité multi-fournisseurs.

FlashCore Module 5 d’IBM

À qui s’adresse-t-il ?

Après avoir digéré toutes ces informations, voici les scénarios où le nouveau FlashSystem s’impose le mieux :

Environnements critiques (banque, assurance, santé) où la combinaison de détection de ransomware matérielle, Safeguarded Copy et chiffrement quantum-safe apporte des couches de sécurité que la concurrence n’égale pas au même niveau.
Organisations avec une infrastructure hétérogène qui doivent consolider sans tout remplacer. La compatibilité avec +500 fabricants et la mobilité des données entre baies est un argument authentique.
Datacenters avec des contraintes d’espace où la densité du 5600 (2,4 Poe dans 1U) peut éviter des extensions physiques.
Entreprises qui travaillent déjà avec l’infrastructure IBM Storage et qui cherchent une évolution naturelle intégrée à leurs investissements existants, notamment en combinaison avec SVC ou d’autres solutions du portfolio.

Et qui devrait y réfléchir à deux fois ? Si votre environnement est 100 % virtualisé avec VMware et que toute votre gestion passe par vCenter, l’intégration avec Dell peut avoir plus de sens sur le plan opérationnel. Si votre priorité est la simplicité contractuelle et que votre équipe est réduite, le modèle Evergreen de Pure Storage est difficile à battre.

Conclusions

IBM a fait ses devoirs avec ce lancement. La combinaison du matériel propriétaire (FCM5 avec du QLC qui performe comme du TLC), de l’IA agentique intégrée (FlashSystem.ai) et de la stratégie de compatibilité multi-fournisseurs positionne le nouveau FlashSystem comme une proposition sérieuse.

Est-ce parfait ? Non. Le marketing gonfle certains chiffres (comme tout le monde, ne nous voilons pas la face), l’étiquette de « stockage autonome » est plus aspirationnelle que descriptive, et tant que nous n’aurons pas vu des benchmarks indépendants et des retours d’expérience terrain avec des mois d’exploitation, certaines affirmations restent des promesses.

Mais si l’on met tout dans la balance : la technologie est solide, l’architecture fait sens, la direction est la bonne. Et le fait qu’IBM contrôle depuis la conception de l’unité flash jusqu’à la couche d’IA en passant par le système d’exploitation SVC lui confère une cohérence de stack que peu de fabricants peuvent offrir.

Disponibilité générale : 6 mars 2026.

Vous évaluez le nouveau IBM FlashSystem ou planifiez une migration ?

Chez SIXE, nous travaillons depuis des années avec les baies IBM FlashSystem dans des environnements de production réels. Nous concevons, déployons, migrons et assurons le support technique IBM Storage sans intermédiaire. Si vous avez besoin de conseils sur la manière dont cette nouvelle génération s’intégrerait dans votre infrastructure, n’hésitez pas à nous contacter.

Stockage distribué 2026. Un guide technique (controversé)

30 janvier, 2026/dans Informations/par sixe

Une autre année vivante, une autre année à regarder l’industrie du stockage distribué se surpasser en créativité commerciale. Si 2024 était l’année où tout le monde a découvert qu’il fallait du “stockage pour l’IA” (spoiler : c’est le même vieux stockage, mais avec un meilleur marketing), 2025 est l’année où MinIO a décidé de s’immoler publiquement pendant que le reste de l’écosystème continue d’évoluer à un rythme soutenu.

Accrochez-vous, ça va secouer !

📋 Table des Matières

→Le Drame de l’Année : MinIO Passe en « Mode Maintenance »
→Ceph Continue de Nager Paisiblement (Tentacle v20.2.0)
•Les Chiffres Qui Comptent : Bloomberg, CERN, DigitalOcean
→L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes
•IBM Fusion : Deux Saveurs pour Différents Besoins
•Red Hat Ceph Storage : Le Standard Entreprise
•SUSE : Une Leçon sur le Verrouillage Fournisseur
•Pure Storage et NetApp : L’Approche Appliance
→La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?
→Démystifier les Affirmations Marketing
→Une Décision Intelligente : Décider en S’informant
→Où Trouver Ces Connaissances
→Conclusions pour 2026

Le Drame de l’Année : MinIO Passe en « Mode Maintenance » (Lire : Mode Abandon)

Si tu n’as pas suivi le feuilleton MinIO, laisse-moi te donner un peu de contexte. MinIO était le stockage d’objets open source que tout le monde déployait. Simple, rapide, compatible avec S3. Tu le mettais en place et en service en 15 minutes. C’était le WordPress du stockage objet.

Eh bien, en décembre 2025, un commit silencieux dans le README a tout changé : « Ce projet est actuellement en maintenance et n’accepte pas de nouvelles modifications. » Pas d’annonce. Pas de guide de migration. Pas d’adieu. Juste un commit et un simple au revoir.

La communauté, sans surprise, s’est enflammée. Un développeur a parfaitement résumé la situation : « Une mise à jour silencieuse du README vient de mettre fin à l’ère de MinIO en tant que moteur S3 open-source par défaut. »

Mais cela ne s’est pas fait du jour au lendemain. MinIO poursuivait depuis des années une stratégie « open source mais sans en faire trop » :

2021 : Passage silencieux d’Apache 2.0 à AGPL v3 (pas d’annonce, pas de PR, rien)
2022-2023 : Campagnes agressives contre Nutanix et Weka pour « violation de licence »
Février 2025 : Console Web, gestion des buckets et réplication supprimées de la version communautaire
Octobre 2025 : Arrêt de la distribution des images Docker
Décembre 2025 : Mode maintenance

Le message est clair : si tu veux MinIO pour de vrai, paie. Leur produit entreprise AIStor commence à 96 000 €/an pour 400 TiB. Pour 1 PB, on parle de plus de 244 000 €/an.

La leçon à retenir ? En 2025, « Open Source » sans gouvernance ouverte ne vaut rien. MinIO était une entreprise avec un produit open source, pas un projet communautaire. La différence est capitale.

Pendant Ce Temps, Ceph Continue de Nager Paisiblement

Pendant que MinIO s’autodétruisait, Ceph fêtait sa 20e version stable : Tentacle (v20.2.0), sortie en novembre 2025. Le projet accumule plus d’un exaoctet de stockage déployé à l’échelle mondiale sur plus de 3 000 clusters.

L’élément le plus intéressant de Tentacle est FastEC (Fast Erasure Coding), qui améliore les performances des petites lectures et écritures de 2x à 3x. Cela rend l’erasure coding enfin viable pour les charges de travail qui ne sont pas du stockage froid pur. Avec un profil EC 6+2, tu peux désormais obtenir environ 50 % des performances de la réplication 3 tout en utilisant seulement 33 % de l’espace.

Pour ceux d’entre nous qui entendent depuis des années que « le codage par effacement est lent pour la production », cela change vraiment la donne.

Autres nouveautés de Tentacle :

Prise en charge intégrée de SMB via Samba Manager
Groupes de passerelles NVMe/TCP avec prise en charge multi-namespace
Authentification OAuth 2.0 sur le tableau de bord
Répertoires CephFS insensibles à la casse (enfin !)
ISA-L remplace Jerasure (qui a été abandonné)

Le Crimson OSD (basé sur Seastar pour l’optimisation NVMe) est encore en avant-première technique. Il n’est pas prêt pour la production, mais la feuille de route est prometteuse.

Les Chiffres Qui Comptent

Bloomberg exploite plus de 100 Po dans des clusters Ceph. Ils sont membre Diamant de la Fondation Ceph et leur responsable de l’ingénierie du stockage siège au conseil d’administration. DigitalOcean possède plus de 54 Po dans 37 clusters de production. Le CERN maintient 50+ Po dans plus de 10 clusters.

Et voici la partie intéressante : ZTE Corporation fait partie des 3 premiers contributeurs mondiaux à Ceph et est numéro 1 en Chine. Son produit TECS CloveStorage (basé sur Ceph) est déployé dans plus de 320 projets NFV dans le monde, notamment chez China Mobile, izzi Telecom (Mexique) et Deutsche Telekom.

Le secteur des télécoms est la superpuissance secrète de Ceph. Alors que beaucoup pensent encore aux appliances traditionnelles, les télécoms font tourner Ceph en production à grande échelle.

L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes

C’est là que les choses deviennent intéressantes. Et il vaut la peine de comprendre ce qui se cache derrière chaque option.

IBM Fusion : Deux Saveurs pour Différents Besoins

IBM propose deux produits sous la marque Fusion, et il est important de comprendre la différence :

IBM Fusion HCI : utilise IBM Storage Scale ECE (l’ancien GPFS/Spectrum Scale). Système de fichiers parallèle avec erasure coding distribué. Appliance hyperconvergée qui évolue de 6 à 20 nœuds.
IBM Fusion SDS : utilise OpenShift Data Foundation (ODF), qui est basé sur Ceph packagé par Red Hat.

Storage Scale est une technologie véritablement différenciée, notamment pour le HPC. Son architecture de système de fichiers parallèle offre des capacités que Ceph n’a tout simplement pas : gestion avancée des métadonnées, tiering intégré, AFM pour la fédération… Si tu as des charges de travail de calcul haute performance, de supercalculateur ou d’IA à une échelle sérieuse, Storage Scale a de solides arguments techniques pour se justifier.

Les performances revendiquées par IBM Fusion HCI sont impressionnantes : accélération de 90x sur les requêtes S3 avec mise en cache locale, performances équivalentes à celles de Databricks Photon à 60 % du coût, etc.

Cependant, il vaut toujours la peine de se poser la question suivante : quelle est la part de cette performance qui relève de la technologie propriétaire et quelle est celle qui relève simplement d’un matériel bien dimensionné dans la bonne configuration ? Ce n’est pas une critique, c’est une question légitime que tout architecte devrait se poser avant de prendre une décision.

Dans le cas de Fusion SDS, tu achètes Ceph avec la valeur ajoutée du packaging, de l’intégration OpenShift et du support entreprise IBM. Pour de nombreuses organisations, cela a une réelle valeur.

Red Hat Ceph Storage : Le Standard Entreprise

Red Hat Ceph Storage continue d’être la distribution de choix pour les entreprises. Ils offrent 36 mois d’assistance production et 24 mois d’assistance étendue en option. Le produit est solide et bien intégré.

Ce que tu achètes réellement : des packages testés et certifiés, un support entreprise 24h/24 et 7j/7, des cycles de vie prévisibles et l’intégration OpenShift.

Est-ce que ça en vaut la peine ? Cela dépend de ton contexte. Si ton organisation a besoin d’un contrat de support pour la conformité ou simplement pour dormir tranquille, probablement oui. Et nous serions heureux de t’aider dans ce domaine. Mais si tu as l’équipe technique pour exploiter Ceph upstream, c’est une décision qui mérite d’être analysée.

SUSE : Une Leçon sur le Verrouillage Fournisseur

Voici une histoire qui mérite réflexion : SUSE a complètement quitté le marché entreprise Ceph. Leur produit SUSE Enterprise Storage (SES) a atteint la fin du support en janvier 2023. Après avoir acquis Rancher Labs en 2020, ils ont pivoté vers Longhorn pour le stockage natif Kubernetes.

Si tu étais client SES, tu t’es retrouvé orphelin. Tes options étaient de migrer vers Red Hat Ceph Storage, Canonical Charmed Ceph, Ceph communautaire, ou de trouver un partenaire spécialisé pour t’aider dans la transition.

Ce n’est pas une critique envers SUSE ; les entreprises pivotent selon leur stratégie. Mais c’est un rappel que le contrôle de ton infrastructure a une valeur qui n’apparaît pas toujours dans le TCO.

Pure Storage et NetApp : L’Approche Appliance

Pure Storage a créé une catégorie appelée « Unified Fast File and Object » (UFFO) avec sa famille FlashBlade. Matériel impressionnant, performances constantes, expérience utilisateur soignée. Son FlashBlade//S R2 évolue jusqu’à 60 Po par cluster avec des modules DirectFlash de 150 To.

NetApp StorageGRID 12.0 met l’accent sur l’IA avec des améliorations de débit de 20x via une mise en cache avancée et la prise en charge de plus de 600 milliards d’objets dans un seul cluster.

Les deux sont des solutions solides qui rivalisent avec Ceph RGW dans le stockage d’objets compatible S3. Les performances sont excellentes. La question que chaque organisation doit se poser est de savoir si le premium justifie le verrouillage fournisseur pour son cas d’utilisation spécifique.

La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?

C’est ici que je mets mon chapeau d’ingénieur réfléchi.

Ceph upstream est extrêmement stable. Il compte 20 versions à son actif. La Fondation Ceph comprend IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud et des dizaines d’autres. Le développement est actif, la communauté est forte et la documentation est abondante.

Alors, quand est-il judicieux de payer pour une distribution entreprise et quand ne l’est-il pas ?

Cela a du sens lorsque : ton organisation a besoin d’un contrat de support pour la conformité ou une politique interne ; tu n’as pas le personnel technique pour faire fonctionner Ceph et tu ne veux pas le développer ; tu as besoin de cycles de mise à jour prévisibles et testés ; le coût de l’arrêt est plus élevé que le coût de la licence ; ou tu as besoin d’une intégration spécifique avec les produits d’autres fournisseurs.

Cela mérite une analyse plus approfondie lorsque : la décision est basée sur « c’est ce que tout le monde fait » ; personne n’a vraiment évalué les alternatives ; la raison principale est que « le fournisseur nous a dit que l’open source n’était pas supporté » ; ou tu disposes d’un équipement technique performant mais tu n’as pas investi dans sa formation.

Le vrai défi, c’est la connaissance. Ceph a une courbe d’apprentissage abrupte. Concevoir correctement un cluster, comprendre les CRUSH maps, régler BlueStore, optimiser les placement groups… tout cela nécessite une formation sérieuse et une expérience pratique.

Mais une fois que tu as ces connaissances, tu as des options. Tu peux choisir judicieusement un fournisseur entreprise, en sachant exactement quelle valeur ajoutée tu achètes. Ou tu peux opérer en upstream avec un support spécialisé. L’essentiel est de prendre une décision en connaissance de cause.

Démystifier les Affirmations Marketing

Une chose que je recommande toujours est de lire les benchmarks et les affirmations marketing avec un esprit critique constructif.

« Notre produit est 90x plus rapide » – Par rapport à quelle base de référence ? Sur quelle charge de travail spécifique ? Avec quelle configuration du concurrent ?

« Des performances équivalentes à celles de [concurrent] à 60 % du coût » – Cela inclut-il le TCO complet ? Licences, support, formation, personnel ?

« Solution certifiée de niveau entreprise » – Qu’est-ce que cela signifie exactement ? Parce que Ceph upstream est également de niveau entreprise au CERN, chez Bloomberg et dans des centaines de télécoms.

Je ne dis pas que ces affirmations sont fausses. Je dis que le contexte est important. En réalité, les performances du stockage distribué dépendent fortement de la conception correcte des clusters (domaines de défaillance, placement groups), du matériel approprié (réseau 25/100GbE, NVMe avec protection contre la perte de puissance), de la configuration du système d’exploitation (IOMMU, CPU governors) et du réglage spécifique à la charge de travail (osd_memory_target, paramètres BlueStore).

Un cluster Ceph bien conçu et géré par des personnes expérimentées peut atteindre des performances impressionnantes. Le benchmark Clyso a atteint 1 TiB/s avec 68 serveurs Dell PowerEdge. IBM a démontré plus de 450 000 IOPS sur un cluster Ceph à 4 nœuds avec 24 NVMe par nœud.

Parfois, cette estampille « solution certifiée » que tu vois sur une fiche technique est, au fond, un logiciel libre avec une configuration experte, un matériel bien dimensionné et beaucoup de tests. Cela a de la valeur, mais c’est bon de le savoir.

Une Décision Intelligente : Décider en S’informant

Après 15 ans dans ce secteur, ma conclusion est qu’il n’y a pas de réponse unique. Ce qu’il y a, ce sont des décisions éclairées.

Pour certaines organisations, une solution entreprise packagée est exactement ce dont elles ont besoin : un support garanti, des temps de cycle prévisibles, une intégration validée et la tranquillité d’esprit d’avoir un fournisseur responsable. IBM Fusion avec Storage Scale est un excellent choix pour le HPC. Red Hat Ceph Storage est une solution solide pour tous ceux qui veulent Ceph avec un backup entreprise.

Pour d’autres organisations, Ceph upstream avec un support et une formation spécialisés offre des avantages significatifs :

Gouvernance de fondation : Ceph est un projet de la Linux Foundation avec une gouvernance ouverte. Le cas MinIO ne peut pas se produire.
Communauté active : des milliers de contributeurs, des versions régulières, des bugs corrigés rapidement.
Flexibilité : c’est ton cluster, ta configuration. Si demain tu décides de changer de partenaire de support, tu ne perds rien.
TCO transparent : Le logiciel est gratuit. Tu investis dans le matériel et les connaissances appropriés.
Contrôle des versions : Tu mets à jour quand cela te semble logique, et non pas quand le fournisseur sort la prochaine version packagée.

Le dénominateur commun dans les deux cas est la connaissance. Que tu achètes une solution entreprise ou que tu déploies upstream, une compréhension approfondie de Ceph te permet de prendre de meilleures décisions, de mieux négocier avec les fournisseurs et de résoudre les problèmes plus rapidement.

Où Trouver Ces Connaissances

Ceph est complexe. Mais il existe des chemins clairs :

La documentation officielle est très complète et s’est beaucoup améliorée. Le blog Ceph propose d’excellents approfondissements techniques.

Cephalocon est la conférence annuelle où tu peux apprendre de ceux qui exploitent Ceph à une échelle réelle (Bloomberg, CERN, DigitalOcean).

Une formation structurée avec des laboratoires pratiques est le moyen le plus efficace d’acquérir de réelles compétences. Tu n’apprends pas Ceph en lisant des diapositives ; tu l’apprends en cassant et en réparant des clusters.

L’assistance technique L3 assurée par des personnes qui vivent Ceph tous les jours te sort du pétrin quand les choses se compliquent en production. Parce qu’elles se compliqueront. Chez SIXE, nous avons passé des années à former des équipes techniques à Ceph et à fournir une assistance L3 à des organisations de tous types : celles qui opèrent upstream, celles qui utilisent des distributions entreprise et celles qui évaluent les options. Notre programme de formation Ceph couvre tout, de l’architecture de base aux opérations avancées, avec de véritables laboratoires pratiques. Et si tu as déjà Ceph en production et que tu as besoin d’une véritable assistance technique, notre support technique spécialisé est conçu exactement pour cela.

Nous venons également de lancer un programme de certification avec des badges sur Credly pour que ton équipe puisse démontrer ses compétences de manière tangible. Parce que dans ce secteur, « connaître Ceph » ne signifie pas la même chose pour tout le monde.

Badge de certification SIXE CEPH Administrator - Administration du stockage Ceph niveau entrée

Badge de certification SIXE CEPH Advanced Administrator - Niveau avancé d'administration du stockage Ceph

Badge de certification SIXE CEPH Production Operations - Niveau expert en opérations Ceph en production

Conclusions pour 2026

MinIO est mort pour une utilisation sérieuse. Cherche des alternatives : Ceph RGW, SeaweedFS, Garage, ou même le fork RustFS si tu es courageux.
Comprends ce que tu achètes. Il y a des cas où une solution entreprise packagée apporte une réelle valeur ajoutée. Il y en a d’autres où tu paies principalement pour un logo et une configuration que tu pourrais reproduire.
Ceph upstream est mature et prêt pour la production. Bloomberg, DigitalOcean, le CERN et plus de 320 projets télécoms ne peuvent pas tous se tromper.
Le véritable coût du stockage distribué est la connaissance. Investis dans une formation et un support de qualité, quelle que soit l’option choisie.
Le contrôle de ton infrastructure a de la valeur. Demande aux clients de SUSE SES comment cela s’est passé lorsque le fournisseur a décidé de pivoter.
La gouvernance du projet compte autant que la technologie. Fondation ouverte > entreprise avec un produit open source.

2026 s’annonce intéressant. FastEC va changer l’équation de l’erasure coding. L’intégration avec l’IA et le ML continuera de pousser vers plus de performance. Et l’écosystème des fournisseurs continuera d’évoluer avec des propositions qui méritent une évaluation sérieuse.

C’est à toi de décider. C’est la seule chose importante.

Portage de MariaDB vers IBM AIX (Partie 2) : comment AIX se met au niveau de Linux

28 janvier, 2026/dans Informations/par sixe

De “AIX est lent” à “AIX égale Linux” (avec les bons outils et le bon code)

Dans la première partie, je me suis battu avec CMake, j’ai implémenté un pool de threads à partir de zéro et j’ai livré un serveur MariaDB 11.8.5 stable pour AIX. Le serveur a passé 1 000 connexions simultanées, 11 millions de requêtes et aucune fuite de mémoire.

Ensuite, j’ai effectué une recherche vectorielle de référence.

AIX: 42 requêtes par seconde.
Linux (même HW) : 971 requêtes par seconde.

Vingt-trois fois plus lent. Sur un matériel IBM Power S924 identique. Même version de MariaDB. Même jeu de données.

Voici l’histoire de la façon dont nous avons découvert qu’il n’y avait aucun écart de performance – juste des erreurs de configuration et un compilateur sous-optimal.

Chapitre 1 : Le sentiment d’affaissement

Il y a un genre particulier de désespoir qui vient quand on voit un écart de performance de 23x sur un matériel identique. C’est le genre de désespoir “j’aurais peut-être dû devenir fleuriste”.

Permettez-moi de planter le décor : les deux machines sont des LPARs fonctionnant sur des serveurs IBM Power S924 avec des processeurs POWER9 à 2750 MHz. Même MariaDB 11.8.5. Même ensemble de données de test – 100 000 vecteurs à 768 dimensions, utilisant l’index MHNSW (Hierarchical Navigable Small World) de MariaDB pour la recherche vectorielle.

Le critère de référence était simple : trouver les 10 voisins les plus proches d’un vecteur de requête. C’est le genre d’opération qui alimente toutes les fonctions de recherche améliorées par l’IA que tu as déjà utilisées.

Linux l’a fait en environ 1 milliseconde. AIX a mis 24 millisecondes.

Mon premier réflexe a été le déni. “Le repère doit être erroné”. Ce n’était pas le cas. “Peut-être que l’index est corrompu”. Ce n’était pas le cas. “Peut-être que le réseau est lent”. Il s’agissait d’une connexion locale.

Il est temps de creuser.

Chapitre 2 : Les premiers 65x – L’importance de la configuration

Le cache qui a tout oublié

Le premier indice est venu du profileur de MariaDB. Chaque requête prenait le même temps, qu’il s’agisse de la première ou de la centième. Ce n’est pas ainsi que fonctionnent les caches.

J’ai vérifié la configuration MHNSW de MariaDB :

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MO. Notre graphique vectoriel a besoin d’environ 300 Mo pour contenir la structure HNSW en mémoire.

C’est là que le bât blesse : lorsque le cache se remplit, MariaDB n’expulse pas les anciennes entrées (pas de LRU). Il jette tout et repart à zéro. Chaque. Chaque. Demande.

Imagine une bibliothèque où, lorsque les étagères sont pleines, le bibliothécaire brûle tous les livres et commande de nouveaux exemplaires. Pour chaque utilisateur.

Correction: mhnsw_max_cache_size = 4GB dans la configuration du serveur.

Résultat : 42 QPS → 112 QPS. Une amélioration de 2,7x à partir d’une seule ligne de configuration.

Le problème de la taille des pages

AIX utilise par défaut des pages de mémoire de 4 Ko. Linux sur POWER utilise des pages de 64 Ko.

Pour le modèle d’accès du MHNSW – la chasse aux pointeurs sur un graphique de 300 Mo – cela a une importance énorme. Avec des pages de 4 Ko, tu as besoin de 16x plus d’entrées TLB (Translation Lookaside Buffer) pour mapper la même quantité de mémoire. Les erreurs du TLB coûtent cher.

C’est comme si tu naviguais dans une ville. Avec des pages de 4 Ko, tu as besoin d’indications pour chaque bâtiment. Avec des pages de 64 Ko, tu obtiens des indications par quartier. C’est beaucoup plus rapide quand tu es constamment en train de sauter d’un bâtiment à l’autre.

Correction: script d’enrobage qui définit LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

Résultat : 112 QPS → 208 QPS en séquentiel, et 2 721 QPS avec 12 travailleurs en parallèle.

Le tableau d’affichage après la phase 1

Configuration	QPS séquentiel	Avec 12 travailleurs
Base de référence	42	~42
+ 4GB cache	112	–
+ 64K pages	208	2,721

Amélioration de 65x à partir de deux changements de configuration. Aucune modification du code.

Mais nous étions toujours 6x plus lents que Linux par cœur. L’enquête s’est poursuivie.

Chapitre 3 : Le mystère du décrochage entre le CPU et la mémoire

Une fois la configuration établie, j’ai sorti les outils de profilage. MariaDB possède un profileur intégré qui décompose le temps de requête par phase.

AIX:

Sending data: 4.70ms total
  - CPU_user: 1.41ms
  - CPU_system: ~0ms
  - Stalls: 3.29ms (70% of total!)

Linux:

Sending data: 0.81ms total
  - CPU_user: 0.80ms
  - Stalls: ~0.01ms (1% of total)

Le temps d’exécution de l’unité centrale était 1,8 fois plus lent sur AIX – ce qui peut s’expliquer par les différences de compilateur. Mais les blocages de la mémoire étaient 329 fois pires.

La cause première : Invalidation du cache de l’hyperviseur

Voici quelque chose que j’ai mis deux jours à comprendre : dans une LPAR (Logical Partition) partagée, l’hyperviseur POWER préempte périodiquement les processeurs virtuels pour donner du temps à d’autres partitions. Ce faisant, il peut invalider des lignes de cache L2/L3.

La traversée du graphe du MHNSW est une chasse aux pointeurs à travers 300 Mo de mémoire – littéralement le pire scénario pour l’invalidation de la mémoire cache. Tu sautes de nœud en nœud, chacun dans une partie différente de la mémoire, et l’hyperviseur vide périodiquement ton cache.

C’est comme essayer de lire un livre alors que quelqu’un ne cesse de le fermer et de le remettre sur l’étagère.

Le système Linux avait des processeurs dédiés. Le système AIX fonctionnait avec des processeurs partagés. Ce ne sont pas des pommes pour des pommes.

Mais avant de pouvoir tester les processeurs dédiés, je devais résoudre le problème du compilateur.

Chapitre 4 : L’odyssée du compilateur

Tout ce que j’ai essayé avec GCC (et pourquoi ça a échoué)

Tentative	Résultat	Pourquoi
`-flto` (Optimisation du temps de connexion)	Impossible	GCC LTO nécessite le format ELF ; AIX utilise XCOFF
`-fprofile-generate` (PGO)	Échec de la construction	Erreurs de l’assembleur concernant la relocalisation relative au TOC
`-ffast-math`	Tout se casse la figure	IEEE float violations corrupt bloom filter hashing
`-funroll-loops`	Plus lent	Cache d’instruction gonflé – POWER9 n’aime pas ça
`-finline-functions`	Plus lent	Même problème de cache I

La boîte à outils AIX GCC est construite sans support LTO. Ce n’est pas un drapeau que tu as oublié – c’est architecturalement impossible parce que l’implémentation LTO de GCC nécessite ELF, et AIX utilise XCOFF.

Les paquets MariaDB d’Ubuntu utilisent -flto=auto. Cette optimisation n’existe tout simplement pas pour AIX avec GCC.

IBM Open XL : Le rebondissement de l’intrigue

À ce stade, j’ai passé trois jours à essayer de rendre GCC plus rapide. Il est temps d’essayer quelque chose de différent.

IBM Open XL C/C++ 17.1.3 est le compilateur moderne d’IBM, basé sur LLVM/Clang. Il génère un code nettement meilleur pour POWER9 que GCC.

Pour construire MariaDB avec Open XL, il a fallu résoudre cinq problèmes différents :

En-tête HTM manquant: Open XL n’a pas le fichier htmxlintrin.h de GCC. J’ai créé un stub.
AR 32 bits par défaut: Les outils AIX sont par défaut en 32 bits. Définis OBJECT_MODE=64.
Incompatibilité LLVM AR: Open XL’s AR ne pouvait pas gérer XCOFF. Utilise le système /usr/bin/ar.
Conflits OpenSSL: Utilise -DWITH_SSL=system pour éviter les problèmes liés à WolfSSL.
Chemins d’accès aux bibliothèques manquants: Explicit -L/opt/freeware/lib pour l’éditeur de liens.

Ensuite, j’ai exécuté le test de référence :

Compilateur	30 requêtes	Par requête
GCC 13.3.0	0.190s	6.3ms
Open XL 17.1.3	0.063s	2.1ms

Trois fois plus rapide. Même code source. Mêmes drapeaux d’optimisation (-O3 -mcpu=power9).

Et voici le bonus : la variance du benchmark de GCC était de 10 à 40 % entre les exécutions. La variance d’Open XL était inférieure à 2 %. Il n’y a pratiquement pas de gigue.

Pourquoi une telle différence ?

Open XL (qui est basé sur LLVM) l’a fait :

Meilleure planification des instructions pour l’exécution hors ordre de POWER9
Attribution de registres supérieurs
Des passes d’optimisation plus agressives

Le backend POWER/XCOFF de GCC n’est tout simplement pas aussi mature. La boîte à outils AIX GCC est fonctionnelle, mais elle n’est pas optimisée pour les charges de travail critiques en termes de performances.

Chapitre 5 : Les impasses du LTO et du PGO

L’espoir est éternel. Peut-être que les LTO et PGO d’Open XL fonctionneraient ?

LTO : L’ironie

Open XL prend en charge -flto=full sur XCOFF. Il se construit vraiment ! Mais…

Résultat : 27 % plus lent que l’Open XL non LTO.

Pourquoi ? Les bibliothèques partagées AIX nécessitent une liste d’exportation explicite (exports.exp). Avec LTO, le script de CMake a vu ~27 000 symboles à exporter.

Le principal avantage de l’OLT est d’internaliser les fonctions, c’est-à-dire de les marquer comme étant locales afin qu’elles puissent être optimisées ou mises en ligne. Lorsque tu es obligé d’exporter 27 000 symboles, aucun d’entre eux ne peut être internalisé. Les frais généraux de l’OLT (fichiers intermédiaires plus volumineux, liaison plus lente) demeurent, mais l’avantage disparaît.

C’est comme si tu payais un abonnement à une salle de sport et qu’on te disait ensuite que tu ne peux utiliser aucun des équipements.

PGO : Les profils qui n’ont jamais existé

L’optimisation guidée par le profil semblait prometteuse :

Construis avec -fprofile-generate
Charge de travail pour l’entraînement à la course à pied
Reconstruis avec -fprofile-use
Profite d’un code plus rapide

L’étape 1 a fonctionné. Étape 2… les profils ne sont jamais apparus.

J’ai lié manuellement le runtime de profilage LLVM à la bibliothèque partagée. Toujours pas de profils.

La cause première : Le runtime de profilage de LLVM utilise atexit() ou __attribute__((destructor)) pour écrire des profils à la sortie. Sur AIX avec XCOFF, la sémantique des destructeurs de bibliothèques partagées est différente de celle d’ELF. Le gestionnaire n’est tout simplement pas appelé de manière fiable pour les configurations complexes à plusieurs bibliothèques comme MariaDB.

Les cas de test simples fonctionnent. Les applications réelles ne fonctionnent pas.

Chapitre 6 : La révélation LPAR

J’avais maintenant un compilateur rapide. Il est temps de tester les processeurs dédiés et d’éliminer le problème d’invalidation du cache de l’hyperviseur.

La matrice de test

Config LPAR	GCC	Open XL
12 vCPUs partagés	0.190s	0.063s
12 plafonds dédiés	0.205s	0.082s
21 dédiés plafonnés	0.320s	0.067s

Attends. Les services partagés sont plus rapides que les services dédiés ?

Le facteur WoF

POWER9 dispose d’une fonction appelée Workload Optimized Frequency (WoF). En mode partagé avec une faible utilisation, un seul cœur peut atteindre ~3,8 GHz. Les processeurs dédiés plafonnés sont bloqués à 2750 MHz.

Pour une requête à un seul fil, le mode partagé obtient 38 % de vitesse d’horloge en plus. Cela bat la pénalité d’invalidation du cache pour cette charge de travail.

Imagine que tu choisisses entre une voiture de sport sur une autoroute avec une circulation occasionnelle (partagée) et un camion avec une voie réservée mais une limite de vitesse (dédiée plafonnée).

Le désastre du mode donateur de PowerVM

Il existe une troisième option : les processeurs dédiés en mode “Donating”, qui redonnent les cycles inactifs au pool partagé.

Mode	GCC	Open XL
Plafonné	0.205s	0.082s
Faire un don	0.325s	0.085s

60% de régression avec GCC.

Chaque fois qu’une requête explose, il y a un temps de latence pour récupérer les cycles donnés. Pour les charges de travail en rafale et à un seul fil, comme les requêtes de base de données, c’est dévastateur.

Recommandation: N’utilise jamais le mode Don pour les charges de travail des bases de données.

Le 21-Core Sweet Spot

Avec 21 cœurs dédiés (contre 24 pour Linux), Open XL a atteint 0,067s – égalant presque les 0,063s du mode partagé. Le cache L3 supplémentaire apporté par plus de cœurs compense l’absence d’augmentation de la fréquence du WoF.

Chapitre 7 : Le tableau d’affichage final (rebondissement)

Nouveaux benchmarks sur du matériel POWER9 identique, janvier 2026 :

Plateforme	Cœurs	30 requêtes
Linux	24 dédié	0.057s
AIX + Open XL	12 partagés	0.063s
AIX + Open XL	21 dédié	0.067s
AIX + GCC	12 partagé	0.190s
AIX + GCC	21 dédié	0.320s

Attends. Le système AIX a 21 cœurs contre 24 pour Linux. Cela représente 12,5 % de cœurs en moins, ce qui signifie 12,5 % de cache L3 en moins.

L’écart mesuré ? 10-18%.

Ce n’est pas un écart de performance. C’est une différence de matériel.

Avec IBM Open XL, AIX offre des performances par cœur identiques à celles de Linux. L’écart de 23x que nous avons constaté au début ? Il n’a jamais été question de la lenteur d’AIX. C’était le cas :

Un cache mal configuré (16 Mo au lieu de 4 Go)
Taille des pages incorrecte (4KB au lieu de 64KB)
Le mauvais compilateur (GCC au lieu d’Open XL)

Le mythe “AIX est lent” est mort.

Le musée complet de l’échec

La science ne se limite pas à ce qui fonctionne – il s’agit aussi de documenter ce qui ne fonctionne pas. Voici notre mur de “bien essayé, mais non” :

Ce que nous avons essayé	Résultat	Notes
`mhnsw_max_cache_size = 4GB`	5 fois plus rapide	Élimine les tressautements de la mémoire cache
`LDR_CNTRL` 64K pages	~40% plus rapide	Réduit les erreurs de la TLB
`MAP_ANON_64K` patch mmap	~8% plus rapide	Amélioration mineure du TLB
IBM Open XL 17.1.3	3x plus rapide	Meilleur codegen POWER9
LPAR partagé (vs dédié)	~25% plus rapide	Augmentation de la fréquence du WoF
Open XL + LTO	27% plus lent	Conflit d’exportation AIX
Open XL + PGO	Ne fonctionne pas	Profils non écrits
GCC LTO	Impossible	XCOFF n’est pas pris en charge
GCC PGO	Échecs de construction	Erreurs de relocalisation du TOC
`-ffast-math`	Casse MHNSW	Corruption par flottaison
`-funroll-loops`	Pire	I-cache bloat
POWER VSX bloom filter	41% plus lent	Pas de multiplication vec 64 bits sur P9
Préfixe logiciel	Aucun effet	L’hyperviseur évince les données préfixées
Réglage du DSCR	Bloqué	L’hyperviseur contrôle le DSCR dans les LPAR partagés
Mode de don	60% de régression	Ne jamais utiliser pour les bases de données

Le résultat de VSX est particulièrement intéressant : nous avons implémenté un filtre Bloom SIMD en utilisant les extensions vectorielles de POWER. Il était 41 % plus lent que le scalaire. POWER9 n’a pas de multiplication vectorielle 64 bits – il faut vec_extract → multiplication scalaire → vec_insert pour chaque voie, ce qui est plus lent que de laisser le moteur Out-of-Order gérer une boucle scalaire.

Ce que j’ai appris

1. Les défauts de paiement sont plus importants que tu ne le penses

Un cache de 16 Mo par défaut a transformé des requêtes de moins d’une milliseconde en requêtes de 24 ms. C’est une pénalité de 24x pour un seul paramètre mal configuré.

Lorsque tu portes un logiciel, remets en question tous les paramètres par défaut. Ce qui fonctionne sous Linux peut ne pas fonctionner sur ta plateforme.

2. Le mythe de la lenteur d’AIX a toujours été un problème de chaîne d’outils

Avec GCC, nous étions 3 à 4 fois plus lents que Linux. Avec Open XL, nous sommes au même niveau que Linux par cœur.

La plateforme n’a jamais été lente. La chaîne d’outils par défaut n’était tout simplement pas optimisée pour les charges de travail critiques en termes de performances. Choisis le bon compilateur.

3. La virtualisation comporte des compromis cachés

Les LPAR partagés peuvent être plus rapides que les LPAR dédiés pour les charges de travail monothématiques (augmentation de la fréquence du WoF). Le mode dédié est plus efficace pour les charges de travail multithreads soutenues. Le mode don est un piège.

Connais ta charge de travail. Choisis ta configuration LPAR en conséquence.

4. Tous les ports d’optimisation n’ont pas la même valeur

LTO, PGO et la vectorisation SIMD ont tous échoué sur AIX pour diverses raisons. Les techniques qui rendent Linux rapide ne se traduisent pas toujours.

Parfois, l’optimisation “évidente” est le mauvais choix. Mesure tout.

5. Parfois, il n’y a pas d’écart du tout

Nous avons passé des jours à enquêter sur un “écart de performance” qui s’est avéré être :

Erreurs de configuration
Mauvais compilateur
Moins de cœurs sur le système de test

La leçon à retenir : vérifie tes données de base. Assure-toi de comparer des pommes avec des pommes avant de supposer qu’il y a un problème à résoudre.

Recommandations

Pour les utilisateurs d’AIX MariaDB

Utilise la version Open XL (version 3, bientôt disponible)
Règle mhnsw_max_cache_size sur au moins 4 Go pour la recherche vectorielle
Conserver le LPAR partagé pour une latence de requête unique
N’utilise jamais le mode don pour les bases de données
Utilise des pages de 64K via le wrapper LDR_CNTRL

Pour MariaDB en amont

Augmente la valeur par défaut de mhnsw_max_cache_size – 16MB est beaucoup trop petit
Mettre en œuvre l’éviction LRU – jeter tout le cache en cas de débordement est brutal.
N’ajoute pas le filtre bloom POWER VSX – le scalaire est plus rapide sur POWER9

Prochaines étapes

Les RPM sont publiés sur aix.librepower.org. Release 2 includes the configuration fixes. La version 3 avec Open XL est également disponible.

Priorités immédiates:

Licence commerciale Open XL : L’évaluation expire bientôt. Il faut vérifier auprès d’IBM si nous sommes d’accord pour utiliser xLC à cette fin.
Implémentation native de l’AIO: AIX a POSIX AIO et IOCP compatible avec Windows. Il est temps d’écrire le backend InnoDB.
Retour d’information sur le MHNSW en amont: La valeur par défaut de mhnsw_max_cache_size (16 Mo) est trop faible pour les charges de travail réelles ; nous suggérerons une valeur par défaut plus élevée.

Pour les organisations qui exécutent déjà des charges de travail critiques sur AIX – et il y en a beaucoup, des banques aux compagnies aériennes en passant par les systèmes de santé – la possibilité d’exécuter également MariaDB moderne et performant ouvre de nouvelles possibilités.

AIX correspond à Linux. Le mythe est mort. Et MariaDB sur AIX est prêt pour la production.

TL;DR

Au départ, l’écart de performance était de 23x (42 QPS contre 971 QPS).
Configuration du cache corrigée : Amélioration de 5x
Taille de page fixe : ~40% de plus
Passage à IBM Open XL: amélioration de 3x par rapport à GCC
LPAR partagé utilisé : ~25% plus rapide que le dédié (WoF boost)
Résultat final : NO GAP – 10% de différence = 12,5% de cœurs en moins (21 vs 24)
AIX atteint les mêmes performances par cœur que Linux grâce à Open XL
Open XL LTO : n’aide pas (27% plus lent)
Open XL PGO : ne fonctionne pas (problème AIX XCOFF)
POWER VSX SIMD : 41% plus lent que le scalaire (pas de multiplication vec 64 bits)
Mode donateur : 60% de régression – ne jamais utiliser pour les bases de données
“AIX est lent pour les bases de données open source” a toujours été un mythe de la chaîne d’outils.

Des questions ? Des idées ? Tu utilises MariaDB sur AIX et tu veux partager ton expérience ?

This work is part of LibrePower – Unlocking IBM Power Systems through open source. Unmatched RAS. Superior TCO. Minimal footprint 🌍

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

MariaDB sur AIX | 3 Semaines de Développement Technique (Partie 1)

28 janvier, 2026/dans Informations/par sixe

MariaDB sur AIX, la plateforme qui alimente les systèmes les plus critiques au monde

Dans la vie, il y a des décisions que tu prends en sachant très bien qu’elles te feront souffrir. Se marier. Avoir des enfants. Courir un marathon. Porter MariaDB 11.8 sur IBM AIX.

Voici (partie 1) l’histoire de la dernière édition – et les raisons pour lesquelles je la referais sans hésiter.

Chapitre 1 : “C’est si dur que ça ?”

Tout a commencé par une question innocente lors d’une réunion d’équipe : “Pourquoi n’avons-nous pas MariaDB sur nos systèmes AIX ?”

Voici ce que les gens qui n’ont jamais travaillé avec AIX ne comprennent pas : AIX ne plaisante pas. Lorsque les banques ont besoin d’un temps de disponibilité de cinq neuf pour leurs systèmes bancaires de base, elles utilisent AIX. Lorsque les compagnies aériennes ont besoin de systèmes de réservation qui ne peuvent pas tomber en panne, elles utilisent AIX. Quand Oracle, Informix ou DB2 doivent fournir des performances absolument brutales pour des charges de travail OLTP critiques, ils utilisent AIX.

AIX n’est pas à la mode. AIX n’a pas de mascotte cool. AIX ne fera pas l’objet d’articles de blogs technologiques essoufflés sur la “perturbation”. Mais lorsque les choses ne peuvent absolument pas échouer, AIX est là, faisant tranquillement son travail pendant que tous les autres sont occupés à redémarrer leurs conteneurs.

Alors pourquoi MariaDB ne prend-elle pas officiellement en charge AIX ? L’économie est simple : la communauté open source s’est concentrée sur Linux, et le portage nécessite une expertise spécifique à la plateforme. MariaDB prend officiellement en charge Linux, Windows, FreeBSD, macOS et Solaris. AIX ne figure pas sur la liste – non pas parce que c’est une mauvaise plate-forme, mais parce que personne n’a encore fait le travail.

Chez LibrePower, c’est exactement ce que nous faisons.

Ma première erreur a été de dire tout haut : “Il suffit sans doute de le compiler et d’ajuster quelques éléments”.

Leçon n° 1: Lorsque quelqu’un dit ” compile-le simplement ” à propos d’un logiciel sur AIX, il est sur le point d’en apprendre beaucoup sur la programmation des systèmes.

Chapitre 2: Défis de CMake pour MariaDB sur AIX

Le premier jour de la compilation a été… éducatif. CMake sur AIX, c’est comme jouer aux cartes avec quelqu’un qui a une compréhension très différente des règles – et qui s’attend à ce que tu les découvres toi-même.

Le bogue de la fonction fantôme

AIX a une caractéristique intéressante : il déclare des fonctions dans les en-têtes pour des raisons de compatibilité, même si ces fonctions n’existent pas réellement au moment de l’exécution. C’est comme si ton GPS te disait “tourne à droite dans 200 mètres” mais que la rue était un mur de briques.

CMake fait un CHECK_C_SOURCE_COMPILES pour tester si pthread_threadid_np() existe. Le code se compile. CMake dit “super, on l’a !” Le binaire démarre et… BOOM. Symbole non trouvé.

Il s’avère que pthread_threadid_np() est réservé à macOS. AIX le déclare dans les en-têtes parce que… eh bien, je ne suis pas encore tout à fait sûr. Peut-être pour une raison de compatibilité POSIX qui avait un sens il y a des décennies ? Quelle que soit la raison, GCC le compile sans problème et l’éditeur de liens ne se plaint pas jusqu’à l’exécution.

Même chose avec getthrid(), qui est spécifique à OpenBSD.

La solution:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

poll.h : Cache-cache

AIX a <sys/poll.h>. C’est juste là. Tu peux cat. Mais CMake ne le détecte pas.

Après trois heures de débogage d’une erreur “POLLIN undeclared” dans viosocket.c, j’ai découvert que la solution consistait simplement à forcer la définition :

cmake ... -DHAVE_SYS_POLL_H=1

Trois heures. Pour un drapeau.

(Pour être honnête, il s’agit d’un problème de détection de plate-forme CMake, et non d’un problème AIX. Les vérifications de CMake supposent des dispositions d’en-tête de type Linux).

Les plugins maudits

À 98 % de la compilation – 98 % ! – le plugin wsrep_info a explosé avec des symboles non définis. Parce qu’il dépend de Galera. Que nous n’utilisons pas. Mais CMake le compile quand même.

Egalement S3 (nécessite les symboles Aria), Mroonga (nécessite Groonga), et RocksDB (profondément lié aux optimisations spécifiques à Linux).

Configuration finale de CMake :

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

Cela ressemble à une amputation chirurgicale, mais il s’agit en fait de tailler dans le gras. Ces plugins sont des cas limites dont peu de déploiements ont besoin.

Chapitre 3: Implémentation du Thread Pool pour MariaDB sur AIX via Pollset

C’est là que les choses sont devenues intéressantes. Et par “intéressant”, je veux dire “j’ai failli me donner un tic permanent”.

MariaDB a deux modes de gestion des connexions :

une-filière-par-connexion: Un thread par client. Simple. S’adapte comme une voiture qui monte une côte.
pool de threads: Un pool fixe de threads gère toutes les connexions. Élégant. Efficace. Et non disponible sur AIX.

Pourquoi ? Parce que le pool de threads nécessite des API de multiplexage d’E/S spécifiques à la plateforme :

Plateforme	API	Statut
Linux	epoll	Pris en charge
FreeBSD/macOS	kqueue	Pris en charge
Solaris	ports d’événements	Pris en charge
Windows	IOCP	Pris en charge
AIX	pollset	Non pris en charge (jusqu’à présent)

Alors… à quel point la mise en œuvre de la prise en charge des jeux de vote peut-elle être difficile ?

(Note de la rédaction : à ce stade, l’auteur a besoin d’une pause de 20 minutes et d’une boisson).

Le problème ONESHOT

Linux epoll possède un merveilleux drapeau appelé EPOLLONESHOT. Il garantit qu’un descripteur de fichier ne déclenche des événements qu’une seule fois jusqu’à ce que tu le réarmes explicitement. Cela empêche deux threads de traiter la même connexion simultanément.

Le pollset AIX est déclenché par niveau. Uniquement déclenché par niveau. Pas d’options. Si des données sont disponibles, il les signale. Encore et encore et encore. Comme un collègue serviable qui te rappelle sans cesse ce courriel auquel tu n’as pas encore répondu.

Onze versions de la sagesse croissante

Il s’en est suivi onze itérations de code, toutes plus élaborées les unes que les autres, pour essayer de simuler le comportement de ONESHOT :

v1-v5 (L’âge de l’innocence)

J’ai essayé de modifier les drapeaux d’événements avec PS_MOD. “Si je mets l’événement à 0, il ne se déclenchera plus”, me suis-je dit. Spoiler : il n’a pas cessé de se déclencher.

v6-v7 (L’ère des machines à états)

“Je sais ! Je vais maintenir l’état interne et filtrer les événements en double.” Le problème : il y a une fenêtre de temps entre le moment où le noyau te donne l’événement et celui où tu mets à jour ton état. Dans cette fenêtre, un autre thread peut recevoir le même événement.

v8-v9 (La phase de déni)

“Je vais mettre l’état à PENDANT avant de traiter”. Ça a marché… en quelque sorte… jusqu’à ce que ça ne marche plus.

v10 (Espoir)

J’ai enfin trouvé la solution : PS_DELETE + PS_ADD. Lorsque tu reçois un événement, supprime immédiatement le fd du pollset. Lorsque tu es prêt à recevoir d’autres données, ajoute-le à nouveau.

// On receiving events: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// When ready: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

Ça a marché ! Avec -O2.

Avec -O3… segfault.

Porter MariaDB sur AIX = Bugs (Le bug -O3)

Imagine mon visage. J’ai un code qui fonctionne parfaitement avec -O2. J’active -O3 pour les benchmarks de production et le serveur se plante avec “Got packets out of order” ou un segfault dans CONNECT::create_thd().

J’ai passé deux jours à penser qu’il s’agissait d’un bug du compilateur. GCC 13.3.0 sur AIX. J’ai accusé le compilateur. J’ai blâmé l’éditeur de liens. J’ai tout blâmé sauf mon propre code.

Le problème était plus subtil : MariaDB a deux chemins de code concurrents qui appellent io_poll_wait sur le même pollset :

Les blocs d’écoute avec timeout=-1
Le travailleur fait appel à timeout=0 pour les vérifications non bloquantes.

Avec -O2, la synchronisation était telle que les collisions étaient rares. Avec -O3, le code était plus rapide, les collisions se produisaient plus souvent, et boom – race condition.

v11 (L’illumination)

La solution consistait à créer un mutex dédié protégeant à la fois pollset_poll et toutes les opérations de pollset_ctl:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... process and delete events ...
    pthread_mutex_unlock(&pollset_mutex);
}

Oui, il sérialise l’accès au pollset. Oui, c’est théoriquement plus lent. Mais tu sais ce qui est encore plus lent ? Un serveur qui tombe en panne.

Le code final de la v11 a passé 72 heures de tests de résistance avec 1 000 connexions simultanées. Aucun plantage. Aucune fuite de mémoire. Aucun “paquet hors service”.

Chapitre 4 : La chose `-blibpath` (en fait une caractéristique)

Une véritable caractéristique d’AIX : tu dois spécifier explicitement le chemin de la bibliothèque au moment de la liaison avec -Wl,-blibpath:/your/path. Si tu ne le fais pas, le binaire ne trouvera pas libstdc++ même s’il se trouve dans le même répertoire.

Au début, cela te semble ennuyeux. Puis tu réalises : AIX préfère les chemins explicites et déterministes aux recherches implicites. Dans les environnements de production où “ça a marché sur ma machine” n’est pas acceptable, c’est une caractéristique, pas un bogue.

Chapitre 5 : Stabilité – Les chiffres qui comptent

Après tout ce travail, où en sommes-nous ?

Le RPM est publié sur aix.librepower.org et déployé sur un système IBM POWER9 (12 cœurs, SMT-8). MariaDB 11.8.5 fonctionne sur AIX 7.3 avec le pool de threads activé. Le serveur a passé avec succès une suite d’assurance qualité brutale :

Test	Résultat
100 connexions simultanées	✓
500 connexions simultanées	✓
1 000 connexions	✓
30 minutes de charge soutenue	✓
11+ millions de requêtes	✓
Fuites de mémoire	ZÉRO

1 648 482 400 octets de mémoire – constants pendant 30 minutes. Pas un seul octet de dérive. Le serveur a fonctionné pendant 39 minutes en charge continue et s’est éteint proprement.

Il fonctionne. Il est stable. Il est prêt à être mis en production.

Impact du pool de fils

Le travail sur le pool de threads a permis des gains massifs pour les charges de travail simultanées :

Configuration	Mélange de 100 clients	par rapport à la ligne de base
Original `-O2` one-thread-per-connection	11.34s	–
`-O3` + pool-of-threads v11	1.96s	83% plus rapide

Pour les charges de travail OLTP à forte concordance, c’est la différence entre “lutter” et “voler”.

Ce que j’ai appris (jusqu’à présent)

CMake suppose qu’il s’agit de Linux. Sur les systèmes non-Linux, vérifie manuellement que la détection des fonctionnalités est correcte. Les faux positifs te feront mal au moment de l’exécution.
Les entrées/sorties déclenchées par niveau nécessitent de la discipline. EPOLLONESHOT existe pour une raison. Si ton système ne l’a pas, prépare-toi à mettre en œuvre ta propre sérialisation.
-O3 expose les bogues latents. Si ton code “fonctionne avec -O2 mais pas avec -O3”, tu as une condition de course. Le compilateur fait son travail ; le bogue est le tien.
Les mutex sont tes amis. Oui, elles ont des frais généraux. Mais tu sais ce qui est le plus coûteux ? Déboguer les conditions de course à 3 heures du matin.
AIX récompense la compréhension profonde. C’est un système qui ne pardonne pas les raccourcis, mais une fois que tu as compris ses conventions, il est prévisible et robuste. Ce n’est pas pour rien que les banques l’utilisent encore – et qu’elles continueront à le faire dans un avenir prévisible.
L’écosystème est important. Des projets comme linux-compat de LibrePower rendent le développement moderne viable sur AIX. Contribuer à cet écosystème profite à tout le monde.

Qu’est-ce qu’on fait maintenant ? La question de la performance

Le serveur est stable. Le pool de discussion fonctionne. Mais il y a une question en suspens à laquelle je n’ai pas encore répondu :

Quelle est sa rapidité par rapport à Linux ?

J’ai effectué un test de recherche vectorielle – le type d’opération qui permet d’améliorer les fonctions de recherche de l’IA. Index MHNSW (Hierarchical Navigable Small World) de MariaDB, 100 000 vecteurs, 768 dimensions.

Linux sur du matériel POWER9 identique : 971 requêtes par seconde.

AIX avec notre nouvelle version : 42 requêtes par seconde.

Vingt-trois fois plus lent.

Mon cœur s’est effondré. Trois semaines de travail, et nous sommes 23x plus lents que Linux ? Sur un matériel identique?

Mais voici ce qu’il en est de l’ingénierie : lorsque les chiffres n’ont pas de sens, il y a toujours une raison. Et parfois, cette raison s’avère être une bonne nouvelle surprenante.

Dans la deuxième partie, je couvrirai :

Comment nous avons découvert que l’écart de 23x était surtout une erreur de configuration.
Le compilateur qui a tout changé
Pourquoi “AIX est lent” s’est avéré être un mythe
Le “musée des échecs” complet des optimisations qui n’ont pas fonctionné.

Les RPM sont publiés sur aix.librepower.org. La version GCC est stable et prête pour la production.

Mais l’histoire de la performance ? C’est là que les choses deviennent vraiment intéressantes.

La deuxième partie arrive bientôt.

TL;DR

MariaDB 11.8.5 fonctionne maintenant sur AIX 7.3 avec le pool de threads activé
Première mise en œuvre d’un pool de threads pour AIX à l’aide d’un pollset (11 itérations pour obtenir une simulation ONESHOT correcte).
Le serveur est stable: 1 000 connexions, plus de 11 millions de requêtes, aucune fuite de mémoire.
Le pool de threads offre une amélioration de 83 % pour les charges de travail simultanées
Le premier test de recherche vectorielle montre un écart de 23x par rapport à Linux – mais est-ce que c’est tout ?
RPMs publiés sur aix.librepower.org
La deuxième partie sera bientôt disponible: L’enquête sur les performances

Des questions ? Des idées ? Tu veux contribuer à l’écosystème open source AIX ?

Ce travail fait partie de LibrePower – Unlocking IBM Power Systems through open source. RAS inégalé. Coût total de possession supérieur. Empreinte minimale 🌍

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

LLMs sur AIX : expérimentation technique au-delà de l’engouement pour les GPUs

12 janvier, 2026/dans Informations/par sixe

À LibrePower, nous avons publié Llama-AIX: une preuve de concept pour exécuter l’inférence de modèle LLM léger directement sur AIX 7.x, en utilisant seulement le CPU et la mémoire, sans GPU.

👉 GitLab

Il faut être clair dès le départ : il s’agit d’amusement technique et d’expérimentation, pas d’un produit, pas d’une promesse commerciale, pas d’une alternative aux grandes plateformes d’IA accélérées par le GPU.

Cela dit, l’expérience repose sur une base technique solide.

La théorie : tous les cas d’utilisation du LLM ne sont pas liés au GPU.

Dans de nombreux scénarios professionnels courants dans les environnements Power :

RAG (Retrieval Augmented Generation)
Questions sur la documentation interne
Assistants techniques sur place
Recherche sémantique sur ses propres connaissances
Analyse de texte fortement dépendante de la latence et de la proximité des données.

Le goulot d’étranglement n’est pas toujours le calcul de la masse, mais.. :

CPU
Largeur de la mémoire
Temps de latence de l’accès aux données
Localisation des données

Dans ces cas, les inférences petites et bien délimitées peuvent être raisonnablement exécutées sans GPU, surtout lorsque le modèle n’est pas le centre du système, mais juste une autre pièce du système.

⚙️ CPU, MMA et accélérateurs basse consommation

L’évolution naturelle ne concerne pas seulement les GPU :

Des processeurs de plus en plus vectorisés
Extensions en tant que MMA
Accélérateurs dédiés et économes en énergie (comme le futur Spyre).
Intégration plus étroite avec le système d’exploitation et la pile de données

Ce type d’accélération est particulièrement pertinent dans les architectures de puissance, où la conception donne la priorité au débit soutenu, à la cohérence et à la fiabilité, et pas seulement aux pics de FLOPS.

🧩 Pourquoi AIX ?

L’exécuter sur AIX n’est pas une nécessité, c’est un choix conscient :

Comprendre les limites réelles
Explorer sa faisabilité technique
Démonter les hypothèses simplistes
Apprendre comment les LLM s’intègrent dans les systèmes d’alimentation existants

De nombreux clients Power exploitent des infrastructures stables, amorties et critiques, où le déplacement des données vers le cloud ou l’introduction de GPU n’est pas toujours souhaitable ou viable.

🔍 Ce qui est (et ce qui n’est pas) Llama-AIX

✔ Un PoC technique
✔ Une exploration honnête
✔ Un exercice d’ingénierie
✔ Source ouverte
✖ Pas un benchmark
✖ Pas une plateforme d’IA complète
✖ Pas destinée à concurrencer les solutions GPU
✖ Pas de ” marketing de l’IA “.

L’idée est simple : voir au-delà du battage médiatique, comprendre les nuances et évaluer où les LLM apportent une réelle valeur dans les environnements Power et AIX.

Purement par curiosité technique.

Et parce que l’expérimentation reste un élément fondamental de l’ingénierie.

Dans quel cas d’utilisation spécifique un LLM in Power sur site aurait-il du sens pour toi ?

Lancement de LibrePower (et voici son Manifeste)

8 janvier, 2026/dans Informations/par sixe

Nous voulons libérer tout le potentiel d’IBM Power.

Nous construisons une communauté pour faire grandir l’écosystème Power – plus de solutions, plus d’utilisateurs, plus de valeur.

Le matériel le plus performant dont tu ne profites pas encore pleinement.

IBM Power est à la base de l’informatique critique dans le monde entier. Les transactions bancaires, les réservations de vols, les systèmes hospitaliers, les installations SAP – les charges de travail qui ne peuvent pas se permettre de tomber en panne fonctionnent sur Power.

Ce n’est pas une coïncidence.

Les systèmes d’alimentation offrent une fiabilité légendaire grâce à leur architecture RAS (fiabilité, disponibilité, facilité d’entretien) que x86 ne peut tout simplement pas égaler. Ils fonctionnent sans problème pendant 10, 15 ans ou plus. Leur conception – grandes caches, SMT8, bande passante mémoire extraordinaire – est conçue pour maintenir les performances à l’échelle de manière durable.

Mais il existe une opportunité que la plupart des organisations manquent :

Le pouvoir peut faire beaucoup plus que ce qu’on lui demande habituellement.

La capacité est là. Le potentiel est énorme. Ce qui a manqué, c’est une validation indépendante, un élan communautaire et des outils accessibles qui ouvrent la porte à de nouveaux cas d’utilisation.

Exactement ce que LibrePower est en train de construire.

Qu’est-ce que LibrePower ?

LibrePower est une initiative communautaire visant à étendre les possibilités d’IBM Power à l’ensemble de l’écosystème :

AIX – L’Unix vétéran qui gère les charges d’entreprise les plus exigeantes
IBM i – Le système intégré sur lequel fonctionnent des milliers d’entreprises dans le monde entier.
Linux on Power (ppc64le ) – Ubuntu, Rocky, RHEL, SUSE, Fedora sur l’architecture POWER

Nous ne sommes pas là pour remplacer quoi que ce soit. Nous sommes là pour ajouter:

Plus de solutions certifiées fonctionnant sur Power
Plus de développeurs et d’administrateurs qui s’appuient sur la plateforme.
Plus de raisons d’investir dans l’énergie – à la fois dans les nouveaux équipements et dans les équipements existants.

Ce que nous faisons

1. Certifié LibrePower – validation indépendante

Les éditeurs de logiciels indépendants et les projets open source ont besoin de savoir que leurs logiciels fonctionnent sur Power. Les acheteurs ont besoin d’être rassurés avant de déployer leurs produits. La certification IBM a sa valeur, mais il y a de la place pour une validation indépendante menée par la communauté.

La certification LibrePower offre trois niveaux :

Niveau	Signification
✅ Travaille sur le pouvoir	Compile et fonctionne correctement sur ppc64le. Validation de base.
⚡ Optimisé pour la puissance	Conçu pour SMT, VSX/MMA. Comprend des données sur les performances.
🏆 Certifié LibrePower	Validation complète + étude de cas + soutien continu.

Gratuit pour les projets open source. Niveaux Premium pour les éditeurs de logiciels indépendants qui recherchent une collaboration plus approfondie.

2. les dépôts de logiciels libres

Nous compilons, emballons et distribuons les logiciels dont la communauté Power a besoin :

AIX(aix.librepower.org) : outils CLI modernes, utilitaires de sécurité, couches de compatibilité
ppc64le: outils de conteneurs (AWX, Podman), utilitaires de développement, surveillance
IBM i: intégration open source (en cours de développement)

Tout est gratuit. Tout est documenté. Tout est sur GitLab.

3. Test de performance et optimisation

Le matériel Power possède des caractéristiques uniques dont la plupart des logiciels ne profitent pas. Nous effectuons des analyses comparatives, identifions les opportunités et travaillons avec des projets en amont pour améliorer les performances sur Power.

Lorsque nous trouvons des optimisations, nous y contribuons en retour. Tout l’écosystème en bénéficie.

4. Construire une communauté

Le monde de Power est fragmenté. Les administrateurs AIX, les équipes Linux on Power, les environnements IBM i – tous résolvent des problèmes similaires de façon isolée.

LibrePower relie ces communautés :

Partage des connaissances entre plates-formes
Amplifier la voix collective auprès des fabricants et des projets.
Créer un réseau d’expertise dans le domaine de l’électricité

5. Élargir le marché

Chaque nouvelle solution validée sur Power est une raison de plus pour les organisations de choisir la plateforme. Chaque développeur qui apprend Power est un talent pour l’écosystème. Chaque histoire de réussite démontre la valeur de la plateforme.

Plus de solutions → plus d’adoption → un écosystème plus fort → plus d’investissements dans Power.

Ce cercle vertueux profite à tout le monde : IBM, partenaires, ISV et utilisateurs.

Pourquoi devrais-tu t’en préoccuper ?

Si tu administres des systèmes Power :

Accède aux outils et aux solutions qui te manquaient.
Rejoins une communauté qui comprend ton environnement
Maximise le retour sur ton investissement en matériel informatique.

Si tu es un développeur :

Apprends une plateforme avec des caractéristiques techniques uniques
Contribue à des projets ayant un impact réel sur le monde de l’entreprise.
Développe une expertise dans un créneau à forte valeur ajoutée.

Si tu es un éditeur de logiciels indépendants :

Fais valider ton logiciel dans Power
Connecte-toi avec les entreprises clientes
Découvre les opportunités de marché dans l’écosystème de l’électricité

Si tu es en train d’évaluer l’infrastructure :

Découvre ce qui est vraiment possible en matière d’alimentation, au-delà de la charge traditionnelle.
Trouver une validation indépendante des solutions
Connecte-toi avec la communauté pour découvrir de vraies expériences

Sur quoi nous travaillons

AIX(aix.librepower.org)

✅ Gestionnaire de paquets moderne (dnf/yum pour AIX).
✅ fzf – fuzzy browser (binaire Go compilé pour AIX)
✅ nano – éditeur moderne
Outils 2FA – Google Authenticator avec QR Codes
🔄 Prochainement : ripgrep, yq, coreutils modernes.

Linux ppc64le

🔄 AWX – automatisation Ansible (portage complet en cours).
🔄 Outils de conteneurs – Podman, Buildah, Skopeo
🔄 Outils de développement – lazygit, k9s, CLIs modernes.

IBM i

📋 Phase de planification – évaluer les priorités avec l’aide de la communauté.

La vision

Imagine :

Tous les grands projets open source considèrent que la puissance au moment de la publication est…
Les éditeurs de logiciels indépendants considèrent Power comme une plate-forme stratégique, et non comme une réflexion après coup.
Les organisations déploient de nouvelles charges utiles sur Power en toute confiance
Une communauté connectée et en pleine croissance qui alimente l’écosystème.

C’est la Renaissance du pouvoir.

Il ne s’agit pas de nostalgie du passé. Il ne s’agit pas seulement de prolonger la durée de vie des déploiements existants.

Expansion active de ce que Power peut faire et de qui l’utilise.

Rejoindre

LibrePower grandit avec la communauté. Voici comment tu peux t’impliquer :

📬 S’abonner aux dernières nouvelles – nouveautés, guides, actualités de la communauté
💻 Explore nos dépôts – utiliser, contribuer, demander
✅ Certifie ton logiciel – valide ton logiciel dans Power
🤝 Deviens sponsor – soutiens l’initiative

Qui est à l’origine de ce projet ?

LibrePower est une initiative de SIXE, un partenaire commercial d’IBM et de Canonical avec plus de 20 ans d’expérience dans l’écosystème Power.

Nous avons vu ce que le pouvoir peut faire. Nous avons vu ce qui manque. Maintenant, nous construisons ce qui devrait exister.

LibrePower – Libérer le potentiel des systèmes électriques grâce aux logiciels libres 🌍. RAS inégalé. Coût total de possession supérieur. Empreinte au sol minimale. 🌍

Qu’est-ce qu’OpenUEM ? La révolution Open Source pour la gestion des appareils

3 décembre, 2025/dans Informations/par albamart

Dans le monde de l’administration des systèmes, nous sommes souvent confrontés à des outils surdimensionnés, coûteux et complexes. Cependant, lorsque nous examinons ce que les gens recherchent le plus en matière d’alternatives efficaces, le nom d’OpenUEM commence à résonner.

Chez SIXE, en tant que spécialistes de l’infrastructure et de l’open source, nous souhaitons répondre aux questions les plus fréquentes sur cette technologie et expliquer pourquoi nous avons opté pour elle.

Qu’est-ce que OpenUEM et comment fonctionne-t-il ?

OpenUEM(Unified Endpoint Management) est une solution open source conçue pour simplifier la vie des administrateurs informatiques. Contrairement aux suites traditionnelles qui facturent par agent ou par appareil, OpenUEM fournit une plateforme centralisée pour l’inventaire, le déploiement de logiciels et la gestion à distance des équipements sans coûts de licence abusifs.

Il fonctionne très bien en raison de sa simplicité et de son efficacité :

L’agent : Un petit programme est installé sur les ordinateurs finaux.
Le serveur : recueille les informations en temps réel et permet l’exécution des actions.
La console web : A partir d’un navigateur, l’administrateur peut visualiser l’ensemble du parc informatique, installer des applications ou se connecter à distance.

OpenUEM vs. les autres outils traditionnels

L’une des questions les plus fréquentes est de savoir comment cet outil se compare aux géants du marché. Nous avons dressé une liste des avantages et des inconvénients avec le point de vue de SIXE, afin que tu puisses tirer tes propres conclusions :).

En faveur :
- Coût : comme il s’agit d’un logiciel libre, tu élimines le coût des licences. Idéal pour les PME et les grands déploiements où le coût par agent monte en flèche.
- Confidentialité : il s’agit d’une solution auto-hébergée. C ‘est toi qui contrôles les données, et non un nuage tiers.
- Légèreté.
Contre :
- En tant qu’outil plus jeune, il n’a peut-être pas (encore) l’écosystème infini de plugins des solutions qui sont sur le marché depuis 20 ans. Cependant, il couvre largement 90 % des besoins habituels en matière de gestion.

Comment intégrer OpenUEM à ton infrastructure informatique existante ?

L’intégration est moins traumatisante qu’il n’y paraît. OpenUEM est conçu pour coexister avec ce que tu as déjà.

Déploiement de logiciels : s’intègre nativement avec des référentiels tels que Winget (Windows) et Flatpak (Linux), en utilisant les normes de l’industrie plutôt que des formats propriétaires fermés.
Assistance à distance : intègre des technologies éprouvées telles que VNC, RDP et RustDesk afin que tu puisses assister les employés à distance sans configuration VPN complexe dans de nombreux cas.

Si tu te demandes comment mettre en place OpenUEM pour surveiller les employés à distance, la réponse réside dans son architecture flexible. Le serveur peut être déployé via Docker en quelques minutes, ce qui permet aux agents de faire des rapports en toute sécurité depuis n’importe quel endroit disposant d’internet.

Qui offre une assistance et des solutions OpenUEM pour les entreprises ?

Bien que le logiciel soit gratuit, les entreprises ont besoin de garanties, de soutien et d’une mise en œuvre professionnelle. C’est là que nous intervenons. Chez SIXE, nous ne nous contentons pas de mettre en œuvre l’outil, nous offrons le soutien commercial nécessaire pour que tu puisses dormir tranquille. Nous savons que l’intégration d’une nouvelle plateforme peut soulever des questions sur les modèles de tarification ou de déploiement pour les petites et moyennes entreprises. C’est pourquoi notre approche ne consiste pas à te vendre une licence (il n’y en a même pas), mais à t’aider à déployer, maintenir et sécuriser ton infrastructure de gestion des appareils avec OpenUEM.

Voulez-vous parler?

Si tu cherches une plateforme de gestion de tes appareils mobiles et de bureau qui soit transparente, vérifiable et rentable, OpenUEM est peut-être une solution pour toi. Tu veux voir comment cela fonctionnerait dans ton environnement ? Jette un coup d’œil à notre solution professionnelle OpenUEM et découvre comment nous pouvons t’aider à gérer le contrôle de tes appareils. Pour ceux qui sont plus curieux ou qui veulent jouer avec l’outil par eux-mêmes, nous recommandons toujours de visiter le dépôt officiel d’OpenUEM.

Claroty xDome vs CTD : Cloud ou local ? Analyse de l’architecture de ton réseau OT

2 décembre, 2025/dans Informations/par albamart

Chez SIXE, nous nous occupons d’infrastructures, de réseaux et de sécurité depuis plus de 15 ans. Nous avons tout vu, des automates connectés à Internet “à la dure”, aux réseaux d’hôpitaux où une machine à café intelligente pourrait faire tomber un serveur critique. Alors quand il s’agit de cybersécurité industrielle (OT) et d’IoMT (Internet des objets médicaux), nous n’épousons pas n’importe qui. Mais, si tu es arrivé jusqu’ici en googlant, tu t’es probablement trompé de nom. Qu’est-ce que xDome, qu’est-ce que CTD, de quoi ai-je besoin ? Ne t’inquiète pas, aujourd’hui nous mettons notre salopette d’ingénieur pour te l’expliquer clairement.

La grande question : quelle est la différence entre Claroty CTD et xDome ?

C’est la question à un million de dollars. Les deux solutions visent la même chose : une visibilité et une protection totales de ton environnement industriel, mais leur architecture est radicalement différente.

1) Claroty xDome (Le futur Cloud-Native)

C’est l’évolution du SaaS. xDome est conçu pour les entreprises qui veulent profiter de l’agilité du cloud sans sacrifier la sécurité.

Comment cela fonctionne-t-il ? Il s’agit d’une solution basée sur le cloud qui effectue la découverte des actifs, la gestion des vulnérabilités et la détection des menaces.
Le meilleur : se déploie super rapidement et évolue comme un charme. Idéal si ton organisation a déjà une mentalité Cloud First et que tu veux gérer plusieurs sites à partir d’un seul tableau de bord sans déployer des tonnes de matériel.

2. Claroty CTD (Continuous Threat Detection – On-Premise)

C’est le poids lourd classique pour les environnements qui, par réglementation ou philosophie, ne peuvent (ou ne veulent) pas toucher au nuage.

Comment cela fonctionne-t-il ? Tout reste chez toi. Il est déployé sur ta propre infrastructure locale.
Le meilleur : la souveraineté totale des données. C’est l’option privilégiée pour les infrastructures critiques très sensibles (énergie, défense) où les données ne quittent en aucun cas le périmètre physique.

Le conseil de SIXE : Il n’y en a pas un “meilleur” qu’un autre, il y en a un qui correspond le mieux à ton architecture. Chez SIXE, nous procédons à une analyse exhaustive avant de recommander quoi que ce soit.

Et quel est le rapport avec Claroty Edge ?

Parfois, tu n’as pas besoin de déployer une infrastructure complète de surveillance continue dès le premier jour, ou tu as juste besoin d’un audit rapide pour savoir “qu’est-ce que j’ai bien pu connecter à mon usine”.

Claroty Edge ne nécessite aucune modification du réseau (pas de ports SPAN, pas de TAP d’entrée complexes). C’est un exécutable que tu lances, il scanne, te donne un “instantané” complet de tes actifs et de tes vulnérabilités en quelques minutes, et se ferme sans laisser de trace.

Avec qui Claroty est-elle en concurrence et quelles sont les meilleures entreprises de cybersécurité ?

Si tu évalues des logiciels, des noms comme Nozomi Networks, Dragos ou Armis te rappelleront sûrement quelque chose. Ce sont les grands “rivaux” du quadrant magique.

Quels sont les meilleurs ? Cela dépend de la personne à qui tu demandes, mais la réalité technique est la suivante :

Claroty : Leader incontesté dans l’exhaustivité des protocoles (parle le langage de tes machines, qu’elles soient Siemens, Rockwell, Schneider, etc.) et leur intégration aux environnements médicaux (Medigate).
Nozomi : Très forte en visibilité passive.
Dragos : Très axé sur le renseignement sur les menaces pures.

Pourquoi SIXE a-t-elle choisi Claroty ? Parce que nous comprenons ce qu’il y a sous le logiciel. La convergence IT/OT est complexe et Claroty propose la suite la plus complète (Secure Remote Access + CTD/xDome). Elle ne se contente pas de te dire “il y a un virus”, elle te permet de gérer l’accès à distance des tiers (fini les VPN non sécurisés des fournisseurs) et de segmenter correctement le réseau.

Si tu veux voir de plus près comment les normes de sécurité industrielle se comparent au niveau mondial, tu peux jeter un coup d’œil à la norme CEI 62443qui est la bible que nous suivons pour ces implémentations.

Mettre en œuvre Claroty, ce n’est pas seulement installer, c’est aussi comprendre

C’est là que nous intervenons. Un outil puissant configuré par des mains inexpérimentées n’est qu’un générateur de bruit et de faux positifs.

Chez SIXE, nous ne nous limitons pas à la mise en œuvre, nous réfléchissons :

Concevoir l’architecture : nous prévoyons où placer les capteurs (ports SPAN, TAP) de façon à ne pas générer de latence. L’usine ne peut PAS être arrêtée.
Affiner les politiques : un faux positif dans une usine peut signifier un ingénieur qui court à 3 heures du matin. Nous ajustons l’outil à la réalité de tes protocoles (Modbus, Profinet, CIP).
Forme ton équipe : nous formons ton SOC pour qu’il comprenne qu’une alerte OT n’est pas la même chose qu’une alerte IT.

👉 Découvre comment nous avons mis en œuvre Claroty chez SIXE.

Comment apprendre Ceph | La réalité que PERSONNE ne raconte

11 novembre, 2025/dans Informations/par albamart

” Je lance des commandes mais je ne comprends rien. ” Je lis la documentation mais quand quelque chose ne va pas, je ne sais même pas par où commencer. “Je travaille avec Ceph depuis un an et j’ai l’impression d’avoir à peine effleuré la surface. Si l’une de ces phrases résonne en toi, tu n’es pas seul. Et surtout, ce n’est pas de ta faute.

Après plus de 10 ans à travailler avec Ceph en production, à enseigner à des centaines d’administrateurs et à sauver des clusters “impossibles” à 3 heures du matin, nous sommes arrivés à une conclusion que personne ne te dira dans les certifications officielles : Ceph est brutalement difficile à maîtriser. Et ce n’est pas parce que tu es un mauvais administrateur, mais parce que la technologie est intrinsèquement complexe, en constante évolution, et que la documentation suppose des connaissances que personne ne t’a explicitement enseignées.

Nous n’allons pas te vendre un “apprendre Ceph en 30 jours”. Nous voulons te dire la vérité sur la façon dont on apprend vraiment, sur le temps que cela prend, sur les malentendus qui te retiendront, et sur le chemin le plus efficace pour passer du jet aveugle de commandes à une véritable expertise ;).

Pourquoi Ceph est si difficile à apprendre (et ce n’est pas ta faute)

La complexité n’est pas accidentelle : elle est inhérente

Ceph n’est pas “un système de stockage comme les autres”. Il s’agit d’une architecture massivement distribuée qui doit résoudre simultanément :

Cohérence de l’écriture avec réplication multi-nœuds et consensus distribué
Disponibilité continue en cas de défaillance du matériel (disques, nœuds, racks complets).
Rééquilibrage automatique de pétaoctets de données sans temps d’arrêt.
Performances prévisibles en cas de charges variables et multi-locataires.
Trois interfaces complètement différentes (bloc, objet, système de fichiers) sur la même base.
Intégration avec de multiples écosystèmes (OpenStack, Kubernetes, virtualisation traditionnelle).

Chacune de ces capacités distinctes constitue un système complexe. Ceph les intègre toutes. Et voici le problème : tu ne peux pas en comprendre un sans comprendre les autres.

Erreur de débutant #1 : Essayer d’apprendre Ceph comme s’il s’agissait d’un autre service sans état. ” Je configure, je lance des commandes et ça devrait fonctionner. Non. Ceph est un système distribué avec un état partagé, un consensus entre les nœuds et des comportements émergents qui n’apparaissent qu’en cas de charge ou d’échec. Si tu ne comprends pas l’architecture sous-jacente, chaque problème sera un mystère indéchiffrable.

La documentation suppose des connaissances que personne ne t’a apprises

Lis n’importe quelle page de la documentation officielle de Ceph et tu trouveras des termes tels que :

Groupes de placement (PG)
Algorithme CRUSH
BlueStore / FileStore
Récurage et nettoyage en profondeur
Peering et récupération
OSDs up/down vs in/out

La documentation explique ce qu’ils sont, mais pas pourquoi ils existent, quel problème ils résolvent ou comment ils interagissent les uns avec les autres. C’est comme si tu essayais d’apprendre la programmation en commençant par la référence du langage au lieu des concepts fondamentaux.

Exemple concret : un élève nous a écrit : ” Cela fait trois mois que j’essaie de comprendre les PG. J’ai lu qu'” ils sont une abstraction logique “, mais… pourquoi existent-ils ? Pourquoi existent-ils, pourquoi ne pas mapper les objets directement sur les OSD ?”

Cette question témoigne d’une profonde compréhension. La réponse (évolutivité de la carte CRUSH, rééquilibrage de la granularité, surcharge des métadonnées) exige une compréhension préalable des systèmes distribués, de la théorie du hachage cohérent et des compromis en matière d’architecture. Personne ne t’apprend cela avant de publier ceph osd pool create.

L’évolution constante invalide les connaissances

Ceph change RAPIDEMENT. Et je ne parle pas de fonctionnalités optionnelles, mais de changements architecturaux fondamentaux :

FileStore → BlueStore (2017) : change complètement la façon dont tu écris sur le disque.
ceph-deploy → ceph-ansible → cephadm (2020) : trois outils de déploiement différents en 5 ans.
Lumineux → Nautilus → Octopus → Pacific → Quincy → Reef → Squid : 7 versions majeures en 7 ans, chacune avec des changements de rupture.
Crimson/Seastore (2026+) : Réécriture complète de l’OSD qui invalidera une grande partie des connaissances en matière de réglage.

Ce que tu as appris il y a 2 ans sur le réglage des FileStore n’est absolument pas pertinent aujourd’hui. Les PG par pool que tu calculais manuellement sont maintenant gérés par autoscaler. Les meilleures pratiques en matière de réseau ont changé avec msgr2.

Erreur du débutant (et de l’expert) n°2 : Apprendre des configurations par cœur sans comprendre pourquoi elles existent. J’ai vu un administrateur configurer manuellement le comptage des PG avec des formules lumineuses […] sur un cluster Squid avec autoscaler activé. L’autoscaler l’ignorait, il ne comprenait pas pourquoi. Le contexte historique compte pour savoir quelles connaissances sont obsolètes.

Combien de temps faut-il vraiment pour maîtriser Ceph ?

Parlons avec des chiffres réels basés sur notre expérience de la formation des administrateurs :

40h

Pour un déploiement fonctionnel de base

6 mois

Pour dépanner sans paniquer

2-3 ans

Pour une véritable expertise en matière de production

Progression réaliste de l’apprentissage

Mois 1-2 : “Je ne comprends rien mais ça marche”.

Tu suis des tutoriels. Tu lances les commandes ceph osd pool create, ceph osd tree. Le cluster fonctionne… jusqu’à ce qu’il ne fonctionne plus. Un OSD est marqué en bas et tu paniques parce que tu ne sais pas comment faire le diagnostic.

Symptôme typique : tu copies des commandes de Stack Overflow sans comprendre ce qu’elles font. “Je l’ai réparé” mais tu ne sais pas comment ni pourquoi.

Mois 3-6 : “Je comprends les commandes mais pas l’architecture”.

Tu as mémorisé les principales commandes. Tu sais comment créer des pools, configurer RBD, mettre en place CephFS. Mais lorsque PG 3.1f is stuck in peering se présente, tu n’as aucune idée de ce que signifie “peering” ou de la façon de résoudre le problème.

Symptôme typique : tu résous les problèmes par essais et erreurs en redémarrant les services jusqu’à ce que ça marche. Il n’y a pas de méthode, il y a de la chance.

Mois 6-12 : “Je comprends l’architecture mais pas le réglage”.

Tu comprends enfin MON/OSD/MGR, l’algorithme CRUSH, ce que sont les PG. Tu peux expliquer l’architecture sur un tableau blanc. Mais ton cluster a de mauvaises performances et tu ne sais pas si c’est le CPU, le réseau, les disques ou la configuration.

Symptôme typique : tu lis des articles sur le réglage de BlueStore, tu changes les paramètres au hasard, tu ne mesures pas l’avant et l’après. Les performances restent les mêmes (ou sont pires).

Année 1-2 : ” Je sais dépanner mais je n’ai pas de méthode “.

Tu as sauvé quelques clusters. Tu sais comment utiliser ceph health detail, interpréter les états de PG, récupérer un OSD en panne. Mais chaque problème est une nouvelle aventure de 4 heures d’essais.

Symptôme typique : tu peux régler les problèmes… éventuellement. Mais tu ne peux pas les prédire ou expliquer à ton patron combien de temps la solution prendra.

Année 2-3 : “J’ai de la méthode et je comprends les compromis”.

Tu diagnostiques systématiquement : collecter les symptômes, formuler des hypothèses, valider avec des outils spécifiques. Tu comprends les compromis : quand utiliser la réplication par rapport à l’erasure coding, comment dimensionner le matériel, quand NVMe est intéressant.

Symptôme typique : ta réponse aux problèmes est “laisse-moi vérifier X, Y et Z” avec un plan clair. Tu peux estimer des temps de récupération réalistes.

Année 3+ : une véritable expertise

Tu conçois des architectures à partir de zéro en tenant compte de la charge de travail, du budget et des accords de niveau de service. Tu fais de la reprise après sinistre sans manuel. Optimise BlueStore pour des charges spécifiques. Comprends suffisamment bien le code source pour déboguer les comportements rares.

Symptôme typique : d’autres administrateurs t’appellent quand un cluster est “impossible”. Il te faut 20 minutes pour identifier le problème qu’ils ont attaqué pendant 3 jours.

La bonne nouvelle : tu peux considérablement accélérer cette progression grâce à une formation structurée. Un bon cours de 3 jours peut condenser 6 mois d’essais et d’erreurs. Non pas parce qu’elle “enseigne plus vite”, mais parce qu’elle évite les impasses et les malentendus qui consomment des semaines.

Les malentendus typiques qui t’empêchent d’apprendre

Malentendu n° 1 : “Plus de matériel = plus de performances”.

J’ai vu des clusters avec 40 OSDs qui fonctionnaient moins bien que des clusters avec 12. Pourquoi ? Parce qu’ils l’ont fait :

Réseau public et cluster sur la même interface (saturation garantie).
Gouverneur de fréquence de l’unité centrale sur “powersave” (dégradation de 5x dans la réplication).
Le nombre de PG est totalement déséquilibré entre les pools
BlueStore : cache très bas pour les charges RGW

La réalité : les performances de Ceph dépendent du maillon le plus faible. Un goulot d’étranglement à un seul thread dans un MON peut faire tomber tout le cluster. Plus de matériel mal configuré ne fait que multiplier le chaos.

Malentendu n°2 : “Le codage par effacement permet toujours d’économiser de l’espace”.

Un jour, un élève a déclaré fièrement : “J’ai fait passer tout mon cluster à l’erasure coding 8+3 pour économiser de l’espace”. Nous lui avons demandé : “Quelle est ta charge de travail ?” – “RBD avec des snapshots fréquents”. Oups.

Le codage par effacement avec des charges de travail qui effectuent de petits écrasements (RBD, CephFS) est TERRIBLE pour les performances. Et les “économies” d’espace sont absorbées par les bandes partielles et la surcharge des métadonnées.

La réalité : EC est excellent pour les données froides du stockage d’objets (archives RGW). Il est nul pour les périphériques de bloc avec des IOPS élevés. Connaître la charge de travail avant de décider de l’architecture est fondamental.

Malentendu n° 3 : ” Si ceph health indique HEALTH_OK, tout va bien “.

Non. HEALTH_OK signifie que Ceph n’a pas détecté de problèmes connus de lui. Il ne détecte pas :

Dégradation progressive du disque (avertissements SMART)
Perte intermittente de paquets réseau
Fuites de mémoire dans les démons
Un nettoyage qui n’a pas été effectué depuis 2 semaines.
Les PGs dont le placement n’est pas optimal causent des points chauds.

La réalité : tu as besoin d’un monitoring externe (Prometheus + Grafana minimum) et de revoir les métriques que Ceph n’expose pas sur ceph health. HEALTH_OK est nécessaire mais pas suffisant.

Malentendu n°4 : ” j’ai lu la doc officielle et ça suffit “.

La documentation officielle est un matériel de référence, pas un matériel d’enseignement. On part du principe que tu as déjà compris :

Systèmes distribués (Paxos, quorum, consensus)
Principes fondamentaux du stockage (IOPS vs débit, percentiles de latence)
Réseau (MTU, trames jumbo, tuning TCP)
Linux interne (cgroups, systemd, paramètres du noyau)

Si tu n’apportes pas cette base, le doc t’embrouillera plus qu’il ne t’aidera.

La réalité : Tu as besoin de ressources supplémentaires : des articles académiques sur les systèmes distribués, des blogs d’expériences réelles, des formations qui relient les points que la doc omet.

Les erreurs typiques (que nous commettons tous)

Les erreurs des débutants

Ne pas configurer le réseau du cluster : Le réseau public est saturé par la réplication interne. Les performances chutent. Solution : --cluster-network dès le premier jour.

Utiliser les valeurs par défaut pour le nombre de PG : Dans les versions antérieures au Pacifique, tu créais des pools avec 8 PG… pour un pool qui atteignait 50 To. Impossible de rééquilibrer par la suite. Solution : Autoscaler ou calculer dès le départ.

Ne pas comprendre la différence OSD up/down vs in/out : Tu sors un OSD pour maintenance avec ceph osd out et tu commences immédiatement un rééquilibrage massif qui dure 8 heures. Tu voulais . Oups.

Erreurs intermédiaires

Codage par effacement surdimensionné : Configure 17+3 ECs dans une grappe de 25 nœuds. Un nœud tombe en panne et la grappe passe en mode lecture seule parce qu’il n’y a pas assez d’OSD sur lesquels écrire. Le compromis n’est pas compris.

Ignore le planificateur d’E/S : utilise le planificateur de délai avec NVMe (absurde). Ou aucun planificateur avec les disques durs (désastreux). Le bon planificateur compte pour 20 à 30 % de la performance.

Ne planifie pas la reprise après sinistre: “Nous avons une réplication 3x, nous sommes en sécurité”. Puis un rack entier tombe en panne et ils perdent le quorum des MON. Ils n’ont jamais pratiqué la récupération. Ils paniquent.

Les erreurs des experts (oui, nous en faisons aussi)

Over-tuning : modification simultanée de 15 paramètres de BlueStore “pour optimiser”. Quelque chose se casse. Lequel des 15 changements était-ce ? Personne ne le sait. Principe : changer UNE chose, mesurer, itérer.

S’appuyer trop sur de vieilles connaissances : appliquer les techniques de réglage de FileStore à BlueStore. Cela ne fonctionne pas parce que l’architecture interne est totalement différente. Le contexte historique est important.

Ne pas documenter les décisions architecturales : il y a 2 ans, tu as décidé d’utiliser EC 8+2 dans un certain bassin pour X raison. Personne ne l’a documenté. Maintenant, un nouvel administrateur veut “simplifier” la réplication. Un désastre que l’on peut éviter grâce à la documentation.

La voie la plus efficace pour apprendre Ceph

Phase 1 : Principes fondamentaux de l’architecture (40-60 heures)

Avant de toucher à une commande, comprends bien :

Quel problème Ceph résout-il (par rapport à NAS, par rapport à SAN, par rapport au stockage en nuage) ?
Architecture RADOS : comment fonctionnent MON, OSD, MGR
Algorithme CRUSH : pourquoi existe-t-il, quel problème résout-il ?
Groupes de placement : l’abstraction qui rend le système évolutif.
Différence entre les pools, les PG, les objets et leur correspondance avec les OSD.

Comment l’étudier : pas avec des commandes, mais avec des diagrammes et des concepts. Un bon cours sur les fondamentaux est 100x plus efficace que les tutoriels “déployer en 10 minutes”.

Cours recommandé : administration Ceph

Niveau : fondamental
3 jours intensifs

Programme spécialement conçu pour construire une base solide à partir de zéro. Il ne suppose aucune connaissance préalable du stockage distribué.

Voir le programme complet →

Phase 2 : configuration avancée et dépannage (60-80 heures)

Avec des bases solides, tu peux maintenant aller plus loin :

BlueStore : comment les données sont écrites en réalité
Règles CRUSH personnalisées pour les topologies complexes
Optimisation des performances : identifier les goulots d’étranglement
RGW multi-sites pour la géo-réplication
Mise en miroir du RBD pour la reprise après sinistre
Dépannage systématique avec méthode

L’objectif : passer de ” je sais configurer ” à ” je comprends pourquoi je configure ainsi et quels sont les compromis que je fais “.

Cours recommandé : Ceph avancé

Niveau : avancé
3 jours intensifs

Pour les administrateurs qui ont déjà un cluster en fonctionnement mais qui veulent maîtriser des configurations complexes et se préparer à l’EX260.

Voir le programme complet →

Phase 3 : opérations productives critiques (80-100 heures)

Le saut final : de “je sais comment configurer et dépanner” à “je peux sauver des clusters en production à 3 heures du matin”.

Dépannage judiciaire : diagnostiquer les pannes complexes à facteurs multiples.
Récupération après sinistre REAL : récupération des métadonnées corrompues, des journaux perdus.
Ingénierie des performances : optimisation du noyau et du matériel
Architectures pour des charges spécifiques : AI/ML, streaming vidéo, conformité.
Renforcement de la sécurité et conformité (GDPR, HIPAA)
Passage à l’échelle des pétaoctets : les problèmes qui ne se posent qu’à grande échelle.

L’objectif : une véritable expertise vérifiable. Éliminer ce “respect” (cette peur) des scénarios critiques.

Cours recommandé : ingénierie de production Ceph

Niveau : expert
3 jours intensifs

Le seul cours sur le marché axé à 100 % sur les opérations de production critiques. Pas de simulations – de vrais problèmes.

Voir le programme complet →

Pratique continue : l’ingrédient non négociable

Voici la vérité qui dérange : tu peux suivre les 3 cours et n’avoir aucune expertise si tu ne pratiques pas. Les connaissances théoriques sont oubliées si tu ne les appliques pas.

Recommandation de SIXE après chaque cours :

Mets en place une grappe d’entraînement (il peut s’agir de VM locales ou d’un nuage bon marché).
Casse intentionnellement les choses: tue les OSD, remplit les disques, sature le réseau.
Pratique la récupération sans manuel: peux-tu récupérer sans Google ?
Mesure tout: repères avant/après chaque changement
Documente ton apprentissage: blog, notes, etc.

Conseil de pro : les meilleurs administrateurs Ceph que je connaisse gardent en permanence un “cluster de laboratoire” où ils testent des choses folles. Certains ont même des scripts qui injectent des bogues aléatoires pour s’entraîner au dépannage. Cela peut sembler extrême, mais ça marche.

“La différence entre un cadre moyen et un expert n’est pas que l’expert ne fait pas d’erreurs. C’est que l’expert reconnaît l’erreur en 5 minutes au lieu de 5 heures, parce qu’il l’a déjà faite et qu’il a documenté la solution”.

Conclusion : la route est longue mais peut être accélérée.

Si tu es arrivé jusqu’ici, tu es déjà dans le top 10 % des administrateurs Ceph par pure intention d’apprendre correctement. La plupart abandonnent lorsqu’ils se rendent compte de la complexité réelle.

Les vérités inconfortables que tu dois accepter :

La maîtrise de Ceph nécessite 2 à 3 ans d’expérience pratique continue. Il n’y a pas de raccourcis magiques.
Tu vas faire des erreurs. Beaucoup d’entre elles. Certaines dans la production. Cela fait partie du processus.
Les connaissances se déprécient rapidement. Ce que tu apprends aujourd’hui sera partiellement obsolète dans 18 mois.
La documentation officielle ne sera jamais adaptée aux tutoriels. Tu as besoin de ressources complémentaires.

Mais il y a aussi de bonnes nouvelles :

La demande d’experts Ceph dépasse massivement l’offre. C’est le bon moment pour se spécialiser.
Tu peux accélérer la courbe d’apprentissage de 6 à 12 mois avec une formation structurée qui évite les impasses.
Une fois que tu as “cliqué” sur l’architecture fondamentale, le reste se construit logiquement sur cette base.
La communauté est généralement ouverte à l’aide. Tu n’es pas seul(e).

Notre dernier conseil après plus de 10 ans avec Ceph : commence par des principes fondamentaux solides, entraîne-toi constamment et n’aie pas peur de casser des choses dans des environnements de test. Les meilleurs administrateurs que je connaisse sont ceux qui ont cassé le plus de clusters (en laboratoire) et qui ont méticuleusement documenté chaque récupération.

Et si tu veux accélérer considérablement ta courbe d’apprentissage, envisage une formation structurée qui condense des années d’expérience pratique en semaines intensives. Non pas parce que c’est plus facile, mais parce que cela t’épargne les 6 mois que nous perdons tous à nous attaquer à des problèmes que quelqu’un d’autre a déjà résolus.

Par où commencer aujourd’hui ?

Si tu es totalement débutant : cours d’administration Ceph.
Si tu gères déjà un cluster : cours Ceph avancé
Si tu as plus de 2 ans et que tu veux une vraie expertise : ingénierie de production Ceph.

Ou alors, il suffit de mettre en place un cluster de 3 VM, de casser des choses et d’apprendre à dépanner. Le chemin est le tien, mais il ne doit pas être solitaire.

Stockage open source pour l’IA et le HPC : quand Ceph cesse d’être une alternative et devient la seule voie viable.

20 octobre, 2025/dans Informations/par albamart

Lorsque le CERN doit stocker et traiter les données du Grand collisionneur de hadrons (LHC, l’accélérateur de particules le plus grand et le plus puissant du monde), l’échelle compte. À ce niveau, la technologie et l’économie convergent vers une conclusion claire : les technologies open source telles que Ceph, EOS et Lustre ne sont pas une “alternative” aux solutions d’entreprise traditionnelles ; dans de nombreux scénarios, elles constituent la seule voie viable.

Avec plus de 1 exaoctet de stockage sur disque, 7 milliards de fichiers y 45 pétaoctets par semaine traités lors des campagnes de collecte de données, le plus grand laboratoire de physique des particules du monde évolue dans un domaine où les modèles classiques de licence de capacité n’ont plus de sens économique.

Cette réalité, documentée dans le document présenté à CHEP 2025, “Ceph at CERN in the multi-datacentre era”, reflète ce que de plus en plus d’universités et de centres de recherche réalisent : il existe des cas d’utilisation où l’open source ne rivalise pas avec les solutions d’entreprise.Ceph reflète ce que de plus en plus d’universités et de centres de recherche réalisent : il existe des cas d’utilisation où l’open source n’est pas en concurrence avec les solutions d’entreprise, il définit sa propre catégorieIl définit sa propre catégorie, pour laquelle les architectures traditionnelles n’ont tout simplement pas été conçues.

CERN : des chiffres qui changent les règles

Les chiffres du CERN ne sont pas seulement impressionnants, ils expliquent pourquoi certaines technologies sont choisies :

>1 exaoctet de stockage sur disque, réparti sur ~2 000 serveurs avec 60 000 disques.
>4 exaoctets de transferts annuels.
Jusqu’à 45 PB/semaine et débit soutenu >10 Go/s débit soutenu pendant les périodes de collecte de données.

L’architecture est hétérogène par nécessité:

EOS pour les fichiers de physique (plus de 1 EB).
CTA (CERN Tape Archive) pour l’archivage à long terme.
Ceph (plus de 60 PB) pour les blocs, les objets S3 et CephFS, colonne vertébrale de OpenStack.

Ce qui compte, ce n’est pas seulement le volume, mais aussi la trajectoire. En une décennie, ils sont passés de quelques pétaoctets à des exaoctets. sans saut architectural perturbateurajout de nœuds marchandise horizontalement. Cette élasticité n’existe pas dans le cabines propriétaires avec des licences de capacité.

L’économie de l’exaoctet : là où les modèles de capacité échouent.

Les modèles de licence actuels sur le marché des entreprises sont raisonnables pour des environnements typiques (dizaines ou centaines de téraoctets, croissance prévisible, CapEx et OpEx équilibrés). Ils fournissent une intégration, une assistance 24×7, des certifications et un écosystème de partenaires. Mais à à l’échelle du pétaoctet ou de l’exaoctet avec une croissance rapide, l’équation change.

Au SIXE nous sommes partenaire principal d’IBMet nous avons évolué vers des licences basées sur la capacité.
- IBM Spectrum Virtualize utilise Unités de capacité de stockage (SCU)~1 TB par SCU. Le coût annuel par SCU peut varier de 445 y 2.000 €en fonction du volume, du profil des clients et des conditions environnementales.
- IBM Storage Defender utilise les unités de ressources (RU). Par exemple , IBM Storage Protect consomme 17 RUs/TB pour les 100 premiers To et 15 UR/TB pour les 250 To suivants, ce qui permet de combiner les capacités de résilience sous une licence unifiée.
Des modèles similaires existent chez NetApp (licence de capacité à terme), Pure Storage, Dell Technologies et autres : payer pour une capacité gérée ou provisionnée.

Tout cela fonctionne dans les environnements d’entreprise conventionnels. Cependant, gérer 60 PB dans le cadre d’une licence par capacité, même avec des remises importantes sur le volume, peut se traduire par des millions d’euros par an rien qu’en logiciels. des millions d’euros par an rien qu’en logicielssans compter le matériel, l’assistance ou les services. À ce moment-là, la question n’est plus de savoir si l’open source est “viable”, mais s’il est “viable”. Existe-t-il une alternative réaliste pour ces échelles.

Capacités techniques : une source ouverte mature

L’avantage économique ne s’appliquerait pas si la technologie était inférieure. Ce n’est pas le cas. Pour certaines charges d’IA et de HPC, les capacités sont équivalent ou supérieur:

Ceph offre une virtualisation unifiée du stockage avec provisionnement fin, compression à BlueStore, instantanés y Clones COW sans pénalité significative, réplication multi-sites (RGW et RBD), et étagement entre les médias, et si tu veux que ton équipe comprenne comment tirer le meilleur parti de Ceph, nous avons…
- Cours d’introduction à Ceph
- Cours Ceph avancé
Documents du CERN stratégies multi-centres de données stratégies pour la continuité des activités et la reprise après sinistre en utilisant grappes extensibles y la réplication multisiteavec RPO/RTO comparables aux solutions d’entreprise.

IBM reconnaît cette maturité avec IBM Storage Ceph (un dérivé de Red Hat Ceph Storage), qui combine la technologie open source technologie open source avec support, certifications et accords de niveau de service au niveau de l’entreprise. Au SIXEen tant que IBM Premier Partnernous implémentons IBM Storage Ceph lorsqu’un soutien commercial est nécessaire et également Ceph en amont lorsque la flexibilité et l’indépendance sont une priorité.

Différence clé dans l’architecture:

IBM Spectrum Virtualize est une couche d’entreprise qui qui gère le stockage hétérogène de blocIl offre des fonctions de mobilité, de réplication et d’automatisation avancées.
Ceph est un système distribué natif qui sert blocs, objets et fichiers à partir de la même infrastructure horizontaleéliminer les silos. Au pipelines pipelines – objets pour les ensembles de données, blocs pour les métadonnées, partage de fichiers pour la collaboration – cette unification apporte des avantages opérationnels clairs. des avantages opérationnels évidents.

IA et HPC à grande échelle : là où le distribué brille.

Les charges d’entraînement formation de formation des modèles fondamentaux lisent des pétaoctets en parallèleavec des bandes passantes globales de 100 Go/s ou plus. Les l’inférence nécessite des temps de latence inférieurs à 10 ms avec des milliers de demandes simultanées.

Architectures traditionnelles avec contrôleurs SAN contrôleurs souffrent de goulots d’étranglement lorsque des centaines de GPUS (A100, H100…) accèdent aux données en même temps. On estime qu’environ 33 % des GPU dans les environnements d’IA des entreprises fonctionnent à moins de 15 % d’utilisation en raison d’une saturation du stockagesaturation, coût actifs sous-utilisés.

Architectures distribuées architectures –Ceph, Lustre, BeeGFS– sont nés pour ces modèles :

Éclat stimule 7 des 10 superordinateurs dans le Top500supercalculateurs, avec >1 TB/s dans les grandes installations. Frontier (ORNL) utilise ~700 PB dans Lustre et écrit >35 TB/s soutenu.
BeeGFS fait évoluer le stockage et les métadonnées de manière indépendante indépendantdépassant 50 Go/s soutenu avec des dizaines de milliers de clients en production.
MinIOoptimisé pour les objets dans l’IA, a démontré >2,2 TiB/s en lecture lors de la formation, ce qui est difficile à égaler pour les architectures centralisées.

Intégration avec GPU a également évolué : GPUDirect Storage permet aux GPU de lire les données des NVMe-oF sans passer par l’unité centrale, ce qui réduit la latence et libère des cycles. Les systèmes open source modernes prennent en charge ces protocoles. nativementdans des solutions propriétaires, ils s’appuient souvent sur des firmware y certifications qui prennent des trimestres à arriver.

SIXE : source ouverte durable, avec ou sans soutien commercial

Migrer vers un système de stockage open source à grande échelle n’est pas trivial. Les systèmes distribués nécessitent expérience spécifique.

Sur SIXE nous sommes plus de 20 ans avec Linux y source ouverte. Comme Partenaire principal d’IBMnous offrons le meilleur des deux mondes:

IBM Storage Ceph e IBM Storage Scale (anciennement Spectrum Scale/GPFS) pour ceux qui ont besoin de des accords de niveau de service (SLA) garantis, certifications y une assistance mondiale 24×7.
Ceph en amont (et technologies connexes) pour les organisations qui préfèrent un maximum de flexibilité et de contrôle.

Il ne s’agit pas d’une position contradictoire, mais d’une stratégiqueDes profils différents, des besoins différents. A banque multinationale valeurs les certifications et le soutien aux entreprises. A centre de recherche doté d’un solide équipement technique, peut opérer en amont directement.

Nos Nos formations intensives sur Ceph Les ateliers sont ateliers de trois joursateliers : des clusters réels sont déployés et les décisions de conception sont expliquées. décisions de conception. Le transfert de connaissances réduit la dépendance à l’égard des consultants et des habiliter à l’équipe interne. Si ton équipe a encore peu d’expérience avec Ceph, clique ici pour voir notre cours pour débutants, si par contre tu veux tirer le maximum de Ceph, nous te laissons ici le cours Ceph avancé, où ton équipe pourra intégrer deux facteurs technologiques cruciaux à l’heure actuelle : Stockage + IA.

Notre philosophieNous ne vendons pas de technologie, nous transférons des capacités. Nous mettons en œuvre IBM Storage Ceph avec une assistance complète, Ceph en amont avec notre système de sauvegarde spécialisé ou Ceph en aval. les approches hybridesau cas par cas.

L’opportunité de la science et du big data

Plusieurs facteurs s’alignent :

Les données augmentent de façon exponentielle: a NovaSeq X Plus peut générer 16 TO par cycle ; le télescope télescope SKA produira exaoctets par an; les modèles d’IA exigent ensembles de données données.
Les budgets ne se développent pas au même rythme. Lla modèles de licences de capacité rendent irréalisables de faire évoluer les systèmes propriétaires au rythme requis.

Les solutions open source, qu’elles soient en amont o soutenues par le commerce (ex, IBM Storage Ceph), élimine cette dichotomie : la croissance est planifiée en fonction du coût du matériel. le coût du matériel y la capacité opérationnelleavec logiciel dont les coûts ne sont pas linéaires par téraoctet.

Des centres tels que Fermilab, DESYle CERN ou le Barcelona Supercomputing Center ont démontré que cette approche est techniquement possible y supérieure sur le plan opérationnel pour leurs cas. Dans son récent document, le CERN détaille multi-centres de données pour DR avec Ceph (stretch et multisite), atteignant une disponibilité comparable aux solutions d’entreprise, avec flexibilité et un contrôle total.

Un écosystème qui arrive à maturité : planifie dès maintenant

L’écosystème de stockage open source pour HPC e AI évolue rapidement :

Fondation Ceph (Fondation Linux) coordonne les contributions du CERN, Bloomberg, DigitalOcean, OVH, IBMentre autres, alignés sur les besoins réels de production.
IBM maintient IBM Storage Ceph en tant que produit pris en charge et contribue activement en amont.

C’est la confluence idéale de l’innovation open source y le soutien aux entreprises. Pour les organisations ayant un horizon de décenniesdécennies, la question n’est plus de savoir si adopter l’open source, mais quand et comment le faire de façon manière structurée.

La technologie est matureLa technologie est mature, des exemples de réussite sont documentées et le soutien existe à la fois en mode communautaire et commercial. Ce qui manque souvent, c’est la l’expertise pour établir la feuille de route : modèle (en amont, commercial ou hybride), dimensionnement, formation y fonctionnement durable.

SIXE : ton partenaire vers un stockage qui grandit avec toi

Sur SIXE nous travaillons à cette intersection. Comme Partenaire principal d’IBMnous avons accès à une assistance de classe mondiale, feuilles de route y certifications. En même temps, nous maintenons une expertise approfondie en amont et d’autres technologies de l’écosystème, parce qu’il n’y a pas de il n’y a pas de solution universelle n’est pas une solution unique.

Lorsqu’un centre nous contacte, nous ne commençons pas par le cataloguemais par les questions clés:

Quels sont tes modèles d’accès?
Ce que croissance prévois-tu ?
Quelles sont les capacités ton équipe dispose-t-elle de capacités ?
Quels sont les risques peux-tu prendre ?
Ce que budget gères-tu (CapEx/OpEx) ?

Les réponses orientent la recommandation : IBM Storage Ceph avec le support de l’entreprise, en amont avec notre support, un hybride, ou même évaluer si une solution traditionnelle a encore du sens dans ton cas. Nous concevons des solutions qui fonctionnent pendant 5 et 10 ans, l’important pour nous est de créer des solutions durables et pérennes ;).

Nous nous engageons à des technologies durablesdes technologies qui ne sont pas soumises aux fluctuations commerciales, qui donnent contrôle de l’infrastructure et de l’échelle techniquement et économiquement.

Le cas du CERN Le cas du CERN n’est pas une curiosité académique : il montre où va le stockage des charges utiles à forte intensité de données. charges de données intensives. La question n’est pas de savoir si ton organisation y parviendra, mais si elle y parviendra tout court. comment arriveront : préparé o en route. La fenêtre d’opportunité de planifier calmement est ouverte. ouverte. Lla succès existent. Les technologie est prêt. Les écosystème également. Il reste à prendre le décision stratégique d’investir dans une infrastructure qui accompagnera ton organisation pendant des décennies. décennies de croissance des données.

Voulez-vous parler?

Ton organisation génère-t-elle des volumes massifs de données pour l’ L’IA o recherche? A SIXE Nous aidons les instituts de recherche, les universités et les organisations innovantes à concevoir, mettre en oeuvre et exploiter stockage modulable avec Ceph, Échelle de stockage et d’autres technologies de pointe, à la fois en amont comme pour Soutien commercial d’IBMselon tes besoins. Contacte-nous à pour un consultation stratégique sans obligation.

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans

Les trois modèles FlashSystem de 2026 : FlashSystem 5600, 7600 et 9600

FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)

FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité

Détection de ransomware en 60 secondes : les données et les astérisques

L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement

Pure Storage, Dell, NetApp et les autres — et maintenant ?

Là où IBM prend clairement l’avantage :

Là où la concurrence résiste :

À qui s’adresse-t-il ?

Conclusions

📋 Table des Matières

Le Drame de l’Année : MinIO Passe en « Mode Maintenance » (Lire : Mode Abandon)

Pendant Ce Temps, Ceph Continue de Nager Paisiblement

Les Chiffres Qui Comptent

L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes

IBM Fusion : Deux Saveurs pour Différents Besoins

Red Hat Ceph Storage : Le Standard Entreprise

SUSE : Une Leçon sur le Verrouillage Fournisseur

Pure Storage et NetApp : L’Approche Appliance

La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?

Démystifier les Affirmations Marketing

Une Décision Intelligente : Décider en S’informant

Où Trouver Ces Connaissances

Conclusions pour 2026

De “AIX est lent” à “AIX égale Linux” (avec les bons outils et le bon code)

Chapitre 1 : Le sentiment d’affaissement

Chapitre 2 : Les premiers 65x – L’importance de la configuration

Le cache qui a tout oublié

Le problème de la taille des pages

Le tableau d’affichage après la phase 1

Chapitre 3 : Le mystère du décrochage entre le CPU et la mémoire

La cause première : Invalidation du cache de l’hyperviseur

Chapitre 4 : L’odyssée du compilateur

Tout ce que j’ai essayé avec GCC (et pourquoi ça a échoué)

IBM Open XL : Le rebondissement de l’intrigue

Pourquoi une telle différence ?

Chapitre 5 : Les impasses du LTO et du PGO

LTO : L’ironie

PGO : Les profils qui n’ont jamais existé

Chapitre 6 : La révélation LPAR

La matrice de test

Le facteur WoF

Le désastre du mode donateur de PowerVM

Le 21-Core Sweet Spot

Chapitre 7 : Le tableau d’affichage final (rebondissement)

Le musée complet de l’échec

Ce que j’ai appris

1. Les défauts de paiement sont plus importants que tu ne le penses

2. Le mythe de la lenteur d’AIX a toujours été un problème de chaîne d’outils

3. La virtualisation comporte des compromis cachés

4. Tous les ports d’optimisation n’ont pas la même valeur

5. Parfois, il n’y a pas d’écart du tout

Recommandations

Pour les utilisateurs d’AIX MariaDB

Pour MariaDB en amont

Prochaines étapes

TL;DR

MariaDB sur AIX, la plateforme qui alimente les systèmes les plus critiques au monde

Chapitre 1 : “C’est si dur que ça ?”

Chapitre 2: Défis de CMake pour MariaDB sur AIX

Le bogue de la fonction fantôme

poll.h : Cache-cache

Les plugins maudits

Chapitre 3: Implémentation du Thread Pool pour MariaDB sur AIX via Pollset

Le problème ONESHOT

Onze versions de la sagesse croissante

Porter MariaDB sur AIX = Bugs (Le bug -O3)

Chapitre 4 : La chose -blibpath (en fait une caractéristique)

Chapitre 5 : Stabilité – Les chiffres qui comptent

Impact du pool de fils

Ce que j’ai appris (jusqu’à présent)

Qu’est-ce qu’on fait maintenant ? La question de la performance

La deuxième partie arrive bientôt.

TL;DR

La théorie : tous les cas d’utilisation du LLM ne sont pas liés au GPU.

⚙️ CPU, MMA et accélérateurs basse consommation

🧩 Pourquoi AIX ?

🔍 Ce qui est (et ce qui n’est pas) Llama-AIX

Nous voulons libérer tout le potentiel d’IBM Power.

Chapitre 4 : La chose `-blibpath` (en fait une caractéristique)