Avec VMware Cloud Foundation (VCF) 9.1, Broadcom introduit une évolution importante dans la gestion de la résilience des données au sein de VMware vSAN Express Storage Architecture (ESA) : Auto-RAID.
Jusqu’à présent, les administrateurs VMware devaient définir les niveaux de protection des données au travers des politiques de stockage (Storage Policy Based Management – SPBM), en tenant compte du nombre d’hôtes, de la topologie du cluster et des contraintes de capacité.
Avec Auto-RAID, cette logique évolue. vSAN détermine automatiquement le niveau de protection adapté à chaque cluster et ajuste ce niveau lorsque sa configuration change.
L’objectif est de simplifier l’exploitation, de réduire les erreurs de configuration et d’optimiser l’utilisation de la capacité de stockage.
Mais derrière cette automatisation se cache un changement intéressant dans la manière de concevoir et d’administrer les infrastructures vSAN.
1. Auto-RAID : qu’est-ce qui change avec vSAN 9.1 ?
Auto-RAID est une fonctionnalité introduite dans vSAN ESA avec VCF 9.1, permettant au système de gérer automatiquement les paramètres de résilience des objets de stockage.
Auparavant, le niveau de protection était principalement défini à travers les politiques de stockage associées aux machines virtuelles, notamment :
- Le nombre de défaillances tolérées (Failures To Tolerate – FTT).
- Le type de protection RAID-1, RAID-5 ou RAID-6.
- Les contraintes liées à la topologie et au nombre d’hôtes disponibles.
Avec Auto-RAID, vSAN détermine lui-même la configuration de protection appropriée, selon les caractéristiques de chaque cluster.
Cette approche s’appuie sur une politique commune, vSAN ESA Auto-RAID Policy, capable de s’adapter à différentes topologies.
Il devient ainsi possible d’utiliser une seule politique de stockage pour plusieurs clusters présentant des caractéristiques différentes, sans devoir créer une politique spécifique pour chaque configuration.
De Auto-Policy Management à Auto-RAID
Broadcom avait déjà introduit Auto-Policy Management avec vSAN 8 Update 1 pour simplifier la gestion des politiques de stockage sur ESA.
Cette fonctionnalité permettait notamment de générer une politique adaptée aux caractéristiques d’un cluster.
Cependant, elle restait basée sur le modèle classique des politiques de stockage.
Auto-RAID va plus loin : il ne se contente pas de proposer une politique optimale, il prend en charge l’application et l’adaptation des paramètres de résilience.
Cette évolution marque le passage d’une configuration administrée individuellement à une gestion davantage pilotée par le système.
2. Comment Auto-RAID détermine-t-il le niveau de protection ?
Le fonctionnement repose principalement sur la topologie du cluster et le nombre d’hôtes disponibles.
Pour un cluster vSAN ESA standard, hébergé sur un seul site, Broadcom définit les règles suivantes :
| Nombre d’hôtes | Niveau de protection | Technologie | Surcoût de capacité |
|---|---|---|---|
| 1 à 2 hôtes | FTT=0 | Aucune redondance locale | 1,0x |
| 3 à 5 hôtes | FTT=1 | RAID-5 (2+1) | 1,5x |
| 6 hôtes ou plus | FTT=2 | RAID-6 | 1,5x |
Cette logique permet à vSAN d’adapter automatiquement la résilience en fonction de la taille du cluster.
Prenons l’exemple d’un cluster vSAN ESA comportant initialement quatre hôtes.
Auto-RAID applique une protection FTT=1 en RAID-5.
Si l’infrastructure évolue vers six hôtes, vSAN peut automatiquement faire évoluer la protection vers FTT=2 en RAID-6, afin de tolérer deux défaillances d’hôtes dans les conditions prévues.
Ce mécanisme évite de devoir modifier manuellement les politiques de stockage à chaque évolution de la topologie.
Une approche orientée efficacité de stockage
Un point particulièrement intéressant concerne le surcoût de capacité.
Avec Auto-RAID, Broadcom annonce un facteur de 1,5x pour les clusters standards utilisant RAID-5 ou RAID-6.
Autrement dit, pour 100 To de données logiques avant déduplication et compression, l’overhead de protection correspond théoriquement à environ 150 To de capacité physique consommée par les objets.
Ce ratio ne tient pas compte des autres réservations et surcoûts d’exploitation du cluster.
L’utilisation du RAID-5 ou du RAID-6 dépend néanmoins de la topologie et des ressources disponibles.
Il ne faut donc pas interpréter cette automatisation comme une garantie de capacité utilisable identique sur tous les clusters.
3. Auto-RAID dans les Stretched Clusters et les clusters 2 nœuds
Auto-RAID ne se limite pas aux clusters traditionnels.
Il prend également en charge les architectures étendues (Stretched Clusters) et les topologies à deux nœuds.
Stretched Clusters : une résilience automatisée à deux niveaux
Dans une architecture vSAN Stretched Cluster, la protection des données repose historiquement sur deux mécanismes complémentaires :
- PFTT (Primary Failures To Tolerate) : protection intersites permettant de tolérer la perte d’un site grâce au mirroring RAID-1.
- SFTT (Secondary Failures To Tolerate) : protection locale permettant de tolérer des défaillances d’hôtes au sein de chaque site, selon le niveau de résilience configuré.
Avec Auto-RAID dans vSAN ESA 9.1, cette logique reste inchangée sur le plan architectural, mais le choix des niveaux de protection devient automatique.
| Hôtes par site | Protection intersites (PFTT) | Protection locale (SFTT) | Overhead |
|---|---|---|---|
| Moins de 3 | PFTT=1, RAID-1 | SFTT=0 | 2,0x |
| 3 à 5 | PFTT=1, RAID-1 | SFTT=1, RAID-5 (2+1) | 3,0x |
| 6 ou plus | PFTT=1, RAID-1 | SFTT=2, RAID-6 | 3,0x |
Pour les objets nécessitant une protection intersites, Auto-RAID maintient le mirroring RAID-1 et adapte automatiquement la résilience locale au nombre d’hôtes par site.
Les concepts PFTT et SFTT restent donc pertinents, mais leur configuration est désormais prise en charge par vSAN pour les objets utilisant Auto-RAID.
Cette automatisation simplifie la gestion des politiques SPBM sans supprimer la nécessité de concevoir correctement les domaines de défaillance, le dimensionnement des sites et les mécanismes de quorum.
Clusters 2 nœuds
Pour les architectures vSAN à deux nœuds, Auto-RAID utilise une protection par mirroring RAID-1 entre les hôtes, avec un facteur de capacité de 2,0x.
Cependant, la résilience secondaire au sein de chaque hôte n’est pas prise en charge par Auto-RAID dans VCF 9.1.
Cette limitation doit être prise en compte dans les architectures nécessitant des niveaux de protection spécifiques.
4. Une seule politique de stockage pour plusieurs clusters
L’un des changements les plus intéressants d’Auto-RAID concerne la simplification du modèle SPBM.
Avec VCF 9.1, une politique commune nommée vSAN ESA Auto-RAID Policy peut être utilisée pour plusieurs clusters vSAN ESA, indépendamment de leur taille et de leur topologie.
Le système détermine les paramètres de résilience appropriés pour chaque environnement.
Prenons l’exemple d’une infrastructure comprenant :
- Un cluster de quatre hôtes sur un site principal.
- Un cluster de huit hôtes sur un autre site.
- Un Stretched Cluster réparti entre deux datacenters.
La même politique Auto-RAID peut conduire à des configurations de protection différentes :
| Cluster | Protection appliquée |
|---|---|
| Cluster standard de 4 hôtes | RAID-5, FTT=1 |
| Cluster standard de 8 hôtes | RAID-6, FTT=2 |
| Stretched Cluster | Mirroring intersites et protection locale adaptée |
Il n’est donc plus nécessaire de multiplier les politiques de stockage uniquement pour gérer les différents niveaux de résilience de chaque cluster.
Cette simplification présente un intérêt particulier dans les environnements VMware mutualisés disposant de plusieurs clusters vSAN.
Les paramètres spécifiques restent disponibles
Auto-RAID ne supprime pas toute possibilité de personnalisation.
Il reste possible de créer des politiques spécifiques utilisant Auto-RAID tout en définissant certains paramètres propres aux workloads, notamment :
- Les limites d’IOPS.
- Les réservations de capacité (Object Space Reservation).
- La localité des objets dans un Stretched Cluster.
En revanche, les paramètres de résilience sont désormais déterminés par le système pour les objets placés sous Auto-RAID.
Cette distinction est importante : Auto-RAID simplifie la gestion de la protection, mais ne remplace pas l’ensemble des mécanismes SPBM.
5. Auto-RAID et Effective Capacity : une évolution complémentaire
Broadcom introduit également avec vSAN pour VCF 9.1 une nouvelle vue de capacité appelée Effective Capacity.
Historiquement, l’analyse de la capacité vSAN nécessitait de tenir compte de plusieurs facteurs :
- La capacité brute disponible.
- Le type de protection RAID utilisé.
- Le niveau de résilience FTT.
- Les gains liés à la compression et à la déduplication.
- Les réservations et les marges nécessaires au fonctionnement du cluster.
La nouvelle vue Effective Capacity vise à présenter une capacité réellement exploitable, plutôt qu’une capacité brute nécessitant des calculs supplémentaires.
Elle permet notamment de mieux visualiser la capacité utilisée, la capacité restante et les gains d’efficacité du stockage.
L’utilisation d’Auto-RAID constitue un prérequis pour bénéficier de cette nouvelle vue de capacité dans vSAN 9.1.
En standardisant les niveaux de protection au sein d’un cluster, Auto-RAID simplifie les calculs de capacité et leur interprétation.
Pour les équipes d’architecture et de Capacity Management, cette évolution peut faciliter les exercices de dimensionnement, de prévision de croissance et d’analyse des consommations.
6. Activation et migration vers Auto-RAID
Broadcom distingue deux situations.
Nouveaux clusters vSAN ESA sous VCF 9.1
Auto-RAID est activé par défaut sur les nouveaux clusters.
La politique de stockage commune est utilisée pour déterminer automatiquement les paramètres de résilience.
Clusters existants mis à niveau vers VCF 9.1
Les clusters existants conservent leurs politiques de stockage précédentes après la mise à niveau.
L’adoption d’Auto-RAID nécessite donc une action spécifique.
Deux approches sont possibles.
Option 1 : appliquer la politique vSAN ESA Auto-RAID
Cette méthode consiste à modifier la politique par défaut du datastore vSAN puis à appliquer la politique Auto-RAID aux objets concernés.
Elle constitue l’approche privilégiée par Broadcom pour simplifier durablement la gestion des politiques.
Option 2 : activer « Apply Auto-RAID to all objects »
Cette option permet d’appliquer le comportement Auto-RAID à l’ensemble des objets du cluster, même lorsque des politiques historiques restent associées aux machines virtuelles.
Elle facilite certaines transitions, mais conserve des dépendances aux anciennes politiques.
Attention : la désactivation ultérieure de cette option peut entraîner une reconfiguration des objets selon leurs anciennes politiques.
Impact potentiel sur les opérations de resynchronisation
L’activation d’Auto-RAID ne provoque pas systématiquement un déplacement massif de données.
Lorsque la configuration de protection existante correspond déjà à celle attendue par Auto-RAID, une simple modification des métadonnées peut suffire.
En revanche, un changement de niveau de protection, par exemple de RAID-1 vers RAID-5, peut nécessiter une reconfiguration des objets et générer du trafic de resynchronisation.
Broadcom prévoit des mécanismes de régulation pour limiter l’impact sur les workloads en production.
Néanmoins, l’activation d’Auto-RAID sur un cluster existant doit être considérée comme une opération de changement à préparer et à superviser, notamment pour les environnements critiques.
7. Quels impacts pour l’architecture et l’exploitation vSAN ?
Au-delà de la simplification administrative, Auto-RAID introduit plusieurs évolutions importantes.
Une réduction de la complexité SPBM
La multiplication des politiques de stockage spécifiques aux clusters peut compliquer l’administration, notamment dans les infrastructures de grande taille.
Une politique commune permet de réduire cette complexité et de limiter les erreurs de configuration.
Une résilience adaptée à l’évolution des clusters
L’ajout ou le retrait d’hôtes peut conduire Auto-RAID à ajuster automatiquement le niveau de protection.
Cependant, cette adaptation doit rester intégrée aux processus de Capacity Management et de gestion des changements.
Une modification de topologie peut avoir un impact sur les niveaux de protection, la capacité consommée et les opérations de resynchronisation.
Une meilleure prévisibilité des capacités
La standardisation des niveaux de protection facilite l’analyse de la capacité et le dimensionnement des infrastructures.
Elle devient particulièrement intéressante lorsqu’elle est associée à la nouvelle vue Effective Capacity.
Une automatisation qui ne remplace pas le design d’architecture
C’est probablement le point le plus important.
Auto-RAID automatise le choix et l’application des paramètres de résilience, mais il ne remplace pas les décisions d’architecture concernant :
- Le dimensionnement du cluster.
- Les domaines de défaillance.
- La disponibilité des ressources et les réservations de capacité.
- Les contraintes réseau et les performances de stockage.
- Les architectures multisites et les objectifs de continuité d’activité.
L’automatisation de la résilience ne dispense donc pas d’une architecture correctement dimensionnée et adaptée aux exigences des applications.
Conclusion
Avec Auto-RAID, VMware vSAN ESA franchit une nouvelle étape dans l’automatisation de la gestion du stockage.
Introduite avec VCF 9.1, cette fonctionnalité permet à vSAN de déterminer et de maintenir automatiquement les niveaux de résilience adaptés à la topologie des clusters.
Elle apporte plusieurs bénéfices : simplification des politiques SPBM, adaptation automatique aux évolutions des clusters, meilleure prévisibilité de la consommation de stockage et intégration avec la nouvelle vue Effective Capacity.
Pour les équipes d’exploitation, elle réduit les interventions manuelles et les risques d’erreurs liés à la configuration des politiques de stockage.
Pour les architectes infrastructure, elle constitue surtout une évolution dans la manière de concevoir les services de stockage vSAN.
Il reste néanmoins essentiel de maîtriser ses règles de fonctionnement, ses limitations et ses impacts potentiels lors de la migration des clusters existants.
Auto-RAID automatise la résilience des données, mais ne remplace pas les principes fondamentaux d’une architecture de stockage robuste, dimensionnée et maîtrisée.
Sources
VMware / Broadcom
