⚡ Storage Systems — Chapitre 35 : Indicateurs de performance

Première page de la Partie 11 — Performance et tuning. Ce chapitre couvre les indicateurs qui permettent de diagnostiquer, dimensionner et comparer un système de stockage : IOPS, latence, throughput, queue depth, block size, random vs sequential I/O, read/write mix, percentiles p95/p99, cache, CPU, réseau, saturation disque, fio, iostat, Windows PerfMon, VMware, bases de données, object storage, NAS, SAN, Kubernetes, cloud storage, performance vs capacité et checklist production.

IOPSLatence p99ThroughputQueue depthBlock sizeRandom vs sequential

35.1

IOPS

Opérations d’entrée/sortie par seconde : métrique centrale des workloads random, bases de données, VM et OLTP.

IOPSRandomOLTP

35.2

Latence

Temps de réponse d’une I/O : moyenne, p95, p99, tail latency, microsecondes/ms et impact utilisateur.

Latencyp99Response time

35.3

Throughput

Débit MB/s ou GB/s : métrique critique pour streaming, backup, restore, analytics, vidéo, IA et scans massifs.

ThroughputMB/sGB/s

35.4

Queue depth

File d’attente I/O : nombre d’opérations simultanées en vol, saturation, parallélisme et effet sur latence.

Queue depthParallelismSaturation

35.5

Block size

Taille des blocs : 4K, 8K, 64K, 1M. Influence IOPS, débit, amplification, cache et alignement.

4K8K64K1M

35.6

Random vs sequential I/O

Bases de données vs streaming : accès aléatoire petit bloc contre accès séquentiel gros bloc.

RandomSequentialPatterns

35.7

Read/write mix

Ratio lecture/écriture : 70/30, 50/50, write-heavy, read-heavy, cache hit et pénalité écriture.

ReadWriteMix

35.8

Percentiles p95/p99/p999

La moyenne ment : p95/p99/p999 révèlent la vraie expérience, les micro-bursts et la tail latency.

p95p99Tail

35.9

Cache hit ratio

DRAM, ARC, page cache, array cache, CDN/object cache : taux de hit, warm-up, eviction et pollution.

CacheHit ratioWarmup

35.10

CPU, checksum, compression, encryption

CPU côté hôte/storage : checksums, compression, dedupe, encryption, TLS, erasure coding et overhead.

CPUCompressionEncryption

35.11

Réseau storage

Ethernet, FC, RDMA, NVMe/TCP, iSCSI, NFS, SMB : latence, drops, retransmits, MTU, buffers.

NetworkFCRDMA

35.12

Utilisation disque et saturation

Utilisation disque, service time, await, busy, saturation queue, rebuild, scrub et noisy neighbors.

UtilizationBusySaturation

35.13

Benchmark fio

fio : outil de référence pour mesurer random/sequential, block size, iodepth, direct I/O et profiles réalistes.

fioBenchmarkProfiles

35.14

iostat, sar, vmstat

Outils Linux : iostat -x, sar, vmstat, pidstat, perf, blktrace et corrélation CPU/I/O.

iostatsarvmstat

35.15

PerfMon Windows

Performance Monitor : Disk sec/Read, Disk sec/Write, Queue Length, IOPS, throughput, CSV, Hyper-V.

PerfMonWindowsHyper-V

35.16

VMware / hyperviseurs

Datastore latency, device/kernel/guest latency, queueing, snapshots, vSAN, NFS/iSCSI/FC et VM noisy neighbors.

VMwareDatastorevSAN

35.17

Bases de données

Oracle, SQL Server, PostgreSQL, MySQL : log latency, datafile reads, checkpoint, WAL/redo, temp, random I/O.

DBWALRedo

35.18

Object storage performance

S3/object : request rate, multipart upload, object size, prefix distribution, latency, throughput, API calls.

S3ObjectsAPI

35.19

NAS performance

NFS/SMB : metadata ops, directory listing, locking, small files, oplocks, SMB multichannel, NFS nconnect.

NASNFSSMB

35.20

SAN performance

FC/iSCSI/NVMe-oF : multipathing, queue depth, HBA, zoning, LUN hot spots, ALUA et path imbalance.

SANMultipathHBA

35.21

Kubernetes storage metrics

PVC latency, CSI, storageclass, node pressure, pod I/O, local PV, Longhorn/Ceph/OpenEBS metrics.

K8sPVCCSI

35.22

Cloud storage metrics

EBS/Azure Disk/GCP PD, burst credits, provisioned IOPS, throughput caps, snapshots, multi-AZ, throttling.

CloudEBSThrottling

35.23

Performance vs capacité

Remplissage, fragmentation, garbage collection SSD, thin provisioning, dedupe dictionary, rebuild reserve et headroom.

CapacityHeadroomGC

35.24

Checklist performance storage

GO/NO-GO : workload profile, baseline, p99, saturation, network, cache, queue depth, restore, monitoring et capacity headroom.

ChecklistGO/NO-GOBaseline

35.1 IOPS

Définition opérationnelle

Opérations d’entrée/sortie par seconde : métrique centrale des workloads random, bases de données, VM et OLTP.

Point clé : la performance storage ne se résume jamais aux IOPS marketing. Elle dépend du profil I/O réel, de la latence p99, du débit, du parallélisme, du cache, du réseau, de la saturation et de la capacité restante.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.2 Latence

Définition opérationnelle

Temps de réponse d’une I/O : moyenne, p95, p99, tail latency, microsecondes/ms et impact utilisateur.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.3 Throughput

Définition opérationnelle

Débit MB/s ou GB/s : métrique critique pour streaming, backup, restore, analytics, vidéo, IA et scans massifs.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.4 Queue depth

Définition opérationnelle

File d’attente I/O : nombre d’opérations simultanées en vol, saturation, parallélisme et effet sur latence.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.5 Block size

Définition opérationnelle

Taille des blocs : 4K, 8K, 64K, 1M. Influence IOPS, débit, amplification, cache et alignement.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.6 Random vs sequential I/O

Définition opérationnelle

Bases de données vs streaming : accès aléatoire petit bloc contre accès séquentiel gros bloc.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.7 Read/write mix

Définition opérationnelle

Ratio lecture/écriture : 70/30, 50/50, write-heavy, read-heavy, cache hit et pénalité écriture.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.8 Percentiles p95/p99/p999

Définition opérationnelle

La moyenne ment : p95/p99/p999 révèlent la vraie expérience, les micro-bursts et la tail latency.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.9 Cache hit ratio

Définition opérationnelle

DRAM, ARC, page cache, array cache, CDN/object cache : taux de hit, warm-up, eviction et pollution.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.10 CPU, checksum, compression, encryption

Définition opérationnelle

CPU côté hôte/storage : checksums, compression, dedupe, encryption, TLS, erasure coding et overhead.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.11 Réseau storage

Définition opérationnelle

Ethernet, FC, RDMA, NVMe/TCP, iSCSI, NFS, SMB : latence, drops, retransmits, MTU, buffers.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.12 Utilisation disque et saturation

Définition opérationnelle

Utilisation disque, service time, await, busy, saturation queue, rebuild, scrub et noisy neighbors.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.13 Benchmark fio

Définition opérationnelle

fio : outil de référence pour mesurer random/sequential, block size, iodepth, direct I/O et profiles réalistes.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.14 iostat, sar, vmstat

Définition opérationnelle

Outils Linux : iostat -x, sar, vmstat, pidstat, perf, blktrace et corrélation CPU/I/O.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.15 PerfMon Windows

Définition opérationnelle

Performance Monitor : Disk sec/Read, Disk sec/Write, Queue Length, IOPS, throughput, CSV, Hyper-V.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.16 VMware / hyperviseurs

Définition opérationnelle

Datastore latency, device/kernel/guest latency, queueing, snapshots, vSAN, NFS/iSCSI/FC et VM noisy neighbors.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.17 Bases de données

Définition opérationnelle

Oracle, SQL Server, PostgreSQL, MySQL : log latency, datafile reads, checkpoint, WAL/redo, temp, random I/O.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.18 Object storage performance

Définition opérationnelle

S3/object : request rate, multipart upload, object size, prefix distribution, latency, throughput, API calls.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.19 NAS performance

Définition opérationnelle

NFS/SMB : metadata ops, directory listing, locking, small files, oplocks, SMB multichannel, NFS nconnect.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.20 SAN performance

Définition opérationnelle

FC/iSCSI/NVMe-oF : multipathing, queue depth, HBA, zoning, LUN hot spots, ALUA et path imbalance.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.21 Kubernetes storage metrics

Définition opérationnelle

PVC latency, CSI, storageclass, node pressure, pod I/O, local PV, Longhorn/Ceph/OpenEBS metrics.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.22 Cloud storage metrics

Définition opérationnelle

EBS/Azure Disk/GCP PD, burst credits, provisioned IOPS, throughput caps, snapshots, multi-AZ, throttling.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.23 Performance vs capacité

Définition opérationnelle

Remplissage, fragmentation, garbage collection SSD, thin provisioning, dedupe dictionary, rebuild reserve et headroom.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.

35.24 Checklist performance storage

Définition opérationnelle

GO/NO-GO : workload profile, baseline, p99, saturation, network, cache, queue depth, restore, monitoring et capacity headroom.

Chaîne de performance

Application→OS / FS→Queue→Network / Fabric→Controller→Media

Throughput ≈ IOPS × block size ; Latency observed = service time + queue time + transport time + application wait.

Composants à analyser

Composant	Rôle / explication
Workload profile	Random/sequential, read/write mix, block size, queue depth, concurrency, working set, burst pattern.
Host layer	Application, database, filesystem, volume manager, OS cache, driver, HBA/NIC, multipath.
Transport layer	FC, iSCSI, NVMe/TCP, RDMA, NFS, SMB, S3, latency réseau, packet loss, MTU, retransmits.
Storage layer	Controller, cache, CPU, SSD/HDD, RAID/EC, pool, snapshots, dedupe, compression, encryption, rebuild.
Metric layer	IOPS, latency p50/p95/p99, throughput, queue, utilization, error rate, saturation, tail latency.
Evidence	Baseline, benchmark reproductible, graphs, logs, configuration, change history et rapport avant/après tuning.

Cas d’usage

Diagnostiquer une base de données lente
Dimensionner une baie SAN/NAS/Object
Comparer SSD, NVMe, cloud disk et stockage distribué
Valider un POC constructeur ou cloud provider
Trouver un goulot réseau, CPU, cache, queue ou disque
Établir un baseline avant migration ou tuning

Workload profile→Baseline→Measure p99→Find bottleneck→Tune→Retest

Apports d’une bonne mesure

Permet de parler chiffres plutôt que ressenti
Relie application, OS, réseau et stockage
Met en évidence saturation et tail latency
Évite surdimensionnement ou mauvais achat
Rend les décisions POC auditables et reproductibles

Pièges fréquents

Benchmark synthétique non représentatif
Moyenne utilisée au lieu du p95/p99
Cache chaud qui masque la vraie performance
Queue depth artificiel qui gonfle les IOPS
Test sans mesurer réseau, CPU, application et rebuild

Matrice de décision performance

Question	Décision à prendre
Quel profil I/O réel ?	Random vs sequential, block size, read/write mix, concurrency, working set et durée des bursts.
Quelle métrique métier ?	Latency p99 pour OLTP, throughput pour backup/streaming, metadata ops pour NAS, API latency pour object.
Où est la saturation ?	Application, OS, queue, HBA/NIC, fabric, controller, media, CPU, cache, pool, snapshots ou cloud throttle.
Le test est-il représentatif ?	Cache warm/cold, durée suffisante, taille supérieure au cache, mixed workload, rebuild/snapshot inclus.
Quelle réserve ?	Headroom capacité/performance, rebuild reserve, failover reserve, croissance, burst credits cloud.
Quelle preuve ?	Graphes avant/après, commandes, versions firmware, config, horodatage, p95/p99 et conclusion GO/NO-GO.

Règle pratique : pour OLTP, la latence p99 compte souvent plus que les IOPS maximales ; pour streaming, le débit stable compte plus que le random 4K.

Runbook de mesure performance

Décrire workload : application, type I/O, block size, read/write mix, RPO/RTO, SLA p99.
Établir baseline hors incident : CPU, RAM, réseau, storage, queue, latency, throughput, erreurs.
Lancer test reproductible avec durée suffisante et taille de dataset supérieure au cache.
Mesurer côté application, OS, réseau/fabric et baie/cloud simultanément.
Identifier goulot : queue, CPU, cache miss, réseau, media, cloud throttle, snapshot, rebuild, noisy neighbor.
Appliquer un changement à la fois puis retester.
Documenter résultats, limites, headroom et GO/NO-GO.

# Linux performance baseline
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting
fio --name=seq1m --rw=read --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --time_based --runtime=300 --group_reporting
# Network / fabric checks
ss -ti
ethtool -S eth0
nstat
# Kubernetes
kubectl top pods -A
kubectl get pvc,pv,storageclass -A

NO-GO : benchmark court, cache-only, sans p99, sans mesure réseau/CPU, sans workload réel, ou sans test de saturation/rebuild/failover.