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
|
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
|
même nœud. Cette section couvre la mise en place d'un **cluster** complet, dans l'ordre où les
|
||||||
fonctionne ensemble — c'est-à-dire pour qu'un subnet s'étende à plusieurs nœuds.
|
étapes se font.
|
||||||
|
|
||||||
Ce n'est pas une extension du quickstart : le réseau du cluster doit exister **avant** que
|
Cet ordre n'est pas indifférent : chaque étape a besoin de la précédente. L'image doit exister
|
||||||
l'agent serve à quelque chose au-delà d'un nœud.
|
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:`architecture-cluster` — la topologie cible, à lire avant tout le reste
|
||||||
#. :doc:`routeurs-cluster` — le routage entre hyperviseurs et vers l'extérieur
|
#. :doc:`image-qcow2` — l'image golden dont dérivent toutes les VM du cluster
|
||||||
#. :doc:`route-reflector` — la VM route reflector, point de rendez-vous du plan de contrôle
|
#. :doc:`routeurs` — le matériel : routeurs de cluster, de datacentre et de bordure
|
||||||
#. :doc:`frr-hyperviseur` — FRR sur chaque hyperviseur, qui peuple le plan de données
|
#. :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::
|
.. toctree::
|
||||||
:hidden:
|
:hidden:
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
architecture-cluster
|
architecture-cluster
|
||||||
routeurs-cluster
|
image-qcow2
|
||||||
|
routeurs
|
||||||
|
premier-hyperviseur
|
||||||
route-reflector
|
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 :
|
**À rédiger.** À documenter :
|
||||||
|
|
||||||
* la création de la VM : image de base, ressources, subnet et mode utilisés, s'il s'agit d'une
|
* la création de la VM : ressources, subnet et mode utilisés, et s'il s'agit d'une VM créée
|
||||||
VM créée par l'agent comme les autres ou d'un cas particulier ;
|
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 ;
|
* son adressage, et comment les hyperviseurs le connaissent ;
|
||||||
* la configuration du démon de routage qu'elle héberge ;
|
* 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 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
|
absent — les tunnels déjà établis continuent-ils de fonctionner, et pendant combien de
|
||||||
temps ;
|
temps ;
|
||||||
* la procédure d'amorçage : ce qui fonctionne, et dans quel ordre, quand on démarre un cluster
|
* 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
|
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`.
|
||||||
14
docs/exploitation/index.rst
Normal file
14
docs/exploitation/index.rst
Normal file
|
|
@ -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
|
||||||
|
|
@ -55,11 +55,7 @@ Par où commencer
|
||||||
:hidden:
|
:hidden:
|
||||||
:caption: Exploitation
|
:caption: Exploitation
|
||||||
|
|
||||||
exploitation/configuration
|
exploitation/index
|
||||||
exploitation/services
|
|
||||||
exploitation/api-agent/index
|
|
||||||
exploitation/observabilite
|
|
||||||
exploitation/diagnostic
|
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:hidden:
|
:hidden:
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue