OpenEBS : stockage Kubernetes natif avec Mayastor

OpenEBS transforme les disques locaux de vos nœuds Kubernetes en stockage persistant haute performance, répliqué via NVMe-oF (NVMe over Fabrics). Projet CNCF Sandbox, il suit le modèle Container Attached Storage (CAS) : le plan de données tourne dans des pods, au plus près des applications. Ce guide vous accompagne du déploiement d’un cluster 3 nœuds à la création de volumes répliqués, snapshots et LocalPV, avec toutes les commandes testées sur Ubuntu 24.04.

Ce que vous allez apprendre

Architecture CAS : moteur io-engine, DiskPools, réplication NVMe-oF
Deux moteurs de stockage : Replicated PV Mayastor et LocalPV Hostpath
Lab complet : déployer OpenEBS 4.4 sur 3 VMs KVM avec k3s
Volumes répliqués : StorageClass, PVC, déploiement PostgreSQL
Snapshots : sauvegarder et restaurer un volume
Dépannage et bonnes pratiques : diagnostic, dimensionnement, sécurité

Qu’est-ce qu’OpenEBS ?

OpenEBS est une solution de stockage persistant pour Kubernetes créée en 2017 par MayaData (aujourd’hui DataCore). Contrairement aux solutions de stockage distribué traditionnelles (Ceph, GlusterFS) qui fonctionnent en dehors de Kubernetes, OpenEBS s’exécute entièrement dans le cluster sous forme de pods.

Analogie : imaginez un immeuble de bureaux (votre cluster Kubernetes). Au lieu de stocker vos dossiers dans un entrepôt externe (stockage réseau classique), chaque étage dispose de ses propres armoires sécurisées (les DiskPools). Un système de coursiers ultra-rapides (le protocole NVMe-oF) fait des copies de chaque dossier dans les armoires des autres étages. Si un étage est inondé, les copies restent accessibles depuis les autres étages, sans interruption.

Ce qui distingue OpenEBS

Caractéristique	Description
Container Attached Storage	Le plan de données tourne dans des pods Kubernetes, pas sur un cluster externe
NVMe over Fabrics	Réplication via le protocole NVMe-oF, plus rapide que iSCSI
Moteurs multiples	Replicated PV Mayastor (HA), LocalPV Hostpath, LocalPV LVM, LocalPV ZFS
Kubernetes-natif	Installation via Helm, configuration via CRD (DiskPool, StorageClass)
CNCF Sandbox	Projet hébergé par la Cloud Native Computing Foundation
Open source	Licence Apache 2.0, développé par DataCore

OpenEBS vs alternatives

Critère	OpenEBS (Mayastor)	Longhorn	Rook-Ceph	NFS classique
Protocole	NVMe-oF	iSCSI	RADOS (propriétaire)	NFS
Performance	Très élevée	Modérée	Élevée	Faible
Complexité	Modérée	Faible	Élevée	Très faible
CPU par nœud	2 cœurs dédiés	Faible	Variable	Négligeable
Prérequis noyau	HugePages + nvme-tcp	Aucun	Aucun	Aucun
Interface web	Non	Oui	Dashboard Ceph	Non
Cas d’usage idéal	Bases de données, performance	Petits clusters, simplicité	Cloud privé complet	Partages simples

Architecture et concepts clés

Le modèle Container Attached Storage

OpenEBS suit le modèle CAS (Container Attached Storage) : chaque volume est géré par son propre contrôleur, tournant dans un pod Kubernetes. Cette approche offre une isolation par workload et permet de configurer le stockage différemment pour chaque application.

Les composants fondamentaux

Le plan de contrôle et le plan de données d’OpenEBS Mayastor s’articulent autour de plusieurs composants :

io-engine : le moteur de données Mayastor. Un DaemonSet qui tourne sur chaque nœud labellisé. Il gère les DiskPools, la réplication NVMe-oF et les I/O. Chaque pod io-engine réserve 2 cœurs CPU exclusifs et 2 GiB de HugePages.
agent-core : le cerveau du plan de contrôle. Il orchestre la création des volumes, la répartition des réplicas et le basculement en cas de panne.
csi-controller / csi-node : les composants CSI (Container Storage Interface) qui font le lien entre Kubernetes (PVC, StorageClass) et Mayastor. Le controller gère le provisionnement, les csi-node montent les volumes dans les pods.
DiskPool : un CRD (Custom Resource Definition) qui représente un disque physique géré par Mayastor. Chaque DiskPool est associé à un nœud et un disque dédié. Les volumes répliqués répartissent leurs réplicas sur plusieurs DiskPools.
etcd : cluster etcd dédié à Mayastor pour stocker les métadonnées des volumes (indépendant de l’etcd de Kubernetes).
NATS : bus de messages pour la communication entre les composants du plan de contrôle.
localpv-provisioner : provisionne les volumes LocalPV Hostpath (stockage local sans réplication, pour les workloads tolérants aux pannes).

Deux moteurs de stockage

Moteur	Réplication	Performance	Cas d’usage
Replicated PV Mayastor	Oui (1 à 3 réplicas)	Très élevée (NVMe-oF)	Bases de données, workloads critiques
LocalPV Hostpath	Non (local uniquement)	Maximale (accès disque direct)	Caches, données régénérables, CI/CD
LocalPV LVM	Non	Élevée	Thin provisioning, snapshots locaux
LocalPV ZFS	Non	Élevée	Compression, déduplication, snapshots

Lab : déployer OpenEBS 4.4 sur 3 nœuds

Prérequis

3 machines virtuelles Ubuntu 24.04 (KVM, Proxmox ou cloud)
4 vCPU et 8 Go de RAM minimum par VM
1 disque système (25 Go) + 1 disque dédié aux DiskPools (10 Go minimum) par VM
Noyau Linux 5.13+ avec le module nvme-tcp
HugePages 2 MiB configurés (1024 pages = 2 GiB)

Le script suivant crée 3 VMs avec cloud-init, chacune avec 2 disques :

#!/bin/bash
# Créer 3 VMs pour le lab OpenEBS
IMAGE="/var/lib/libvirt/images/ubuntu-24.04-cloud.img"

for i in 1 2 3; do
  # Disque système (backing file pour économiser de l'espace)
  qemu-img create -f qcow2 -b "$IMAGE" -F qcow2 \
    /var/lib/libvirt/images/openebs${i}.qcow2 25G

  # Disque dédié aux DiskPools (vierge)
  qemu-img create -f qcow2 \
    /var/lib/libvirt/images/openebs${i}-data.qcow2 10G

  virt-install --name openebs${i} \
    --ram 8192 --vcpus 4 \
    --disk /var/lib/libvirt/images/openebs${i}.qcow2 \
    --disk /var/lib/libvirt/images/openebs${i}-data.qcow2 \
    --os-variant ubuntu24.04 \
    --cloud-init user-data=cloud-init.yaml \
    --network network=default \
    --graphics none --noautoconsole
done

Le fichier cloud-init configure les HugePages, le module nvme-tcp et les paquets nécessaires :

#cloud-config
hostname: openebs1  # Adapter pour chaque nœud
users:
  - name: bob
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... votre-clé-publique
packages:
  - open-iscsi
  - nfs-common
bootcmd:
  # Configurer les HugePages (1024 × 2 MiB = 2 GiB)
  - echo "vm.nr_hugepages = 1024" >> /etc/sysctl.d/99-hugepages.conf
  - sysctl -p /etc/sysctl.d/99-hugepages.conf
runcmd:
  # Charger le module noyau NVMe-TCP
  - apt-get install -y linux-modules-extra-$(uname -r)
  - modprobe nvme-tcp
  - echo "nvme-tcp" >> /etc/modules-load.d/nvme-tcp.conf

Installer k3s et préparer le cluster

Installer k3s sur le premier nœud (control plane)

k3s est une distribution Kubernetes légère, idéale pour les labs. On désactive Traefik pour alléger le cluster :

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -

Vérification :

sudo kubectl get nodes
# NAME       STATUS   ROLES                  AGE   VERSION
# openebs1   Ready    control-plane,master   1m    v1.34.4+k3s1

Récupérer le token d’enregistrement
Fenêtre de terminal
```
sudo cat /var/lib/rancher/k3s/server/node-token
```

Joindre les agents (sur openebs2 et openebs3)

curl -sfL https://get.k3s.io | K3S_URL=https://openebs1:6443 \
  K3S_TOKEN="<token>" sh -

Vérification (depuis openebs1) :

sudo kubectl get nodes
# NAME       STATUS   ROLES                  AGE   VERSION
# openebs1   Ready    control-plane,master   5m    v1.34.4+k3s1
# openebs2   Ready    <none>                 1m    v1.34.4+k3s1
# openebs3   Ready    <none>                 1m    v1.34.4+k3s1

Vérifier les prérequis sur chaque nœud

Avant d’installer OpenEBS, vérifiez que chaque nœud dispose des HugePages et du module nvme-tcp :
Fenêtre de terminal
```
# HugePages (doit afficher 1024)
cat /proc/sys/vm/nr_hugepages
# 1024

# Module nvme-tcp chargé
lsmod | grep nvme_tcp
# nvme_tcp  ...

# Disque dédié disponible (vierge, sans partitions)
lsblk /dev/vdb
# NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
# vdb  252:16   0  10G  0 disk
```
Le noyau cloud d’Ubuntu 24.04 n’inclut pas le module nvme-tcp par défaut. Installez le paquet linux-modules-extra-$(uname -r) pour le rendre disponible, puis chargez-le avec modprobe nvme-tcp.
Labelliser les nœuds pour Mayastor

Le DaemonSet io-engine ne se déploie que sur les nœuds portant le label openebs.io/engine=mayastor :
Fenêtre de terminal
```
kubectl label node openebs1 openebs2 openebs3 \
  openebs.io/engine=mayastor
```

Installer OpenEBS avec Helm

Ajouter le dépôt Helm et installer

helm repo add openebs https://openebs.github.io/openebs
helm repo update

helm install openebs openebs/openebs \
  --namespace openebs --create-namespace \
  --version 4.4.0 \
  --set engines.replicated.mayastor.enabled=true \
  --set loki.enabled=false \
  --set alloy.enabled=false

Les options loki.enabled=false et alloy.enabled=false désactivent la stack de logging intégrée, inutile en lab.

Vérifier le déploiement

Attendez 2 à 3 minutes que tous les pods démarrent :

kubectl get pods -n openebs

NAME                                  READY   STATUS    AGE
openebs-agent-core-5b7f8c5b9-x2g7k   2/2     Running   2m
openebs-api-rest-6c8f5d4b7-7q9zv      1/1     Running   2m
openebs-csi-controller-0              6/6     Running   2m
openebs-csi-node-xxxxx                2/2     Running   2m  (×3)
openebs-etcd-0                        1/1     Running   2m  (×3)
openebs-io-engine-xxxxx               2/2     Running   2m  (×3)
openebs-localpv-provisioner-xxx       1/1     Running   2m
openebs-nats-0                        3/3     Running   2m  (×3)
openebs-obs-callhome-xxx              2/2     Running   2m
openebs-operator-diskpool-xxx         1/1     Running   2m

Les pods io-engine (un par nœud labellisé) sont les plus critiques : ils gèrent les I/O et la réplication.

Si les pods io-engine restent en Pending :

kubectl describe pod -n openebs -l app=io-engine | grep -A5 Events

Cause la plus fréquente : Insufficient cpu. Le io-engine exige 2 cœurs CPU exclusifs. Vos VMs doivent avoir au moins 4 vCPU.

Créer les DiskPools

Un DiskPool associe un disque physique à Mayastor. Chaque nœud héberge un ou plusieurs DiskPools qui servent de réservoirs pour les réplicas de volumes.

Mayastor exige un lien de périphérique persistant (/dev/disk/by-id/... ou /dev/disk/by-path/...), pas un chemin comme /dev/vdb qui peut changer au redémarrage. Identifiez le lien correct avec :

ls -la /dev/disk/by-path/ | grep vdb
# virtio-pci-0000:05:00.0 -> ../../vdb

Pour des disques physiques (SATA, NVMe), utilisez /dev/disk/by-id/.

apiVersion: openebs.io/v1beta3
kind: DiskPool
metadata:
  name: pool-openebs1
  namespace: openebs
spec:
  node: openebs1
  disks:
    - uring:///dev/disk/by-path/virtio-pci-0000:05:00.0
---
apiVersion: openebs.io/v1beta3
kind: DiskPool
metadata:
  name: pool-openebs2
  namespace: openebs
spec:
  node: openebs2
  disks:
    - uring:///dev/disk/by-path/virtio-pci-0000:05:00.0
---
apiVersion: openebs.io/v1beta3
kind: DiskPool
metadata:
  name: pool-openebs3
  namespace: openebs
spec:
  node: openebs3
  disks:
    - uring:///dev/disk/by-path/virtio-pci-0000:05:00.0

Vérification :

kubectl get dsp -n openebs

NAME            NODE       STATE     POOL-STATUS   CAPACITY   USED   AVAILABLE
pool-openebs1   openebs1   Created   Online        10 GiB     0 B    10 GiB
pool-openebs2   openebs2   Created   Online        10 GiB     0 B    10 GiB
pool-openebs3   openebs3   Created   Online        10 GiB     0 B    10 GiB

Les trois pools sont Online avec 10 GiB de capacité chacun. Si un pool reste en état Creating, vérifiez les logs du pod io-engine correspondant :

kubectl logs -n openebs -l app=io-engine --tail=20

Volumes répliqués avec Mayastor

Créer un StorageClass répliqué

L’installation crée par défaut un StorageClass openebs-single-replica (1 réplica). Pour la haute disponibilité, créez un StorageClass avec 3 réplicas :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-replicated
parameters:
  protocol: nvmf
  repl: "3"
provisioner: io.openebs.csi-mayastor
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

Le paramètre protocol: nvmf active le transport NVMe over Fabrics pour la réplication entre les nœuds. Le paramètre repl: "3" crée 3 copies de chaque volume, une par DiskPool.

Déployer PostgreSQL sur un volume répliqué

Créer la PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgdata-replicated
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: openebs-replicated
  resources:
    requests:
      storage: 2Gi

Vérification :

kubectl get pvc pgdata-replicated
# NAME                STATUS   VOLUME                                     CAPACITY   STORAGECLASS
# pgdata-replicated   Bound    pvc-044150cf-302d-44f5-8b8b-9b7ef66b2889   2Gi        openebs-replicated

Vérifier la réplication

Chaque DiskPool consomme maintenant 2 GiB (une copie du volume par pool) :

kubectl get dsp -n openebs
# NAME            NODE       STATE     POOL-STATUS   CAPACITY   USED    AVAILABLE
# pool-openebs1   openebs1   Created   Online        10 GiB     2 GiB   8 GiB
# pool-openebs2   openebs2   Created   Online        10 GiB     2 GiB   8 GiB
# pool-openebs3   openebs3   Created   Online        10 GiB     2 GiB   8 GiB

Déployer PostgreSQL

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          env:
            - name: POSTGRES_PASSWORD
              value: openebs-demo
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: pgdata
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: pgdata
          persistentVolumeClaim:
            claimName: pgdata-replicated

Tester l’écriture et la lecture

kubectl exec -it deploy/postgres -- psql -U postgres -c "
CREATE TABLE test_openebs (
  id SERIAL PRIMARY KEY,
  message TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO test_openebs (message) VALUES ('Hello OpenEBS Mayastor!');
INSERT INTO test_openebs (message) VALUES ('Réplication 3x NVMe-oF');
SELECT * FROM test_openebs;
"

 id |         message         |         created_at
----+-------------------------+----------------------------
  1 | Hello OpenEBS Mayastor! | 2026-03-01 11:57:25.027307
  2 | Réplication 3x NVMe-oF  | 2026-03-01 11:57:25.027307
(2 rows)

LocalPV Hostpath

Pour les workloads qui n’ont pas besoin de réplication (caches, données régénérables, CI/CD), OpenEBS fournit LocalPV Hostpath. Ce moteur crée des répertoires sur le système de fichiers local du nœud, sans surcoût de réplication.

Le StorageClass openebs-hostpath est créé automatiquement par Helm :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-test
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: openebs-hostpath
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-local
spec:
  containers:
    - name: busybox
      image: busybox:1.36
      command: ["sh", "-c", "echo 'LocalPV Hostpath OK' > /data/test.txt && cat /data/test.txt && sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: local-test

Vérification :

kubectl logs busybox-local
# LocalPV Hostpath OK

Snapshots et restauration

Les VolumeSnapshots permettent de sauvegarder l’état d’un volume à un instant donné. Combinés avec la réplication Mayastor, ils offrent une protection complète des données.

Créer un VolumeSnapshotClass

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: openebs-mayastor-snapshotclass
driver: io.openebs.csi-mayastor
deletionPolicy: Delete

Prendre un snapshot

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pgdata-snapshot
spec:
  volumeSnapshotClassName: openebs-mayastor-snapshotclass
  source:
    persistentVolumeClaimName: pgdata-replicated

Vérification :

kubectl get volumesnapshot pgdata-snapshot
# NAME              READYTOUSE   SOURCEPVC           RESTORESIZE   SNAPSHOTCLASS
# pgdata-snapshot   true         pgdata-replicated   2Gi           openebs-mayastor-snapshotclass

Restaurer depuis un snapshot

Créez une nouvelle PVC avec le snapshot comme source de données :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgdata-restored
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: openebs-replicated
  resources:
    requests:
      storage: 2Gi
  dataSource:
    name: pgdata-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Vérifier l’intégrité des données

Montez la PVC restaurée dans un nouveau pod et vérifiez que les données sont intactes :

kubectl exec postgres-restored -- psql -U postgres -c \
  "SELECT * FROM test_openebs;"

 id |         message         |         created_at
----+-------------------------+----------------------------
  1 | Hello OpenEBS Mayastor! | 2026-03-01 11:57:25.027307
  2 | Réplication 3x NVMe-oF  | 2026-03-01 11:57:25.027307
(2 rows)

Commandes essentielles

DiskPools et volumes

# Lister les DiskPools avec leur capacité
kubectl get dsp -n openebs

# Détails d'un DiskPool (événements, erreurs)
kubectl describe dsp pool-openebs1 -n openebs

# Lister les StorageClasses OpenEBS
kubectl get sc | grep openebs

# Vérifier les PVC et leurs volumes
kubectl get pvc

# Inspecter un PV Mayastor (réplicas, protocole)
kubectl describe pv <nom-du-pv>

# Lister les snapshots
kubectl get volumesnapshot

Pods et diagnostics

# État des pods OpenEBS
kubectl get pods -n openebs -o wide

# Logs du plan de contrôle
kubectl logs -n openebs deploy/openebs-agent-core -c agent-core

# Logs d'un io-engine spécifique
kubectl logs -n openebs -l app=io-engine \
  --field-selector spec.nodeName=openebs1

# Logs de l'API REST Mayastor
kubectl logs -n openebs deploy/openebs-api-rest

# Version d'OpenEBS installée
helm list -n openebs

Nœuds et labels

# Vérifier les labels Mayastor
kubectl get nodes --show-labels | grep openebs

# Ajouter le label io-engine à un nouveau nœud
kubectl label node nouveau-noeud openebs.io/engine=mayastor

# Retirer le label (décommissionner un nœud)
kubectl label node ancien-noeud openebs.io/engine-

Sécurité

Chiffrement au repos

Depuis la version 4.3, Mayastor supporte le chiffrement au repos des DiskPools. Les données sont chiffrées avant d’être écrites sur le disque, protégeant contre le vol physique de disques :

apiVersion: openebs.io/v1beta3
kind: DiskPool
metadata:
  name: pool-chiffre
  namespace: openebs
spec:
  node: openebs1
  disks:
    - uring:///dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-data
  encryption:
    enabled: true

Bonnes pratiques sécurité

Pratique	Description
Namespace dédié	OpenEBS tourne dans le namespace `openebs`, isolé des workloads applicatifs
RBAC Kubernetes	Les ServiceAccounts OpenEBS ont des droits minimaux configurés par le chart Helm
Réseau dédié	En production, séparer le réseau de réplication NVMe-oF du réseau applicatif
Disques dédiés	Ne jamais partager un disque entre le système et un DiskPool
Chiffrement	Activer le chiffrement au repos pour les données sensibles (v4.3+)
Mise à jour	Suivre les releases de sécurité via `helm upgrade`

Dépannage

Problèmes courants et solutions

Symptôme	Cause probable	Solution
Pod io-engine Pending : `Insufficient cpu`	VM avec moins de 4 vCPU	Augmenter les vCPU à 4 minimum (io-engine réserve 2 cœurs exclusifs)
Pod io-engine Init error : `/run/udev is not a directory`	Conteneur Docker (k3d, Kind) au lieu d’une VM	Utiliser des VMs ou du bare-metal — Mayastor nécessite un accès direct aux périphériques
DiskPool bloqué en Creating : `InvalidDevlink`	Chemin `/dev/vdb` au lieu d’un lien persistant	Utiliser `/dev/disk/by-path/...` ou `/dev/disk/by-id/...`
DiskPool : `no matches for kind DiskPool in version v1beta2`	Mauvaise version d’API	Utiliser `openebs.io/v1beta3` (vérifier avec `kubectl api-resources`)
PVC Pending : `no capacity available`	Pas assez d’espace dans les DiskPools	Vérifier `kubectl get dsp -n openebs` et ajouter des disques
HugePages insuffisants	`nr_hugepages` non configuré	`echo "vm.nr_hugepages = 1024" > /etc/sysctl.d/99-hugepages.conf && sysctl -p`
Module `nvme-tcp` absent	Paquet kernel manquant	`apt install linux-modules-extra-$(uname -r) && modprobe nvme-tcp`

Commandes de diagnostic

# Vérifier la santé globale
kubectl get pods -n openebs -o wide
kubectl get dsp -n openebs

# Événements récents dans le namespace OpenEBS
kubectl get events -n openebs --sort-by='.lastTimestamp' | tail -20

# Logs détaillés du plan de contrôle
kubectl logs -n openebs deploy/openebs-agent-core -c agent-core --tail=50

# Vérifier les HugePages sur un nœud
ssh noeud "cat /proc/meminfo | grep HugePages"

# Vérifier le module nvme-tcp
ssh noeud "lsmod | grep nvme_tcp"

Bonnes pratiques

Dimensionnement

Composant	Minimum (test)	Recommandé (production)
vCPU par nœud	4	8+ (io-engine réserve 2 cœurs)
RAM par nœud	8 Go	16 Go+ (HugePages + workloads)
HugePages 2 MiB	1024 (2 GiB)	1024+ (2 GiB)
Disque DiskPool	10 Go (SSD)	100 Go+ (NVMe dédié)
Réseau	1 Gbps	10 Gbps (25 Gbps idéal pour NVMe-oF)
Nœuds Mayastor	3	3+ (toujours impair pour le quorum)

Organisation

Un disque dédié par DiskPool : ne jamais partager avec le système d’exploitation.
Utiliser des liens persistants : toujours référencer les disques via /dev/disk/by-id/ ou /dev/disk/by-path/, jamais /dev/sdX ou /dev/vdX.
Séparer les StorageClasses par usage : un SC répliqué (3 réplicas) pour les bases de données, un SC single-replica pour les logs, un SC LocalPV pour les caches.
Labelliser les nœuds : seuls les nœuds portant openebs.io/engine=mayastor exécutent io-engine. Gérez ce label pour contrôler la topologie de stockage.
Prévoir la capacité : un volume répliqué 3× consomme 3× sa taille dans les DiskPools. Un volume de 10 GiB avec repl: "3" utilise 30 GiB au total.

Performance

NVMe dédié : utilisez des disques NVMe pour les DiskPools en production. Mayastor tire parti du protocole NVMe nativement.
Réseau 10-25 Gbps : la réplication NVMe-oF est limitée par la bande passante réseau. En 1 Gbps, les performances chutent significativement.
HugePages : les 2 GiB de HugePages sont utilisés comme cache I/O par io-engine, améliorant la latence.
CPU exclusif : les 2 cœurs réservés par io-engine fonctionnent en polling mode (pas d’interruptions), maximisant le débit I/O.

À retenir

OpenEBS = stockage Kubernetes-natif : tout tourne dans des pods, pas de cluster de stockage externe à gérer.
Mayastor réplique les données via NVMe-oF, plus rapide que le iSCSI de Longhorn.
DiskPool = un disque dédié par nœud, référencé par un lien persistant (/dev/disk/by-id/ ou /dev/disk/by-path/).
io-engine réserve 2 cœurs CPU exclusifs + 2 GiB de HugePages par nœud : prévoyez au moins 4 vCPU et 8 Go de RAM.
LocalPV Hostpath pour les données régénérables (zéro overhead), Replicated PV pour la haute disponibilité.
Les VolumeSnapshots permettent de sauvegarder et restaurer un volume en quelques secondes.
API openebs.io/v1beta3 pour les DiskPools (v4.4) — vérifiez avec kubectl api-resources.
Mayastor nécessite des VMs ou du bare-metal : les conteneurs Docker (k3d, Kind) ne fournissent pas l’accès aux périphériques requis.

Prochaines étapes

Ceph : stockage distribué unifié Architecture complète avec objets, blocs et fichiers dans un seul cluster

MinIO : stockage objet S3 Solution légère pour le stockage objet compatible S3

NFS : partage de fichiers réseau Partage simple pour les environnements locaux

Stockage distribué : le guide Comprendre les concepts et choisir la bonne solution

Ressources

Site officiel : openebs.io
Documentation : openebs.io/docs
GitHub : github.com/openebs/openebs
Releases : github.com/openebs/openebs/releases
CNCF Landscape : landscape.cncf.io — OpenEBS