VMware vSAN 7.0

Parmi les nouveautés de vSAN:

• Gestion de cycle de vie simplifié: fiabilité et réduction du nombre d’outil
• Service de fichier natif: Gestion unifiée de stockage block et fichier
• Stockage Cloud natif: expansion de service de données pour plus de use cases

vSphere Lifecycle Manager (vLCM)

Le traditionnel vSphere Update Manager (VUM) se voit remplacé par vLCM pour une gestion de cycle de vie complète. Une nouvelle approche qui consiste de ne plus permettre la mise à niveau des hosts, mais plutôt la mise à niveau des clusters. VMware se rapproche des constructeurs hardware afin de permettre l’intégration de pilotes et firmware matériels.

Service de fichier intégré géré depuis vCenter:

Le service de fichier permet l’approvisionnement des file shares depuis le cluster vSAN. Il supporte le NFS v3 et v4.1, le quotas , et adapté au workloads Cloud natif (Persistent volume) et traditionnel.

L’intégration continue du stockage cloud natif sur vSphere et vSAN permet d’offrir du file based des volumes persistant vSAN, le support vVols, le chiffrement et snapshots des volumes persistant, resize des volumes et supporté par Wavefront, Prometheus et vROps.

Amélioration du placement intelligente des VMs en Stretched Cluster:

• Prioriser les I/O read locality
• En cas de perte de la liaison ISL entre 2 sites, HA redémarre les VMs sur le site préféré. Une fois la liaison ISL rétablie, DRS ne pourra s’exécuter que lorsque le resync sera totalement finalisé.
• Réduction des I/O à travers la liraison ISL afin de permettre l’amélioration de la performance read des VMs
• Disponibilité de l’ISL pour le resync

Amélioration de la résilience du Stretched Cluster:

Le remplacement d’un Witness provoquera une réparation et un resync immédiat afin d’être compliance et ainsi minimiser les interruptions

Gestion de capacité intelligente pour Stretched Cluster

Les architecture Stretched Cluster sont asymétrique, donc la capacité de stockage est égale à celui du deuxième site. Dans le cas où nous appliquons différent SPBM pour certaines VMs, l’architecture ne le sera plus et ainsi on se retrouve avec un site avec plus de stockage consommée que le deuxième et ainsi impossible de garantir la disponibilité en cas de sinistre d’un site et provoqué une dégradation de performance de la VM. Dans ce cas, les objets de la VM seront marqué comme absente et les I/O seront automatiquement redirigé vers le site avec plus de disponibilité de capacité.

Amélioration de visibilité de capacité vSAN

Réduction de la confusion de la capacité de consommation des VMs avec la consistance de l’utilisation du niveau de capacité de VMs depuis vCenter et les APIs.

Plus de capacité:

vSAN est capable de supporter 32TB de capacité physique et 1PB (dedup et compression) de capacité logique.