Meilleures pratiques RAID pour VMware : meilleures pratiques RAID VMware et conception du stockage

Choisir la bonne configuration RAID, c'est super important pour VMware ESXi. Le RAID influence la vitesse d'exécution de tes machines virtuelles, la sécurité de tes données et la facilité avec laquelle tu peux récupérer tes données en cas de panne de disque. Tous les niveaux RAID ne se valent pas : certains privilégient la vitesse, d'autres la redondance, et d'autres encore essaient de trouver un équilibre entre les deux.

Cet article explique quelles options RAID fonctionnent le mieux pour VMware, quels compromis il faut prévoir et comment adapter les niveaux RAID à votre charge de travail.

Résumé : comment le RAID affecte la stabilité et les performances de VMware

1. 1. Les performances de VMware dépendent d'une latence prévisible, et pas d'un débit maximal. Les charges de travail ESXi ont besoin de temps de réponse constants ; les pics ou les retards déstabilisent les clusters plus vite que la bande passante brute ne peut le compenser.
2. 2. Le choix du RAID a un impact direct sur le comportement des machines virtuelles.

• De mauvais niveaux RAID déclenchent des événements d'étourdissement des machines virtuelles en cas d'E/S intensives.
• Ils ralentissent les opérations de snapshot, ce qui nuit à la sauvegarde et à la restauration.
• Ils prolongent les temps de reconstruction, exposant les clusters à des pannes de disque en cascade.

1. 3. Un RAID inadapté détruit les clusters plus rapidement que les pénuries de CPU ou de RAM. Les goulots d'étranglement informatiques sont récupérables, contrairement au stockage instable. Le RAID est la base de la stabilité de VMware.

Comment VMware ESXi utilise vraiment le stockage

E/S aléatoires, pas de charges de travail séquentielles

• VMFS génère des lectures et des écritures aléatoires mixtes.

Le système de fichiers de machine virtuelle (VMFS) de VMware est conçu pour héberger plusieurs machines virtuelles en même temps. Chaque machine virtuelle émet ses propres requêtes d'E/S indépendantes, qui se combinent pour former un modèle hautement aléatoire. Contrairement aux charges de travail traditionnelles qui diffusent des lectures/écritures séquentielles, le stockage ESXi voit un accès fragmenté sur de nombreux petits blocs.

• Les snapshots multiplient l'amplification d'écriture.

Quand les instantanés sont actifs, chaque écriture est redirigée via la logique de copie à l'écriture. Ça veut dire qu'une seule écriture sur une machine virtuelle peut déclencher plusieurs opérations en arrière-plan : mise à jour des métadonnées, écriture de nouveaux blocs et conservation des anciens. Plus tu empiles d'instantanés, plus l'amplification est importante, ce qui augmente la latence et sollicite le RAID de parité.

• Les bases de données et les VDI pénalisent le RAID parité.

Les charges de travail des bases de données et les environnements d'infrastructure de bureau virtuel (VDI) génèrent constamment de petites écritures aléatoires. Sur RAID 5/6, chaque écriture nécessite un calcul de parité et plusieurs opérations sur le disque. Cette surcharge transforme le RAID de parité en un goulot d'étranglement, provoquant des retards imprévisibles et une dégradation de la réactivité des machines virtuelles.

Pourquoi la cohérence de la latence est plus importante que les IOPS

• La planification ESXi dépend du temps de réponse du stockage.

Le planificateur de CPU de VMware s'attend à ce que le stockage réponde dans des délais prévisibles. Si la latence du disque augmente, l'hyperviseur bloque l'exécution de la VM, ce qui entraîne des pauses ou des événements « stun ». Même des IOPS élevés ne sont d'aucune utilité si la latence est inégale.

• Les reconstructions RAID provoquent des pics de latence qui déclenchent des pauses des machines virtuelles.

Quand un disque tombe en panne, les reconstructions RAID inondent la baie de calculs de parité et d'E/S en arrière-plan. Ça entre en concurrence avec le trafic des VM, ce qui introduit des retards imprévisibles. Dans le RAID de parité, les reconstructions peuvent durer des heures ou des jours, pendant lesquels les pics de latence perturbent à plusieurs reprises la planification des VM. Résultat : les VM se figent, les snapshots échouent et le cluster devient instable.

Les charges de travail VMware ESXi sont aléatoires, sensibles à la latence et gourmandes en instantanés. Les niveaux RAID qui reposent sur la parité (RAID 5/6) ont du mal dans ces conditions, tandis que les conceptions basées sur la mise en miroir ou la mise en miroir par bandes (RAID 1, RAID 10) offrent la latence prévisible dont VMware a besoin.

Meilleure configuration RAID pour VMware par type de charge de travail

Hôtes de virtualisation à usage général

RAID 10 comme norme de base.

Pour les charges de travail mixtes, RAID 10 offre la combinaison la plus équilibrée entre performances, sécurité de reconstruction et latence prévisible.

Pourquoi le RAID 10 fonctionne ici :

• Le striping améliore le débit pour les machines virtuelles qui lisent beaucoup.
• La mise en miroir garantit des reconstructions rapides et minimise les temps d'arrêt après des pannes de disque.
• La latence reste constante, ce qui évite les événements d'étourdissement des machines virtuelles courants avec le RAID de parité.

Le RAID 10 devrait être le choix par défaut pour les clusters ESXi généraux où la diversité des charges de travail exige avant tout de la stabilité.

Bases de données et machines virtuelles transactionnelles

RAID 10 uniquement.

Les bases de données et les systèmes transactionnels génèrent des écritures aléatoires importantes. Le RAID 5/6 introduit une surcharge de parité qui ralentit les opérations de validation et la gestion des instantanés.

Pourquoi le RAID parité ne marche pas ici :

• Chaque écriture nécessite plusieurs opérations sur le disque pour le calcul de la parité.
• La consolidation des instantanés devient super lente avec le RAID parité.
• Les pics de latence perturbent la cohérence des transactions et la planification des machines virtuelles.

Le RAID 10 élimine les pénalités de parité, garantissant des performances fiables pour les charges de travail transactionnelles critiques.

Environnements VDI et VM haute densité

RAID 10 ou RAID 6 avec un cache important et une hiérarchisation SSD.

Les pics de démarrage VDI et l'activité VM haute densité génèrent des E/S aléatoires massives. Le RAID 10 reste l'option la plus sûre, mais le RAID 6 peut être viable s'il est associé à une mise en cache de niveau entreprise et à une accélération SSD.

Exigences pour le RAID 6 dans le VDI :

• Cache d'écriture important pour absorber les écritures aléatoires.
• Hiérarchisation SSD pour décharger les données chaudes et réduire la surcharge de parité.
• Protection du cache par batterie pour éviter la perte de données en cas de coupure de courant.

Le RAID 10 est préférable, mais le RAID 6 peut être acceptable dans les déploiements sensibles au coût si la mise en cache et la hiérarchisation SSD sont correctement mises en œuvre.

Niveaux RAID pour VMware ESXi : ce qui marche et ce qui ne marche pas

RAID 10 : le choix le plus sûr de VMware

• Reconstruction rapide. Les paires en miroir permettent une récupération rapide après une panne de disque, ce qui réduit les temps d'arrêt.
• Latence prévisible. Le striping répartit les E/S sur les disques, tandis que la mise en miroir évite la surcharge de parité, garantissant des temps de réponse constants.
• Résiste aux pannes de disque pendant la charge. Le RAID 10 peut tolérer plusieurs pannes de disque (une par ensemble de miroirs) sans que le datastore ne s'effondre, ce qui permet de garder les machines virtuelles stables même en cas de forte charge.
• Conclusion : le RAID 10 est la référence absolue pour VMware ESXi, offrant un équilibre entre performances, résilience et fiabilité.

RAID 5 — acceptable uniquement dans des scénarios limités

• Charges de travail avec beaucoup de lectures. Le RAID 5 peut offrir des performances correctes lorsque les charges de travail sont principalement des lectures avec un minimum d'écritures aléatoires.
• Contrôleurs flash. La mise en cache des écritures peut masquer les pénalités de parité, mais seulement avec des contrôleurs de niveau entreprise.
• Petit nombre de machines virtuelles. Avec une concurrence limitée, le RAID 5 peut être viable, mais la mise à l'échelle révèle rapidement ses faiblesses.
• Conclusion : le RAID 5 est un compromis. Utilisez-le uniquement pour les charges de travail légères, centrées sur la lecture, où les économies réalisées l'emportent sur les risques.

RAID 6 : la capacité avant la performance

• VM d'archivage. Convient pour le stockage à froid ou les machines virtuelles rarement utilisées.
• Référentiels de sauvegarde. Convient aux banques de données secondaires où le débit importe moins que la capacité.
• Les longs délais de reconstruction augmentent les risques. La double parité protège contre deux pannes de disque, mais les reconstructions sont lentes et les pics de latence peuvent paralyser les machines virtuelles.
• Conclusion : le RAID 6 vise à maximiser l'espace, pas les performances. Évitez-le pour les charges de travail de production avec des E/S intensives.

RAID 0 — jamais pour les banques de données ESXi

• Pas de tolérance aux pannes. Le RAID 0 offre de la vitesse, mais aucune redondance.
• Une seule panne de disque détruit le VMFS. Un disque défaillant efface tout le magasin de données, emportant avec lui toutes les machines virtuelles.
• Conclusion : le RAID 0 n'est pas acceptable pour VMware ESXi. Il ne convient qu'aux laboratoires de test où la perte de données n'a pas d'importance.

Comportement de reconstruction RAID et risque VMware

Pourquoi les reconstructions RAID perturbent les clusters VMware

• Les pics de latence provoquent un blocage des machines virtuelles.

Pendant une reconstruction, les disques sont saturés par les E/S en arrière-plan. VMware ESXi dépend d'une latence prévisible ; lorsque les temps de réponse augmentent, l'hyperviseur met les machines virtuelles en pause, ce qui entraîne des événements de blocage et une dégradation des performances.

• Les snapshots peuvent échouer.

La création et la consolidation des instantanés nécessitent des performances d'écriture stables. La charge de reconstruction perturbe ces opérations, provoquant des échecs d'instantanés ou des temps de consolidation prolongés qui ont un impact sur les workflows de sauvegarde et de restauration.

• Les événements HA augmentent.

VMware High Availability (HA) considère les pauses prolongées des VM comme des échecs. Les pics de latence pendant les reconstructions peuvent déclencher des redémarrages HA inutiles, ce qui aggrave l'instabilité du cluster.

Règles de conception pour survivre aux reconstructions

• Limitez la taille des disques.

Les gros disques rallongent les temps de reconstruction, augmentant ainsi la fenêtre de risque. Les disques plus petits de qualité professionnelle réduisent la durée de la reconstruction et minimisent l'exposition.

• Optez pour un RAID basé sur la mise en miroir.

Les RAID 10 et RAID 1 se reconstruisent plus vite et avec moins d'impact sur la latence par rapport au RAID parité. La mise en miroir évite les calculs de parité, ce qui permet de garder une latence prévisible pendant la récupération.

• Gardez des disques de secours.

Les reconstructions automatiques vers les disques de secours réduisent le temps passé par les baies en mode dégradé. Ça diminue le risque d'une deuxième panne de disque et stabilise les charges de travail VMware pendant la récupération.

Mauvaises configurations RAID entraînant une perte de données

Pannes courantes dans la réalité

• RAID 5 avec de gros disques SATA.

L'utilisation du RAID 5 avec des disques SATA de plusieurs téraoctets entraîne des temps de reconstruction trop longs. Le risque d'une deuxième panne de disque pendant la reconstruction est élevé, ce qui conduit souvent à la perte complète de la matrice.

• RAID 6 sous une charge d'écriture importante.

Même si le RAID 6 protège contre deux pannes de disque, sa charge de parité s'effondre sous des écritures aléatoires continues. Dans les environnements VMware, ça provoque des pics de latence, des événements d'étourdissement des machines virtuelles et, au final, la corruption du datastore.

• Extension des matrices sans sauvegardes.

Ajouter des disques ou étendre des groupes RAID sans sauvegarde vérifiée, c'est prendre des risques. Des erreurs de contrôleur ou des interruptions de reconstruction pendant l'extension peuvent détruire instantanément les volumes VMFS.

Scénarios de corruption VMFS

• Coupure de courant pendant la reconstruction.

Si l'alimentation est coupée au milieu de la reconstruction, les calculs de parité incomplets laissent la baie dans un état incohérent. Les métadonnées VMFS sont particulièrement vulnérables, ce qui entraîne une corruption irrécupérable.

• Bugs du micrologiciel du contrôleur.

Un micrologiciel de contrôleur RAID obsolète ou instable peut mal gérer les reconstructions ou les écritures de parité. Ces erreurs silencieuses se manifestent souvent sous forme de corruption VMFS longtemps après l'événement initial.

• Remplacement incomplet du disque.

Remplacer un disque défectueux de manière incorrecte, ou avec un micrologiciel/une géométrie incompatible, peut perturber le contrôleur RAID. Ça entraîne des reconstructions partielles, une parité brisée et des banques de données VMware corrompues.

Considérations relatives aux pannes et à la récupération du RAID VMware

Quand VMware ne peut plus monter VMFS

• Métadonnées RAID endommagées.

Si les métadonnées RAID sont corrompues ou perdues, le contrôleur ne peut plus présenter un ensemble cohérent à VMware. Les volumes VMFS deviennent inaccessibles, même si la plupart des disques sont intacts.

• Disposition des bandes incohérente.

Les ensembles de bandes mal alignés ou partiellement reconstruits perturbent la couche de stockage de VMware. ESXi s'attend à un mappage de blocs prévisible ; lorsque les bandes sont incohérentes, VMFS ne peut pas se monter et l'accès aux données échoue.

• Dommages causés par une reconstruction partielle.

Les reconstructions interrompues ou incomplètes laissent les matrices dans un état dégradé. VMware interprète ça comme un stockage corrompu, empêchant VMFS de se monter et risquant une perte permanente des données.

Options de RAID Recovery

• Reconstruction RAID au niveau logiciel avant réparation physique.

Des outils spécialisés peuvent reconstruire les matrices RAID de manière logique, en contournant les erreurs du contrôleur. C'est souvent plus sûr que d'essayer d'abord de réparer le matériel.

• Exemple : DiskInternals RAID Recovery.

Des outils comme DiskInternals peuvent détecter les paramètres RAID, reconstruire virtuellement les matrices et récupérer les volumes VMFS sans toucher aux disques sources.

• Détection manuelle des paramètres RAID.

Quand les métadonnées sont perdues, les paramètres RAID (taille de bande, ordre, disposition de parité) doivent être identifiés manuellement. Une détection correcte permet la reconstruction virtuelle de la matrice.

• Récupération des volumes VMFS.

Une fois le RAID reconstruit, les structures VMFS peuvent être analysées et restaurées. Ça permet d'accéder aux fichiers de la machine virtuelle même si la matrice d'origine est inutilisable.

• Opération en lecture seule sur les disques sources.

La récupération doit toujours être effectuée en mode lecture seule pour éviter toute corruption supplémentaire. Les disques sources doivent rester intacts jusqu'à ce que les données soient extraites en toute sécurité.

Liste de contrôle de conception RAID pour les administrateurs VMware

Avant le déploiement

• Définissez le profil d'E/S de la charge de travail.

Vérifie si les charges de travail sont aléatoires ou séquentielles, si elles sont plutôt en lecture ou en écriture. Ça permet de s'assurer que le RAID choisi correspond bien aux besoins réels de VMware.

• Choisissez le RAID pour la sécurité de la reconstruction, pas pour la capacité.

Donnez la priorité aux reconstructions prévisibles et à la stabilité de la latence plutôt qu'à l'optimisation de l'espace utilisable. RAID 10 devrait être la base par défaut pour ESXi.

• Vérifiez la protection du cache du contrôleur.

Assurez-vous que le cache d'écriture est alimenté par batterie ou protégé par flash. Sans protection du cache, le RAID de parité risque de perdre des données en cas de coupure de courant.

Avant la production

• Teste les scénarios de panne de disque.

Simule la perte d'un disque et mesure l'impact de la reconstruction sur la latence des machines virtuelles. Vérifie que les charges de travail restent stables dans des conditions dégradées.

• Vérifiez les restaurations de sauvegarde.

Fais des tests de restauration complète à partir des sauvegardes pour vérifier les chemins de récupération. Le RAID seul ne remplace pas l'intégrité vérifiée des sauvegardes.

• Documentez la configuration RAID.

Note la taille des bandes, l'ordre des disques et les paramètres du contrôleur. La documentation accélère la récupération en cas de défaillance du contrôleur ou de reconstruction de la matrice.