🏗️ Storage Systems — Chapitre 14 : Stockage hyperconvergé

• Datastore distribué ou storage pool.
• Policies par VM ou volume.
• Witness/quorum pour petits clusters ou stretched cluster.
• Cache tier et capacity tier selon solution.
• Resync/rebuild après panne ou maintenance.

vSAN agrège les disques locaux des hôtes ESXi en datastore distribué piloté par policies. Il est fort dans les environnements VMware existants, avec intégration vCenter, HA, DRS, snapshots et écosystème backup.

• ESA/OSA selon génération.
• Storage Policy Based Management.
• Stretched clusters possibles.
• Hardware Compatibility List critique.

Nutanix fournit une plateforme HCI complète : AHV, Prism, stockage distribué, services data, automatisation, intégration cloud hybride. Elle est souvent étudiée comme alternative VMware, surtout quand l'entreprise cherche une plateforme intégrée plutôt qu'un assemblage open source.

Storage Spaces Direct agrège des disques locaux Windows Server/Azure Local pour fournir du stockage hautement disponible à Hyper-V et workloads Microsoft. Le design réseau, RDMA, firmware et validation matériel sont déterminants.

L'HCI réduit le nombre de briques séparées : moins de baies SAN, moins de zoning FC, moins de LUN manuelles. L'administrateur pilote compute et stockage depuis une console unique ou presque.

• Ajouter un nœud augmente CPU, RAM et stockage.
• Le cluster rééquilibre les données.
• La capacité grandit par blocs standardisés.
• Les sites distants peuvent être déployés comme appliances.

L'HCI est souvent très proche de l'hyperviseur : policies par VM, snapshots, HA, live migration, DRS/placement, dashboards VM-level. Cela accélère l'exploitation quotidienne.

L'HCI promet la simplicité, mais cette simplicité vient souvent d'une forte intégration verticale : hyperviseur, stockage, management, licensing, support, backup ecosystem. Il faut anticiper la sortie avant d'entrer.

• Pas de réseau dédié ou QoS.
• Pas de backup externe.
• Capacité utile mal calculée.
• Cluster trop petit pour tolérer panne + maintenance.
• Hardware non certifié par la solution.

1. Inventorier VMs, dépendances, snapshots, RDM, datastores, VLAN, backup.
2. Classer workloads : garder, migrer, refactorer, retirer.
3. Créer landing zone cible.
4. Tester migration V2V sur lots non critiques.
5. Valider performance, backup, restore, supervision.
6. Planifier vagues par criticité.
7. Conserver rollback jusqu'à stabilisation.

Les petits clusters et stretched clusters utilisent souvent un witness pour éviter split-brain. Le witness ne stocke pas forcément les données complètes, mais porte des votes/metadata nécessaires à la décision.

• Définir ce que le cluster doit tolérer.
• Ne pas mettre toutes les copies dans le même nœud/rack.
• Dimensionner la capacité après panne.

• DB critique : policy performance, mirroring, faible latence.
• VDI : dedup/compression utile, attention boot storm.
• Archive VM : EC/RAID-5/6 si supporté.
• Infrastructure management : policy très résiliente.

• 10G minimum dans petits environnements ; 25G+ recommandé pour clusters modernes.
• Redondance switches et uplinks.
• MTU cohérent si jumbo frames.
• QoS ou séparation de trafic.
• Mesurer latence, drops, retransmits.

iperf3 -c node02
ethtool -S eth0
ss -ti
mtr node02
sar -n DEV 1
# côté plateforme : vérifier latency datastore, resync, dropped packets

Le cluster doit continuer à fonctionner après perte d'un nœud et idéalement pendant maintenance. N+1 signifie capacité et performance suffisantes malgré une perte. N+2 ajoute une marge pour panne + maintenance.

• Combien de VM et quelle croissance 24 mois ?
• Ratio vCPU/pCPU et RAM overcommit ?
• Profil I/O : random, sequential, write heavy ?
• Snapshots et rétention ?
• FTT/RAID policies ?
• Fenêtre rebuild acceptable ?

Une VM très intensive peut impacter les autres via CPU, disque, cache ou réseau. Les outils QoS, reservations, limits, storage policies et observabilité par VM sont essentiels.

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

# Toujours mesurer côté VM + hyperviseur + datastore

• HCI HA locale ≠ PRA complet.
• Réplication distante nécessaire pour site perdu.
• Runbook failover/failback.
• Tests réguliers.

Les clusters HCI regroupent hyperviseur, drivers, firmware, stockage distribué et management. Le patching doit suivre une matrice de compatibilité et un rolling upgrade contrôlé.

La sortie VMware ne signifie pas tout basculer en Kubernetes. Les bonnes migrations séparent : VMs à déplacer, apps à moderniser, données à garder, services à retirer.

Proxmox + Ceph est une option sérieuse pour organisations capables d'opérer Linux, KVM, réseau et Ceph. Le coût licence peut être attractif, mais le coût compétence et support doit être budgété.

OpenShift/ODF est pertinent pour modernisation applicative et Kubernetes enterprise. Il ne remplace pas automatiquement un parc VMware traditionnel sans refonte partielle des applications.

1. Vérifier cluster healthy.
2. Vérifier capacité de resync et policy compliance.
3. Mettre nœud en maintenance selon procédure.
4. Appliquer firmware/patch.
5. Sortir maintenance.
6. Attendre resync complet avant nœud suivant.

• Capacity high.
• Policy non-compliance.
• Resync stuck.
• Disk group degraded.
• Witness unreachable.
• VM latency spike.

• Combien de VMs et quels SLA ?
• Quelle équipe opérera jour 2 ?
• Quelle dépendance backup actuelle ?
• Quel budget renouvellement 3-5 ans ?
• Faut-il remplacer VMware ou moderniser applications ?

1. Identifier disque/groupe.
2. Vérifier policy compliance.
3. Remplacer disque certifié.
4. Surveiller rebuild/resync.
5. Valider retour healthy.

1. Stopper créations/snapshots non critiques.
2. Identifier VMs/snapshots volumineux.
3. Libérer capacité validée ou ajouter nœud/disques.
4. Ne pas supprimer à l'aveugle.

1. Comparer VM latency, datastore latency, network latency.
2. Vérifier resync/rebuild.
3. Identifier noisy neighbor.
4. Vérifier cache tier et disk groups.
5. Vérifier drops réseau.

• Backup externe immuable.
• Test restore VM complet.
• Plan DR site.
• Runbook failover/failback.
• Snapshots locaux non considérés comme backup.

• Monitoring VM/datastore/network.
• Alertes capacity/resync/witness.
• RBAC admin.
• Upgrade plan.
• Documentation nœuds, disques, firmwares.

• Inventaire VM et dépendances.
• Classification workloads.
• POC migration V2V.
• Validation backup sur cible.
• Plan rollback.
• Fenêtres de migration par vagues.