docs: fix configuration for errors
Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
This commit is contained in:
parent
cb904c4744
commit
08e5c0d871
GPG key ID:
4406BBBF8845D632
5 changed files with 24 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`.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue