syonad/two
2
0
Fork 0
Code Issues 17 Pull requests 1 Projects Releases 4 Packages Wiki Activity Actions

docs: build de df6c90d216

Browse source
This commit is contained in:
forgejo-actions 2026-09-09 21:10:00 +00:00
commit 4419d6ef68
193 changed files with 33340 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

98
_sources/deploiement/architecture-cluster.rst Normal file
View file

@ -0,0 +1,98 @@
Architecture du cluster
=======================
Topologie
---------
.. figure:: /schemas/topologie-cluster.svg
:alt: Topologie du cluster : routeurs, route reflector et hyperviseurs
:align: center
:width: 100%
:class: only-light
Topologie cible. Trait plein : plan de données. Trait pointillé : plan de contrôle.
.. figure:: /schemas/topologie-cluster-dark.svg
:alt: Topologie du cluster : routeurs, route reflector et hyperviseurs
:align: center
:width: 100%
:class: only-dark
Topologie cible. Trait plein : plan de données. Trait pointillé : plan de contrôle.
Deux plans distincts, à ne pas confondre au moment du diagnostic :
Plan de données
les tunnels VXLAN entre hyperviseurs, encapsulés sur le réseau qui les relie.
Plan de contrôle
ce qui dit à chaque hyperviseur où se trouvent les adresses MAC des autres. C'est le rôle de
FRR et du route reflector.
Ce que l'agent suppose déjà en place
------------------------------------
L'agent ne configure **que** son propre hyperviseur, et seulement à partir du bridge d'uplink.
Tout ce qui est en amont — adressage des hyperviseurs, routage entre eux, plan de contrôle — lui
préexiste et n'est jamais créé ni vérifié par lui.
Concrètement, il attend :
* le bridge d'uplink de la configuration (``br-000000`` par défaut), avec l'interface physique
esclave et l'adresse de l'hyperviseur portée par le bridge — c'est ce que fait
``deploy.sh --bootstrap``, voir :doc:`/demarrage/installation` ;
* une connectivité IP entre hyperviseurs sur cette adresse, port UDP **4789** ouvert dans les
deux sens ;
* un plan de contrôle qui peuple la table de transfert VXLAN — voir ci-dessous.
Pourquoi un plan de contrôle est nécessaire
-------------------------------------------
L'agent crée les interfaces VXLAN sur le port 4789 **sans groupe multicast et avec
l'apprentissage désactivé** (``Learning: false``). Il n'y a donc ni inondation multicast, ni
apprentissage des adresses MAC depuis le trafic, ni voisin statique configuré.
.. important::
Conséquence directe : sur un même VNI, **rien ne traverse d'un hyperviseur à l'autre** tant
qu'un composant externe n'a pas peuplé la table de transfert (FDB) du VXLAN. Sur un nœud
isolé le trafic reste sur le bridge local et cette absence ne se voit pas ; elle apparaît dès
le deuxième nœud.
C'est exactement le rôle que remplissent FRR sur chaque hyperviseur et le route reflector qui
les fait converger.
MTU
---
.. warning::
L'agent crée bridges, veth et interfaces VXLAN avec un **MTU figé à 1500**. VXLAN ajoute 50
octets d'encapsulation : le réseau qui relie les hyperviseurs doit donc accepter au moins
**1550 octets** de MTU, sinon les paquets pleine taille des VM sont perdus.
Le symptôme est trompeur : le ping passe, les petites requêtes passent, les transferts
volumineux et les poignées de main TLS échouent.
Hyperviseurs sans état
----------------------
L'hyperviseur est **stateless** — sa racine est en tmpfs, rien de ce que pose
``deploy.sh --bootstrap`` ne survit à un redémarrage, et le script est rejoué à chaque démarrage.
Toute configuration ajoutée à un hyperviseur — FRR compris — doit donc être posée par un
mécanisme rejouable au démarrage, jamais par une modification manuelle d'un fichier sous
``/etc``.
Adressage
---------
.. note::
**À rédiger** — cette page ne décrit pas encore le plan d'adressage du cluster. À documenter :
* la plage utilisée pour les adresses d'hyperviseurs, et son rapport avec ``br-000000`` ;
* l'allocation des VNI VXLAN : qui la tient, et comment on évite les collisions, puisque
l'agent ne valide pas ``vxlan_id`` ;
* l'usage prévu de ``br-public``, créé vide et réservé par le bootstrap ;
* le plan d'adressage des VPC, et ce qui garantit qu'ils ne se recouvrent pas entre clients.

337
_sources/deploiement/image-qcow2.rst Normal file
View file

@ -0,0 +1,337 @@
Construction de l'image qcow2
=============================
Toutes les VM du cluster — ``intel``, PostgreSQL, route reflector et les suivantes — partent
d'une même image qcow2 « golden », construite une fois puis réutilisée. Cette page décrit la
procédure en service.
.. important::
Cette image est un **artefact redistribuable** : tout ce qui s'y trouve se retrouve dans
chaque VM qui en dérive. Les étapes de nettoyage de la fin ne sont pas une commodité, ce sont
des exigences.
Principe
--------
La construction se fait dans une **VM jetable**, et non par montage de l'image sur l'host : le
chroot a besoin d'un noyau et d'un espace utilisateur cohérents avec la distribution cible, ce
que l'host ne fournit pas nécessairement.
Cette VM de construction démarre sur un overlay de l'image du fournisseur et voit deux disques
supplémentaires : le futur disque « golden », et un espace de travail.
.. mermaid::
graph LR
ISO["seed.iso<br/>cloud-init NoCloud"] --> BVM
OVL["&lt;os&gt;-tmp.qcow2<br/><i>overlay, jetable</i>"] --> BVM["VM de construction"]
BVM --> ROOT["&lt;os&gt;-root.qcow2<br/><b>image golden</b>"]
BVM --> WORK["tmp.qcow2<br/><i>espace de travail</i>"]
BASE["image du fournisseur<br/>(qcow2)"] -.backing file.-> OVL
.. list-table::
:header-rows: 1
:widths: 26 20 54
* - Disque
- Vu dans la VM
- Rôle
* - ``<os>-tmp.qcow2``
- ``vda`` (virtio-blk)
- système de la VM de construction ; overlay de l'image du fournisseur, jeté à la fin
* - ``<os>-root.qcow2``
- ``sda`` (SCSI)
- **le résultat** : l'image golden, écrite en brut depuis la VM
* - ``tmp.qcow2``
- ``sdb`` (SCSI)
- espace de travail : téléchargement et conversion
Variables
---------
.. code-block:: bash
export os=<nom_os>
export os_link=<url_du_qcow2_fournisseur>
export os_file=<nom_du_fichier_qcow2>
export os_dir=<repertoire_de_telechargement>
export disk_dir=<repertoire_des_disques>
Étape 1 — Le seed cloud-init de la VM de construction
------------------------------------------------------
Ce seed ne concerne **que la VM de construction**. Il n'a aucun rapport avec la configuration
cloud-init de l'image produite, qui est posée plus loin en chroot. Son seul rôle est de donner
un accès à la VM le temps du build.
.. code-block:: bash
mkdir -p "${os_dir}" && cd "${os_dir}"
mkdir -p /opt/seed/${os}
cat << 'ENDFILE' > /opt/seed/${os}/meta-data
instance-id: iid-local01
local-hostname: my-vm-01
ENDFILE
cat << 'ENDFILE' > /opt/seed/${os}/network-config
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: true
ENDFILE
cat << 'ENDFILE' > /opt/seed/${os}/user-data
#cloud-config
users:
- name: <utilisateur>
lock_passwd: false
passwd: "<hash du mot de passe>"
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- <clé publique ssh>
ENDFILE
mkisofs -o /opt/seed/${os}_seed.iso -V cidata -J -r /opt/seed/${os}/
Le label de volume ``cidata`` n'est pas décoratif : c'est ce qui fait reconnaître l'ISO comme une
source NoCloud par cloud-init.
.. warning::
``passwd`` attend un **hash**, et ``ssh_authorized_keys`` une clé publique personnelle : ces
deux valeurs sont des données à ne pas recopier hors de l'host de construction. Elles ne
figurent volontairement pas dans cette documentation.
``openssl passwd -5`` pour generer un hash
Étape 2 — Les disques
---------------------
.. code-block:: bash
curl "${os_link}" -O
qemu-img create -f qcow2 "${disk_dir}/${os}-root.qcow2" 10G
qemu-img create -f qcow2 "${disk_dir}/tmp.qcow2" 50G
qemu-img create -f qcow2 -b "${os_dir}/${os_file}" -F qcow2 "${disk_dir}/${os}-tmp.qcow2" 10G
.. important::
``-F qcow2`` est **obligatoire** sur qemu récent : sans lui, le format du backing file n'est
pas figé dans l'en-tête de l'overlay.
La taille de ``<os>-root.qcow2`` (10 Gio ici) borne l'image produite : elle doit être au moins
égale à la taille **virtuelle** de l'image du fournisseur, pas à la taille de son fichier.
Étape 3 — Lancer la VM de construction
--------------------------------------
.. code-block:: bash
qemu-system-x86_64 \
-enable-kvm \
-cpu host \
-m 2048 \
-smp 2 \
-nographic \
-serial mon:stdio \
-monitor unix:/tmp/vm-build.mon-sock,server,nowait \
-drive file=/opt/seed/${os}_seed.iso,media=cdrom,if=ide \
\
-drive file=${disk_dir}/${os}-tmp.qcow2,format=qcow2,if=none,id=vda \
-device virtio-blk-pci,drive=vda,bootindex=0 \
\
-device virtio-scsi-pci,id=scsi0 \
\
-drive file=${disk_dir}/${os}-root.qcow2,if=none,id=hd0 \
-device scsi-hd,drive=hd0,bus=scsi0.0 \
\
-drive file=${disk_dir}/tmp.qcow2,if=none,id=hd1 \
-device scsi-hd,drive=hd1,bus=scsi0.0 \
\
-netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
-device virtio-net-pci,netdev=net0,mac=00:22:33:00:00:01
La répartition virtio-blk pour le système / SCSI pour les disques supplémentaires est la même que
celle qu'impose l'agent — voir :doc:`/architecture/contraintes`. Le tap ``tap0`` doit exister et
être raccordé à un réseau qui donne un accès sortant : la suite télécharge l'image du
fournisseur depuis la VM.
Étape 4 — Écrire l'image du fournisseur sur le disque cible
------------------------------------------------------------
Les commandes suivantes s'exécutent **dans la VM de construction**. Identifier d'abord les
disques : le disque de travail et le disque cible ne doivent pas être confondus.
.. danger::
``qemu-img convert`` écrase intégralement le disque cible. Vérifier les noms avant, avec
``lsblk``, plutôt que de supposer l'ordre d'énumération.
.. code-block:: bash
work_disk=/dev/sdb
os_disk=/dev/sda
mkdir /work
mkfs.xfs ${work_disk}
mount ${work_disk} /work
cd /work
curl "${os_link}" -O
qemu-img convert ./*.qcow2 -O raw ${os_disk}
L'image du fournisseur est écrite **en brut** directement sur le disque cible : le qcow2 obtenu
côté host contient donc une image disque complète et amorçable, sans backing file.
.. code-block:: bash
partprobe
echo 1 > /sys/block/sda/device/rescan
sleep 2
# La partition racine est la plus grande du disque
root_partition=$(fdisk -lo device,size /dev/sda | grep -E '^\/dev\/' | tr -s ' ' \
| sort -rhk2 | head -n1 | cut -d ' ' -f1)
mount -o nouuid $root_partition /mnt
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
cp /etc/resolv.conf /mnt/etc/resolv.conf
``-o nouuid`` est nécessaire parce que le système de fichiers qui vient d'être écrit porte le
même UUID que celui déjà monté par la VM de construction. Le ``resolv.conf`` est copié pour que
les commandes en chroot aient la résolution DNS ; il est supprimé au nettoyage.
Étape 5 — Personnaliser l'image
-------------------------------
**Accès SSH**
.. code-block:: bash
yum install -y augeas
echo "The default user for Syonad VMs is 'syonad'." > /mnt/etc/banner
augtool -r /mnt -s <<'EOF'
set /files/etc/ssh/sshd_config/X11Forwarding no
set /files/etc/ssh/sshd_config/PermitTunnel no
set /files/etc/ssh/sshd_config/PermitRootLogin no
set /files/etc/ssh/sshd_config/RSAAuthentication yes
set /files/etc/ssh/sshd_config/PubkeyAuthentication yes
set /files/etc/ssh/sshd_config/PasswordAuthentication no
set /files/etc/ssh/sshd_config/UseDNS no
set /files/etc/ssh/sshd_config/ChallengeResponseAuthentication no
set /files/etc/ssh/sshd_config/GSSAPIAuthentication no
set /files/etc/ssh/sshd_config/Match[1]/Condition/User "root,centos,ubuntu,debian,ec2-user"
set /files/etc/ssh/sshd_config/Match[1]/Settings/Banner "/etc/banner"
EOF
``PasswordAuthentication no`` vaut pour toutes les VM dérivées : l'accès se fait par clé, et le
champ ``password`` de l'API de l'agent ne sert donc **pas** à ouvrir une session SSH.
**Utilisateur par défaut et source de metadata**
.. code-block:: bash
cat << 'ENDFILE' > /mnt/etc/cloud/cloud.cfg.d/20_user.cfg
system_info:
default_user:
name: syonad
ENDFILE
cat << 'ENDFILE' > /mnt/etc/cloud/cloud.cfg.d/99_metadata.cfg
datasource_list: [ NoCloud ]
datasource:
NoCloud:
seedfrom: 'http://169.254.169.254:80'
timeout: 5
max_wait: 10
ENDFILE
C'est ce second fichier qui raccorde l'image au serveur de metadata de l'agent : ``NoCloud`` est
la seule source retenue, et elle pointe sur ``169.254.169.254``. La route ``/32`` vers cette
adresse est indispensable côté agent — voir :doc:`/concepts/modes-reseau`.
**Services et durcissement**
.. code-block:: bash
chroot /mnt/ systemctl enable fstrim.timer
chroot /mnt/ systemctl disable rpcbind.service
chroot /mnt/ systemctl disable rpcbind.socket
augtool -r /mnt -s set /files/etc/selinux/config/SELINUX disabled
chroot /mnt/ dnf remove -y 'cockpit*'
chroot /mnt/ rm -rf /run/cockpit
Étape 6 — Nettoyer, puis éteindre
---------------------------------
.. code-block:: bash
rm -f /mnt/etc/resolv.conf
rm -rf /mnt/var/cache/yum
rm -rf /mnt/root/.ssh
rm -rf /mnt/root/.bash_history
rm -rf /mnt/tmp/*
rm -rf /mnt/var/lib/dhcp/*
rm -rf /mnt/var/tmp/*
find /mnt/var/log ! -type d -exec rm '{}' \;
rm -rf /mnt/var/lib/cloud/*
poweroff
``/mnt/var/lib/cloud/*`` est le nettoyage le plus important : c'est lui qui fait que cloud-init
considère chaque VM dérivée comme une instance neuve. Sans lui, l'image embarque l'identité de
l'instance de construction et le user-data n'est pas appliqué — même mécanisme que la
recréation d'une VM sous un nom déjà utilisé, cf. :doc:`/concepts/metadata-cloud-init`.
Une fois la VM éteinte, ``${disk_dir}/${os}-root.qcow2`` est l'image golden.
``${os}-tmp.qcow2`` et ``tmp.qcow2`` sont jetables.
Points de vigilance
-------------------
.. warning::
**SELinux est désactivé** dans l'image. C'est une couche de protection en moins sur toutes les
VM qui en dérivent, y compris celles qui portent des fonctions sensibles comme le route
reflector ou la base de données. Décision à assumer explicitement, et à réévaluer : le mode
``permissive`` permettrait au minimum de savoir ce qui serait bloqué.
.. note::
``fstrim.timer`` est activé dans l'image, mais l'agent lance QEMU **sans** ``discard=unmap``
ni ``detect-zeroes=unmap`` sur les disques. Le ``fstrim`` du guest ne rend donc aujourd'hui
aucun espace à l'host : les qcow2 ne se rétractent pas. L'activation reste utile pour le jour
où l'option sera ajoutée côté agent, mais ne pas compter dessus pour la place disque.
.. note::
**À vérifier** — ``seedfrom`` sans barre oblique finale. cloud-init construit l'URL des
documents en concaténant ``seedfrom`` avec ``meta-data`` et ``user-data``. Confirmer sur une
VM réelle que les deux documents sont bien récupérés, et corriger en
``http://169.254.169.254:80/`` si ce n'est pas le cas.
.. note::
**Provenance de l'image du fournisseur** — tout ce qui est construit en hérite. Vérifier la
somme de contrôle, et la signature quand elle existe, avant de construire dessus. La
procédure actuelle télécharge l'image deux fois, une fois sur l'host et une fois dans la VM,
sans vérification.
.. note::
**À rédiger** — la procédure ne dit pas encore comment l'image produite est nommée, versionnée
et distribuée aux hyperviseurs, ni quelles variantes existent par rôle (``intel``, PostgreSQL,
route reflector) : image unique personnalisée au démarrage par cloud-init, ou images
dérivées ?

32
_sources/deploiement/index.rst Normal file
View file

@ -0,0 +1,32 @@
Déploiement d'un cluster
========================
Le :doc:`/demarrage/index` couvre un hyperviseur isolé : un VPC, un subnet, une VM, tout sur le
même nœud. Cette section couvre la mise en place d'un **cluster** complet, dans l'ordre où les
étapes se font.
Cet ordre n'est pas indifférent : chaque étape a besoin de la précédente. L'image doit exister
avant qu'on puisse démarrer quoi que ce soit ; le réseau doit être en place avant le premier
hyperviseur ; le route reflector est lui-même une VM, il lui faut donc un hyperviseur qui
fonctionne.
Étapes
------
#. :doc:`architecture-cluster` — la topologie cible, à lire avant tout le reste
#. :doc:`image-qcow2` — l'image golden dont dérivent toutes les VM du cluster
#. :doc:`routeurs` — le matériel : routeurs de cluster, de datacentre et de bordure
#. :doc:`premier-hyperviseur` — le premier nœud, agent et plan de contrôle
#. :doc:`route-reflector` — les VM route reflector
D'autres étapes viendront à mesure que les composants d'orchestration seront livrés.
.. toctree::
:hidden:
:maxdepth: 1
architecture-cluster
image-qcow2
routeurs
premier-hyperviseur
route-reflector

74
_sources/deploiement/premier-hyperviseur.rst Normal file
View file

@ -0,0 +1,74 @@
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 :doc:`/demarrage/installation` 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.
:doc:`architecture-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 :
.. code-block:: bash
# 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 :doc:`/demarrage/premier-vpc`, avec
``storage[0].path`` pointant sur une copie de l'image produite par :doc:`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
:doc:`route-reflector`.

42
_sources/deploiement/route-reflector.rst Normal file
View file

@ -0,0 +1,42 @@
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.
.. note::
**À rédiger.** À documenter :
* la création de la VM : ressources, subnet et mode utilisés, 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` ;
* son adressage, et comment les hyperviseurs le connaissent ;
* la configuration du démon de routage qu'elle héberge ;
* la redondance : une seule VM route reflector, ou deux, et sur quels hyperviseurs ;
* la procédure de reconstruction, et l'état du cluster pendant que le route reflector est
absent — les tunnels déjà établis continuent-ils de fonctionner, et pendant combien de
temps ;
* 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`.

51
_sources/deploiement/routeurs.rst Normal file
View file

@ -0,0 +1,51 @@
Routeurs
========
Trois niveaux de routage entourent le cluster, du plus proche des hyperviseurs au plus proche de
l'extérieur. Tous préexistent à l'agent : celui-ci ne les configure pas et n'en a aucune
connaissance.
Routeurs de cluster
raccordent les hyperviseurs entre eux. C'est le niveau dont dépend directement le plan de
données VXLAN.
Routeurs de datacentre
agrègent les clusters d'un même site.
Routeurs de bordure
terminent le routage vers l'extérieur.
.. note::
**À rédiger.** Cette page attend les éléments de terrain. Pour chacun des trois niveaux :
* le matériel ou le logiciel employé, et la version de référence ;
* la configuration de référence : interfaces, adressage, protocole de routage et numéros
d'AS ;
* la redondance : combien d'équipements, quel mécanisme de bascule, quel comportement attendu
pendant une bascule ;
* ce qui est annoncé et ce qui est filtré à chaque niveau ;
* l'ordre de mise en service, et ce qui doit être opérationnel avant de préparer le premier
hyperviseur.
Contraintes imposées par le reste du cluster
---------------------------------------------
Indépendamment des choix d'équipement, deux contraintes viennent de ce que fait l'agent.
.. warning::
**MTU** — l'agent crée bridges, veth et interfaces VXLAN avec un MTU figé à 1500, et VXLAN
ajoute 50 octets d'encapsulation. Les liens entre hyperviseurs doivent donc accepter au moins
**1550 octets**. Cf. :doc:`architecture-cluster`.
.. warning::
**UDP 4789** doit passer entre hyperviseurs, dans les deux sens : c'est le port des tunnels
VXLAN.
.. warning::
**L'API de l'agent n'a aucune authentification.** Le filtrage réalisé ici est aujourd'hui
l'une des rares barrières entre cette API et le reste du réseau : son port ne doit être
joignable que depuis le réseau d'administration. Cf. :doc:`/exploitation/configuration`.