🌐 Storage Systems — Chapitre 27 : Acteurs open source et souverains

Chapitre très dense consacré aux solutions open source, software-defined storage et architectures souveraines : Ceph, MinIO, OpenEBS, Longhorn, SeaweedFS, JuiceFS, Scality, OpenIO legacy, Garage, Rook, GlusterFS, OpenZFS, LINBIT/DRBD, Mayastor, OpenStack Swift, Lustre, BeeGFS, MooseFS, NAS souverain et méthodologie de choix. L’objectif est de comparer liberté, coût, souveraineté, réversibilité et responsabilités d’exploitation.

Ceph / RookMinIO / Scality / GarageOpenEBS / Longhorn / LINSTOROpenZFS / NAS souverainLustre / BeeGFSDay-2 operations

27.1

Ceph

Stockage distribué open source unifié : block, file et object, très utilisé dans OpenStack, Kubernetes, clouds privés et infrastructures souveraines.

RBDCephFSRGWCRUSH

27.2

MinIO

Object storage S3-compatible haute performance, très populaire pour Kubernetes, AI datasets, cloud privé, edge et workloads applicatifs modernes.

S3-compatibleObjectKubernetesAIStor

27.3

OpenEBS

Projet CNCF orienté stockage Kubernetes : LocalPV, volumes persistants, engines container-native et intégration workloads stateful.

KubernetesLocalPVMayastorCNCF

27.4

Longhorn

Stockage distribué Kubernetes par SUSE/Rancher : volumes bloc répliqués, UI simple, snapshots, backups et DR pour clusters K8s.

RancherSUSEKubernetesReplicated block

27.5

SeaweedFS

Stockage distribué léger orienté objets/fichiers : volumes, filer, S3 gateway, replication, tiering et architecture simple à opérer.

DistributedObjectFileLightweight

27.6

JuiceFS

Filesystem distribué POSIX construit au-dessus d’un object storage et d’un moteur metadata, utile pour analytics, AI, Kubernetes et cloud portability.

POSIXObject backendMetadataCloud-native

27.7

Scality

Object storage enterprise, logiciel, S3-compatible, souverain : RING pour grands clusters et ARTESCA pour cloud-native/Kubernetes.

RINGARTESCAS3Souverain

27.8

OpenIO legacy

Historique français du stockage objet distribué, important dans l’histoire du SDS souverain, racheté par OVHcloud, désormais plutôt à considérer comme legacy.

FranceObject legacySDSOpen source history

27.9

Garage

Object storage S3-compatible léger, écrit en Rust, orienté auto-hébergement, petites infrastructures distribuées, géo-réplication et sobriété.

S3-compatibleGeo-distributedRustSelf-hosted

27.10

Rook

Rook est l’opérateur Kubernetes le plus connu pour déployer et opérer Ceph dans Kubernetes, avec CSI block/file/object.

KubernetesCeph operatorCNCFCSI

27.11

GlusterFS legacy

Filesystem distribué historique, très utilisé par le passé pour fichiers POSIX scale-out, aujourd’hui davantage legacy face à CephFS, NFS managé et solutions modernes.

Distributed fileLegacyRed Hat historyPOSIX

27.12

OpenZFS

OpenZFS n’est pas un cluster storage complet, mais une brique souveraine fondamentale : checksums end-to-end, snapshots, clones, replication, compression et RAID-Z.

ZFSSnapshotsChecksumsReplication

27.13

LINBIT / DRBD / LINSTOR / Piraeus

LINBIT fournit DRBD et LINSTOR pour réplication bloc, HA Linux, Kubernetes via Piraeus, et stockage bloc distribué avec forte tradition open source.

DRBDLINSTORKubernetesBlock replication

27.14

Mayastor / OpenEBS Mayastor

Mayastor, dans l’écosystème OpenEBS, vise le stockage Kubernetes haute performance via NVMe, SPDK, replicas et CSI.

NVMeSPDKKubernetesPerformance

27.15

OpenStack Swift

Object storage distribué historique d’OpenStack, robuste et mature, souvent présent dans clouds privés existants, même si S3-compatible domine aujourd’hui.

ObjectOpenStackSwift APILegacy cloud

27.16

Lustre

Filesystem parallèle open source de référence HPC, utilisé dans supercalculateurs, IA, simulation, recherche, genomics et workloads très haut débit.

HPCParallel FSExascaleScratch

27.17

BeeGFS

Filesystem parallèle orienté HPC/AI/recherche, plus simple à déployer que certains environnements Lustre, avec support commercial et communauté active.

HPCParallel fileResearchAI

27.18

MooseFS / LizardFS legacy

Filesystems distribués légers historiquement utilisés pour stockage fichier scale-out simple, petites infrastructures et workloads non critiques.

Distributed fileLightweightPOSIX-likeLegacy

27.19

OrangeFS

Filesystem parallèle open source issu du monde recherche/HPC, utilisé dans certains environnements scientifiques et académiques.

Parallel FSResearchHPCOpen source

27.20

OpenMediaVault / TrueNAS CORE / NAS souverain

Écosystème NAS open source/self-hosted : OpenMediaVault, TrueNAS CORE/Scale, OpenZFS, Samba, NFS, snapshots, replication et sauvegarde locale souveraine.

NASZFSSMB/NFSSelf-hosted

27.21

Architecture souveraine open source

Construire un stockage souverain ne consiste pas seulement à choisir un logiciel open source : il faut maîtriser localisation, clés, support, compétences et réversibilité.

SovereignOpen sourceRGPDExit strategy

27.22

Choisir une solution open source storage

Matrice de choix entre Ceph, MinIO, Longhorn, OpenEBS, ZFS, Scality, JuiceFS, Lustre, BeeGFS et autres selon workload et équipe.

DecisionSLASkillsWorkload

27.23

Day-2 operations open source storage

Le vrai coût d’un storage open source est dans le day-2 : monitoring, upgrades, rebalance, firmware, recovery, capacity planning et incidents.

MonitoringUpgradeRecoveryRunbooks

27.24

Synthèse open source et souverain 2026

Synthèse des familles open source et souveraines : SDS généraliste, object S3, Kubernetes storage, NAS/ZFS, HPC, archive, legacy et gouvernance.

Market mapSDSSovereigntyKubernetes

27.1 Ceph

Positionnement

Stockage distribué open source unifié : block, file et object, très utilisé dans OpenStack, Kubernetes, clouds privés et infrastructures souveraines.

URLs officielles :
Ceph — https://ceph.io/
Ceph Documentation — https://docs.ceph.com/
Rook Ceph — https://rook.io/docs/rook/latest-release/Storage-Configuration/Ceph-Storage/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
RADOS	Moteur distribué objet interne.
RBD	Block devices pour VM, OpenStack, Kubernetes.
CephFS	Filesystem distribué POSIX-like.
RGW	Gateway S3/Swift-compatible.
CRUSH	Placement déterministe sans metadata server central pour les objets RADOS.
cephadm / orchestrator	Déploiement et gestion moderne.

Cas d’usage principaux

Cloud privé souverain
OpenStack Cinder/Glance/Nova
Kubernetes via Rook
Object storage S3-compatible
Backup repository
SDS sur matériel standard

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Open source mature
Block/file/object unifié
Scalabilité horizontale
Pas de vendor lock-in matériel
Écosystème Red Hat/SUSE/Canonical/Proxmox

Points de vigilance

Complexité opérationnelle réelle
Design réseau/disques critique
Recovery/backfill à dimensionner
Mise à jour et tuning demandent expertise

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.2 MinIO

Positionnement

Object storage S3-compatible haute performance, très populaire pour Kubernetes, AI datasets, cloud privé, edge et workloads applicatifs modernes.

URLs officielles :
MinIO — https://min.io/
MinIO Documentation — https://min.io/docs/minio/linux/index.html
MinIO Kubernetes Operator — https://min.io/docs/minio/kubernetes/upstream/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
MinIO Server	Object storage S3-compatible.
Erasure coding	Protection distribuée des objets.
Bucket versioning / object locking	Protection logique selon configuration.
Kubernetes Operator	Gestion de tenants object storage.
AIStor / Enterprise	Packaging enterprise et AI data positioning.

Cas d’usage principaux

S3 privé lightweight
Kubernetes object storage
Backup Velero/restic/Veeam compatible S3
AI/ML datasets
Edge object storage
Dev/test S3 local

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Simplicité de déploiement
Très bonne compatibilité outillage S3
Performance élevée
Kubernetes-native
Adoption très large

Points de vigilance

Pas block/file
Opérations distribuées à respecter
Networking et disques critiques
Licensing/support à clarifier selon usage enterprise

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.3 OpenEBS

Positionnement

Projet CNCF orienté stockage Kubernetes : LocalPV, volumes persistants, engines container-native et intégration workloads stateful.

URLs officielles :
OpenEBS — https://openebs.io/
OpenEBS Docs — https://openebs.io/docs/
Mayastor — https://openebs.io/docs/concepts/mayastor

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
LocalPV Hostpath	Provisionnement local simple pour Kubernetes.
LocalPV LVM	Volumes locaux via LVM.
LocalPV ZFS	Volumes locaux via ZFS.
Mayastor	NVMe/SPDK-based engine pour performance.
CSI drivers	Intégration Kubernetes.

Cas d’usage principaux

Kubernetes stateful local
Dev/test clusters
Edge K8s
High-performance local PV
Databases avec node affinity
Lab cloud-native

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Kubernetes-native
CNCF ecosystem
LocalPV très utile
Mayastor performant
Flexible par engine

Points de vigilance

Pas storage distribué universel selon mode
Risque node failure avec local PV
Backup/restore applicatif indispensable
Choix engine à bien comprendre

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.4 Longhorn

Positionnement

Stockage distribué Kubernetes par SUSE/Rancher : volumes bloc répliqués, UI simple, snapshots, backups et DR pour clusters K8s.

URLs officielles :
Longhorn — https://longhorn.io/
Longhorn Documentation — https://longhorn.io/docs/
SUSE Longhorn — https://www.suse.com/products/longhorn/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Longhorn Manager	Control plane et UI.
Engine/Replica	Volumes block répliqués entre nœuds.
Snapshots/backups	Protection volume et backup vers object/NFS.
Recurring jobs	Planification snapshots/backups.
DR volumes	Reprise via backup store.

Cas d’usage principaux

Kubernetes PME/edge
Rancher clusters
Stateful apps simples
Backup PVC vers S3/NFS
Lab et production modérée
Environnements souverains K8s

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Très simple à comprendre
UI claire
Intégration Rancher/SUSE
Backups pratiques
Bonne adoption homelab/PME

Points de vigilance

Performance dépend réseau/disques
Pas adapté à tous workloads très lourds
Replica rebuild à surveiller
Architecture block répliquée à dimensionner

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.5 SeaweedFS

Positionnement

Stockage distribué léger orienté objets/fichiers : volumes, filer, S3 gateway, replication, tiering et architecture simple à opérer.

URLs officielles :
SeaweedFS GitHub — https://github.com/seaweedfs/seaweedfs
SeaweedFS Wiki — https://github.com/seaweedfs/seaweedfs/wiki

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Master servers	Coordination metadata et volume locations.
Volume servers	Stockage physique des blobs.
Filer	Interface fichiers/directories.
S3 gateway	API S3-compatible.
Replication and tiering	Copies, règles et backends froids.

Cas d’usage principaux

Object/file lightweight
Petits clusters souverains
Media storage
Backups simples
Edge storage
Alternative légère à Ceph dans certains cas

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Architecture relativement simple
S3 + file interfaces
Bon pour objets nombreux
Facile à tester
Empreinte légère

Points de vigilance

Écosystème enterprise plus limité
Moins standard enterprise que Ceph/MinIO
Support selon communauté/contrat
Fonctionnalités à valider par workload

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.6 JuiceFS

Positionnement

Filesystem distribué POSIX construit au-dessus d’un object storage et d’un moteur metadata, utile pour analytics, AI, Kubernetes et cloud portability.

URLs officielles :
JuiceFS — https://juicefs.com/
JuiceFS Docs — https://juicefs.com/docs/community/introduction/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
JuiceFS client	Mount POSIX-compatible.
Metadata engine	Redis, MySQL, TiKV, PostgreSQL, etc. selon édition/usage.
Object backend	S3, GCS, Azure Blob, MinIO, Ceph RGW, etc.
Cache local	Accélération lecture/écriture.
CSI driver	Kubernetes integration.

Cas d’usage principaux

POSIX sur object storage
AI/ML datasets
Data lake mountable
Kubernetes shared filesystem
Cloud migration
Hybrid analytics

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Découple metadata et objets
Très portable multi-cloud
POSIX interface pratique
Cache local
Bon fit analytics/AI

Points de vigilance

Metadata backend critique
Pas identique à un FS local pour tous workloads
Performance dépend cache/object store
Sauvegarder metadata est vital

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.7 Scality

Positionnement

Object storage enterprise, logiciel, S3-compatible, souverain : RING pour grands clusters et ARTESCA pour cloud-native/Kubernetes.

URLs officielles :
Scality — https://www.scality.com/
Scality RING — https://www.scality.com/products/ring/
Scality ARTESCA — https://www.scality.com/products/artesca/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
RING	Object storage scale-out enterprise.
ARTESCA	S3 object storage léger/cloud-native.
S3 API	Compatibilité écosystème objet.
Immutability	Protection ransomware et compliance.
Multi-site	Réplication et distribution selon architecture.

Cas d’usage principaux

Object storage souverain
Cloud privé S3
Backup immuable
Archive active
Service provider storage
Data lake on-prem

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Spécialiste objet enterprise
Logiciel sur matériel standard
Souveraineté forte
RING scalable
ARTESCA moderne

Points de vigilance

Pas block/file généraliste
Design hardware/réseau à maîtriser
Coût/support enterprise
Comparer à MinIO/Ceph/ECS selon besoin

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.8 OpenIO legacy

Positionnement

Historique français du stockage objet distribué, important dans l’histoire du SDS souverain, racheté par OVHcloud, désormais plutôt à considérer comme legacy.

URLs officielles :
OpenIO GitHub — https://github.com/open-io
OVHcloud — https://www.ovhcloud.com/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
OpenIO SDS	Object storage software-defined historique.
Grid architecture	Distribution par services et namespaces.
S3/Swift concepts	Interfaces objet selon versions.
OVHcloud acquisition	Intégration historique dans stratégie storage OVHcloud.
Legacy footprint	Installations existantes et code historique.

Cas d’usage principaux

Étude historique storage objet français
Legacy clusters
Migration vers S3 moderne
Souveraineté européenne
Analyse SDS
Comparaison Ceph/Scality/MinIO

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Histoire française du stockage objet
Approche SDS intéressante
Influence souveraine
Code et concepts utiles
Référence culturelle storage FR

Points de vigilance

À traiter comme legacy
Support/roadmap à vérifier
Migration probable vers solutions modernes
Ne pas choisir pour nouveau projet sans justification forte

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.9 Garage

Positionnement

Object storage S3-compatible léger, écrit en Rust, orienté auto-hébergement, petites infrastructures distribuées, géo-réplication et sobriété.

URLs officielles :
Garage — https://garagehq.deuxfleurs.fr/
Garage GitLab — https://git.deuxfleurs.fr/Deuxfleurs/garage

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
S3 API	Interface objet compatible pour applications courantes.
Distributed layout	Placement d’objets sur nœuds.
Rust codebase	Sécurité mémoire et simplicité de build.
Geo distribution	Usage multi-sites modestes.
Self-hosting	Projet adapté communautés/associations/PME techniques.

Cas d’usage principaux

Petit cloud souverain associatif
Object storage multi-site léger
Backups S3 modestes
Edge/community infrastructure
Alternative low-footprint
Expérimentation Rust storage

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Très léger
Philosophie souveraine/self-hosted
S3-compatible
Rust
Adapté petits clusters

Points de vigilance

Moins mature enterprise
Pas pour hyperscale critique
Fonctions S3 à valider
Support communautaire

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.10 Rook

Positionnement

Rook est l’opérateur Kubernetes le plus connu pour déployer et opérer Ceph dans Kubernetes, avec CSI block/file/object.

URLs officielles :
Rook — https://rook.io/
Rook Ceph Documentation — https://rook.io/docs/rook/latest-release/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
CephCluster CRD	Déclaration cluster Ceph.
CSI drivers	RBD/CephFS integration.
Object store CRDs	RGW dans Kubernetes.
Toolbox	Administration Ceph.
Operator lifecycle	Automatisation day-2.

Cas d’usage principaux

Ceph dans Kubernetes
OpenShift/OKD-like storage
Clusters bare metal K8s
Kubernetes PVC block/file
S3 RGW interne
Lab/production cloud-native

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Standard de fait Ceph-on-K8s
CNCF ecosystem
Automatise beaucoup d’opérations
CSI intégré
Très documenté

Points de vigilance

Ceph reste complexe
Kubernetes failure domain à concevoir
OSD sur disques dédiés
Upgrade operator + Ceph à tester

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.11 GlusterFS legacy

Positionnement

Filesystem distribué historique, très utilisé par le passé pour fichiers POSIX scale-out, aujourd’hui davantage legacy face à CephFS, NFS managé et solutions modernes.

URLs officielles :
Gluster — https://www.gluster.org/
Gluster Docs — https://docs.gluster.org/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Gluster volumes	Replicate, distribute, disperse.
FUSE/native client	Accès fichiers.
Geo-replication	Réplication asynchrone.
NFS/SMB integrations	Selon setup.
Legacy Red Hat Storage	Historique enterprise.

Cas d’usage principaux

Legacy file clusters
Migration planning
Archives fichiers internes
Labs historiques
Comparaison CephFS
Petits partages distribués

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Simple conceptuellement
POSIX-like
Historique riche
Communauté existante
Facile à comprendre

Points de vigilance

Roadmap enterprise affaiblie
Performances/metadata variables
Recovery complexe
À éviter pour nouveaux grands projets critiques

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.12 OpenZFS

Positionnement

OpenZFS n’est pas un cluster storage complet, mais une brique souveraine fondamentale : checksums end-to-end, snapshots, clones, replication, compression et RAID-Z.

URLs officielles :
OpenZFS — https://openzfs.org/
OpenZFS Documentation — https://openzfs.github.io/openzfs-docs/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Zpool	Pool de stockage.
Datasets/zvols	Filesystems et block devices.
Snapshots/clones	Protection et dev/test.
Send/receive	Réplication et backup.
RAID-Z	Protection locale avec checksums.

Cas d’usage principaux

NAS souverain
Backup server
Proxmox storage
Ceph backing nodes avec prudence
Snapshots locaux
Replication site à site

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Intégrité données exceptionnelle
Snapshots puissants
Compression native
Réplication simple
Très mature

Points de vigilance

Pas scale-out natif
RAM/ARC à dimensionner
RAID-Z expansion historique limitée selon versions
SLOG/L2ARC souvent mal compris

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.13 LINBIT / DRBD / LINSTOR / Piraeus

Positionnement

LINBIT fournit DRBD et LINSTOR pour réplication bloc, HA Linux, Kubernetes via Piraeus, et stockage bloc distribué avec forte tradition open source.

URLs officielles :
LINBIT — https://linbit.com/
LINSTOR — https://linbit.com/linstor/
Piraeus Datastore — https://piraeus.io/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
DRBD	Replication block device Linux.
LINSTOR	Resource management et provisionnement.
Piraeus	Kubernetes integration for LINSTOR/DRBD.
Gateway integrations	iSCSI/NVMe-oF selon architecture.
HA stacks	Pacemaker/Corosync integrations.

Cas d’usage principaux

HA Linux block replication
Kubernetes RWO storage
Two/three-node clusters
Edge/ROBO
Low-latency replicated block
Alternative Ceph pour petits clusters

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Bloc répliqué mature
Très bon pour petits clusters HA
Kubernetes via Piraeus
Performance prévisible
Entreprise LINBIT derrière

Points de vigilance

Pas object/file généraliste
Split-brain à comprendre
Failure domains restreints
Design quorum critique

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.14 Mayastor / OpenEBS Mayastor

Positionnement

Mayastor, dans l’écosystème OpenEBS, vise le stockage Kubernetes haute performance via NVMe, SPDK, replicas et CSI.

URLs officielles :
OpenEBS Mayastor — https://openebs.io/docs/concepts/mayastor
OpenEBS — https://openebs.io/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Mayastor data plane	SPDK/NVMe optimized engine.
Control plane	Kubernetes CRDs/controllers.
Pools	Disques locaux pour volumes.
Replicas	Protection par réplication.
CSI	Provisionnement PVC.

Cas d’usage principaux

Kubernetes high-performance PVC
NVMe local clusters
Edge performance
Databases containerisées
Low-latency stateful apps
Lab cloud-native avancé

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Architecture performance moderne
SPDK/NVMe
Kubernetes-native
OpenEBS ecosystem
Bon fit bare metal K8s

Points de vigilance

Plus pointu que Longhorn
Réseau NVMe/latence critique
Maturité à valider par version
Backup externe indispensable

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.15 OpenStack Swift

Positionnement

Object storage distribué historique d’OpenStack, robuste et mature, souvent présent dans clouds privés existants, même si S3-compatible domine aujourd’hui.

URLs officielles :
OpenStack Swift — https://docs.openstack.org/swift/latest/
OpenStack — https://www.openstack.org/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Proxy servers	API frontend.
Account/container/object servers	Architecture distribuée.
Ring	Mapping données vers devices.
Replication/auditors	Protection et vérification.
Swift API	API objet propre OpenStack.

Cas d’usage principaux

Cloud OpenStack legacy
Object storage interne
Archive active
Migration vers S3-compatible
Service provider cloud
Souveraineté OpenStack

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Mature
Architecture robuste
OpenStack native
Bon pour objets massifs
Pas dépendant S3

Points de vigilance

Écosystème S3 plus fort
Nouveaux projets préfèrent souvent Ceph RGW/MinIO
Ops OpenStack nécessaire
Compatibilité apps à vérifier

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.16 Lustre

Positionnement

Filesystem parallèle open source de référence HPC, utilisé dans supercalculateurs, IA, simulation, recherche, genomics et workloads très haut débit.

URLs officielles :
Lustre — https://www.lustre.org/
OpenSFS — https://www.opensfs.org/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
MDS/MDT	Metadata servers/targets.
OSS/OST	Object storage servers/targets.
Clients	Accès parallèle haute performance.
HSM	Tiering/archive integrations.
LNet	Networking layer.

Cas d’usage principaux

HPC scratch
Simulation scientifique
Genomics
AI training datasets
Render farms
Supercomputing centers

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Très haut débit parallèle
Écosystème HPC énorme
Scalabilité exascale
Optimisé large files
Support via DDN/Whamcloud/autres

Points de vigilance

Pas généraliste NAS PME
Ops HPC spécialisée
Metadata workloads à concevoir
HA/backup séparés

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.17 BeeGFS

Positionnement

Filesystem parallèle orienté HPC/AI/recherche, plus simple à déployer que certains environnements Lustre, avec support commercial et communauté active.

URLs officielles :
BeeGFS — https://www.beegfs.io/
BeeGFS Documentation — https://doc.beegfs.io/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Management service	Coordination cluster.
Metadata service	Metadata distributed.
Storage service	Data storage targets.
Client module	Mount BeeGFS.
Monitoring/tools	Administration et observabilité.

Cas d’usage principaux

HPC mid-size
AI training
Research labs
Scratch parallèle
Engineering simulation
Academic clusters

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Performance parallèle
Déploiement relativement accessible
Bon fit HPC PME/recherche
Support commercial disponible
Architecture flexible

Points de vigilance

Pas object/block
Moins omniprésent que Lustre en supercomputing
Backup/HA à concevoir
Tuning réseau nécessaire

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.18 MooseFS / LizardFS legacy

Positionnement

Filesystems distribués légers historiquement utilisés pour stockage fichier scale-out simple, petites infrastructures et workloads non critiques.

URLs officielles :
MooseFS — https://moosefs.com/
LizardFS GitHub — https://github.com/lizardfs/lizardfs

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Master server	Metadata/control plane.
Chunkservers	Data chunks.
Clients	Mount filesystem.
Replication goals	Nombre de copies.
Web UI/tools	Monitoring de base.

Cas d’usage principaux

Petits clusters fichiers
Labs
Archive active non critique
Migration legacy
Stockage interne simple
Education

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Simple à comprendre
Léger
POSIX-like
Facile à tester
Coût faible

Points de vigilance

Master/metadata critique
Écosystème enterprise limité
Pas idéal haute criticité
Projet/fork roadmap à vérifier

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.19 OrangeFS

Positionnement

Filesystem parallèle open source issu du monde recherche/HPC, utilisé dans certains environnements scientifiques et académiques.

URLs officielles :
OrangeFS — https://www.orangefs.org/
OrangeFS GitHub — https://github.com/waltligon/orangefs

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Metadata/data servers	Services distribués.
Client kernel/userspace	Accès filesystem.
MPI-IO focus	Historique HPC.
Parallel access	Accès concurrent.
Research ecosystem	Usage académique.

Cas d’usage principaux

Recherche HPC
Expérimentation filesystem
Workloads MPI-IO
Clusters académiques
Comparaison Lustre/BeeGFS
Labs storage

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Open source HPC
Architecture parallèle
Historique recherche
Intéressant pédagogiquement
Adapté certains workloads scientifiques

Points de vigilance

Écosystème plus restreint
Support enterprise limité
Moins mainstream
Nouveaux projets préfèrent souvent Lustre/BeeGFS

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.20 OpenMediaVault / TrueNAS CORE / NAS souverain

Positionnement

Écosystème NAS open source/self-hosted : OpenMediaVault, TrueNAS CORE/Scale, OpenZFS, Samba, NFS, snapshots, replication et sauvegarde locale souveraine.

URLs officielles :
OpenMediaVault — https://www.openmediavault.org/
TrueNAS — https://www.truenas.com/
Samba — https://www.samba.org/
NFS Ganesha — https://github.com/nfs-ganesha/nfs-ganesha

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
OpenMediaVault	NAS Debian-based extensible.
TrueNAS CORE/Scale	ZFS NAS, apps, shares, replication.
Samba	SMB/CIFS server.
NFS	Partages Unix/Linux.
ZFS snapshots	Protection et réplication.

Cas d’usage principaux

NAS PME souverain
Home lab avancé
Backup local
Partages SMB/NFS
Proxmox storage
Archive ZFS

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Coût faible
Contrôle total
ZFS mature
Communautés fortes
Très bon pour backup/PME technique

Points de vigilance

Support à assumer
Sécurité si exposé Internet
Pas SAN enterprise
Hardware/RAM/ECC/backups à dimensionner

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.21 Architecture souveraine open source

Positionnement

Construire un stockage souverain ne consiste pas seulement à choisir un logiciel open source : il faut maîtriser localisation, clés, support, compétences et réversibilité.

URLs officielles :
CNIL — https://www.cnil.fr/
ANSSI — https://cyber.gouv.fr/
CNCF — https://www.cncf.io/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Logiciel ouvert	Ceph, MinIO, OpenZFS, Longhorn, etc.
Matériel standard	Serveurs x86/ARM, NVMe, HDD, réseau.
Clés maîtrisées	KMS/HSM ou chiffrement applicatif.
Support local	Prestataire national/européen.
Réversibilité	Protocoles ouverts : S3, NFS, SMB, iSCSI, NVMe-oF.

Cas d’usage principaux

Cloud privé public/collectivité
Santé/données sensibles
Industrie stratégique
Education/recherche
Backup souverain
PRA national

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Contrôle fort
Réduction lock-in
Auditabilité
Protocoles standards
Alignement RGPD/souveraineté

Points de vigilance

Compétences rares
Responsabilité opérationnelle
Support 24/7 à organiser
Ne pas confondre open source et gratuit

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.22 Choisir une solution open source storage

Positionnement

Matrice de choix entre Ceph, MinIO, Longhorn, OpenEBS, ZFS, Scality, JuiceFS, Lustre, BeeGFS et autres selon workload et équipe.

URLs : sélectionner la documentation officielle du projet, les release notes, les matrices de compatibilité et les guides upgrade avant tout déploiement.

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Block VM/K8s	Ceph RBD, LINSTOR/DRBD, Longhorn, OpenEBS.
Object S3	MinIO, Ceph RGW, Scality, Garage, SeaweedFS.
File/NAS	CephFS, OpenZFS+NFS/SMB, JuiceFS, Qumulo-like alternatives.
HPC	Lustre, BeeGFS, IBM Storage Scale non open-core selon édition.
Archive	OpenZFS, object storage + lifecycle, tape gateways.

Cas d’usage principaux

Architecture cible
RFP souverain
Audit existant
Migration VMware
Kubernetes stateful
Backup strategy

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Permet choix rationnel
Évite mode marketing
Aligne compétences et criticité
Clarifie support
Facilite POC

Points de vigilance

Sous-estimer opérations
Mauvais fit protocole
Pas de restore testé
Négliger upgrade et monitoring

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.23 Day-2 operations open source storage

Positionnement

Le vrai coût d’un storage open source est dans le day-2 : monitoring, upgrades, rebalance, firmware, recovery, capacity planning et incidents.

URLs officielles :
Prometheus — https://prometheus.io/
Grafana — https://grafana.com/
fio — https://fio.readthedocs.io/

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
Monitoring	Prometheus, Grafana, exporters, alerts.
Capacity planning	Growth, rebalance, failure domains.
Upgrade runbooks	Version matrix, rolling upgrades, rollback.
Recovery drills	Disk/node/site failure.
Security	Secrets, IAM, TLS, audit logs.

Cas d’usage principaux

Production readiness
SRE storage
Managed service internal
Cloud privé
Kubernetes platform
Disaster recovery

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Prévisibilité
Moins d’incidents surprises
Meilleure confiance restore
Automatisation possible
Documentation capitalisée

Points de vigilance

Alert fatigue
Upgrades non testés
Pas de spare capacity
Backups non isolés
Dépendance à 1 expert

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.

27.24 Synthèse open source et souverain 2026

Positionnement

Synthèse des familles open source et souveraines : SDS généraliste, object S3, Kubernetes storage, NAS/ZFS, HPC, archive, legacy et gouvernance.

URLs : sélectionner la documentation officielle du projet, les release notes, les matrices de compatibilité et les guides upgrade avant tout déploiement.

Lecture architecture

Hardware standard→Software-defined layer→Block / File / Object→Automation→Sovereign operations

CritèreSkills

Compétences internes nécessaires.

CritèreSLA

Support, astreinte, runbooks.

CritèreRTO

Recovery réel testé.

CritèreExit

Protocoles ouverts.

Composant / module	Rôle
SDS généraliste	Ceph domine block/file/object open source.
Object S3	MinIO, Scality, Ceph RGW, Garage, SeaweedFS.
Kubernetes storage	Longhorn, OpenEBS, Rook, LINSTOR/Piraeus.
NAS souverain	OpenZFS, TrueNAS, OMV, Samba/NFS.
HPC	Lustre et BeeGFS pour très haut débit parallèle.
Legacy/historique	GlusterFS, OpenIO, Swift, MooseFS selon contexte.

Cas d’usage principaux

Cloud privé souverain
Plateforme Kubernetes
Backup open source
AI data on-prem
Archive et conformité
Remplacement appliances coûteuses

Pattern d’intégration

Design→POC→Benchmark→Runbooks→Production

Forces

Réversibilité
Coût logiciel maîtrisable
Protocoles ouverts
Souveraineté
Innovation cloud-native

Points de vigilance

Compétences et support
Complexité distribuée
Responsabilité sécurité
SLA à construire
POC obligatoire

Matrice de décision open source

Question	Pourquoi c’est critique
Quel protocole réel ?	Block, file, object, POSIX, S3, NFS, SMB, iSCSI, NVMe-oF : le mauvais protocole détruit le projet.
Quel failure domain ?	Disque, nœud, rack, AZ, site : le logiciel ne compense pas un mauvais design physique.
Quelle équipe day-2 ?	Upgrades, monitoring, alerting, recovery et capacity planning ne sont pas optionnels.
Quel support ?	Communauté, éditeur, intégrateur local, astreinte interne : à clarifier avant production.
Quel plan backup ?	Un cluster distribué n’est pas un backup ; corruption logique et ransomware se répliquent aussi.
Quel coût complet ?	Matériel, réseau, énergie, racks, support, formation, incidents, migration et tests.

Règle pratique : open source storage = liberté + responsabilité opérationnelle. Le POC doit inclure incidents, upgrades et restore.

Runbook POC production-grade

Définir workload : VM block, Kubernetes PVC, S3 backup, NAS, AI dataset, HPC scratch.
Construire un cluster pilote avec matériel proche production.
Mesurer performance : random, séquentiel, metadata, petits fichiers, gros objets, p95/p99.
Déclencher incidents contrôlés : perte disque, perte nœud, perte réseau, perte site si applicable.
Tester upgrade mineur/majeur et rollback documentaire.
Tester restore : objet, volume, filesystem, namespace, application complète.
Valider monitoring, alertes, logs, audit, rotation secrets et capacité.

fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./dataset s3target:bucket/poc --progress
kubectl get pvc,pv,storageclass
kubectl describe pvc my-volume
df -h
iostat -x 1

NO-GO : pas de restore testé, pas de monitoring, pas de procédure upgrade, pas de support identifié, performance mesurée uniquement en régime normal.