Daniel Allaire
d645532c88
Le port du commutateur vers la frontière était figé sur le seul VLAN de transit. Depuis que les bifrost ont une patte sur le VLAN de sortie tenant, ce port serait resté muet : le devis aurait eu l'air juste et le trafic ne serait jamais arrivé. Il dérive maintenant des rattachements déclarés des hôtes `role: frontiere`. Contexte, côté underlay (dépôt de l'hébergeur) : le VTEP vivait sur le VLAN 10, donc le transport tenant partageait son domaine de diffusion avec l'administration des équipements. Plus grave, un nœud de sortie décapsule le trafic tenant et le remet dans sa table principale — dont la route par défaut sort par vmbr0, l'interface de gestion des nœuds. D'où deux VLAN dédiés, 11 (transport VXLAN) et 41 (trafic décapsulé). Le second n'a volontairement pas de passerelle : le commutateur le transporte sans le router, et le devis n'émet donc pas d'interface Vlan41. Services de l'hébergeur — décision consignée, rien n'est construit : Aucun équipement de l'hébergeur n'est dans un inventaire Ansible, et rien ne sauvegarde leurs configurations. Ni hyperviseurs, ni commutateurs, ni frontière. D-46 : un hébergeur porte trois catégories — son tenant (un client comme les autres), ses opérations (supervision de la fabric, journaux, sauvegarde des configs, DNS d'underlay), et le plan de contrôle (déjà dehors). D-47 : les opérations vivent dans le dépôt de l'hébergeur, et leurs VM se rattachent à un pont VLAN, jamais un VNet. Un service qui observe la fabric ne peut pas dépendre d'elle : l'EVPN tombe, et la supervision tombe avec la raison de la panne. D-48 : les hyperviseurs sont gérables par Ansible ; « hors flotte » ne vaut que pour les commutateurs (aucun agent) et la frontière (API seulement). Question laissée ouverte : l'index 0 réservé au tenant propre de l'hébergeur. Il produit les VNI 1001-1006, que le parc hérité utilise déjà (1001 TechnoLibre historique, 1003 KBR), et P21 déclencherait une fausse collision entre deux dépôts d'hébergeurs. Construction parallèle vérifiée : aucune collision entre les 38 VM héritées et les VNI/VLAN projetés. 30 preuves OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 lines
4.2 KiB
Markdown
86 lines
4.2 KiB
Markdown
# Les services d'exploitation de l'hébergeur
|
||
|
||
> **Décision du 2026-08-04.** Tout ce qu'un hébergeur fait tourner n'appartient pas à un
|
||
> tenant. Ce document dit où va quoi, et pourquoi certains services ne peuvent pas vivre
|
||
> dans l'overlay qu'ils observent. **Rien n'est construit** : la décision est consignée,
|
||
> le chantier reste devant.
|
||
|
||
## 1. Le test qui tranche
|
||
|
||
Pour chaque service, une seule question : **de quoi doit-il survivre ?**
|
||
|
||
Un service qui observe ou répare la fabric ne peut pas dépendre de la fabric. Mettez
|
||
Prometheus dans une zone EVPN pour surveiller les hyperviseurs, et le jour où le VXLAN
|
||
tombe vous perdez la supervision **et** la raison de la panne en même temps. Pire pour les
|
||
sauvegardes : on veut restaurer la configuration d'un commutateur précisément quand le
|
||
réseau est cassé.
|
||
|
||
C'est le motif *in-band / out-of-band*, et il ne se contourne pas.
|
||
|
||
## 2. Trois catégories, pas deux
|
||
|
||
**Le tenant de l'hébergeur** — son courriel, sa forge, son nuage, son site. L'hébergeur
|
||
*comme entreprise*. Aucune différence avec un client : même plan, même machinerie, mêmes
|
||
preuves, même EVPN. Chezlepro est ici hébergeur **et** tenant, ce qui a longtemps masqué
|
||
la distinction (D-13).
|
||
|
||
**Les opérations de l'hébergeur** — ce qui fait tenir la fabric. Doit rester **hors
|
||
overlay**.
|
||
|
||
**Le plan de contrôle** — Set-OPS lui-même, les dépôts, la voûte. Déjà dehors, sur le
|
||
poste de l'opérateur et sa forge. Rien à changer.
|
||
|
||
## 3. Ce qui n'a pas de maison aujourd'hui
|
||
|
||
Constaté le 2026-08-04 : **aucun équipement de l'hébergeur n'est dans un inventaire
|
||
Ansible**, et rien ne sauvegarde leurs configurations.
|
||
|
||
| Besoin | État |
|
||
|---|---|
|
||
| Supervision des hyperviseurs, commutateurs, frontière | personne |
|
||
| Journaux de ces équipements | personne |
|
||
| Sauvegarde de leurs configs (`running-config`, `config.xml`, `/etc/pve`) | personne |
|
||
| Résolution des noms d'underlay (`asgard`, `sleipnir-01`, `bifrost-1`) | personne |
|
||
| Certificats pour leurs interfaces web | personne |
|
||
|
||
Ce n'est pas un oubli de conception : ces besoins tombaient entre les chaises. Ils ne sont
|
||
d'aucun tenant, et `underlay.yml` ne décrit que du matériel, sans service.
|
||
|
||
## 4. Où ça va
|
||
|
||
**Dans le dépôt de l'hébergeur** — celui qui porte déjà `underlay.yml` et
|
||
`proxmox-hebergeur.yml`. Ses services d'exploitation lui appartiennent au même titre que
|
||
sa fabric ; les loger ailleurs recréerait la confusion qu'on vient de défaire.
|
||
|
||
Ce dépôt n'a pas d'inventaire Ansible aujourd'hui : c'est ce que le chantier ajoutera.
|
||
|
||
**Rattachement réseau : un pont VLAN ordinaire, jamais un VNet du SDN.** C'est la
|
||
contrainte qui découle du §1, et la seule qui distingue ces VM de celles d'un tenant.
|
||
|
||
## 5. Ce que ça ne change pas
|
||
|
||
Les **commutateurs** et la **frontière** restent hors flotte : le premier n'a pas d'agent,
|
||
la seconde se pilote par API. Ils reçoivent des devis, pas des rôles (D-23).
|
||
|
||
Les **hyperviseurs** sont un cas différent, et la doctrine « hors flotte » les englobait à
|
||
tort : ce sont des machines Debian, joignables en SSH. Rien n'empêche de les gérer par
|
||
Ansible depuis l'inventaire de l'hébergeur — c'est même la seule façon d'y poser un
|
||
`node_exporter` et un expéditeur de journaux.
|
||
|
||
## 6. Question ouverte, non tranchée
|
||
|
||
**L'index du tenant propre de l'hébergeur.** L'idée d'un `0` réservé — local par
|
||
construction, donc jamais à coordonner entre hébergeurs, et jamais porté par un tenant qui
|
||
déménage — est séduisante et reste **en attente**.
|
||
|
||
Deux obstacles mesurés le 2026-08-04, à lever avant :
|
||
|
||
- l'index 0 produit les VNI `1001`–`1006`, et le parc hérité utilise déjà `1001`
|
||
(TechnoLibre historique, 8 VM) et `1003` (KBR). C'est une condition de **séquence** :
|
||
la place se libère quand l'ancien monde s'éteint ;
|
||
- **P21** vérifie l'unicité des index entre dépôts frères. Si tout hébergeur a un tenant
|
||
`0`, poser deux dépôts d'hébergeurs côte à côte déclencherait une fausse collision — il
|
||
faudrait exempter `0`, donc inscrire dans la garde que cette valeur est locale.
|
||
|
||
À noter au passage : la convention héritée était déjà `1000 + numéro de tenant`. La formule
|
||
de Set-OPS (`1000 + index×10 + zone`) en est un raffinement, pas une invention.
|