Aller au contenu

Performances : benchmark rados bench, fio, lecture des latences

Day 2 · ExploiterNiveau 3 · MaîtriserLabRédigé · à valider en lab

Ce lab vous apprend à mesurer les performances d'un cluster Ceph à trois niveaux (OSD, cluster RADOS, disque RBD vu par une VM) et à lire les latences pour repérer un disque ou un lien réseau défaillant. Vous en repartez avec une mesure de référence à conserver : c'est elle qui permettra, plus tard, de dire objectivement si « Ceph est lent ».

Jamais sur la production

Un benchmark sature volontairement les disques et le réseau : les VMs de production subiraient des latences de plusieurs secondes. Ce lab se fait sur un cluster de test ou sur le cluster de production avant sa mise en service, après accord du MSP. Une fois en production, seule la lecture des latences (étape 6) est autorisée.

Prérequis

  • Cluster Ceph de test de 3 nœuds (pve01 à pve03), en HEALTH_OK (Installer Ceph).
  • fio installé sur un nœud : apt install fio.
  • Une VM Linux de test (VMID 101) avec un disque sur ceph-vm, contrôleur VirtIO SCSI single, iothread et discard activés.

Objectifs

  1. Mesurer le débit brut de chaque OSD et repérer un disque plus lent que les autres.
  2. Mesurer le débit et les IOPS du cluster avec rados bench.
  3. Mesurer la latence d'écriture synchrone 4 K, l'indicateur qui compte pour les bases de données.
  4. Lire ceph osd perf et interpréter un OSD qui s'écarte des autres.

Scénario

1. Créer un pool de test dédié

pveceph pool create bench --size 3 --min_size 2 --pg_autoscale_mode on
ceph -s                                   # attendre active+clean

2. Tester chaque OSD isolément

for id in $(ceph osd ls); do echo -n "osd.$id "; ceph tell osd.$id bench | grep -E 'bytes_per_sec|iops'; done

Par défaut, ceph tell osd.N bench écrit 1 Gio en blocs de 4 Mio directement sur l'OSD, sans réseau ni réplication.

3. Débit du cluster avec rados bench

rados bench -p bench 60 write -b 4M -t 16 --no-cleanup   # écriture séquentielle 4 Mo, 16 requêtes parallèles
rados bench -p bench 60 seq -t 16                         # relecture séquentielle des objets écrits
rados bench -p bench 60 rand -t 16                        # relecture aléatoire
rados bench -p bench 30 write -b 4K -t 16 --no-cleanup   # petits blocs : IOPS et latence moyenne
rados -p bench cleanup                                    # supprimer les objets de test

Notez pour chaque test : Bandwidth (MB/sec), Average IOPS, Average Latency(s) et Max latency(s).

4. Disque RBD avec fio (moteur rbd, depuis un nœud)

rbd create bench/fio-test --size 10G
fio --name=lat-4k --ioengine=rbd --clientname=admin --pool=bench --rbdname=fio-test \
    --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --direct=1 --runtime=60 --time_based
fio --name=iops-4k --ioengine=rbd --clientname=admin --pool=bench --rbdname=fio-test \
    --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_based --group_reporting
rbd rm bench/fio-test

Si fio --enghelp ne liste pas rbd, passez directement à l'étape 5.

5. Ce que voit la VM

Dans la VM 101 :

fio --name=sync-4k --filename=/root/fio.test --size=4G --rw=randwrite --bs=4k \
    --iodepth=1 --direct=1 --fsync=1 --runtime=60 --time_based
rm /root/fio.test

Relevez la latence moyenne (clat avg) et les percentiles 99 et 99,9 (clat percentiles).

6. Lire les latences pendant la charge

Relancez le test de l'étape 3 dans un terminal et observez dans un autre :

ceph osd perf                 # commit_latency(ms) / apply_latency(ms) par OSD
ceph -s                       # ligne io: client débit et op/s
rbd perf image iotop          # images RBD les plus actives (module rbd_support du MGR)

GUI : nœud → Ceph → tableau de bord (graphes Reads, Writes, IOPS, Latency) ; VM → Summary pour les I/O de la VM.

7. Nettoyer

pveceph pool destroy bench

Archivez les résultats (date, version Ceph, matériel) dans votre documentation d'exploitation ou joignez-les au ticket de recette.

Questions

  1. Un OSD affiche dans ceph tell osd.N bench un débit deux fois inférieur aux autres. Que vérifiez-vous ?
  2. Pourquoi rados bench en blocs de 4 Mo donne-t-il un chiffre flatteur pour un usage VM ?
  3. Pourquoi le test fio iodepth=1 avec fsync=1 est-il le plus révélateur ?
  4. ceph osd perf montre un OSD à 80 ms quand les autres sont à 2 ms. Hypothèses et actions ?
  5. Le débit d'écriture rados bench plafonne autour de 1,1 Go/s quelle que soit la charge. Quelle piste ?
Corrigé
  1. Le modèle et le firmware du disque (smartctl -i), son état SMART (secteurs réalloués, usure), le contrôleur (disque derrière un RAID au lieu d'un HBA), et que ce n'est pas un SSD sans PLP glissé parmi des SSD entreprise. Un OSD lent ralentit tous les PG dont il est membre.
  2. Les gros blocs séquentiels mesurent le débit agrégé, que les SSD et le réseau délivrent facilement. Les VMs font surtout de petites I/O aléatoires où la latence domine.
  3. Une écriture 4 K synchrone, une à la fois, mesure le temps d'aller-retour complet : client, réseau, OSD primaire, répliques, acquittement. C'est ce que subit une base de données à chaque commit, et c'est là que les SSD sans PLP et un réseau lent se voient.
  4. Disque en fin de vie ou saturé, SSD sans PLP, problème de contrôleur, ou nœud surchargé (CPU, RAM, swap). Vérifier smartctl, journalctl -u ceph-osd@<id>, la charge du nœud ; si le disque est en cause, RB-03. Si tous les OSD d'un même nœud sont lents, suspecter le nœud ou son lien réseau.
  5. Environ 1,1 Go/s correspond à la limite pratique d'un lien 10 Gb/s : le réseau est le goulet. Vérifier la vitesse négociée (ethtool), le hash du bond (layer3+4) et le MTU (voir Réseaux Ceph).

Quand ouvrir un ticket iTop

Écart de plus de 30 % entre vos mesures et la référence de recette, un OSD durablement plus lent que les autres, latences VM en hausse sans changement de charge : P3 avec les sorties de ceph osd perf, ceph -s et vos résultats fio. Latences de plusieurs secondes et VMs qui gèlent : P2.

Ouvrir un ticket iTop

Pour aller plus loin