Ne sous-estimez pas la consommation réseau de VSAN…

A l’occasion de la migration de l’ensemble de notre environnement Exchange (6 serveurs de production, 3 serveurs d’archive, quelques dizaines de To et pas moins de 16000 BALs, tout de même), j’ai été confronté, pour la première fois, à des limites sur notre cluster VxRail principal, dit “le monstre”, dont j’ai déjà longuement parlé depuis environ un an. Plus exactement, ce n’est pas le cluster VSAN lui-même qui a atteint ses limites, mais plutôt le réseau DataCenter sur lequel nous l’avons bâti !

Vous le savez sans doute, si vous avez du VSAN chez vous, le SDS de VMware dispose de toute une batterie de paramètres permettant de définir très précisément la politique de stockage de chaque VM en fonction de son niveau de criticité, redondage, qualité de service souhaité, consommation d’espace etc. Etant donné que nous disposons d’un stretched cluster, on est capable d’aller encore plus loin en indiquant le niveau de plan de secours à appliquer sur chaque machine : ses données doivent-elles être répliquées entre les deux domaines, ou seulement sur un seul, typiquement.

Il se trouve que, dans le cas qui nous occupe, nous avons beaucoup de machines Exchange, précisément pour assurer un niveau de tolérance aux pannes suffisant en cas de défaillance d’un des sites, les bases de données Exchange étant répliquées 3 fois sur l’ensemble des 6 machines principales (via une matrice d’équilibrage). Or, pendant la phase de migration proprement dite, nous avions simplifié les choses au maximum pour le déménagement de chaque serveur et laissé la politique par défaut, PFTT=1 SFTT=0 (la procédure en question étant déjà assez complexe et IO intensive, en raison de notre choix de re-seeder l’ensemble des bases exchange à cette occasion).

Une fois cette grosse opération terminée, j’ai donc préparé les serveurs en question à leur “destination finale” c’est à dire une Storage Policy de type : PFTT=0 SFTT=1 associée à une redondance locale de type Erasure Coding, vue la grosse volumétrie de chaque machine. Mais comme de bien entendu, je n’avais pas anticipé que l’application de cette nouvelle politique à toutes les machines en même temps aurait posé un quelconque souci et que VSAN se serait illico attaché à les remettre en conformité toutes en parallèle ! Grosse erreur de ma part …

En effet, au bout de quelques minutes, nous avons reçu des appels de certains utilisateurs nous informant de gros ralentissements sur certaines applications. Concomitamment, certains graphiques réseau commençaient à s’affoler… Nous avons très vite identifié la cause, forcément : VSAN saturait une grosse partie de ses liaisons réseau ! Cette machine diabolique générait quasiment 40 Gbit/s soit environ 4,5 Go/s sur chacune de nos salles, provoquant des congestions sur les accès applicatifs des VMs.

Immédiatement, j’ai appliqué la contre-mesure : la limitation de bande passante allouée pour le resync VSAN (le resync concerne autant la reconstruction lors de pertes de disques et/ou serveurs que les modifications dans les Storage Policies ou même le Re-balancing). L’effet a été bénéfique dans l’instant puisque tout est revenu à la normale en quelques minutes. Au final, plus de peur que de mal, mais une grosse frayeur malgré tout…

NDLR : Du coup, forcément, j’ai encore appris plein de choses sur le pilotage de VSAN et nous avons par ailleurs – roue de Deming oblige – des pistes précises pour éviter que cela ne se reproduise, je vous en reparle en fin d’article.

Même si les choses étaient désormais sous contrôle, je voulais absolument disposer d’un moyen rapide et efficace de suivre ses grosses manoeuvres back-end sur VSAN pour ne plus être aveugle à l’avenir. J’ai creusé rapidement la piste réseau et j’ai construit un dashboard VRops spécifique pour suivre globalement l’activité réseau de notre cluster :

… Vous avez sur ces deux graphiques l’ensemble des deux derniers jours de cette semaine. Vous pouvez remarquer le joli pic de saturation bien plat de Jeudi midi. On le voit bien hein ? Ouh qu’il est beau … (ce tableau de bord est relativement simple à réaliser en fait, il suffit d’agréger le débit réseau global de l’ensemble des machines).

J’ai également trouvé facilement des petites commandes esxcli (elles doivent exister aussi sous PowerCLI) pour tracer l’activité de reconstruction/ré-équilibrage. Vous disposez en particulier de quelques commandes bien utiles:
esxcli vsan debug resync list : vous affiche la liste des objets VSAN faisant l’objet d’une reconstruction/mise à jour.
esxcli vsan debug resync summary get : vous affiche un résumé des opérations avec la volumétrie restant à traiter.
esxcli vsan resync throttle get : la limite de traffic actuelle de l’ESXi sur lequel vous vous trouvez.
esxcli vsan resync bandwidth get : la bande passante actuelle consommée par l’ESXi pour les activités back-end de VSAN.

Voici ce que ça donne dans la pratique :

Vous disposez aussi, dans la section “Cluster->Monitor->VSAN->Resyncing components”, d’un bouton “Resync Throttling” qui vous affiche la liste de tous les hosts et leur consommation instantanée :

Au final, ce coup de chaud récent nous a fait prendre conscience de plusieurs choses.

D’une part que nous avions, en présence de notre cluster de 20 Noeuds full flash, un monstre de performance (on en avait déjà une certaine idée, mais rien de vraiment “atteignable” au départ) capable de saturer gentiment, OKLM, une grande partie de nos liaisons DataCenter. Oui, d’ailleurs, j’ai oublié de préciser que pendant que VSAN faisait ses petites affaires sympathiques, la latence disque (back-end donc) n’a jamais dépassé les 600/700 micro-secondes… autant dire qu’il en avait encore sous la pédale, s’il avait pu disposer de plus de bande passante ! Ca laisse rêveur.

Ensuite, que nous savons désormais quelles sont les limites de notre infra aujourd’hui s’il on veut progresser encore en terme de qualité de service : l’architecture réseau de notre DataCenter, basée sur des choix réalisés il y a déjà quasiment 5 ans et qu’il faut, sinon repenser, du moins adapter aux nouvelles exigences de ces nouveaux ensemble scale-out basés sur IP.

Enfin, de manière plus concrète et court terme, il va nous falloir rapidement faire évoluer la partie interconnexion locale des serveurs de notre VxRail. Aujourd’hui, en raison de l’architecture actuelle de notre réseau DataCenter “Nexus 7000 – 5000 – 2000”, tous les échanges entre machines remontent inévitablement à travers les interconnexion entre nos Top-of-rack Nexus 2000 et les agrégateurs Nexus 5000. Nous allons vraisemblablement mettre en oeuvre deux étapes : d’abord ajouter des liaisons uplink vers nos 5000 pour passer de 4×10 Gbit/s actuellement à 8×10 (afin de repousser la limite actuelle) ; ensuite, acheter des switchs dédiés pour chaque ensemble de machines afin qu’au moins les échanges locaux restent sur les switchs et ne remontent pas vers les 5000.

Qu’en pensez-vous ? Que d’aventures !