Premier hyperviseur

Premier hyperviseur#

Le premier nœud du cluster se déploie comme les suivants, mais il est le seul à devoir fonctionner avant que le plan de contrôle existe : c’est lui qui hébergera la première VM route reflector.

Installation#

L’installation de l’agent est identique à celle d’un nœud isolé et n’est pas reprise ici : voir Installation d’un hyperviseur pour deploy.sh, ses options, la préparation de l’host et la migration réseau vers le bridge d’uplink.

Deux points à relire avant de lancer un -i sur un nœud de production : la migration réseau coupe le réseau de l’host si elle échoue à mi-parcours, et l’hyperviseur est sans état — tout ce qui est posé doit l’être par un mécanisme rejoué à chaque démarrage.

Plan de contrôle — FRR#

FRR tourne sur chaque hyperviseur et peuple la table de transfert (FDB) des interfaces VXLAN créées par l’agent. C’est ce qui rend un subnet utilisable au-delà d’un seul nœud, puisque l’agent désactive l’apprentissage et ne configure aucun voisin — cf. Architecture du cluster.

Note

À rédiger. À documenter :

  • la version de FRR de référence et son mode d’installation, sachant que l’hyperviseur est sans état : le paquet et la configuration doivent être posés à chaque démarrage, par le bootstrap ou par un mécanisme équivalent ;

  • les démons activés dans /etc/frr/daemons ;

  • la configuration de référence : numéro d’AS, session vers le route reflector, famille d’adresses utilisée pour annoncer les MAC et les VNI ;

  • l’articulation avec les interfaces créées par l’agent : comment FRR découvre une interface VXLAN qui apparaît à la création d’un subnet, et si une action est nécessaire ensuite ;

  • ce qui se passe au démarrage à froid, quand FRR démarre avant ou après l’agent ;

  • le cas particulier du premier hyperviseur, dont la session ne peut pas s’établir tant que le route reflector n’existe pas.

Vérifier le plan de données#

Ces deux vérifications restent valables quelle que soit la configuration retenue, et méritent d’être dans toute procédure de diagnostic :

# La FDB du VXLAN doit contenir des entrées vers les autres hyperviseurs.
# Vide, c'est le plan de contrôle qui ne fonctionne pas, pas l'agent.
ip netns exec <vpc> bridge fdb show dev <interface-vxlan>

# L'interface VXLAN telle que l'agent l'a créée : port 4789, learning off,
# aucun groupe multicast, aucun remote.
ip netns exec <vpc> ip -d link show <interface-vxlan>

Important

Une FDB vide alors que le subnet est en running n’est pas un défaut de l’agent : il crée délibérément l’interface sans apprentissage ni voisin, et laisse le peuplement au plan de contrôle.

Valider le nœud#

Avant de passer à la suite, le nœud doit savoir créer une VM de bout en bout à partir de l’image golden — c’est exactement le parcours de Premier VPC, premier subnet, première VM, avec storage[0].path pointant sur une copie de l’image produite par Construction de l’image qcow2.

Une VM qui démarre, obtient son adresse en DHCP et applique son user-data valide d’un coup l’agent, le DHCP, la route vers le serveur de metadata et l’image. C’est le prérequis de VM route reflector.