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/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/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/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: