Prérequis réseau VMware vSAN

Prérequis réseau pour VMware vSAN

Nous allons expliquer les prérequis VMware vSAN afin de respecter les best practices VMware.

Les ports réseau physiques pour chaque hyperviseur :

Tout va dépendre du type d’architecture que nous souhaitons mettre en place. S’il s’agit d’une architecture hybride, on pourra se baser sur un réseau 1G (attention tout de même au performances attendues) ou un réseau 10G.

Pour une architecture « All Flash », il faudra opter pour un réseau 10G uniquement.Il est aussi possible mais pas obligatoire,  de mettre en place un agrégat de ports (NICs Teaming), pour la redondance.

Types de vSwitchs supportés :

VMware vSAN supporte à la fois VMware Standard Switch (VSS), et VMware Distributed Switch (VDS). Il y a certains avantages à utiliser VDS, comme par exemple isoler et segmenter le réseau vSAN par exemple.

A noter que la fonctionnalité VDS, est incluse avec la licence vSAN.

Support des couches réseau :

VMware vSAN supporte les couches 2 (switch) et 3 (routage). La couche 3 est supportée depuis la version vSAN 6.0.

Si on utilise les couches 2 et 3, il faudra obligatoirement activer le mode multicast, jusqu’à la version 6.5 inclus. Avec la couche 3, il sera tout simplement routé entre les réseaux. Il est préférable de bien vérifier ce point avec les équipes réseau, car ce mode est rarement utilisé par défaut chez les clients

La version 6.6 apporte le mode unicast à la solution.

Le réseau VMkernel :

Chaque hôte d’un cluster vSAN, disposera d’un port de communication VMkernel dédié. Ce port de communication est utilisé en interne, et gère le trafic i/o en lecture et écriture entre les hyperviseurs, lorsqu’une VM est hébergée sur un hôte (CPU/Mémoire), et que son stockage est situé sur un ou plusieurs autres hôtes du cluster vSAN.

Le trafic réseau vSAN :

Le protocole de communication utilisé par vSAN est un protocole propriétaire, au même titre que ceux utilisés par vMotion, vSphere replication, Fault Tolerance, etc…

Jusqu’à la version 6.5, le réseau vSAN utilise trois types de trafic différents :

  1. Multicast heartbeats :

Ce type est utilisé afin de découvrir tous les nœuds qui participent au cluster vSAN, mais aussi afin de déterminer l’état de l’hôte. Il génère très peu de trafic.

  1. Multicast and Unicast packets from the clustering services (CMMDS) :

Ce type met à jour les metadata tels que le placement des objets, et les statistiques. Ce mode génère un petit peu plus de trafic que le mode « Multicast heartbeats ».

  1. Storage trafic (lectures/écritures)

Ce type constitue la majeure partie du trafic, et permet la communication entre les hôtes du cluster en mode unicast.

 

Afin de s’assurer que la communication fonctionne correctement, il faudra bien s’assurer que les switchs physiques autorisent le mode multicast. Bien que le mode multicast ne concerne que très peu de trafic, il est cependant essentiel au bon fonctionnement du cluster vSAN, jusqu’à la version 6.5 inclue.

En version vSAN 6.6, il ne sera plus nécessaire d’activer le mode multicast sur les switchs physiques, puisque le mode unicast sera le seul mode utilisé.

JUMBO FRAME :

Le mode Jumbo Frame est supporté par vSAN. Cependant, les architectures sont très différentes les unes des autres, et il est très difficile d’être pour ou contre l’activation du Jumbo Frame. Lorsque ce mode n’est pas configuré de bout en bout, des problèmes réseau peuvent apparaitre rapidement.

Certains tests ont permis de relever une amélioration des performances réseau d’environ 15%, et une légère diminution de l’utilisation des CPUs.

D’autres tests n’ont absolument rien changé.

Agrégats de ports :

L’agrégat de ports (NICs Teaming) est une autre possibilité d’optimisation de performance réseau. L’agrégat de ports est transparent pour vSAN, et permet à vSAN d’utiliser plusieurs ports réseau physique. Il est aussi possible d’utiliser le LACP (Link Aggregation Control Protocol), ou bien de créer plusieurs interfaces vSAN VMkernel.

Cependant, il n’y a aucune garantie que vSAN soit capable d’utiliser toute la bande passante disponible à travers les tous les ports, en même temps. Plusieurs facteurs entrent en considération, comme la taille du cluster, le nombre d’interfaces réseau physiques, et le nombre d’adresses IP différentes utilisées.

NIOC (Network I/O Control) :

Même si le réseau 10G reste très recommandé pour le traffic vSAN, il peut aussi être utilisé pour d’autres types de besoins, lorsqu’on utilise DVS. (administration, sauvegarde, DMZ,…). Toutefois, il faudra peut-être avoir recourt à l’utilisation de la fonctionnalité Network I/O Control, afin d’assurer un minimum de bande passante dédiée au réseau vSAN, en cas de congestion réseau. A noter que NIOC n’est disponible qu’avec DVS.

vSAN Streched Cluster :

Cette fonctionnalité est apparue avec vSAN 6.1, et permet de configurer la fonctionnalité vSAN sur un cluster multisites. Pour un cluster réparti sur deux sites, un « witness » sera nécessaire. Il s’agit d’une VM « témoin » permettant de vérifier le bon fonctionnement des hôtes situés sur chaque site, afin d’éviter le « split brain » en cas de perte d’un site. Lorsque cela se produit, la VM « witness » ordonne le redémarrage des VMs injoignables sur le site encore actif. Si le stretched cluster est réparti sur plus de deux sites, il ne sera pas nécessaire de prévoir une VM « witness ». Il est cependant important de respecter certains prérequis.

  • Maximum 5ms de latence (2,5ms aller – 2,5ms retour) entre les deux sites
  • Maximum 200ms de latence (100ms aller – 100ms retour) entre un site et la VM witness
  • 10Gbps entre les deux sites VMware vSAN
  • 100Mbps entre un site et la VM witness

vSAN ROBO (Remote Office – Branch Office) 2 noeuds :

Pour le déploiement ROBO sur deux sites, les prérequis réseau sont différents :

  • Maximum 500ms entre le site ROBO et le witness
  • 1Mbps entre le site ROBO et la VM witness
  • 1Gbps entre les serveurs hôtes sur le site ROBO.

Les ports Firewall :

Lorsque vSAN est activé, plusieurs ports réseau sont automatiquement ouverts en entrée et en sortie, sur chaque serveur hôte qui participe au cluster vSAN.

Ces ports sont utilisés entre les hôtes du cluster mais aussi pour la communication avec le storage provider sur les hôtes ESXi.

Voici les ports et protocoles ouverts par vSAN :

Noms Port Protocol
CMMDS 12345 – 23451 UDP
RDT 2233 UDP
VSANVP 8080 UDP
Health Check 443 UDP

 

 

About Author

Michael PERES

Solutions Architect Specialist chez SCC

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Why ask?