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.

Configuration de FRR#

Seul bgpd est activé dans /etc/frr/daemons. D’un hyperviseur à l’autre ne changent que hostname et router-id, l’adresse de l’hyperviseur sur son segment.

frr defaults traditional
hostname hv1
log syslog informational
!
router bgp 64600
 bgp router-id 192.168.14.11
 no bgp default ipv4-unicast
 neighbor fabric peer-group
 neighbor fabric remote-as 64600
 neighbor fabric capability extended-nexthop
 neighbor 10.255.255.1 peer-group fabric
 !
 address-family l2vpn evpn
  neighbor fabric activate
  advertise-all-vni
 exit-address-family
 !
exit
!

Ce qu’elle établit :

  • Une seule session, en iBGP dans l’AS 64600, vers la loopback du route reflector (10.255.255.1), jointe par la passerelle par défaut — le routeur de cluster l’a apprise du route reflector (Routeurs). Aucune adresse d’un autre hyperviseur n’est écrite : ajouter un nœud ne touche pas la configuration des autres.

  • EVPN seulement : l’IPv4 unicast n’est pas activé (no bgp default ipv4-unicast). advertise-all-vni annonce les VNI de toutes les interfaces VXLAN que FRR voit, et donc celles que l’agent crée.

  • Pas de BFD sur cette session, contrairement à la session entre route reflector et routeur.

Articulation avec l’agent#

Rien à configurer à la création d’un subnet : la VXLAN apparaît, FRR la voit et l’annonce, sans action ni redémarrage. Il faut en revanche que la VXLAN porte une adresse VTEP locale : sans elle, FRR voit la VNI mais n’annonce rien, et deux hyperviseurs gérés par two ne se joignent pas. L’agent la pose à partir de la release 0.2.0rc003 (#51) : l’adresse IPv4 primaire du local_iface du subnet.

Note

À rédiger. Reste à documenter :

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

  • le démarrage à froid, selon que FRR démarre avant ou après l’agent ;

  • les subnets vxlan créés avant 0.2.0rc003, dont la VXLAN n’a pas d’adresse VTEP locale : les recréer ou poser l’adresse à chaud, à trancher dans #51 ;

  • 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.