From 45f8e43de870023b9341e118232f3db217eb276c Mon Sep 17 00:00:00 2001 From: GnomeZworc Date: Thu, 27 Aug 2026 23:54:07 +0200 Subject: [PATCH] docs: configuration for orchestrator Signed-off-by: GnomeZworc --- docs/deploiement/frr-hyperviseur.rst | 43 --- docs/deploiement/image-qcow2.rst | 337 +++++++++++++++++++++++ docs/deploiement/index.rst | 30 +- docs/deploiement/premier-hyperviseur.rst | 74 +++++ docs/deploiement/route-reflector.rst | 8 +- docs/deploiement/routeurs-cluster.rst | 31 --- docs/deploiement/routeurs.rst | 51 ++++ docs/exploitation/index.rst | 14 + docs/index.rst | 6 +- 9 files changed, 500 insertions(+), 94 deletions(-) delete mode 100644 docs/deploiement/frr-hyperviseur.rst create mode 100644 docs/deploiement/image-qcow2.rst create mode 100644 docs/deploiement/premier-hyperviseur.rst delete mode 100644 docs/deploiement/routeurs-cluster.rst create mode 100644 docs/deploiement/routeurs.rst create mode 100644 docs/exploitation/index.rst diff --git a/docs/deploiement/frr-hyperviseur.rst b/docs/deploiement/frr-hyperviseur.rst deleted file mode 100644 index 313b7e9..0000000 --- a/docs/deploiement/frr-hyperviseur.rst +++ /dev/null @@ -1,43 +0,0 @@ -FRR sur les hyperviseurs -======================== - -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. - -.. 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 ; - * les commandes de vérification à utiliser en exploitation. - -Vérifier le plan de données ---------------------------- - -Indépendamment de la configuration retenue, deux vérifications restent valables 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 bridge fdb show dev - - # L'interface VXLAN telle que l'agent l'a créée : port 4789, learning off, - # aucun groupe multicast, aucun remote. - ip netns exec ip -d link show - -.. 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. Cf. :doc:`architecture-cluster`. diff --git a/docs/deploiement/image-qcow2.rst b/docs/deploiement/image-qcow2.rst new file mode 100644 index 0000000..63ddc28 --- /dev/null +++ b/docs/deploiement/image-qcow2.rst @@ -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
cloud-init NoCloud"] --> BVM + OVL["<os>-tmp.qcow2
overlay, jetable"] --> BVM["VM de construction"] + BVM --> ROOT["<os>-root.qcow2
image golden"] + BVM --> WORK["tmp.qcow2
espace de travail"] + BASE["image du fournisseur
(qcow2)"] -.backing file.-> OVL + +.. list-table:: + :header-rows: 1 + :widths: 26 20 54 + + * - Disque + - Vu dans la VM + - Rôle + * - ``-tmp.qcow2`` + - ``vda`` (virtio-blk) + - système de la VM de construction ; overlay de l'image du fournisseur, jeté à la fin + * - ``-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= + export os_link= + export os_file= + export os_dir= + export disk_dir= + +É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: + lock_passwd: false + passwd: "" + sudo: ALL=(ALL) NOPASSWD:ALL + ssh_authorized_keys: + - + 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 ``-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 ? diff --git a/docs/deploiement/index.rst b/docs/deploiement/index.rst index f50714f..9586f3a 100644 --- a/docs/deploiement/index.rst +++ b/docs/deploiement/index.rst @@ -2,25 +2,31 @@ 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 ce qu'il faut mettre en place pour qu'un **parc** d'hyperviseurs -fonctionne ensemble — c'est-à-dire pour qu'un subnet s'étende à plusieurs nœuds. +même nœud. Cette section couvre la mise en place d'un **cluster** complet, dans l'ordre où les +étapes se font. -Ce n'est pas une extension du quickstart : le réseau du cluster doit exister **avant** que -l'agent serve à quelque chose au-delà d'un nœud. +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. -Ordre de mise en place ----------------------- +Étapes +------ -#. :doc:`architecture-cluster` — la topologie cible et ce que l'agent suppose déjà en place -#. :doc:`routeurs-cluster` — le routage entre hyperviseurs et vers l'extérieur -#. :doc:`route-reflector` — la VM route reflector, point de rendez-vous du plan de contrôle -#. :doc:`frr-hyperviseur` — FRR sur chaque hyperviseur, qui peuple le plan de données +#. :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 - routeurs-cluster + image-qcow2 + routeurs + premier-hyperviseur route-reflector - frr-hyperviseur diff --git a/docs/deploiement/premier-hyperviseur.rst b/docs/deploiement/premier-hyperviseur.rst new file mode 100644 index 0000000..ae70bc1 --- /dev/null +++ b/docs/deploiement/premier-hyperviseur.rst @@ -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 bridge fdb show dev + + # L'interface VXLAN telle que l'agent l'a créée : port 4789, learning off, + # aucun groupe multicast, aucun remote. + ip netns exec ip -d link show + +.. 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`. diff --git a/docs/deploiement/route-reflector.rst b/docs/deploiement/route-reflector.rst index 0dca3cc..e0095d2 100644 --- a/docs/deploiement/route-reflector.rst +++ b/docs/deploiement/route-reflector.rst @@ -12,8 +12,9 @@ explicitement : la VM qui porte le plan de contrôle du cluster est hébergée p **À rédiger.** À documenter : - * la création de la VM : image de base, ressources, subnet et mode utilisés, s'il s'agit d'une - VM créée par l'agent comme les autres ou d'un cas particulier ; + * 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 ; @@ -21,7 +22,8 @@ explicitement : la VM qui porte le plan de contrôle du cluster est hébergée p 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. + 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 ------------------- diff --git a/docs/deploiement/routeurs-cluster.rst b/docs/deploiement/routeurs-cluster.rst deleted file mode 100644 index 1faaf10..0000000 --- a/docs/deploiement/routeurs-cluster.rst +++ /dev/null @@ -1,31 +0,0 @@ -Routeurs de cluster -=================== - -Les routeurs de cluster raccordent les hyperviseurs entre eux et au monde extérieur. Ils -préexistent à l'agent : celui-ci ne les configure pas et n'en a aucune connaissance. - -.. note:: - - **À rédiger.** Cette page attend les éléments de terrain. À documenter : - - * le rôle exact des routeurs dans la topologie : passerelle du réseau d'hyperviseurs, - terminaison du routage externe, ou les deux ; - * 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 employé avec - les hyperviseurs, numéros d'AS si BGP ; - * la redondance : combien de routeurs, quel mécanisme de bascule, quel comportement attendu - pendant une bascule ; - * le MTU configuré sur les liens vers les hyperviseurs — il doit tenir compte des 50 octets - d'encapsulation VXLAN, cf. :doc:`architecture-cluster` ; - * le filtrage : ce qui est autorisé entre hyperviseurs (au minimum UDP 4789), et ce qui est - autorisé depuis l'extérieur. - -Points de vigilance -------------------- - -.. warning:: - - L'API de l'agent n'a **aucune authentification**. Le filtrage réalisé par les routeurs de - cluster est aujourd'hui l'une des rares barrières entre cette API et le reste du réseau : le - port de l'API ne doit être joignable que depuis le réseau d'administration. - Cf. :doc:`/exploitation/configuration`. diff --git a/docs/deploiement/routeurs.rst b/docs/deploiement/routeurs.rst new file mode 100644 index 0000000..76ec2e7 --- /dev/null +++ b/docs/deploiement/routeurs.rst @@ -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`. diff --git a/docs/exploitation/index.rst b/docs/exploitation/index.rst new file mode 100644 index 0000000..58915bc --- /dev/null +++ b/docs/exploitation/index.rst @@ -0,0 +1,14 @@ +Exploitation +============ + +Faire tourner un hyperviseur en service : configuration, services systemd, API de l'agent, +observabilité et diagnostic. + +.. toctree:: + :maxdepth: 1 + + configuration + services + api-agent/index + observabilite + diagnostic diff --git a/docs/index.rst b/docs/index.rst index 05b18c7..b72be04 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -55,11 +55,7 @@ Par où commencer :hidden: :caption: Exploitation - exploitation/configuration - exploitation/services - exploitation/api-agent/index - exploitation/observabilite - exploitation/diagnostic + exploitation/index .. toctree:: :hidden: