L1 & L2, c’est quoi?
Les liens L1 et L2 sont des ports physiques dédiés (GbE) sur les platefome UCS Fabric Interconnect, véhiculant le traffic de heartbeat de l’application en cluster UCSM. Autant dire qu’ils sont cruciaux à la survie du cluster!
L’image du post est bien un Nexus, et ce n’est pas une erreur :-). Pour la petite histoire, les Fabric Interconnect (ou FI), sont basés sur une plateforme matérielle Nexus, adaptée pour la situation :
- Les FI Gen 1 (6100XP) sont basés sur les plateformes matérielles Nexus 5000,
- Les FI Gen 2 (6200UP) sont basés sur les plateformes matérielles Nexus 5500.
Si vous vous demandiez « à quoi servent les ports L1 & L2 sur mon joli Nexus tout neuf? », vous avez votre réponse : ils ne servent à rien (sur un Nexus). Ils sont présents depuis le début sur les Nexus, car la vision moyen terme prévoyait déjà une déclinaison du boîtier pour servir de base matérielle aux futur Fabric Interconnects.
Il faut y voir une simple rationalisation des chaînes de production : il est plus rentable de laisser ces 4 ports GbE sur l’ensemble des boites plutôt que de gérer l’exception.
Et oui, la société à la genèse de la gamme Nexus (Nuova Systems, qui a été racheté par Cisco en 2008) pensait aigle UCS dès le départ. Si l’on se penche un peu sur le parcours des fondateurs de Nuova, le puzzle devient tout de suite plus clair. Ce sont trois anciens cerveaux de chez Cisco, Mario Mazzola, Prem Jaim & Luca Cafiero, que j’aime appeler les trois mousquetaires 🙂 (même si le trio est à majorité italienne), et ils n’en sont pas à leur coup d’essai. Mais ceci est une autre histoire – à destination d’un autre billet pourquoi pas.
Pour revenir aux ports L1 & L2, tout en restant dans l’analogie avec les plateformes Nexus, les liens L1 & L2 pourrait être assimilés aux liens VPC Peer-Links, à quelques détails près. Dit comme ça, je suis certains que ça parle à tout le monde 🙂
Note : les connexions des ports L1 & L2 sur chaque FI se fait de la manière suivante :
- FI-A L1 <–> FI-B L1,
- FI-A L2 <–> FI-B L2.
Autre détail (de taille), pas de switch sur le chemin des connexions L1 & L2!!! Ces ports sont configurés en bonding et attendent à l’autre bout de la connexion : un autre Fabric Interconnect. Ne pensez pas à configurer du port-channel côté switch, placer les bons vlans, etc : c’est une configuration explicitement hors support.
Le traffic de heartbeat
UCSM est le logiciel de gestion de la plateforme UCS. Il est embarqué au sein de chaque Fabric Interconnect et fonctionne en mode Actif/Passif. La motivation et la pertinence de ce choix, plutôt que d’opter pour une application à installer ou exécuter au sein d’une VM, pourrait alimenter tout une tribu de troll.
– Ici on aime les trolls mais ils seront nourris une autre fois dans un autre billet (encore!) –
Comme toute application en cluster, un lien de signalisation est nécessaire afin de pouvoir maintenir une bonne connaissance de l’état de santé de chaque membre : cela se fait généralement via un lien de heartbeat redondé, autrement dit un bus de communication.
Nous sommes donc ici en présence d’un cluster à deux membres, et ce n’est pas un détail.
Perte d’un membre et Split-Brain
Le cluster surveille l’état de santé de chaque membre via le lien de heartbeat, et bascule les services sur un membre réputé sein en cas de panne. Sans entrer dans les détails et transformer cet article en un essai sur les clusters (c’est bien prétentieux :-)), un membre est réputé sein si le quorum (voir la définition stricte, et ne pas faire d’amalgame avec du jargon Microsoft) est atteint au sein des membres. Pour un cluster à deux membres, c’est la parole d’un bandit contre un autre … Il faut donc faire recours à un arbitre (appelé suivant les technologies : « Tie-Breaker », « Failover Monitor », etc …), afin d’éviter le phénomène de Split-brain. Dans un cluster UCSM, c’est la passerelle par défaut qui fait office d’arbitre lorsqu’un membre n’arrive pas à joindre l’autre.
Note : le cluster UCSM effectue un test supplémentaire, visant à vérifier le lien entre le FI et le/les châssis. Il s’appuie pour cela sur la SEEPROM (Serial EEPROM) : espace de stockage en mémoire non-volatile, accessible par chaque FI. L’article suivant chez UCSGuru explique un peu plus en détail les différents tests menés, ainsi que le cas particulier de serveurs C-Series (format rack), qui ne disposent pas de SEEPROM : HA with UCSM Integrated Rack Mounts.
Que se passe-t-il lorsque l’on perd les liens L1&L2 sur un cluster UCSM?
Toute cette introduction pour arriver à la question initiale. Quel est l’effet concret constaté, d’un point de vue opérateur/administrateur?
Lorsque un des deux liens n’est plus disponible, une alerte de type « majeur » est remontée dans UCSM pour chaque FI : « HA Cluster interconnect Link Failure »
- Erreur visible « immédiatement »,
- Pas d’impact sur le data path.
Lorsque les deux liens ne sont plus disponibles (L1 & L2), après une période de timeout (En minutes) :
- Une nouvelle erreur de type « Critique » est levée : « HAClusterInterconnectTotallinkfailure »,
- Le FI subordinate est déclaré « injoignable »,
- Toutes la partie B est « shut » (en admettant que c’était la partie passive (subordinate) du cluster UCSM) DATA PATH compris :
- FEX,
- Uplinks LAN & SAN.
Attention donc à vos liens L1 & L2, il faut les choyer et assurer la présence d’au-moins un lien sur deux, sinon effets surprise-party garanti!
Je n’ai malheureusement pas connaissance de la durée exacte du timeout avant coupure complète de la partie « passive ». L’ordre de grandeur est en minutes, j’essayerai de reproduire le test à l’occasion, équipé d’un super chronographe mécanique 😀
Toujours pour rester dans l’analogie avec les Nexus et le mécanisme VPC, c’est un comportement similaire qui est observé lorsque l’on perd le sacro-saint VPC Peer-Link : le secondary est sacrifié sur l’autel du split-brain.
Retour à la normale
Lorsqu’au moins un des liens est de nouveau présent :
- Resync du FI subordinate sur le primary,
- Réactivation des liens,
- Rétablissement du cluster UCSM.
Notes et recommandations sur L1&L2
- Les connexions L1-L1 et L2-L2 doivent être en DIRECT, pas de switchs sur le chemin,
- En cas de migration/déménagement, on peut être amené à fonctionner avec seulement L1, mais essayez de garder cette période aussi courte que possible et rendez lui au plus vite son copain L2,
- Média Ethernet : les limitations usuelles s’appliquent, ne dépassez pas les 100m!
Laisser un commentaire