docs: configuration for orchestrator
Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
This commit is contained in:
parent
cb904c4744
commit
45f8e43de8
GPG key ID:
4406BBBF8845D632
9 changed files with 500 additions and 94 deletions
|
|
@ -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 <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. Cf. :doc:`architecture-cluster`.
|
||||
337
docs/deploiement/image-qcow2.rst
Normal file
337
docs/deploiement/image-qcow2.rst
Normal 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["<os>-tmp.qcow2<br/><i>overlay, jetable</i>"] --> BVM["VM de construction"]
|
||||
BVM --> ROOT["<os>-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 ?
|
||||
|
|
@ -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
|
||||
|
|
|
|||
74
docs/deploiement/premier-hyperviseur.rst
Normal file
74
docs/deploiement/premier-hyperviseur.rst
Normal 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`.
|
||||
|
|
@ -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
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
51
docs/deploiement/routeurs.rst
Normal file
51
docs/deploiement/routeurs.rst
Normal 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`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue