Accueil > VMware > nouveauté vSphere5: amélioration Stockage
août/11180

La plus grosse partie des nouveautés vSphere 5 se situe au niveau du stockage. Et c’est bien normal, le stockage devient le nerf de la guerre pour des infrastructures virtualisées, aussi bien au niveau des performances que du management. Voici donc une description des nouveautés au niveau stockage : VMFS5, VAAI v2, VASA, Storage vMotion, FCoE soft adapter (la partie Storage DRS et Profile-Driven Storage sera traité dans un prochain article).

VMFS5

La nouvelle version du système de fichier : VMFS5 apporte une meilleure évolutivité et de meilleur performance.

Avec le VMFS5, les limitations du système de fichier sont repoussées. En effet, les Datastores supportent des volumes allant jusqu’à 64 To sans nécessité d’extend. Cela est possible car les partitions VMFS5 sont basées sur une table GPT (GUID Partition Table). La limitation du nombre maximum de fichier dans un volume VMFS est repoussé à plus de 100 000 fichiers.

Les disques virtuels et les RDM en mode virtuels conservent leur limitation à 2 To (-512 octets) par contre les RDM en mode physique peuvent aller jusqu’à 64 To.

Les performances sont optimisées par l’utilisation du mécanisme de verrouillage VAAI (ATS) qui s’applique désormais à plus de tâches. Il est possible de supporter en théorie 2048 VMs allumées sur un même LUN.

De plus l’overhead des I/O disques est diminué par l’utilisation de sous-blocs réduits de 8 Ko. Pour les fichiers inférieurs à 1 Ko, un descripteur d’emplacement fichier est utilisé dans les méta-datas plutôt qu’un bloc fichier.

Le VMFS5 permet la récupération d’espace sur les LUN en Thin-Provisionning.

Le taille de bloc (Block-Size) est unifié entre tous les volumes à la valeur de 1 Mo. On n’a plus le problème de limite de taille vDisk d’une VM à cause d’une taille de bloc trop faible. En VMFS3 on était alors obligé reformater le volume pour modifier la taille de bloc.

La mise à niveau de VMFS3 vers VMFS5 se fait à chaud sans perturbation. Les VMs restent actives dans le DataStore pendant le passage de VMFS-3 à VMFS-5. A noter que les ESXi5 supportent en lecture/écriture les VMFS3 et 5, par contre les VMFS5 ne sont pas supporté par les hôtes ESX/ESXi4.X.

Les volumes upgradés en VMFS5 peuvent utiliser la fonction de petits fichiers 1Ko, peuvent grandir jusqu’à 64To et utiliser le mécanisme VAAI ATS. Cependant, ils gardent des différences par rapport au volume nouvellement créé en VMFS5:

  • Ils continuent d’utiliser leur précédente taille de Bloc (qui peut être plus grand la taille de bloc unifié à 1Mo)
  • Ils continuent d’utiliser les Sub-blocs de 64Ko (au lieu des nouveaux Sub-blocs de 8Ko)
  • Ils conservent la limite de 30720 fichiers (au lieu d’une limite supérieure à 100000 fichiers)
  • Ils continuent d’utiliser une partition type MBR. Quand les volumes dépasseront 2 To, ils basculeront automatiquement en GPT
  • Ils continuent d’avoir leur partition commençant au secteur 128 (au lieu du secteur 2048).

Si vous avez le luxe de pouvoir le faire, il est conseillé de créer de nouveau volume VMFS5 plutôt que de les upgrader.

Voici un tableau de comparaison entre les 2 générations de système de fichier:

Fonctionnalités VMFS-3 VMFS-5
(upgraded)
VMFS-5
(brandnew)
Volumes VMFS > 2 To Oui
(avec des extend)
Oui
(max 64 To)
Oui
(max 64 To)
Taille max RDM en mode virtuel 2 To 2 To 2 To
Taille max RDM en mode physique 2 To 64 To 64 To
Nombre max. de fichiers 30 072 30 072 >100 000
Taille de bloc unifiée (1 Mo) Non
(1, 2, 4 ou 8 Mo)
Non
(1, 2, 4 ou 8 Mo)
Oui
Fonction ATS de verrouillage optimisé Non Oui Oui
Récupération de l’espace mort sur les LUNs Thin-Provisionnés Non Oui Oui
Sous-blocs pour usage optimal de l’espace 64 Ko
(max. ~ 3000)
64 Ko
(max. ~3000)
8 Ko
(max. ~30000)
Prise en charge des petits fichiers Non 1 Ko 1 Ko
Type de partition MBR MBR puis GPT GPT
Partition débutant au secteur (LBA) 128 128 2048
Mise à niveau en ligne sans perturbation N/A Oui Oui

VAAI v2

Les API vSphere Storage pour l’intégration de baies de stockage : VAAI (vStorage API for Array Integration) permettent de rediriger (si possible) certaines tâches vers la baie de stockage. On parlera ici d’accélération matériel fournit par la baie de stockage.

Les primitives « traditionnel » VAAI (celle présente en vSphere 4.1) ont été améliorées :

  • En vSphere 4.1, seul la primitive « Block Zeroing » était en conformité avec la norme T10, les primitives « ATS » (anciennement appelé Hardware Assisted Lock­ing) et « Full Copy » ne l’étaient pas.
  • En vSphere 5, les 3 primitives sont en conformité avec la norme T10 et directement intégré dans la pile ESXi. Ce qui permet à toutes les baies qui utilisent cette norme de profiter de ces primitives avec le plugin VAAI par défaut dans vSphere 5
  • La primitive ATS (Atomic Test & Set) qui gère le mécanisme de verrouillage de fichiers dans les volumes VMFS à été amélioré en VMFS5. Il permet de couvrir plus d’opérations et ainsi obtenir de meilleur performance et une meilleur scalabilité.

Nb : L’organisme T10 est responsable de la normalisation SCSI (SCSI-3), c’est la norme utilisé par la majorité des vendeurs de stockage.

En version 2, de nouvelles primitives VAAI ont été ajoutées pour les LUNs Thin-Provisionnés :

  • Dead Space Reclamation : permet la récupération de l’espace mort, c’est à dire les blocs écrits qui ne sont plus utilisés (par exemple après un Storage vMotion). Il récupère les blocks sur un LUN Thin-Provisionné via VAAI quand un fichier VMFS est supprimé. ESXi 5.0 transmet les informations des blocs libérés au système de stockage via VAAI avec une commande SCSI UNMAP standard, le système de stockage récupère alors les blocs morts.

  • Out of Space : que l’on peut décomposer en 3 sous-fonctionnalités.
    • Le « Thin-Provisionning LUN Reporting » : qui permet  de faire le suivi de l’utilisation de l’espace sur la baie de stockage dans vCenter.
    • Le « Quota Exceeded » : qui permet d’afficher une alerte dans vCenter quand on dépasse un seuil de remplissage d’un DataStore Thin-provisionné (différentes alarmes configurables en fonction des outils du constructeur de la baie).

  • Le « Out of Space behaviour » : sur les LUNs Thin-Provisionnés, les VMs demandent au stockage si l’espace est disponible avant l’écriture. Ce qui signifie que si ce le stockage est plein un message d’alerte remonte dans vCenter et seule cette VM est mise en pause (les autres VMs continuent de fonctionner). Cela évite les écrans bleux dans les VMs !

Dans vSphere 5.0, la version 2 de VAAI introduit des fonctions d’accélération/redirection matérielle pour les DataStores de type NAS (NFS). Cependant, les plug-ins NAS VAAI ne sont pas fournis avec ESXi 5.0. Ils sont développés et distribués par des fournisseurs de solutions de stockage, mais signés par VMware dans le cadre du programme de certification.

Voici le primitives suivantes sont définies pour le stockage NAS VAAI :

  • Clonage complet (Full File Clone) : Similaire au clonage de bloc VMFS (Full Copy). Permet au NAS de cloner des fichiers VMDK à froid. Le Storage vMotion sur un NAS ne permet pas l’accélération matériel.
  • Prise en charge native des Snapshots (Native Snapshot Support) : Permet que le traitement pour la création de Snapshots de VM soit effectué directement par la baie NAS.
  • Statistiques étendues (Extended Statistics) : Permet d’avoir la visibilité sur les espaces consommés sur les DataStores NFS.
  • Réservation d’espace (Reserve Space) : Permet de créer des fichiers VMDK en mode Thick-Provisionning sur un stockage NAS.

Sur la capture d’écran ci-dessous en NAS VAAI, on peut voir 2 formats : Flat (Thick) et Flat pre-initialized (eager zeroed-thick)

VASA

VASA (vStorage APIs for Storage Awareness) est une API de détection du stockage, qui est une simple extension des APIs vStorage. Elle permet d’intégrer les baies de stockage à vCenter pour remonter des informations sur la topologie stockage via les « Storage Providers » comme la réplication, le type de RAID, la compression, la déduplication, le format Thin/Thick, le type de disque, l’état des Snapshots, les performances (IOps/MBps)… Cette API est une des clés du fonctionnement du « Profile-Driven Storage ».

Les DataStores disposent maintenant d’une nouvelle zone de propriétés nommée Storage Capabilities (capacités du stockage). En revanche, pour le moment, il y a une grosse limitation aux possibilités de VASA: Il n’est possible pour le Storage Provider de remonter qu’une seule Capabilities pour les DataStores (System-provided capability). Le VASA provider doit fournir un seul “meta-attribute” qui peut être une combinaison de plusieurs options de configuration (exemple du screenshot : « nom_ baie : constructeur : nom_array ») et un label (qui sera affiché dans Profile-Driven Storage).

Storage vMotion

Un certain nombre d’améliorations ont été apportées à Storage vMotion dans vSphere 5.0, c’est la troisième génération de cette fonctionnalité. Elle est disponible qu’à partir de la gamme Enterprise est la brique de base pour le “Storage DRS”.

Storage vMotion est compatible avec les VMs possédant des Snapshots, ce qui signifie la compatibilité avec d’autres produits & fonctionnalités VMware (VCB, vDR, HBR…). Il supporte également le déplacement des Linked-Clones.

Dans vSphere 4.1, Storage vMotion utilisait le mode CBT (Changed Block Tracking) pour copier des blocs disques entre la source et la destination. Le principal obstacle dans cette approche était la durée de convergence de la phase de pré-copie du disque et le risque de dysfonctionnement de Storage vMotion si la charge d’E/S de la VM était très importante.

Dans vSphere 5.0, Storage vMotion utilise une nouvelle architecture qui met en miroir les blocs de disques modifiés après qu’ils ont été copiés sur la destination. La mise en miroir des E/S entre les disques source et destination est nettement préférable à la pré-copie itérative du disque. De plus, elle présente les avantages suivants par rapport aux versions précédentes : la réussite garantie de la migration même en cas de lenteur de la destination & la durée de la migration plus courtes et plus prévisible.

Voici le détail des actions réalisées lors d’un Storage vMotion (dernière génération):

  1. Le répertoire de travail de la VM est copié par VPXA vers le DataStore de Destination.
  2. Une “shadow” VM est démarré sur le DataStore de Destination en utilisant les fichiers copiés. La “shadow” VM en pause, attendant que la copie des fichiers disques de la VM soit terminée.
  3. Storage vMotion active le Mirror Driver pour écrire en miroir les blocs déjà copiés vers la destination.
  4. En un passage, la copie des fichiers disques de la VM est complétée vers le DataStore de Destination pendant la mise en miroir des E/S.
  5. Storage vMotion appel un « Fast Suspend » et un « Resume » de la VM (identique au vMotion) pour transférer la VM en cours d’exécution vers la « shadow » VM en pause.
  6. Après que la phase « Fast Suspend » & « Resume » soit terminé, l’ancien répertoire et les fichiers disques de la VM sont supprimés du Datastore de la Source.

Une étude très poussée sur l’évolution de Storage vMotion par Ali Mashtizadeh, Emre Celebi, Tal Garfinkel et Min Cai (de chez VMware) fait la comparaison en la comparaison entre les 3 générations de la fonctionnalité Storage vMotion. En voici un extrait:

Sur les graphiques, on constate les IOps observés et la durée des phases d’un Storage vMotion entre les 3 générations. On y retrouve:

  • la phase (S) de pré-migration comparable entre les 3 générations
  • la phase (M) de première copie comparable entre les 3 générations
  • les phases (Cs) et (Cd) pour la première génération correspondent aux phases de consolidations des snapshots sur la source et la destination
  • la phase (DBT) pour la deuxième génération correspond à la copie itérative
  • et la phase (D) de post-migration qui est nettement plus longue pour la seconde génération

On voit très nettement qu’entre la première et la seconde génération les IOps ont diminué mais la durée et qu’entre la seconde et la troisième génération la durée a nettement diminuée. Au final, une migration de disques à chaud avec la dernière génération Storage vMotion n’est que 9,7% plus long qu’une migration à froid.

FCoE software adapter

La technologie FCoE (Fiber Channel over Ethernet) est une amélioration de faire passer les trames Fiber Channel à travers un réseau Ethernet. En vSphere 4.x, seules les cartes FCoE hardware adapters étaient supportées. En vSphere 5, le FCoE software adapter utilise des cartes réseau “FCoE capable” que l’on nomme “Converged Network Adapters” (CNAs). Il est maintenant possible d’utiliser ces cartes pour accéder à un Stockage de type SAN Fibre Channel.

Le FCoE software adapter est un bout de code effectuant du travail d’encapsulation FCoE. Cet adaptateur peut être utilisé avec un certain nombre de carte réseau supportant “partial FCoE offload”. Tout comme l’iSCSI software adapter, le FCoE software adapter doit être ajouté et activé dans la page “Storage Adapters” avant de pouvoir être utilisé.

Et pour finir une liste de sources intéressantes:

%d blogueurs aiment cette page :