🧠 Storage Systems — Chapitre 11 : Software-Defined Storage

Le SDS devient puissant quand il est piloté par API : Terraform, Ansible, Kubernetes CSI, opérateurs, workflows CI/CD, politiques de classes de stockage.

# Examples of automation targets
- create storage class
- provision volume
- create snapshot
- expand PVC
- replicate dataset
- apply retention policy
- rotate keys

• Répliquer données on-prem vers cloud.
• Utiliser API S3-compatible entre sites.
• Fournir un stockage homogène aux applications Kubernetes.
• Créer des politiques de placement selon coût, performance et conformité.

Le scale-out exige une stratégie de placement : copies réparties sur nœuds, racks, zones, avec rebalance automatique après ajout/retrait.

L'hyperconvergence intègre stockage et compute : chaque nœud apporte CPU/RAM/disques. Elle simplifie le déploiement d'un cluster VM ou Kubernetes, mais impose de dimensionner simultanément compute, stockage, réseau et licences.

• Ne jamais placer toutes les copies sur le même hôte.
• Éviter plusieurs copies dans le même rack si le rack est un failure domain.
• Prévoir la capacité disponible après perte d'un nœud.

• Maturité de l'équipe ops.
• Support entreprise nécessaire ou non.
• Type de service : bloc, fichier, objet.
• Performance attendue et latence p99.
• Intégration Kubernetes/VMware.
• Stratégie backup/DR.

Le SDS peut réduire le coût matériel, mais il transfère une partie du coût vers l'ingénierie, le monitoring, l'automatisation et l'exploitation.

• Linux storage.
• Réseau datacenter.
• Observabilité Prometheus/Grafana.
• Kubernetes/CSI si cloud-native.
• Runbooks incident et drills.

CRUSH calcule où placer les données sans table centrale massive. Il tient compte des failure domains : host, rack, room, zone. C'est le cœur de la distribution Ceph.

ceph -s
ceph health detail
ceph osd tree
ceph osd df
ceph pg stat
ceph df
rados df
ceph orch ps

• Une DB dans Kubernetes exige un stockage prévisible et backup applicatif.
• Snapshots CSI doivent être cohérents avec l'application.
• Les opérateurs DB gèrent souvent réplication et failover au-dessus du SDS.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-rbd
provisioner: rbd.csi.ceph.com
parameters:
  pool: kubernetes
  imageFeatures: layering
reclaimPolicy: Delete
allowVolumeExpansion: true

• Déploiement plus simple qu'un SAN séparé.
• Scalabilité par nœuds.
• Intégration hyperviseur.
• Bon pour ROBO, PME, clusters VM.

• Scaling compute et storage parfois couplé.
• Réseau est critique.
• Licences/support peuvent être élevés.
• Réparation/rebalance impacte production.

Les gateways rendent un backend distribué compatible avec des protocoles clients standards. Elles ajoutent une couche à monitorer : saturation CPU, latence, auth, logs, TLS.

• DB transactionnelle : bloc rapide ou local + réplication.
• Partage multi-pods : fichier RWX.
• Archive/data lake : objet S3.
• VM datastore : bloc ou HCI validé.

• Réseau storage séparé ou QoS stricte.
• Redondance switches et liens.
• MTU cohérent bout-en-bout si jumbo frames.
• Monitoring drops, errors, retransmits.
• Tester perte de lien et switch reboot.

iperf3 -c node02
ethtool -S eth0
ss -ti
ping -f node02
mtr node02
sar -n DEV 1

L'erasure coding découpe les données en fragments data + parity. Il améliore le rendement capacité au prix de CPU, latence et complexité de recovery.

• Scrub détecte incohérences et bit rot.
• Self-heal réplique à nouveau après panne.
• Backfill/rebalance consomme réseau et disques.
• Full cluster empêche parfois healing correct.

# fio block workload example
fio --name=randrw --filename=/mnt/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=120 --group_reporting

# Ceph examples
rados bench -p pool 60 write --no-cleanup
rados bench -p pool 60 seq

• Séparer HDD/SSD/NVMe dans classes/pools.
• Choisir replication vs EC selon latency/capacity.
• Éviter sur-commit capacité.
• Contrôler recovery throttling.
• Optimiser clients et mount options.

• Exporter metrics cluster et nœuds.
• Dashboards Grafana par service.
• Alertes health, capacity, latency, degraded.
• Corrélation réseau/disque/CPU.

Le SDS peut servir plusieurs équipes ou clients. Il faut isoler buckets, pools, namespaces, quotas, policies, clés et métriques.

Pour les services objet, WORM/Object Lock protège backups et archives contre suppression ou chiffrement ransomware.

• Création/suppression volumes.
• Modification policies.
• Accès admin.
• Suppression snapshots.
• Accès bucket public ou policy dangereuse.

• Quel protocole : bloc, fichier, objet ?
• Quelle latence p99 attendue ?
• Quelle équipe opérera le cluster ?
• Quel support 24/7 ?
• Quelle stratégie backup/DR ?

1. Stopper ingestion non critique.
2. Identifier pools/buckets volumineux.
3. Ajouter capacité ou supprimer données validées.
4. Vérifier snapshots/versions.
5. Surveiller retour à état healthy.

1. Comparer clients, cluster, réseau, disques.
2. Vérifier recovery/rebalance en cours.
3. Identifier hot node/hot pool.
4. Vérifier drops/retransmits réseau.
5. Throttle recovery si nécessaire.

1. Lire release notes et matrice compatibilité.
2. Backup configs.
3. Vérifier health parfait avant upgrade.
4. Upgrade rolling par nœud.
5. Valider métriques et clients après chaque étape.

• Runbooks testés.
• Upgrade procedure validée.
• Restore drill périodique.
• Inventaire disques/nœuds.
• Support et escalade documentés.

• RBAC admin.
• Segmentation réseau.
• Chiffrement selon criticité.
• Audit actions sensibles.
• Secrets stockés proprement.