Déploiement VxRail 4.7 Stretched Cluster WTS

J’ai eu pas mal d’occasion de concevoir et d’implémenter des clusters VxRail, allant par la phase de presales jusqu’au support. Des Clusters composés de nœuds E-Series et P-Series, passant par un simple cluster vers des architectures plus complexes avec des besoins exigeants. La sécurisation de l’infrastructure représentait un défi, que ce soit par la disponibilité (DR avec RP4VM, Stretched Cluster), exposition public (DMZ: Cluster dédié ou séparation de trafic à partir de NIC dédié) ou intégration avec l’infrastructure existante. Que ce soit le besoin et les exigences, VxRail a toujours répondu à ces challenges avec un coût très compétitifs.

Avant d’entrer dans le vif du sujet, Il est à noter que des formations et certifications pour implémenter VxRail sont disponibles. Et que seules ces certifications garantie l’éligibilité de pouvoir déployer VxRail. Autrement, vous devez faire appel à un partenaire certifié. Vous pouvez vous référer aux logos de la partie droite de votre écran 🙂 Sinon, voici à quoi elles ressembles:

Il est également possible d’intégrer la communauté VxRail Xpert afin d’échanger avec une communauté d’expert VxRail à travers un Channel Slack. Des webinars sont souvent animés afin de présenter la RoadMap et les dernières nouveautés. Pour intégrer la communauté, il faut être déjà partenaire DellEMC et passer un test technique. Le lien pour plus de détails: Become a VxRail Xpert.

Avant de commencer, voici ce qu’il faut retenir du produit :

Solution hyperconvergé basé sur les produits DellEMC (Serveurs Poweredge, RecoverPoint, ESRS) et VMware (vSphere, vSAN, Log Insight)
Un support unique (un seul numéro) que ce soit pour les incidents matériel ou Software
Plusieurs modèles de nœuds disponibles :
- E-Series (Entry 1U)
- P-Series (Performance, 2U)
- V-Series (VDI, 2U)
- S-Series (Storage, 2U)
Tout les modèles sont disponibles en hybride ou Full Flash hormis le S-Series (hybride)
Une connectivité de 1G (hybride), 10G et 25G supporté
La dernière version VxRail 4.7 présente plusieurs particularités par rapport à la version 4.5 d’où :
- Un vCenter interne pour le Stretched Cluster (Un vCenter externe n’est plus obligatoire)
- La mise en place du Witness Trafic Seperation

Maintenant, nous allons voir les différentes phases de déploiement d’un VxRail Stretched cluster avec la séparation du trafic du Witness.

L’implémentation commence par l’acquisition des prérequis (NTP, DNS, adressage Mgt vMotion et vSAN, paramètres du Witness,…). Les prérequis sont tellement différentes et nombreuses que DellEMC a mis en place un fichier Excel (nommé PEQ, précédemment Preinstallation checklist) basé sur des Macros afin de centraliser toutes ces informations et pour enfin générer un fichier JSON qui nous facilitera la tâche. Voici un aperçu du fichier en comparaison de son prédécesseur:

Avant: Preinstallation Checklist (v4.5) Après: Pre-Engagement Questionnaire (v4.7)

L’installation et la configuration des ToR switch jouent un rôle crucial sur le succès d’une implémentation VxRail. Je profite de cette occasion pour remercier un de mes anciens collègues Anas Awad (CCIE R&S #62739) qui a su répondre aux challenges par lesquelles nous faisons face et avec qui j’ai beaucoup appris afin d’optimiser et suivre les best practices pour une implémentation VxRail. Une fois les prérequis réseau communiqués à l’équipe réseau (VLAN, Trunk des ports, IPV6 Multicast pour le management, IPV4 Unicast pour vSAN, etc…) et tester la joignabilité NTP, valider les entrées DNS et vérifier la disponibilité des adresses IPs, nous pouvons commencer le déploiement. Les étapes ci-dessous sont présentées après avoir câblé correctement les nœuds aux ToR et configurer les iDRAC.

1- Accès à l’installation initiale de VxRail

Pour accéder à l’installation initiale de VxRail, il faudrait se rendre à la page de bienvenue depuis un navigateur en tapant l’adresse IP 192.168.10.200. Votre laptop doit donc être obligatoirement configurer avec une IP du même réseau (par ex: 192.168.10.199) et brancher directement au ToR du VxRail. Il est possible de changer l’adresse par défaut en cas de nécessité et il faudra cependant contacter le support afin qu’il accèdent au VxRail Manager et le changer par eux mêmes.

Une fois le EULA VxRail accepter et avoir choisi la configuration (VxRail Cluster ou 2 nœuds), VxRail procédera à la découverte des noeuds à travers le processus Loudmouth. Dans notre exemple, 6 nœuds ont été installés et répartis sur 2 sites.

Comme nous pouvons le remarquer, le Stretched Cluster n’est pas proposé. Il sera possible de le configurer une fois VxRail déployé. Donc l’installation du Witness n’est pas nécessaire pour le moment, ni pendant l’étape de découverte précédente. Une fois les nœuds sont affichés au complet, on choisi le mode de configuration: soit manuel, qui nécessite la saisie de toute la configuration manuellement, soit via le fichier JSON généré depuis le PEQ:

Personnellement, j’ai toujours opté pour la seconde option qui permet de remplir les champs automatiquement et ainsi gagner du temps.

La première page de configuration comporte le NTP et les NIC sur lesquelles le réseau de Management, vSAN et vMotion seront déployés:

Ensuite le domaine, les règles de nommage et adresses IP des ESXi et du vCenter:

Configuration du PSC, VxRail Manager, du réseau de Management et DNS. Il est à noter que le PSC est livré en externe avec VxRail. A partir de la version 6.7 de vCenter, le PSC externe n’est pas supporté. J’ai contacté le support à ce sujet et ils m’ont confirmé que le PSC externe est supporté pour le cas de VxRail et que le Embeded PSC sera disponible dans les prochaines release VxRail. Donc inutile de penser à converger le PSC 🙂 .

Configuration vMotion:

Configuration vSAN:

Configuration des VM Network

Configuration du Log Insight

Configuration des comptes et des mots de passe

Les paramètres requis ont été introduits, le VxRail procèdera à la validation de la configuration avant de procéder au déploiement. Le processus de validation consiste à vérifier la disponibilité des paramètres ainsi que la consistance de la configuration. Si la validation échoue pour n’importe quelle raison (indisponibilité DNS par exemple) il sera impossible de passer à l’étape suivante tant que le problème n’est pas résolu.

Maintenant que l’étape de validation est finalisée, nous pouvons lancer le déploiement qui prends en moyenne 2 heures

Une fois le déploiement finalisé, un jolie petit message nous l’indique

2- Déploiement du Stretched Cluster

Nous avons désormais la possibilité d’accéder au vCenter via l’adresse préalablement configurée.

Nous constatons la présence du DC, Cluster et des noeuds qui respectent la règle de nommage introduite pendant la configuration. Nous remarquons également la présence de 4 VMs:

VMware vCenter Server Appliance
VMware vCenter Server Platform Services Controller
VMware vRealize Log Insight
VxRail Manager

Avant de configurer le Stretched Cluster, nous ajoutons d’abord le Witness au vCenter. Le Witness a été déployé sur un 3ème site qui est complétement indépendant des 2 sites. Nous l’ajoutons au vCenter en tant que hôte après avoir créé un Datacenter dédié au Witness. Le witness peut être physique (licence requise) ou virtuelle (pas de licence requise).

Le Witness ajouté, nous procédons ensuite par configurer le réseau vSAN du Witness sur le second adaptateur VMkernel.

Ces information se trouvent sur le PEQ

Toujours avant d’activer le Stretched Cluster, nous allons d’abord séparer le trafic Witness du réseau vSAN. Cette manipulation n’est pas obligatoire mais recommandée. Pour celà, nous allons procéder par créer 2 nouveaux port group depuis le DVS Vxrail préalablement créé en lui assignant le nom du port group, le VLAN ID et les membres du port group (1 port group pour chaque site). Ensuite, nous procédons par la configuration des adaptateurs VMkernel de chaque port group:

Une fois les port group configurés, nous activons le trafic Witness sur le VMkernel de Management sur chaque nœud ESXi d’où le # représente le numéro du port VMkernel de Management. Se connecter en SSH et taper la commande:

esxcli vsan network ip add -i vmk# -T=witness

Sur la capture ci-dessous, nous démontrons l’état avant et après l’activation du trafic Witness. Nous constatons que uniquement le trafic vSAN était activé:

Pour vérifier la configuration, nous testons la joignabilité du Witness depuis le VMkernel de management sur lequel nous avons activé le trafic Witness d’un ESXi.

Pour le cas d’utilisation d’un réseau L3, il suffit d’ajouter des route static sur le Witness et chaque nœud ESXi afin qu’il puissent communiquer. La commande:

[ESXi] esxcli network ip route ipv4 add -n <Site Witness Traffic Subnet/24>-g <Witness vSAN Gateway>

[Witness] esxcli network ip route ipv4 add -n < Witness vSAN Subnet/24>-g < Site Witness Traffic Subne Gateway>

Nous procédons ensuite par configurer le Stretched Cluster. Se rendre sur configuration vSAN: Fault Domain du Cluster

Le process consiste à ajouter le Witness et répartir les nœuds de chaque site en configurant les fault domain vSAN: définir le preferred et le secondary fault domain. Pour notre cas, nous avons 2 sites et chaque site comporte 3 nœuds