Oops! It appears that you have disabled your Javascript. In order for you to see this page as it is meant to appear, we ask that you please re-enable your Javascript!

VMware vSphere 6.5 Part4- Storage

La suite de ma présentation de version 6.5 de vSphere sur les fonctionnalités autour du stockage. (Je reviens parfois sur des features existantes)

twitterlinkedin

VMware vSphere 6.5 Part3- Network

La suite de ma présentation de version 6.5 de vSphere sur les fonctionnalités autour du réseau. (Je reviens parfois sur des features existantes)

twitterlinkedin

VMware vSphere 6.5 Part2- Cluster

La suite de ma présentation de version 6.5 de vSphere sur les fonctionnalités accessibles après la création d’un cluster. (Je reviens parfois sur des features existantes)

twitterlinkedin

VMware vSphere 6.5 Part1 – ESXi & vCenter

Je partage avec vous ma présentation des nouveautés de la version 6.5 de vSphere. Le but étant d’avoir une synthèse des nouveautés apportées par cette version sans avoir chercher partout sur internet 🙂

  • VMware vSphere 6.5 Part1 – ESXi & vCenter
  • VMware vSphere 6.5 Part2- Cluster
  • VMware vSphere 6.5 Part3- Network
  • VMware vSphere 6.5 Part4- Storage

VMware vSphere 6.5 Part1 – ESXi & vCenter

twitterlinkedin

Cas de panne de vSan en FTT1 – Part 7

Dans cet article, nous aborderons plusieurs cas de panne vSan en configuration FTT1 mais le principe reste le même en FTT2/FTT3, si ce n’est que nous aurons plus de réplica d’objet et que cela nécessitera un nombre d’hôte minimum afin de garantir la résilience des objets. Cela nous permettra de démontrer l’avantage du FTT2/FTT3 😉

vSan connaît deux types d’évènement lors d’une panne :

  • Absent : vSan considère que la donnée (objet) est perdue de façon permanente et qu’elle ne reviendra pas. Il n’y donc aucune raison d’attendre et une récupération immédiate des données (objets) est initiée par vSan. Il n’est pas possible de configurer ce timer.
  • Degraded : vSan considère que la donnée est temporairement indisponible. Il considère que l’évènement responsable de cette indisponibilité requière le déclenchement d’un timer de 60 minutes avant de lancer des opérations de récupération des données (objets). Ce timer est configurable dans les paramètres avancés des hôtes « ClomRepairDelay ».

Ne pas oublier qu’en mode vSan (non streched), les lectures sont effectuées en round-robin sur les objets sources et réplicas du cluster par blocs de 1Mo.

Cas de panne d’un hôte sur le cluster n’exécutant pas de VM:

La VM s’exécute sur l’hôte A du cluster. La VM possède 2 objets VMDK0 et VMDK1. Les deux objets sont configurés avec un SW=2 qui divise chaque objet en deux composants d’objet. Les composants d’objet sont repartis sur des disques différents.

Lire la suite ›

twitterlinkedin

vSan – Read and Write Cache en vSan Streched cluster – part 6

Nous avons vu dans les articles précédents comment vSan gère les lectures et écritures dans un mode standard. Ici, nous aborderons les particularités de vSan en mode Streched Cluster.

Contrairement au mode vSan classique, en mode Streched Cluster, vSan utilise un algorithme lui permettant d’effectuer ses lectures sur le site qui exécute la VM et cela dans les deux versions (Hybrid / All Flash). En streched cluster, chaque site représente un domaine de panne (FD = Fault Domain) et les hôtes ESXi de chaque site doivent être ajoutés dans un Fault Domain. La définition des Fault Domain permet à chaque objet provisionné d’avoir son réplica dans un Fault Domain différent et donc un site différent. Cet algorithme permet d’éviter la répartition des lectures en Round Robin sur les deux sites comme en vSan non Streched. En Streched, vSan utilise volontairement de la Read Locality afin d’éviter les latences pouvant être engendrées par le lien inter-sites. En cas de migration de VM par vMotion entre les hôtes ESXi du cluster d’un même site, le cache n’est pas reconstruit sur l’hôte qui exécute la VM (même principe que vSan non streched). Par contre, en cas de migration d’une VM sur un hôte du cluster du site distant, le cache est reconstruit sur les SSD des hôtes du 2nd Fault Domain et la Read Locality s’applique à nouveau.

Lire la suite ›

twitterlinkedin

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

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
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
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
Tagués avec : , , , , , , ,
Top