vSan Hybrid and All Flash – Write Cache – part 5

La gestion des écritures dans vSan en version Hybrid et All Flash.

Comme nous l’avons vu dans l’article précèdent, en version Hybrid, vSan possède 1 disque SSD dédié par disk group. vSan utilise 30% de ce disque comme cache en écriture.

En version All Flash, vSan utilise 100% de la capacité d’un disque SSD ‘Write intensive’ dédié par disk group comme cache en écriture avant le destaging sur les disques capacitifs (SSD).

En version Hybrid, les 30% du disque de cache SSD dans un disk group est principalement utilisé comme buffer en écriture afin d’accélérer le traitement des I/O. En effet, cela permet un acquittement (Ack) bien plus rapide des opérations et évite ainsi les latences d’écriture.

En version All Flash, le disque de cache SSD par disk group est principalement utilisé pour prolonger la durée de vie des disques capacitifs SSD. Les disques utilisés pour le cache supportent des écritures intensives et ont une durée de vie bien plus longue exprimée en TBW (Terabytes Written) par VMware ou en DWDP (Drive Writes Per Day) par les constructeurs.

En vSan 6 (Hybrid ou All Flash), la taille maximale des disques de cache utilisés dans les disk group est de 600GB.

Lire la suite ›

twitterlinkedin
Publié dans Stockage, Virtualisation, Vmware vSphere

vSan Hybrid and All Flash – Read Cache – part 4

Dans cet article, nous allons découvrir comment vSan gère les lectures. Nous étudierons les lectures sur vSan en version Hybrid en fonction de la présence en cache ou non des blocs demandés par les VM ainsi que l’utilisation du cache suite au déplacement d’une VM par vMotion au sein du cluster. Bien entendu, nous aborderons aussi la version All Flash.

Comme nous l’avons vu dans l’article précèdent, en version Hybrid, vSan possède 1 disque SSD dédié par disk group. vSan utilise 70% de la capacité de ce disque comme cache en lecture et les 30% restant comme cache en écriture.

En version All Flash, vSan utilise 100% de la capacité d’un disque SSD ‘Write intensive’ dédié par disk group comme cache en écriture et tous les autres disques capacitifs (SSD) du disk group pour les lectures. En All Flash, il n’y a pas de gestion de bloc chaud et froid lors des opérations de lecture contrairement au mode hybrid qui nécessite le déplacement des blocs récemment lus (blocs chauds) sur les disques de cache SSD dédiés du disk group qui héberge les objets. En version All Flash, il n’existe pas de placement des blocs chauds sur un disque de cache SSD dédié par disk group. En effet, les lectures sont lues directement depuis les disques capacitifs eux-mêmes en SSD.

Lire la suite ›

twitterlinkedin
Publié dans Stockage, Virtualisation, Vmware vSphere Tagués avec : , , , ,

vSan – Stratégie de résilience – part 3

La résilience des objets dans un cluster Standard ou Streched Cluster vSan est assurée par la politique FTT <NumberOfFailuresToTolerate> appliqué aux objets et par la définition de FD <Fault Domain>. Pour assurer cette résilience, un cluster vSan requière un minimum de 3 hôtes mais 4 hôtes minimum sont conseillés afin d’assurer la protection des données lors d’une panne pendant la maintenance d’un hôte.

FTT <NumberOfFailuresToTolerate>, est une politique de tolérance de panne appliquée aux objets VMs ou individuellement aux disques virtuels des VMs. Cette politique définit le nombre de pannes d’hôte qu’un objet de VM peut tolérer. Pour N échecs tolérés, chaque donnée écrite est stockée sur le stockage de N+1 hôtes. Cela permet de s’assurer qu’une réplique de l’objet est créée sur les disques d’un autre hôte du cluster vSan. La mise en place de cette politique multiplie par N (2, 3 ou 4) l’espace consommé sur le cluster vSan. En streched cluster, cette politique est limitée à 1.

Lire la suite ›

twitterlinkedin
Publié dans Stockage, Virtualisation, Vmware vSphere Tagués avec : , , , , , , , ,

vSan – Design des disk groups vSan – part 2

Le design des disk groups doit être minutieusement étudié avant la mise en place d’un cluster vSan, . Dans cet article, nous allons découvrir quelles sont les considérations à prendre en compte pour définir le cache et le stockage capacitif d’un cluster vSan. Nous donnerons un exemple de sizing et quelques explications sur le choix des composants.

disk groups vsan

Ci-dessus la représentation du design vSan d’un hôte ESXi composé de 2 disques locaux en RAID1 pour l’installation du système ESXi et 2 disk groups pour vSan. A noter que les disques locaux pour l’installation du système ESXi peuvent être remplacés par des cartes SSD ou une clé USB.

Lire la suite ›

twitterlinkedin
Publié dans Stockage, Virtualisation, Vmware vSphere Tagués avec : , , , , , , ,

vSan – Présentation – part 1

Présentation de la solution vsan

VMware Virtual SAN (vsan) est une plate-forme de stockage de type SDS (Software-Defined Storage) hyper-convergé entièrement intégrée à VMware vSphere. Cette solution permet d’agréger des disques locaux d’hôtes physiques membres d’un cluster vSphere, afin de créer une solution de stockage partagée et distribuée.

La solution offre deux options de configuration :

vsan

 

  • Une configuration Hybrid qui exploite deux types de support, des disques flash (SSD) et disques magnétiques (SAS)

Cette option utilise des périphériques flash pour fournir une couche de cache en lecture et écriture afin de garantir des performances optimales tout en utilisant des disques magnétiques pour fournir une capacité de stockage aux données persistantes.

  • Une configuration All-Flash.

Cette configuration utilise le flash à la fois pour la couche de mise en cache en écriture mais aussi pour les besoins capacitifs.

Lire la suite ›

twitterlinkedin
Publié dans Stockage, Virtualisation, Vmware vSphere Tagués avec : , , , , , , , , , ,

Parcours des I/O d’une VM

Découvrons les différentes couches que traversent les I/O lorsqu’une VM souhaite lire ou écrire sur son disque virtuel (VMDK).


  1. Lorsqu’une application ou système d’exploitation d’une VM souhaite effectuer des opérations de lecture ou d’écriture sur son disque virtuel, ils envoient des commandes SCSI vers le VMDK.
  2. Un driver installé dans le système d’exploitation invité de la VM va permettre au contrôleur SCSI virtuel de transférer les données au VMkernel. La VM va utiliser l’émulation SCSI via son contrôleur SCSI virtuel pour rediriger les demandes I/O clientes vers le VMkernel de l’ESXi
  3. Le Vmkernel va localiser le fichier correspondant au disque de la VM sur le volume VMFS. Il va mapper les requêtes des blocs du disque virtuel (VMDK) vers les disques physiques du volume VMFS.
  4. En fonction du type de disque virtuel, les demandes I/O peuvent traverser différentes couches qui gèrent la transcription du VMDK (Snapshot, Vmfs, Nfs, Rdm, etc …)
  5. Les demandes d’I/O sont prises en charge par le scheduler d’I/O au sein du VMkernel. C’est lui qui gère les demandes en I/O de toutes les VMs depuis et vers les périphériques physiques. Le scheduler d’I/O va transmettre les demandes à l’architecture PSA.
  6. L’hyperviseur ESXi, utilise un ensemble d’API de stockage, appelé également PSA (Pluggable Storage Architecture). La PSA permet de gérer les multiples chemins d’accès, l’équilibrage de charge et les mécanismes de bascule des multiples périphériques de stockage présentés aux ESXi. La PSA est une structure ouverte permettant aux développeurs de logiciels tiers de concevoir leurs propres techniques d’équilibrage et/ou mécanismes de basculement pour des baies de stockage particulières. Cela leurs permet d’insérer leur code directement sur le chemin des I/O. Lire la suite ›
twitterlinkedin
Publié dans Stockage, Vmware vSphere

Automatiser l’installation et la configuration de vos ESXi

Création d’un Custom ISO VMware vSphere ESXi 6

Pourquoi créer un ISO personnalisé ?

121515_2315_Construireu18.png

Pour déployer un maximum d’hyperviseur en une journée ? Pour ne pas perdre son temps à regarder la jauge de progression de l’installeur ? Pour s’éviter les tâches répétitives ? Ou simplement éviter les erreurs de configuration ? etc … 

Dans cet article, je vais vous montrez comment créer un ISO personnalisé avec des kickstarts directement injectés dans l’iso de VMware vSphere ESXi, le tout avec un menu de boot permettant de démarrer une installation sur le kickstart désiré.

Pour ceux qui ne savent pas ce qu’est un kickstart, il s’agit d’un simple fichier texte contenant une liste d’éléments dont chacun est identifié par un mot-clé. Ce fichier permet d’automatiser l’installation et la configuration d’un système d’exploitation de type Linux.

L’avantage d’une solution comme celle-ci est d’avoir dans un seul média d’installation permettant la configuration complète de tous vos hyperviseurs. Cela permet un provisionnement rapide sans le moindre effort. (Sans faire appel aux fonctionnalités avancés comme « host profile » et donc pas besoin de licence entreprise plus)

Les prérequis :

  • Une VM sous une distribution Linux
  • Un média original de VMware vSphere ESXi
  • Le package vmtar et mkisofs

Lire la suite ›

twitterlinkedin
Publié dans Virtualisation, Vmware vSphere Tagués avec : , , , , , , , ,

Deepdive – Thin provisioning Reclaim Space (VAAI / UNMAP)

Le Reclaiming Space (UNMAP)

Qu’est-ce que c’est ?

Cela consiste à réclamer des blocs de stockage inutilisés sur une LUN provisionnée en mode dynamique (thin).

Avant d’expliquer pourquoi il est utile de faire du reclaiming space, attardons nous sur les deux modes de provisionnement de LUN existant au sein d’une baie SAN.

Le provisionnement statique (thick):

C’est le modèle traditionnel de provisionnement de stockage. Les blocs sont réservés sur le pool de disque de la baie SAN à la création de la LUN. En mode thick, tous les blocs utilisés ou non sur les disques physiques sont mappés à la LUN. Avec le provisionnement statique, une quantité d’espace de stockage est prévue à l’avance en prévision des futurs besoins de stockage. Toutefois, l’espace peut rester inutilisé et entraîner une sous-utilisation de la capacité de stockage.

Ci-dessous un exemple de RAID groupe de 5 disques de 10GB et 6 LUNs en mode thick :

Lire la suite ›

twitterlinkedin
Publié dans Vmware vSphere Tagués avec : , , , , , , , , , , , , , ,

Deepdive – Veeam backup & réplication

veeam

 

Nous allons dans un premier temps étudier comment Veeam transporte les données à sauvegarder (les VMs) de son emplacement source (datastores des VMs) à la destination (stockage des sauvegardes Veeam) en fonction du mode de transport configuré dans le composant proxy.

Nous étudierons ensuite en profondeur comment les blocs de données sont déplacés en fonction du mode de sauvegarde et comment agit la période de rétention en fonction du mode de sauvegarde.

Il existe 3 modes de transport que nous allons parcourir rapidement afin d’étudier les interactions entre les différents composants

Lire la suite ›

twitterlinkedin
Publié dans Sauvegarde Tagués avec : , , , , , , , , , , ,

Deepdive – vSphere HA – Comment ça marche ?

Deepdive vSphere HA – Comment ça marche ?

Présentation de HA :

VMware vSphere High Availability (HA), est une solution de « haute disponibilité ». Elle peut être activée sur un cluster avec de multiples hyperviseurs ESXi par l’intermédiaire du vCenter.

HA va permettre en cas de panne d’un hyperviseur du cluster, de redémarrer automatiquement les machines virtuelles reposant sur l’hyperviseur impacté sur d’autres hyperviseurs ESXi au sein de ce même cluster vSphere.

Exemple: Un hôte ESXi02 en panne et le processus de HA relance les VMs sur les autres hyperviseurs du cluster

Lire la suite ›

twitterlinkedin
Publié dans Vmware vSphere Tagués avec : , , , , , , , , , , , , ,

Nware

Nware