Daniel Allaire
63aa79e710
Il valait partout ; il ne vaut que dans l'adressage dérivé des tenants, où passerelle_de(index, zone) produit le même .1 dans les treize sous-réseaux d'un tenant. C'est une propriété de la dérivation, pas une loi universelle. Dans l'underlay il produisait deux effets pervers. Un seuil arbitraire : les sous-réseaux plus étroits qu'un /24 étaient exemptés, donc élargir un /29 changeait la validité du fichier sans que rien d'autre bouge. Et une couture entre propriétaires : l'octet attendu venait de la nomenclature d'un tenant, appliquée à la fabric de l'hébergeur — la validité de l'underlay aurait dépendu du tenant actif. Ce qui reste est plus fort et suffit (D-52) : une passerelle doit être l'adresse d'un hôte déclaré sur ce réseau. Elle attrape les passerelles fantômes, ce que le comptage d'octets ne faisait pas. Vérifié : la garde mord toujours. À noter, parce que l'ordre était mauvais : le ré-adressage de l'OPNsense en .1 a été demandé au nom de cette règle, deux messages avant qu'elle soit recadrée. Pas perdu — .1 est la position conventionnelle d'une passerelle — mais la portée aurait dû être questionnée avant de faire changer une adresse en service. D-53 : le réseau et l'underlay de l'hébergeur méritent leur propre dépôt. underlay.yml décrit une infrastructure, le dépôt de tenant une organisation ; un tenant peut déménager, une fabric non. Consigné, non fait. D-54 : 10.0.0.0/24 est réservé à l'IPAM, la gestion des équipements et l'OOB, accès sysadmin. Aucun hyperviseur, aucune VM, aucun trafic tenant. C'est la raison d'être des VLAN 11 et 40. 30 preuves OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
114 lines
5.7 KiB
Markdown
114 lines
5.7 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.
|
||
|
||
## 7. Un dépôt à part pour le réseau (décidé, non fait)
|
||
|
||
`underlay.yml` et `proxmox-hebergeur.yml` vivent aujourd'hui dans `OPS-Chezlepro`, qui est
|
||
aussi le dépôt du **tenant** Chezlepro. C'est ce qui a permis de démarrer, et c'est ce qui
|
||
oblige, à chaque commit, à trancher si l'on touche à l'infrastructure ou à l'organisation.
|
||
|
||
Ils décrivent des objets différents : l'un une **infrastructure** — des câbles, des VLAN,
|
||
un cluster —, l'autre une **organisation** — ses serveurs, ses applications, ses comptes.
|
||
Un tenant peut déménager ; une fabric ne déménage pas.
|
||
|
||
Le dépôt réseau de l'hébergeur porterait donc `underlay.yml`, `proxmox-hebergeur.yml`, et
|
||
plus tard l'inventaire des services d'exploitation (§4). Le symlink qui désigne
|
||
l'hébergeur pointerait vers lui plutôt que vers son tenant — ce qui rendrait enfin la
|
||
distinction visible dans les chemins eux-mêmes.
|
||
|
||
**Rien n'est fait.** La bascule demande de déplacer deux fichiers, de refaire le symlink,
|
||
et de vérifier que les trois générateurs qui les lisent suivent.
|
||
|
||
## 8. Le VLAN de gestion, et ce qu'il n'est pas
|
||
|
||
`10.0.0.0/24` est réservé à l'**IPAM, la gestion des équipements et l'OOB/IPMI**. Accès
|
||
sysadmin uniquement.
|
||
|
||
Aucun hyperviseur n'y a d'adresse, aucune VM n'y est branchée, aucun trafic tenant ne le
|
||
traverse — ni encapsulé, ni décapsulé. C'est précisément la raison d'être des VLAN 11
|
||
(transport VXLAN) et 40 (sortie tenant) : les avoir sortis de ce domaine de diffusion.
|
||
|