Vue d’ensemble

Stockage distribué (dans le contexte de nos serveurs)

Qu'est-ce que le stockage distribué?

Le stockage distribué consiste à répartir les données sur plusieurs serveurs physiques de manière transparente. Au lieu d'avoir un seul serveur dédié au stockage, tous les disques de tous les serveurs participent à un pool commun, géré comme s'il s'agissait d'une seule ressource.

Ceph

Ceph est une plateforme de stockage distribué open-source qui unifie tous les disques de nos différents serveurs physiques en un seul système de stockage cohérent.

Ceph vs RAID — Quelle différence?

Pour comprendre l'intérêt de Ceph, il faut d'abord comprendre le RAID traditionnel :

RAID (Redundant Array of Independent Disks) est une technologie qui regroupe plusieurs disques dans un même serveur pour obtenir redondance et/ou performance. Les types courants :

• RAID 0 — Striping pur. Les données sont réparties en blocs sur tous les disques. Performance maximale, zéro redondance. Un seul disque en panne = perte totale.

• RAID 1 — Mirroring. Chaque donnée est écrite deux fois (sur deux disques). Redondance totale, mais 50% de l'espace est "perdu" en copie.

• RAID 5 — Striping avec parité distribuée. 3 disques minimum. Tolère la panne d'un seul disque. Bon compromis performance/espace/redondance.

• RAID 6 — Comme RAID 5, mais avec deux blocs de parité. Tolère la panne de deux disques simultanément.

• RAID 10 — Combinaison de RAID 1 + RAID 0. Mirroring ET striping. Redondant et performant, mais coûteux en espace.

La limite fondamentale du RAID : il est local à un serveur. Si le serveur lui-même tombe en panne (alimentation, carte mère, incendie), toutes les données sont inaccessibles, peu importe la configuration RAID.

Ceph résout ce problème en distribuant les données entre plusieurs serveurs :

Avec Ceph, chaque objet de données est répliqué (par défaut 3 copies) sur des serveurs distincts. Si un serveur entier disparaît, les données restent accessibles via les autres nœuds, et Ceph se répare automatiquement en re-répliquant les données manquantes.

Architecture Ceph en bref

Ceph repose sur quelques composants clés :

• OSD (Object Storage Daemon) — Un processus par disque physique. Il stocke les données, gère la réplication, et communique avec les autres OSDs.

• MON (Monitor) — Maintient la "carte" du cluster (le cluster map). Minimum 3 monitors pour la haute disponibilité.

• MGR (Manager) — Collecte les métriques, expose les dashboards, gère les modules de monitoring.

• CRUSH Algorithm — L'algorithme qui décide où placer les données dans le cluster. Il garantit une distribution uniforme et permet de définir des règles de placement (ex : « ne jamais mettre deux copies sur le même rack »).

Les trois interfaces de Ceph

Ceph expose le même cluster de stockage via trois interfaces distinctes selon les besoins.

Ceph Block Device (RBD)

Le Ceph Block Device (RBD — RADOS Block Device) présente le stockage Ceph comme un disque virtuel, identique à un disque dur classique du point de vue du système d'exploitation.

Comment ça fonctionne : RBD découpe un "volume" en petits objets (généralement 4MB) distribués dans le cluster. L'OS ou l'hyperviseur voit simplement un périphérique bloc /dev/rbd0.

Cas d'usage typiques :

• Disques de machines virtuelles (KVM, Proxmox, OpenStack)

• Volumes persistants dans Kubernetes via le driver CSI de Ceph

• Base de données nécessitant un stockage bloc rapide

Avantages : snapshots, redimensionnement à chaud, réplication intégrée.

Ceph File System (CephFS)

Le Ceph File System est un système de fichiers POSIX complet distribué — c'est-à-dire qu'il se monte comme un dossier classique (mount -t ceph) et supporte toutes les opérations de fichiers standard.

C'est ce que nous utilisons dans nos clusters Kubernetes.

Rook

Rook est l'opérateur Kubernetes qui gère notre cluster Ceph. Au lieu de configurer Ceph manuellement, Rook permet de déclarer l'état souhaité du stockage en YAML, comme n'importe quelle autre ressource Kubernetes.

Rook s'occupe de :

• Déployer et configurer les MONs, MGRs, et OSDs en tant que pods

• Gérer les mises à jour et la récupération après panne

• Exposer CephFS via des StorageClass Kubernetes

• Gérer le driver CSI pour provisionner des PersistentVolumeClaims

Flux typique dans nos clusters :

1. Un pod Kubernetes demande un PersistentVolumeClaim avec notre StorageClass CephFS

2. Le CSI driver de Rook/Ceph crée un sous-répertoire ou un volume CephFS

3. Le volume est monté dans le pod — le pod voit un dossier normal

4. Les données sont distribuées et répliquées automatiquement dans le cluster Ceph sous-jacent

Pourquoi CephFS plutôt que RBD pour Kubernetes? CephFS supporte le mode ReadWriteMany (RWX) — plusieurs pods sur plusieurs nœuds peuvent monter le même volume en lecture/écriture simultanément. RBD est limité à ReadWriteOnce (un seul nœud à la fois).

Ceph Object Storage (S3 / RADOS Gateway)

Le RADOS Gateway (RGW) expose le stockage Ceph via une API compatible S3 (et Swift). C'est l'équivalent d'un AWS S3 auto-hébergé.

Interface : HTTP/HTTPS avec les mêmes appels API que S3 (PUT, GET, DELETE sur des buckets/objets).

Cas d'usage typiques :

• Backups applicatifs

• Stockage de fichiers statiques, assets

• Archivage de logs

• Tout ce qu'on mettrait normalement dans un bucket S3

Vue dans proxmox

Object Storage (principalement pour les backups)

Object Storage (principalement pour les backups)

Nous utilisons deux solutions de stockage objet, suivant la règle 3-2-1 : une copie primaire on-premise et une copie distante hors site. pour plus d’info → Backups

• Garage HQ — Serveur object storage open-source auto-hébergé, compatible API S3. C'est notre destination primaire pour les backups.

• Backblaze B2 — Service cloud compatible S3. Sert de copie distante (offsite) pour protéger contre une perte physique au HQ.

Bases de données (pour des déploiements)

Nous hébergeons plusieurs bases de données pour différents déploiements.

SQL

Nous préférons offrir des bases de données CNPG (CloudNativePG) pour les déploiements qui nécessitent une base relationnelle. CNPG est un opérateur Kubernetes qui gère le cycle de vie complet d'un cluster PostgreSQL (failover, backups, réplicas).

Nous devons parfois déployer MySQL ou MariaDB lorsqu'une application l'exige et qu'elle ne supporte pas PostgreSQL.

NoSQL

Pareillement, certaines applications nécessitent du NoSQL — nous hébergeons des bases de données MongoDB dans ces cas.

Cache

Pour la mise en cache, nous déployons Redis/Valkey

Amélioration Continue

Points Positifs

• Stockage distribué avec Ceph élimine les points de défaillance unique au niveau serveur

• Utilisations de S3 pour backups (Garage HQ + Backblaze offsite)

• CephFS via Rook permet le mode ReadWriteMany pour les workloads Kubernetes qui en ont besoin

• PostgreSQL (CNPG) comme standard pour les bases relationnelles — opérateur mature avec failover et backups intégrés

• Infrastructure majoritairement gérée en YAML/Kubernetes (Rook, CNPG), ce qui la rend reproductible et versionnable

• Usage exact de Ceph RBD dans Proxmox pour les VMs

• …

Points à améliorer

• Utilisations de Ceph S3 pour les volumes, possible amélioration

• MySQL/MariaDB et MongoDB déployés via Helm charts ou docker image sans opérateur dédié — moins de HA et de gestion automatisée comparé à CNPG

• Redis/Valkey déployé mais pourrait être analyser leur performance et même CNPG permet de faire de la cache

• Meilleur utilisation de S3 pour des déploiements si ceux-ci le supporte (avoir les données sur garage HQ par S3 au lieu de ceph pour certaines choses comme des fichiers binaires…)

• Faire des analyses de vitesses et de débit d’écriture et lecture et quels outils nous permettrait de le faire

• Pour possiblement améliorer la rapidité des bases de données, avoir leur storage directement sur un SSD par serveur au lieu de passer par Ceph FS.