Les noeuds VxRail Dell EMC disposent de plusieurs options de connectivité physique au niveau du réseau. Chaque noeud est fourni avec une connectivité réseau intégrée à la carte mère, celle-ci permet de proposer 10Gbps (fibre ou cuivre) et 2 ports 1Gbps (Cuivre). Tous les ports peuvent être utilisés simultanément.

Avec la 14G, les appliances sont livrées par défaut avec 4 ports 10Gbps.

Pourquoi VxRail nécessite l’IP Multicast ?

Deux composants au sein du Cluster VxRail s’appuient sur l’IP Multicast :

• Loudmouth.
• Les services de surveillance, d’appartenance et d’annuaire de cluster (CMMDS) dans VMware VSAN utilisant la multidiffusion IPv4  valables jusqu’à la version de VxRail 4.0.xx (jusqu’à la version de VSAN 6.2). En effet, l’IP multicast pour la communication VSAN CMMDS est remplacée par la communication unicast, grâce à la version de VSAN 6.6.

Pour le Scale-Out, VxRail Manager utilise l’auto-discovery de VMware Loudmouth (port UDP 5353), basé sur le protocole « Zero Network Configuration » pour découvrir et configurer automatiquement les appliances sur le réseau. Loudmouth s’exécute sur chaque hôte ESXi et dans le VxRail Manager. Loudmouth permet à VxRail Manager de découvrir tous les nœuds et d’automatiser la configuration. Loudmouth nécessite IPv6 multicast. La communication IPv6 multicast est strictement limitée au VLAN de gestion, utilisé par les nœuds pour la communication.

• Désactiver le MLD Snooping est une méthode alternative pour permettre la multidiffusion IPv6 (attention toutefois, il peut entraîner un trafic de multidiffusion supplémentaire sur le réseau).

#show running-config mld
#show ipv6 mld_host

Virtual SAN utilise une base de données de métadata en cluster, et un service de monitoring (CMMDS) pour mettre à disposition sur chacun des hôtes les métadonnées. Le CMMDS est conçu pour être un service hautement disponible, performant et efficace en réseau; qui partage des informations sur l’hôte, le réseau, les disques, les objets, les composants, etc… parmi tous les hôtes du cluster VSAN.

VSAN exploite le transfert de multidiffusion de couche 2 pour la découverte d’hôtes et pour optimiser la consommation de bande passante réseau pour les mises à jour de métadonnées du service CMMDS (le trafic de stockage est toujours unicast). Cela élimine les pénalités de ressources informatiques et de bande passante du réseau que l’UNICAST impose pour envoyer des données identiques à plusieurs destinataires.

Mes recommandations relatives au paramétrage réseau :

• Pensez à configurer chaque interface pour qu’elle soit en trunk port.
• Assurez-vous que tous les virtual networks du VxRail (Management, vMotion, Virtual SAN, et le réseau Guest VM) soient autorisés sur ces ports.
• Ne configurez pas « port-channels » pour les ports des noeuds VxRail. Les ports réseaux des noeuds VxRail ne prennent pas en charge le LACP, et donc n’utilisent pas les channel groups.
• Gardez en tête le fait que les ports du VxRail soient configurés en mode active/standby (voir le tableau ci-dessous).

Type de trafic	conditions	UPLink 10Gb VMNIC0	UPLink 10Gb VMNIC1	UPLink 10Gb VMNIC2	UPLink 10Gb VMNIC3
Management	IPv6 multicast	Actif	Standby	non utilisé	non utilisé
vMotion		non utilisé	non utilisé	Standby	Actif
VSAN	IPv4 unicast	non utilisé	non utilisé	Actif	Standby
VM Guest OS		Standby	Actif	non utilisé	non utilisé

# switchport mode trunk
# spanning-tree shutdown
# no shutdown
# switchport trunk allowed vlan add 0,1002,1011…
# switchport trunk tag native-vlan
# switchport trunk native-vlan 0

Mes recommandations concernant le choix des switch

Au travers de mes différentes expériences sur le HCI et le SDS, j’ai trop souvent essuyé les plâtres du fait du réseau !!! Parallèlement, j’entends trop souvent que la partie Network sur le HCI se réduit à pousser du 10Gb/s ! 🙁

Comme vous l’aurez compris, VxRail s’appuie majoritairement sur le trafic réseau serveur, il est ainsi naturellement recommandé d’utiliser un commutateur de type Datacenter. Mais, pour un petit cluster en hybride (pas plus de 3 nodes), et pour des configurations n’excédant pas plus de 2 Disk Group (DG pour VxRail ou VSAN), il est tout à fait envisageable d’investir dans quelque chose de plus léger tel qu’un commutateur de type Campus. Point de vigilance cependant…

Il existe deux principales catégories de commutateurs à disposition : Campus et Datacenter.

La différence provient des diverses exigences auxquelles ils doivent répondre.

• Un commutateur Campus doit avoir un ensemble de fonctionnalités L2 / L3 / L4 très élevé, un contrôle élevé des utilisateurs sur le trafic et permet de prendre en charge une large gamme de types de ports (100Mb, 1Gb, 10Gb) et être capable de faire du POE.
• Un commutateur Datacenter doit supporter un débit élevé avec une portée entre 10Gb et 100Gb et toutes les fonctionnalités L2 / L3.

Par conséquent, les capacités des ASIC, dans ces deux catégories de commutateurs sont littéralement différentes :

• Les commutateurs de campus sont majoritairement dédiés au trafic des utilisateurs : débit faible / moyen, la plupart des flux allant vers le nord / le sud (depuis port d’accès / vers le port Uplink).
• Les commutateurs de datacenter sont plus adaptés au trafic du serveur : débit élevé, milliers de flux  allant vers le nord / sud / est / ouest

Exemples de switchs datacenter :

• Cisco Nexus 5k, 6k, 7k et 9k
• Dell EMC Serie S et Z ( S4148)
• Arista 70xx, 71xx et 72xx

Exemples de switchs Campus :

• Cisco Catalyst c2k
• Dell EMC Serie N (N4048)

Initialisation de la plateforme VxRail

Le déploiement de la plateforme VxRail n’a rien de complexe, c’est avant tout une question de préparation qui nécessite une réponse à cette interrogation : vais-je utiliser un vCenter Server en externe ou en interne ?

Dans le cadre d’un Streched Cluster, le vCenter Server doit être externe obligatoirement.

L’appliance VxRail peut joindre un vCenter Server externe déjà existant dans votre infrastructure, il peut être soit en :

• physique ou virtuel,
• Windows ou VCSA,
• Embedded ou non-embedded avec un PSC externe.

Alors quoi de neuf avec VxRail 4.5 ?

VxRail 4.5 a été annoncée en octobre 2017, depuis cette sortie, nous en sommes à la 8 ème release de cette version majeure. VxRail 4.5 ne prend pas en charge le matériel de la 1ère génération des VxRail, il en prend en charge à partir des G2 et G3 Quanta et aussi les appliances Dell PowerEdge 13G.

Avant la version 4.5, on ne pouvait étendre un cluster existant un noeud à la fois. A présent, VxRail 4.5 permet plusieurs noeuds à la fois d’être ajoutés (limite à 6 noeuds). Il est également possible toujours à partir du VxRail Manager de dé-commissionner des noeuds d’un cluster.

Désormais, avec la version VxRail 4.5, les appliances sont livrées avec des serveurs PowerEdge 14G.

Les modèles E et P peuvent bénéficier des disques cache de type NVMe (800GB et 1.6TB) pour les noeuds hybrides et full Flash. De nouvelles options de mise en réseau et de connectivité sont disponibles sur les VxRail, le 25GbE est désormais disponible (connecteur SFP28). Il ne sera pas possible de mixer les différents type de réseau (10GbE et 25GbE) au sein du même cluster.

De nouveaux disques font leur apparition avec la 14G de PowerEdge : 1.8TB 10K et 2.4TB 10K SAS.

Support  ESRS Proxy Server :  possibilité de paramétrer un proxy individuel sur VxRail Manager et ESRS.

Améliorations de VSAN 6.6

Désormais, prise en charge du nouveau format filesystem (on-disk) des diskgroup version 5, KB VMware.

vSAN on-disk version 5 amène le chiffrement natif, le chiffrement (« Encryption » en anglais) vSAN “data-at-rest” (D@RE) est maintenant une option pour les datastores vSAN. Le chiffrement des Datastores vSAN utilise une clé AES 256. Le chiffrement vSAN peut être déployée sur n’importe quel type de configuration hybrides et All-Flash. Le chiffrement vSAN est activée et configurée au niveau du Datastore vSAN.  La plupart des fournisseurs KMS sont compatibles,  spécifiquement  HyTrust, Gemalto, Thales e-Security, CloudLink, and Vormetric.

Unicast est pris en charge pour les communications vSAN, l’objectif est de réduire la complexité et la configuration du réseau, je pense notamment aux hébergeurs et Cloud Provider…

Présentation d’une target iSCSI pour les environnements physiques, vSAN 6.6 permet d’offrir aux environnements physiques via le protocole iSCSI un stockage en mode bloc.

Les versions VxRail et les niveaux de chaque composant

VxRail Release	System Version	Esxi (Version – Build #)	VxRail manager	vSAN	Internal vCSA
3.0	3.0.0.3482248	6.0 U1b – 3380124	3.0.0.3482248 (VRMe)	6.1	6.0 U1b
3.5	3.5.0.3936871	6.0 U2 – 3620759	3.5.0.3936871	6.2	6.0 U2
4.0	4.0.0-4631185	6.0 U2 P03 – 4192238	4.0.0-4631184	6.2	6.0 U2
4.0.00001	4.0.00001-4631185	6.0 U2 P04 – 4600944	4.0.0-4631184	6.2	6.0 U2
4.0.100	4.0.100-4907697	6.0 U2 P04 – 4600944	4.0.100-4907696	6.2	6.0 U2a
4.0.132	4.0.132.00000-5128178	6.0 U3 – 5050593	4.0.132-5128177	6.2	6.0 U3
4.0.200	4.0.200-5234143	6.0 EP07a – 5224934	4.0.200-5234142	6.2	6.0 U3a
4.0.300	4.0.300-5629429	6.0 P5 – 5572656	4.0.300-5629428	6.2	6.0 U3b
4.0.301	4.0.301-6026519	6.0 P5 – 5572656	4.0.301-6026518	6.2	6.0 U3b
4.0.302	4.0.302-6829778	6.0 EP11 – 6765062	4.0.302-6829777	6.2	6.0 U3b
4.0.310	4.0.310-6137115	6.0 P5 – 5572656	4.0.310-6137114	6.2	6.0 U3b
4.0.400	4.0.400-7209247	6.0 P6 – 6921384	4.0.400-7209246	6.2	6.0 U3c
4.5.070	4.5.070-6881819	6.5 EP02 – 6765664	4.5.070-6881818	6.6.1	6.5 U1a
4.5.101	4.5.101-7050966	6.5 EP04 – 6765664	4.5.101-7050966	6.6.1	6.5 U1a
4.5.150	4.5.150-7653787	6.5 P02 – 7388607	4.5.150-7653787	6.6.1	6.5 U1e
4.5.152	4.5.152-8119832	6.5 EP06 – 7967591	4.5.152-8119832	6.6.1	6.5 U1g

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

KB utiles pour VxRail:

• vSAN Health Service – Performance Service (2144403)
• vSAN Performance service is not enabled after upgrading the VMware vSAN to 6.2.x (2145179)
• On vSAN 6.6 and 6.6.1 cluster, Testing health check fails randomly (2151992)

Pour plus d’information et un retour d’expérience, je vous invite à consulter le blog vblog.io de mon ami Cédric, et notamment sur l’application de la dernière KB.