01Le modèle Ceph en cinq minutes
- MON (moniteurs) : gardent la carte du cluster et arbitrent le quorum Ceph. Trois exemplaires, sur trois noeuds différents. Cinq sur les grandes plateformes.
- MGR (gestionnaires) : exposent les métriques et l'interface. Deux suffisent, un actif et un en attente.
- OSD : un démon par disque, qui stocke réellement les données.
- Pools : des espaces logiques, avec un facteur de réplication et un nombre de groupes de placement.
- CRUSH : l'algorithme qui décide ou vont les copies, en fonction de la topologie déclarée.
Ce qu'il faut retenir : Ceph ne fait aucun compromis sur la cohérence. Si les conditions de sécurité ne sont plus réunies, il bloque les écritures plutôt que de risquer une perte. La plupart des incidents Ceph perçus comme des pannes sont en réalité ce comportement de protection, déclenche par un manque de marge.
02Déploiement sur Proxmox VE
# sur chaque noeud pveceph install --repository no-subscription # une seule fois, sur le premier noeud : les deux réseaux sont distincts pveceph init \ --network 10.10.3.0/24 \ --cluster-network 10.10.4.0/24
# sur trois noeuds pveceph mon create # sur deux noeuds pveceph mgr create # un OSD par disque, sur chaque noeud pveceph osd create /dev/nvme0n1 pveceph osd create /dev/nvme1n1 # état général ceph -s ceph osd tree
Le réseau cluster-network porte la réplication entre OSD. Le déclarer sur le
même lien que le réseau public double la charge sur ce lien pendant les reconstructions.
C'est le moment où la plateforme est la plus fragile, et donc le pire moment pour saturer.
03Pools, réplication et groupes de placement
pveceph pool create vm-data \ --size 3 \ --min_size 2 \ --pg_autoscale_mode on \ --application rbd \ --add_storages 1
- size 3 et min_size 2 : trois copies, écriture autorisée tant qu'il en reste deux. C'est la seule configuration raisonnable en production.
- Jamais size 2 et min_size 1. Cette combinaison économise du disque et garantit une perte de données le jour ou une seconde défaillance survient pendant une reconstruction. Ce jour arrive.
- Codage par effacement : pertinent pour de l'archivage ou de la sauvegarde, rarement pour des disques de machines virtuelles, dont le profil d'accès s'y prête mal.
- Groupes de placement : laissez l'ajustement automatique actif. Si le
pool a une taille cible connue, renseignez
target_size_ratiopour éviter des rééquilibrages successifs pendant la montée en charge.
Ajoutez également un CephFS pour les images ISO, les modèles de conteneurs et les extraits de configuration. Cela rend ces ressources disponibles depuis tous les noeuds.
pveceph fs create --name cephfs --add-storage 1
04Domaine de défaillance et classes de périphériques
Par défaut, CRUSH place les copies sur des hôtes différents. C'est le bon choix dans une seule baie. Si les noeuds sont répartis sur plusieurs baies ou plusieurs salles, déclarez cette topologie pour que la perte d'une baie entière ne fasse pas disparaître les trois copies.
ceph osd crush add-bucket baie-a rack
ceph osd crush move baie-a root=default
ceph osd crush move pve-01 rack=baie-a
# puis une règle dont le domaine de défaillance est la baie
ceph osd crush rule create-replicated par-baie default rack nvme
ceph osd pool set vm-data crush_rule par-baie
Les classes de périphériques permettent de séparer les technologies. Ceph
détecte automatiquement les classes nvme, ssd et hdd,
et une règle peut cibler une classe précise.
ceph osd crush rule create-replicated rapide default host nvme ceph osd crush rule create-replicated volume default host hdd ceph osd pool set vm-data crush_rule rapide ceph osd pool set archives crush_rule volume
05Réglages d'exploitation
Marge de capacité
Ceph déclenche un avertissement à 85 % de remplissage et bloque les écritures à 95 %. Ces seuils sont des filets de sécurité, pas des objectifs. La vraie limite est la capacité à reconstruire après la perte d'un noeud : sur trois noeuds, la perte d'un noeud répartit ses données sur les deux restants. Au-delà de 70 à 75 % d'occupation, cette reconstruction risque de saturer les OSD survivants.
Nettoyage et vérification
Le scrub vérifie l'intégrité des données. Utile, mais coûteux en entrées-sorties. Cantonnez le nettoyage approfondi aux heures creuses.
ceph config set osd osd_scrub_begin_hour 22 ceph config set osd osd_scrub_end_hour 6 ceph config set osd osd_max_scrubs 1 ceph config set osd osd_scrub_load_threshold 0.5
Pendant les opérations de maintenance
# avant l'arrêt ceph osd set noout ceph osd set norebalance # après le retour du noeud et le retour à HEALTH_OK ceph osd unset norebalance ceph osd unset noout
Oublier de retirer noout. Le cluster semble parfaitement sain, mais un OSD
réellement défaillant ne sera jamais remplacé automatiquement. Cet oubli mérite une alerte
dédiée, prévue au chapitre 06.
06Quand préférer ZFS et la réplication
Ceph n'est pas toujours le bon outil. Sur deux ou trois noeuds modestes, sans réseau à 10 Gb/s dédié, ZFS local avec la réplication intégrée de Proxmox VE donne souvent un meilleur résultat.
| Critère | Ceph | ZFS et réplication |
|---|---|---|
| Perte de données en cas de panne | Nulle | Jusqu'à l'intervalle de réplication |
| Bascule automatique | Immédiate | Possible, avec retour arrière |
| Réseau requis | 10 à 25 Gb/s dédié | 1 Gb/s suffit souvent |
| Noeuds minimum | 3 | 2 |
| Capacité utile | Un tiers du brut | Selon le niveau RAIDZ |
| Complexité d'exploitation | Élevée | Faible |
pvesr create-local-job 101-0 pve-02 --schedule "*/15" --rate 100 pvesr status
La question n'est pas technique mais contractuelle : quelle perte de données le service peut-il accepter. Si la réponse est zéro, il faut Ceph et le réseau qui va avec. Si quinze minutes sont tolérables, ZFS coûte beaucoup moins cher à l'achat comme à l'exploitation.
Un cluster a batir, a auditer ou a reprendre en main
Nous concevons, deployons et exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Nous formons aussi vos equipes, notamment dans le cadre des migrations depuis VMware.