EDIT: j’ai eu la réponse de Cormac au sujet de la version de VSAN à partir de laquelle le comportement décrit a changé. A priori, ce serait depuis VSAN 6.2. Le plus simple serait de tester… ça tombe bien, VxRail 4.0 est basé sur du VSAN 6.2 ! On va donc tester tout de suite :)
EDIT2 du 25/01: je vous confirme, pour l’avoir testé sur notre VxRail d’admin tout neuf, que ce nouveau comportement est implémenté au moins sur VSAN 6.2. Confirmé aussi par Cormac lui-même dans les commentaires de son billet.
Cormac Hogan, blogger émérite de la scène VMware et spécialiste du stockage chez VMware a posté hier un article particulièrement intéressant au sujet des stretched clusters VSAN. A l’occasion de la mise en place d’un nouveau cluster de qualification sur une nouvelle version de VSAN (probablement la 6.5, ce n’est pas précisé mais j’ai demandé dans le flux des commentaires) il a constaté avec un collègue un changement de comportement de VSAN vis à vis des problématiques d’isolation réseau.
Je vous propose une traduction/interprétation libre de cette découverte.
Rappel du principe de Stretched Cluster VSAN
Un cluster VSAN de type “stretched” consiste à déclarer au sein de celui-ci deux “fault domain” qui regroupent chacun l’ensemble des serveurs ESXi situés dans une même salle physique (ou en tout cas, ayant une position identique en terme de PRA). VSAN s’appuie ensuite sur cette déclaration pour positionner les copies des données des VM sur chaque fault domain (sous réserve que la politique associée indique bien un FTT>0). Dit autrement, si vous déclarez une VM au sein d’un stretched cluster VSAN avec une tolérance au pannes supérieure à zéro vous aurez forcément au moins une copie sur chaque fault domain déclaré.
Enfin, comme dans toute architecture étendue de ce type, un cluster stretched nécessite forcément un witness afin de résoudre les problèmes de split brain. Prenons ce schéma de principe comme exemple :
La découverte : le comportement du witness face à l’isolation réseau à changé !
Jusqu’à présent (au moins VSAN 6.1), lorsque le witness perdait la visibilité d’un seul des deux fault domain, c’est à dire, traditionnellement, lorsqu’il perdait l’accès à une des deux salles, celui-ci générait par son propre poids, un partitionnement déséquilibré du cluster, forçant celui-ci à éteindre/couper entièrement l’accès au stockage sur la partition isolée du witness, que celle-ci soit réellement déconnectée de l’autre fault domain ou non. Il en découlait forcément un déclenchement HA sur APD (All-Path-Dead) et la relance des VMs sur la partition de plus fort poids.
Cela signifiait dans la pratique que la seule perte de connectivité du witness, même sans réelle dégradation du service VSAN actif entre les serveurs, pouvait provoquer des HA et donc de grosses perturbations sur le cluster alors que finalement, tout allait bien ou presque :
Or, depuis VSAN 6.5 (vraisemblablement, je vais me faire confirmer cela), le comportement d’isolation du witness a changé. En effet, désormais, si le witness se trouve par le hasard des incidents de liaison, isolé d’une partie du cluster mais que le cluster lui-même ne rencontre aucun souci, il en découle une isolation beaucoup plus favorable et une continuité de service :
Explication
Après constatation de ce nouveau comportement, Cormac Hogan a escaladé cela auprès d’un ingénieur développeur VSAN et a obtenu l’explication. Contrairement à précédemment, pour qu’un witness VSAN face partie d’un cluster il doit être en communication non seulement avec les noeuds primaires mais également avec les noeuds secondaires. Si ce n’est plus le cas, le witness est directement partitionné et les serveurs opérationnels restent opérationnels.
Au final, le bénéfice est réel puisque comme déjà évoqué, si le witness a des problèmes tout seul dans son coin, il ne risque pas de perturber le cluster comme il aurait pu le faire auparavant.
Le billet original de Cormac Hogan : http://cormachogan.com/2017/01/17/vsan-stretched-cluster-partition-behaviour-changes/
Je vous confirme, pour l’avoir testé sur notre VxRail d’admin tout neuf, que ce nouveau comportement est implémenté au moins sur VSAN 6.2. Confirmé aussi par Cormac lui-même dans les commentaires de son billet. Je place un edit dans le billet pour préciser.