🖥️ Storage Systems — Chapitre 15 : Stockage pour hyperviseurs

Sur SAN bloc, ESXi utilise des chemins multiples vers les LUN. Les policies comme Round Robin, Fixed ou Most Recently Used dépendent du type de baie et des recommandations constructeur.

• Vérifier tous les chemins actifs/standby.
• Valider ALUA et preferred paths.
• Surveiller datastore latency et path failover.
• Aligner firmware HBA/driver/array.

• VADP/CBT pour backup agentless.
• Snapshots VMware courts, jamais rétention longue.
• Application-aware backup pour DB/AD.
• Immutable repository externe.
• Test restore VM complet et fichiers.

# ESXi shell examples
esxcli storage filesystem list
esxcli storage core path list
esxcli storage nmp device list
esxtop  # storage views : d/u/v
vmkfstools -P /vmfs/volumes/datastore1

Hyper-V supporte les VMs stockées sur partages SMB3 si la plateforme fournit continuous availability, SMB Multichannel, permissions correctes et réseau adapté.

• SMB Multichannel pour débit/résilience.
• SMB Direct/RDMA si disponible.
• Kerberos et permissions constrained delegation si nécessaire.
• Monitoring latency côté host et file server.

Storage Spaces Direct agrège des disques locaux entre nœuds Windows Server/Azure Local. Il fournit une architecture HCI Microsoft avec resiliency, tiers, cache et volumes partagés.

Get-ClusterSharedVolume
Get-VMHardDiskDrive -VMName VM01
Get-VHD -Path "C:\ClusterStorage\Volume1\VM01\disk.vhdx"
Get-StoragePool
Get-PhysicalDisk
Get-ClusterNode

• Checksums, snapshots, compression.
• Très bon pour serveur standalone ou petits clusters avec réplication.
• Exige RAM, disques fiables, scrub.
• Attention sync writes et SLOG pour certains workloads.

zpool status
zfs list
pvesm status
qm config 100

Ceph intégré à Proxmox permet un stockage distribué partagé. Il facilite HA et migration, mais demande réseau, monitoring, capacity headroom et compétences Ceph.

ceph -s
ceph osd tree
pveceph status
rbd ls -p vm-pool

Proxmox Backup Server fournit sauvegarde dédupliquée, incrémentale, vérification, chiffrement et restauration fine. C'est presque indispensable pour une production Proxmox sérieuse.

• cache=none : souvent recommandé pour éviter double cache.
• cache=writeback : performant mais risques si mal protégé.
• io=native ou io_uring selon versions.
• discard/unmap pour thin provisioning.

virsh pool-list --all
virsh vol-list default
virsh domblklist vm01
qemu-img info disk.qcow2
qemu-img convert -O raw disk.qcow2 disk.raw
virtio-scsi + discard/unmap for thin reclaim

La migration live est simple avec stockage partagé ; en shared-nothing, il faut copier le disque pendant la migration, ce qui augmente durée, réseau et risque de rollback.

Xen Orchestra/XOA fournit backup, delta backup, continuous replication selon édition/configuration, orchestration et visibilité des pools. Les tests de restauration restent essentiels.

xe sr-list
xe vdi-list sr-uuid=
xe pbd-list
xe vm-disk-list vm=
xe sr-scan uuid=

• Ne jamais juger un stockage VM uniquement au débit séquentiel.
• La latence p95/p99 est plus révélatrice que la moyenne.
• Snapshots longs dégradent performance et augmentent risque.
• Un datastore full est un incident critique.
• Tester restore avant de valider le design.

• Local si la simplicité et la latence locale priment.
• Shared si HA/live migration indispensable.
• Distributed si scale-out/HCI souhaité.
• Object pour backups, archives, images, pas datastores transactionnels.

• Thin économise capacité au départ mais risque datastore full.
• Thick est plus prévisible mais consomme immédiatement.
• Lazy/eager zeroing impacte préparation/performance selon plateforme.
• Surveiller provisioned vs used.

# KVM examples
qemu-img info disk.qcow2
qemu-img convert -p -O raw disk.qcow2 disk.raw
qemu-img convert -p -O qcow2 disk.raw disk.qcow2

# Toujours valider boot, drivers, UUID, fstab, bootloader après migration

• Durée courte.
• Nommer avec raison et date.
• Surveiller consolidation.
• Vérifier espace datastore.
• Ne pas snapshoter une DB critique sans cohérence applicative.

Pour obtenir une cohérence applicative, l'hyperviseur ou l'outil backup demande au guest de flusher filesystem et applications. Sous Windows, VSS coordonne writers ; sous Linux, on utilise agents, scripts ou fsfreeze selon cas.

• Veeam : très présent sur VMware/Hyper-V/Nutanix/Proxmox selon versions.
• Proxmox Backup Server : déduplication, incrémental, vérification.
• Xen Orchestra/XOA : backups XCP-ng/Xen.
• Restic/Borg agents : complément fichiers/applications.

1. Tester restore VM complète.
2. Tester restore fichier.
3. Tester restore applicatif DB/AD.
4. Mesurer RTO/RPO réel.
5. Documenter procédure et écarts.

• vMotion nécessite réseau rapide et compatibilité CPU.
• Storage vMotion déplace VMDK entre datastores.
• HA nécessite datastores accessibles ou vSAN conforme.

• Hyper-V Live Migration avec CSV/SMB/S2D ou shared-nothing.
• Proxmox migration live plus simple avec stockage partagé/Ceph.
• Local storage demande réplication ou déplacement disque.

# Dans une VM de test uniquement
fio --name=vm-randrw --filename=/data/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=120 --group_reporting

# Corréler guest latency + hypervisor latency + backend metrics

• Réseau stockage séparé ou QoS stricte.
• Redondance switches/uplinks.
• MTU cohérent bout-en-bout.
• Surveiller drops, retransmits, latency.
• Ne pas mélanger backup massif et storage critique sans contrôle.

iperf3 -c storage01
ping -s 8972 -M do storage01
ethtool -S eth0
ss -ti
mtr storage01

Les clés de chiffrement, credentials backup, access keys S3 et comptes hyperviseurs doivent être gérés comme secrets critiques, pas stockés dans scripts en clair.

• Garder VM pour legacy stable.
• Moderniser apps candidates containers.
• Séparer storage VM et storage pods si SLO différents.
• Tester backup/restore des deux mondes.

• Combien d'hôtes ?
• Live migration obligatoire ?
• Quel outil backup ?
• Quelle latence p99 acceptable ?
• Quel budget 3-5 ans ?
• Quelle compétence interne ?

1. Identifier VM et chaîne snapshot.
2. Vérifier espace datastore.
3. Éviter reboot sauvage.
4. Lancer consolidation selon plateforme.
5. Valider backup récent avant action risquée.

1. Comparer plusieurs VMs/datastores.
2. Vérifier path down ou réseau storage.
3. Vérifier backup/rebuild/resync en cours.
4. Identifier noisy neighbor.
5. Corréler backend metrics.

1. Définir point de restauration.
2. Restaurer isolé si possible.
3. Valider boot et application.
4. Basculer réseau/DNS.
5. Documenter RTO/RPO.

• Backup externe immuable.
• Test restore VM complet.
• Application-aware pour DB/AD.
• RPO/RTO mesurés.
• Repository isolé des admins hyperviseur si possible.

• Runbook datastore full.
• Runbook snapshot bloqué.
• Runbook path down.
• Procédure upgrade hyperviseur/storage.
• Inventaire VMs/datastores/backends.