Ceph distribué ou SAN traditionnel : le vrai arbitrage

Ce débat revient régulièrement en architecture, souvent formulé comme un choix entre "le vieux monde" et "le cloud-native". Ce cadrage est mauvais et il mène à de mauvaises décisions.

Un SAN moderne (iSCSI, FC, ou NVMe-oF) et un cluster Ceph ne résolvent pas le même problème. Ils ont des profils de performance, des modes de défaillance, et des charges opérationnelles profondément différents. Ce qui compte, c'est de choisir en fonction de son contexte réel — pas d'une tendance.

Ce que le SAN garantit

Un SAN bien dimensionné offre des garanties que Ceph ne peut pas toujours matcher sans infrastructure significative.

Latence déterministe. Un SAN fibre ou NVMe-oF sur réseau dédié offre une latence sub-milliseconde, stable, prévisible. Cette prévisibilité est critique pour les bases de données à haute fréquence d'écriture, les plateformes Oracle, les applications de trading, ou tout ce qui est sensible aux variances de latence.

Simplicité opérationnelle et débogage. Quand un LUN ne répond plus sur un SAN, le périmètre de débogage est clair : le SAN, le fabric, l'initiateur. Le mode de défaillance est bien documenté, les outils de diagnostic sont matures, et l'expertise est disponible sur le marché.

Support éditeur clair. Les SAN d'entreprise (Pure Storage, NetApp AFF, HPE Nimble) viennent avec du support 24/7, des engagements contractuels de RTO, et des équipes d'escalade dédiées. Pour les infrastructures dont le stockage est une infrastructure critique, cet aspect a de la valeur.

Ce que Ceph offre

Ceph est une approche fondamentalement différente. C'est un système distribué, sans point central de défaillance, qui transforme des serveurs commodity en stockage objet, bloc, ou fichier.

Scalabilité horizontale. Extensible en ajoutant des nœuds. Pas de "uplift" éditeur pour passer à un tier supérieur. Pas de limite architecturale à l'échelle.

Pas de SPOF structurel. Le SAN a des contrôleurs. Même en mode actif-actif, une panne firmware peut affecter tout le cluster. Ceph n'a pas ce profil — la perte d'un OSD ou d'un nœud entier est absorbée par la réplication, dans les limites du facteur de réplication configuré.

Coût de commodité à grande échelle. Pour des clusters de petabyte-scale, le coût total d'un déploiement Ceph sur hardware commodity peut être significativement inférieur à un SAN équivalent. Mais ce calcul s'inverse souvent à petite échelle.

Intégration native avec Proxmox et OpenStack. Ceph s'intègre directement avec Proxmox VE comme backend RBD. Pas d'iSCSI intermédiaire, pas de couche de virtualisation supplémentaire. La VM a un accès direct au volume distribué.

La charge opérationnelle comparée

C'est ici que la réalité dépasse souvent les projections initiales.

Ceph demande de la compétence active. Tuning du pool, suivi des IOPS par OSD, gestion des rebalancings lors d'ajout/suppression de nœuds, compréhension du comportement de scrubbing en production... Un cluster Ceph sain, c'est une équipe qui le surveille, le comprend, et intervient de manière proactive.

Le syndrome courant : déployer Ceph en POC, être impressionné par les performances, passer en production, puis découvrir 6 mois plus tard que personne ne regarde les alertes HEALTH_WARN, que plusieurs OSDs sont dégradés, et que le cluster tourne avec un facteur de réplication effectif inférieur à ce qui était planifié.

Le SAN se gère de façon plus réactive. L'administrative burden quotidien est inférieur. Les alertes sont plus explicites. L'impact d'une anomalie est plus localisé. Mais cette simplicité a un coût matériel.

Quand le SAN reste le bon choix

Certains contextes sont clairement en faveur du SAN :

• Applications Oracle ou SQL Server avec workload intensif — les garanties de latence du SAN restent supérieures à ce qu'un cluster Ceph offre à iso-budget pour les workloads de type OLTP.
• Équipes sans expertise Linux/distributed systems — opérer Ceph sans base solide en systèmes distribués est risqué.
• Petits environnements (< 20 TB) — le seuil de rentabilité de Ceph vs SAN s'inverse rapidement à petite échelle. Le coût minimum d'un cluster Ceph viable (3 nœuds, suffisamment de disques) peut dépasser celui d'un SAN entry-level pour les mêmes capacités.
• Workloads Windows lourds avec DRS — le SAN en iSCSI ou Fibre Channel avec des LUNs dédiés reste plus flexible pour les environnements Windows-first.

Quand Ceph excelle

Ceph est le meilleur choix dans des contextes spécifiques :

• Infrastructure hyperconvergée Proxmox/OpenStack — c'est le cas d'usage pour lequel Ceph a été conçu. L'intégration est native, les outils de gestion sont intégrés.
• Volumétrie importante (> 100 TB) — au-delà d'un certain seuil, le coût du SAN devient difficilement justifiable face à du hardware commodity Ceph.
• Besoin de stockage objet (S3-compatible) — Ceph offre RGW (RADOS Gateway), une interface S3 native. Un SAN ne peut pas fournir du stockage objet directement.
• Équipe avec expertise Linux distribuée — si l'infra est gérée par des ingénieurs compétents en systèmes distribués, Ceph offre plus de contrôle et de flexibilité qu'un SAN propriétaire.

La maturité du débogage sous incident

C'est un critère rarement discuté dans les comparaisons techniques — et pourtant décisif lors d'un incident de production à 2h du matin.

Débogage SAN. Quand un LUN iSCSI ou FC disparaît, la chaîne de débogage est connue : initiateur → fabric → contrôleur SAN → vérification du zoning → vérification du mapping. Chaque étape est documentée, outillée, et la plupart des ingénieurs infra expérimentés ont traversé ce workflow. Les journaux sont structurés, les alertes sont explicites, et le périmètre d'impact est délimité.

Débogage Ceph. Un cluster Ceph dégradé peut se manifester de dizaines de façons différentes. HEALTH_WARN peut coexister avec des performances nominales pendant des semaines — puis basculer en HEALTH_ERR lors d'un rebuild mal planifié. Diagnostiquer pourquoi les IOPS d'une VM sont brutalement dégradées dans un cluster Ceph hyperconvergé demande de comprendre simultanément l'état des OSDs, le trafic réseau interne Ceph, la charge du nœud, et le facteur de réplication effectif.

Les domaines de défaillance

La comparaison des domaines de défaillance est une des analyses les plus importantes qui manque dans la plupart des discussions.

SAN enterprise. Le domaine de défaillance principal est le contrôleur. En configuration active-active avec des contrôleurs en miroir, la majorité des SANs modernes tolèrent la perte d'un contrôleur sans interruption. La panne d'un disk shelf peut être absorbée par la protection RAID du tier concerné. La défaillance simultanée de plusieurs composants est rare et généralement couverte par le support éditeur avec remplacement rapide.

Ceph. Ceph est conçu pour tolérer des pannes multiples — c'est sa force. Mais la tolérance dépend du facteur de réplication (minimum 3 pour survivre à la perte d'un nœud), de la distribution des PGs, et du nombre suffisant d'OSD actifs. Un cluster Ceph en configuration 3 nœuds avec replication=2 ne tolère pas la perte d'un nœud complet sans risque de perte de données. Et un cluster hyperconvergé où un nœud sous charge CPU prolongée ralentit l'accès aux OSDs qu'il héberge crée des dépendances entre les domaines de défaillance compute et storage.

L'impact des opérations de maintenance

La maintenance courante est un indicateur fiable de la charge opérationnelle réelle d'une infrastructure.

Maintenance SAN. Remplacement d'un disque défaillant : procédure documentée éditeur, 15-30 minutes, souvent hot-plug sans interruption. Upgrade firmware contrôleur : procédure de maintenance planifiée, généralement basculement sur le contrôleur actif pendant la mise à jour. Expansion capacité : ajout de shelf ou de disques selon les procédures éditeur. La prévisibilité est haute.

Maintenance Ceph. Remplacement d'un OSD défaillant déclenche un rebalancing automatique. Selon la taille du cluster et des données, ce rebalancing peut durer de quelques minutes à plusieurs heures, pendant lesquelles la résilience du cluster est réduite et les performances peuvent être affectées. L'upgrade d'un nœud Ceph complet impose de drainer ce nœud (procédure ceph osd noout, maintenance des OSDs), effectuer la mise à jour, et vérifier le retour à l'état HEALTH_OK avant de passer au nœud suivant. Pour un cluster de 6 nœuds, une mise à jour complète peut prendre une journée de travail.

Ce que Ceph n'est pas automatiquement

Il y a une tendance, dans les projets post-VMware, à présenter Ceph comme le storage distribué naturel de tout déploiement Proxmox. Ce n'est pas exact.

Ceph est le bon choix pour de nombreux contextes — mais ce n'est pas le bon choix par défaut. C'est une infrastructure complexe qui demande une équipe compétente, un dimensionnement sérieux, et une gouvernance opérationnelle active.

Les environnements qui bénéficient le plus de Ceph sont ceux où la volumétrie justifie la complexité (100+ TB), où l'équipe a une expertise systèmes distribués réelle, et où l'architecture hyperconvergée est un choix conscient et non une simplification par défaut.

Pour des clusters Proxmox de petite ou moyenne taille sans ces conditions, un storage NFS sur serveur dédié, ou un iSCSI ciblant un équipement storage plus simple, peut être une meilleure réponse — plus simple à opérer, plus facile à déboguer, et sans la charge cognitive de gérer un système distribué.

Là où le SAN reste opérationnellement plus solide

Pour être complet, les cas dans lesquels un SAN traditionnel bien configuré reste supérieur à Ceph en termes de fiabilité opérationnelle :

• Workloads OLTP latence-sensibles — Oracle RAC, SQL Server critique, applications ERP avec des IOPS de type random write intensif
• Équipes sans expertise Linux distribuée — dans ce contexte, le modèle de support éditeur SAN a plus de valeur que la flexibilité théorique de Ceph
• Environnements mixtes hyperviseurs — un SAN sert VMware, Proxmox, et des serveurs physiques sans complexité supplémentaire ; Ceph est Proxmox-natif pour son meilleur usage
• Infrastructures avec DR multisite existant sur réplication SAN — remplacer une réplication SAN établie par une architecture Ceph stretch cluster est un projet de refonte complet, pas un remplacement direct

Les critères de décision honnêtes

Un tableau comparatif ne remplace pas une analyse de contexte. La plupart des architectures complexes finissent par avoir les deux : du SAN pour les workloads Oracle/SQL critiques, et du Ceph pour les workloads de virtualisation généraliste. Ce n'est pas une faiblesse architecturale. C'est une réponse adaptée à des besoins hétérogènes.

Ce qui est une faiblesse, en revanche, c'est de choisir l'un ou l'autre sans avoir répondu aux quatre questions ci-dessus.