Dans Infrastructures (hyper) convergentes
J'ai écrit cet article à partir du document « VMware Virtual SAN Design and Sizing Guide » pour expliquer les bonnes pratiques sur les définitions, les directives de dimensionnement et les caractéristiques de la base de données distribuée virtual SAN.
Par définition, les Disk groups sont créé par un assemblage de disques flash ou magnétiques. La création d'un Disk group nécessite donc l'affectation d'un disque flash (SAS, SATA ou SSD PCIe) avec un ou plusieurs disques magnétiques (SAS ou SATA).
La couche distribuée Virtual SAN, constitué de mémoire flash, optimise les performances des applications et des machines virtuelles en fournissant un cache en lecture/écriture pour tous les disques magnétiques.
La capacité est divisée en deux segments :
Tous les Disk groups sont formatés avec le système de fichier VMFS-L de VMware vSphere. Ils sont ensuite montés en tant qu’objets du système de fichiers de la Datastore pour ne former qu’une seule Datastore. Le formatage VMFS-L utilise 750 Mo d’espace de stockage de chaque disque.
|
|
Minimum |
Maximum |
|
Disk groups |
1 par hôte |
5 par hôte |
|
Disque flash (SAS, SATA, PCIe SDD) |
1 par Disk group |
1 par Disk group |
|
Disques magnétiques |
1 HDD par Disk group |
7 HDDs par Disk group |
|
Overhead par disque formaté |
750 Mb |
750 Mb |
Configuration maximum de Disk groups pour un hôte
La capacité totale de la base de données distribuée Virtual SAN est déterminée par la somme des Disk groups de tous les hôtes du cluster vSphere et de la taille de leurs disques magnétiques. En effet, les Disk groups sont constitués à la fois d’un disque à mémoire flash et des disques magnétiques, mais seule la capacité utile des disques magnétiques est prise en compte pour la capacité totale de la Datastore car le disque à mémoire flash est spécifiquement dédié à la gestion du cache du Virtual SAN.
Les Objets
Dans une architecture Virtual SAN, un objet est défini sur la base d'un dispositif de bloc de données compatible avec la sémantique SCSI. Conceptuellement, un objet peut également être considéré comme « volumes », terme utilisé dans Amazon EC2 et OpenStack. Seul les fichiers de la machine virtuelle, tels que VMDK sont considéré comme des objets.
Dans une architecture Virtual SAN, chaque objet qui se trouve sur la « Virtual SAN Datastore » comprend plusieurs composantes, qui sont distribués à travers tous les hôtes membres d'un cluster vSphere. Les objets sont assignés aux politiques de stockage de la machine virtuelle pour répondre au mieux aux exigences de disponibilité et de performance.
|
Type d’objet |
Définition |
|
VM Home |
Endroit où tous les fichiers de configuration de la machine virtuelle résident: Vmx, les fichiers journaux et autres |
|
Swap |
Objet de stockage unique créé uniquement lorsque les machines virtuelles sont sous tension |
|
VMDK |
Fichiers des disques des machines virtuelles |
|
Delta/Snapshot |
Objet de stockage unique créé uniquement pour les clichés instantanés des machines virtuelles |
Les composants
Dans une architecture Virtual, des objets comprennent des composants répartis sur tous les hôtes dans un cluster de vSphere. Ces composants sont stockés dans les Disk groups au sein de la base de données distribuée Virtual SAN. Les composants sont copiés de manière transparente dans le cache des dispositifs à mémoire flash, avec leurs données «au repos» toujours stockées sur les disques magnétiques. Virtual SAN 5.5 prend actuellement en charge un maximum de 3000 composants par hôte.
Les objets de plus de 255 Go sont automatiquement divisés en plusieurs composants. Pour chaque composant créé dans un Virtual SAN, 2 Mo sont consommés pour les métadonnées.
Le paramètre de stratégie de nombre toléré de défaillance est une fonction de disponibilité qui peut être appliqué à chacune des machines virtuelles ou VMDK. Cette politique joue un rôle important lors de la planification et du dimensionnement de la capacité de stockage du cluster Virtual SAN. Sur la base des exigences de disponibilité d'une machine virtuelle, le réglage défini dans le mode de stockage de la machine virtuelle peut conduire à une consommation disque pouvant être jusqu’à quatre fois supérieur à la capacité de la machine virtuelle.
Par exemple, si le nombre toléré de défaillance est mis à 1, deux copies en miroir de la machine virtuelle ou VMDK sont créées au sein du cluster. Si le nombre est fixé à 2, trois copies miroirs sont créées. Si le nombre est fixé à 3, quatre copies de la machine virtuelle sont créées.
Disk groups multiples
Avant de commencer à parler des Disks groups multiples, il faut savoir que la gestion du stockage dans le cluster Virtual SAN se fait à la fois :
A l'horizontal (ajout de serveurs), on parle alors de « Scale Out »
A la verticale (ajout de disques dans le serveur), on parle alors de « Scale Up »
Dans une architecture Virtual SAN, les Disk groups sont limités à un dispositif de mémoire flash maximum. Si les hôtes d’un cluster Virtual SAN contiennent plus d'un dispositif à base de flash, il faudra créer plusieurs Disk groups pour utiliser ces derniers.
Une autre raison d'envisager une configuration avec plusieurs Disk groups, c'est d'avoir la possibilité de réduire les impacts sur le stockage en gérant les domaines de défaillance. En effet, si un dispositif à base de flash est indisponible, tous les disques magnétiques au sein de ce Disk group deviennent inutilisables et la totalité de la capacité de stockage de ce Disk group devient indisponible pour le cluster. Lorsque vous configurez plusieurs Disk groups, vous réduisez le domaine de défaillance aux seuls disques magnétiques du Disk group défaillant.
Dimensionnement de la capacité flash
Dans Virtual SAN, 30% de chaque dispositif à mémoire flash est utilisé en cache écriture. Le premier accès à la donnée va la copier dans le dispositif à mémoire flash. Elle est répliquée et conservée dans tous les dispositifs à base de flash du cluster qui contiennent une réplique de l’objet (objets-VMDK par exemple) fonction du nombre toléré de défaillance. Cette règle est strictement appliquée pour assurer la disponibilité des données.
Virtual SAN utilise 70% de chaque dispositif à mémoire flash comme cache en lecture. Un bloc n’est placé que dans le cache en lecture d’un seul dispositif à mémoire flash du cluster. Contrairement au cache en écriture, Virtual SAN utilise la même taille de cache en lecture que celle de l’objet dans le dispositif à mémoire flash, quel que soit le nombre de répliques dans le cluster.
En général, il est recommandé d’utiliser 10% du DiskCapacity (capacité prévue pour le stockage avant le décompte du nombre toléré de défaillance) pour dimensionner le dispositif à mémoire flash.
Par exemple, imaginons de devoir délivrer 1 000 machines virtuelles, chacune implémentée d’un disque en Thin-Provisioning de 100 Go, sachant que la volumétrie moyenne consommée par chaque machine virtuelle est de 20 Go. Sur la base des recommandations de dimensionnement de la mémoire flash, le tableau ci-dessous résume le calcul de la volumétrie à prévoir.
|
Exigences de mesures |
Valeurs |
|
Estimation de la volumétrie utilisée par les VM |
20 Go |
|
Estimation du nombre de machines virtuelles |
1 000 |
|
Estimation de la volumétrie totale |
20 Go x 1 000 = 20 To |
|
Pourcentage de la capacité pour la mémoire flash |
10% |
|
Total de capacité pour la mémoire flash |
20 To X 10% = 2 To |
Le stockage consommé à prévoir avant la réplication est de 1 000 x 20 Go, soit 20 To. Si le facteur de disponibilité de la machine virtuelle est définie pour traiter un nombre toléré de défaillance égale 1 (TTF = 1), deux répliques seront alors créées pour chaque machine virtuelle, la volumétrie sera alors de un peu plus de 40 Go (données répliquées comprises). Cependant, pour ce cas, le dimensionnement de la mémoire flash restera à 10% de 20 To, soit 2 To au globale pour le cluster où sont provisionnées les 1 000 machines virtuelles.
Mémoire et CPU
La taille mémoire pour Virtual SAN va dépendre du nombre de Disk groups et de disques gérés par un hyperviseur. Virtual SAN prend actuellement en charge un maximum de 5 Disk groups par hôte et un maximum de 8 unités de disques par Disk group (1 dispositif à mémoire flash et 7 disques magnétiques).
Tant que les hôtes vSphere ont des configurations mémoire supérieur à 32 Go de RAM, ils peuvent soutenir les 8 Disk groups et la configuration de disque pris en charge dans Virtual SAN. Virtual SAN est conçu pour ne pas consommer plus de 10% de la charge CPU par hôte même avec un nombre important d’applications gourmandes en temps processeur.
Réseau
Virtual SAN fournit un support à la fois pour les commutateurs standards vSphere et pour VMware vSphere Distributed Switch ™, soit à 1 GbE ou 10 GbE. Bien que les deux types de commutateurs de vSphere et les deux vitesses du réseau soient compatibles avec Virtual SAN, VMware recommande l'utilisation de vSphere Distributed Switch avec des 10GbE liaisons réseau montantes à 10GbE.
Ces recommandations sont liées aux éventuelles activités de réplication et de synchronisation que Virtual SAN pourrait imposer sur le réseau en fonction du nombre de machines virtuelles hébergées dans le système et du nombre d'opérations actives.
A chaque fois que c’est possible, il faut envisager l'utilisation de vSphere Distributed Switch ™ avec VMware vSphere Network I/O Control sur des interfaces 10 GbE. Il faut séparer les niveaux de gestion sur des VLAN différents, à savoir, VMware vSphere vMotion, les machines virtuelles et Virtual et utiliser des mécanismes de qualité de service (QoS) pour maintenir le niveau de performance attendu pendant les possibles scénarios de contention.
Avant de calculer la volumétrie de stockage d'une infrastructure Virtual SAN, je souhaitais mentionner les limitations d'un cluster :
Le Design des matériels est aussi à prendre en compte :
Les limitations matérielles (voir le guide de compatibilité) au niveau configuration, ajoutés aux paramètres de stratégie, vont permettre de définir l’espace de stockage qui sera disponible pour les machines virtuelles. Ce dimensionnement est nécessaire pour déterminer la capacité utile disponible dans un cluster Virtual SAN.
Prenons le scénario suivant :
Le calcul de la capacité de stockage du cluster Virtual SAN s’effectue en utilisant la formule suivante:
Le nombre d'objets est basé sur les fichiers qui composent la machine virtuelle. On y retrouve l’enveloppe de la machine virtuelle, le fichier de swap, les fichiers VMDK et les snapshots. Le calcul du nombre d’objets s’effectue en utilisant la formule suivante :
Le nombre d'objets par machine virtuelle, en plus de leurs exigences en matière de performance et de disponibilité, donne le nombre de composants qui seront créés. Un cluster Virtual SAN prend actuellement en charge un maximum de 3 000 éléments par hôte.
On utilise la formule suivante pour calculer le nombre de composants par machine virtuelle. Il représente les répliques et les témoins créés sur la base du réglage de tolérance de panne. Le nombre résultant de composants est théoriquement répartie entre tous les hôtes du cluster.
Chaque machine virtuelle utilisera une capacité brute de stockage pour gérer son swap. Virtual SAN réserve toujours par machine virtuelle l'espace de swap pour deux répliques, quelle que soit le réglage de la tolérance de panne. On utilise la formule suivante pour calculer la capacité disque du cluster:
La capacité utile du cluster Virtual SAN est la quantité de stockage qui peut être utilisé pour stocker les fichiers VMDK de toutes les machines virtuelles. Il est déterminé en soustrayant la capacité overhead au DiskCapacity du cluster Virtual SAN, puis en divisant le montant restant par le nombre de tolérance de panne plus 1. On utilise la formule suivante pour calculer la capacité utile du cluster:
REMARQUE: En règle générale, pour le VSANoverhead, on estime à 1 Go la capacité de stockage par disque pour les composants Virtual SAN et les métadonnées VMFS entendu.
Pour une capacité de stockage brute d’environ 1 120 To, la capacité utile sera de 551 To pour créer des fichiers VMDK. Le reste est consommé principalement par des répliques créées pour la tolérance de panne et par swap.
Les 800 machines virtuelles pourront toutes avoir un disque virtuel (soit 1 VMDK) de 689 Go
Environ 500 000 IOPs en lecture et 160 000 IOPs en lecture/écriture (70% / 30%) pourront être disponibles pour cette infrastructure.
A titre indicatif, voici un tableau qui donne une idée des IOPs pour différents environnements
Les liens utiles :
