113 lines
5.3 KiB
ReStructuredText
113 lines
5.3 KiB
ReStructuredText
VM route reflector
|
|
==================
|
|
|
|
Le route reflector est le point de rendez-vous du plan de contrôle : plutôt que de maintenir une
|
|
session entre chaque paire d'hyperviseurs, chaque hyperviseur ouvre une session vers le route
|
|
reflector, qui redistribue.
|
|
|
|
Il tourne lui-même en machine virtuelle, ce qui crée une dépendance circulaire à traiter
|
|
explicitement : la VM qui porte le plan de contrôle du cluster est hébergée par le cluster.
|
|
|
|
Adressage
|
|
---------
|
|
|
|
Le route reflector est **sur le même segment L2 que les hyperviseurs**, avec trois adresses :
|
|
|
|
.. list-table::
|
|
:header-rows: 1
|
|
:widths: 30 25 45
|
|
|
|
* - Adresse
|
|
- Interface
|
|
- Rôle
|
|
* - une adresse de ``192.168.14.0/24``
|
|
- interface principale
|
|
- celle de n'importe quelle machine du segment ; les réponses aux hyperviseurs en partent
|
|
* - ``169.254.0.3/28``
|
|
- interface principale, **adresse secondaire**
|
|
- le lien avec les routeurs de cluster (``169.254.0.1`` et ``.2``), sur le même L2
|
|
* - ``10.255.255.1/32``
|
|
- ``lo1``, interface ``dummy``
|
|
- ``router-id``, ``cluster-id`` et source des sessions EVPN ; seule route annoncée aux routeurs
|
|
|
|
Les hyperviseurs ne connaissent que la loopback : ils ouvrent leur session vers ``10.255.255.1``
|
|
par leur passerelle (``192.168.14.1``), les routeurs l'ayant apprise du route reflector en eBGP.
|
|
Aucune adresse d'hyperviseur n'est déclarée côté route reflector : il accepte toute session venant
|
|
du segment (``bgp listen range``).
|
|
|
|
L'adresse du lien est une **adresse secondaire** de l'interface principale, pas une interface à
|
|
part : même L2, même MAC sur le fil, une interface de moins qu'avec un ``ipvlan``. Elle doit
|
|
survivre aux renouvellements DHCP de l'adresse principale : la déclarer dans la configuration
|
|
réseau du système, pas la poser à la main.
|
|
|
|
.. note::
|
|
|
|
**Non vérifié sur l'image de production.** Avec NetworkManager, la forme attendue est :
|
|
|
|
.. code-block:: bash
|
|
|
|
nmcli connection modify <connexion> +ipv4.addresses 169.254.0.3/28
|
|
nmcli connection add type dummy ifname lo1 con-name lo1 \
|
|
ipv4.method manual ipv4.addresses 10.255.255.1/32 ipv6.method disabled
|
|
|
|
Ces commandes restent à valider sur l'image golden.
|
|
|
|
Configuration de FRR
|
|
--------------------
|
|
|
|
``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``.
|
|
|
|
.. literalinclude:: ../../test/e2e/topologies/frr/rr1.conf
|
|
:language: text
|
|
|
|
Ce qu'elle établit :
|
|
|
|
* **Routeurs de cluster** (groupe ``CLUSTER``) : eBGP vers l'AS 65100, avec BFD, en IPv4
|
|
unicast. Le route reflector n'annonce que sa loopback (``RR-LOOPBACK-OUT``) et **n'accepte
|
|
rien** (``NO-IN``) : il ne reçoit aucune route des routeurs.
|
|
* **Hyperviseurs** (groupe ``fabric``) : voisins dynamiques, toute session venant de
|
|
``192.168.14.0/24`` étant acceptée, jusqu'à 200. ``local-as 64600 no-prepend replace-as`` fait
|
|
que, du point de vue des hyperviseurs, la session est en iBGP dans l'AS 64600 — celui de leur
|
|
configuration — alors que le route reflector est en AS 65000 face aux routeurs.
|
|
* **EVPN** : seule famille activée vers les hyperviseurs, qui sont ses clients
|
|
(``route-reflector-client``) : il réfléchit les routes EVPN de chacun vers tous les autres.
|
|
|
|
.. warning::
|
|
|
|
**Les tunnels ne survivent pas à la perte du route reflector.** Avec un seul route reflector
|
|
et sans ``graceful-restart``, à l'arrêt de FRR sur le route reflector, la session EVPN des
|
|
hyperviseurs tombe aussitôt, FRR retire les routes apprises et, avec elles, le VTEP distant et l'entrée d'inondation du VXLAN — **plus
|
|
aucun paquet ne passe** entre hyperviseurs, à 30 s comme à 90 s. Au redémarrage de FRR sur le
|
|
route reflector, VTEP distant et trafic reviennent **31 s** plus tard. Le trafic entre VM d'un
|
|
même hyperviseur n'est pas concerné. La redondance (deux route reflectors) ou
|
|
``graceful-restart`` sont les deux leviers ; ni l'un ni l'autre n'est encore qualifié.
|
|
|
|
.. note::
|
|
|
|
**À rédiger.** Reste à documenter :
|
|
|
|
* la création de la VM : ressources, subnet et mode utilisés (``bridge``, pour pouvoir la
|
|
lancer sur n'importe quel hyperviseur), et s'il s'agit d'une VM créée par l'agent comme les
|
|
autres ou d'un cas particulier — l'image, elle, est l'image golden de :doc:`image-qcow2` ;
|
|
* la redondance : une seule VM route reflector, ou deux, et sur quels hyperviseurs ;
|
|
* la procédure de reconstruction — l'état du cluster pendant l'absence du route reflector est
|
|
décrit ci-dessus : plus de trafic entre hyperviseurs ;
|
|
* la procédure d'amorçage : ce qui fonctionne, et dans quel ordre, quand on démarre un cluster
|
|
entier depuis zéro — le premier hyperviseur n'a pas de session FRR établie tant que cette VM
|
|
n'existe pas, cf. :doc:`premier-hyperviseur`.
|
|
|
|
Points de vigilance
|
|
-------------------
|
|
|
|
.. warning::
|
|
|
|
L'agent **ne réattache pas** les VM existantes à son démarrage, et les processus QEMU ne
|
|
survivent pas à un redémarrage de l'hyperviseur. Le redémarrage de l'hyperviseur qui héberge
|
|
le route reflector est donc un événement à part entière : la procédure de remise en service
|
|
doit être écrite, et testée.
|
|
|
|
.. warning::
|
|
|
|
``instance-id`` valant le nom de la VM, recréer la VM route reflector sous le même nom sur le
|
|
même disque fait que cloud-init **ne rejoue pas** le user-data. Cf.
|
|
:doc:`/concepts/metadata-cloud-init`.
|