diff --git a/CHANGELOG.md b/CHANGELOG.md index fc132ce..7a27450 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,47 @@ # CHANGELOG — Set-OPS +## 2026-08-12 — D-78 : destination ou chemin, et le VLAN 50 pour éviter une collision + +D-77 sortait déjà le stockage de l'espace dérivé, mais par une **exception nommée** plutôt +que par une règle. Une question de l'exploitant — *« le VLAN 40 n'a aucune VM, pourquoi ne +pas lui donner une adresse non routée ? »* — a fait apparaître le critère juste. + +Ce n'est pas « y a-t-il des machines dedans » : le VLAN de gestion n'en a pas plus qu'un +autre. C'est : + +> **Ce réseau est-il jamais une *destination*, ou seulement un *chemin* ?** + +| Réseau | Rôle réel | Adressage | +|---|---|---| +| **Gestion** (10) | le poste, un VPN, demain le lien inter-sites doivent l'**atteindre** | `10..0.0/24` — **unique** | +| Transit (40) | rien que des prochains sauts, deux extrémités adjacentes | `192.168.40.0/24` | +| Transport VXLAN (**50**) | VTEP ↔ VTEP, destination de rien | `192.168.50.0/24` | +| Stockage (20/30/31) | baie ↔ hyperviseurs | `192.168.20/30/31.0/24` | + +Sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs — +et « unique » redevient signifiant : seul ce qui doit l'être l'est. + +### L'os : le VLAN 11 aurait collisionné + +Sous la règle `192.168.`, le transport VXLAN (VLAN 11) aurait produit +`192.168.11.0/24` — **déjà occupé** par la gestion des hyperviseurs sur `vmbr0`, +passerelle `.254`. Trouvé par l'exploitant avant écriture. + +Le VLAN 11 se libérera lorsque cette gestion rejoindra `10..0.x` — mais **faire +dépendre un plan d'adressage de l'ordre d'une migration** est le genre de dette qui se paie +un an plus tard. Le transport passe donc au **VLAN 50** : libre, `192.168.50.0/24` libre, +et ne dépend de rien. Vérifié : rien ne code le 11 en dur, c'est de la donnée d'underlay. + +### Ce qui n'est PAS fait, et pourquoi + +`underlay.yml` décrit le matériel **tel qu'il est**. Y écrire les nouvelles plages avant le +déplacement physique le ferait mentir : P23 validerait une fiction et les devis émettraient +une configuration pour un état inexistant. La décision est consignée ; les adresses +changeront **avec** le matériel, dans l'ordre du runbook §6. + +**Un site neuf, lui, se monte directement au schéma final** — le document de préparation +d'un site hébergeur porte déjà le VLAN 50 et les `192.168`. + ## 2026-08-12 — P03 regarde TOUTES les instances, et trouve une collision au premier essai P03 ne vérifiait la fraîcheur de l'inventaire que pour l'instance **active** — laissant un diff --git a/docs/decisions-architecture.md b/docs/decisions-architecture.md index cad74df..fb9b5c6 100644 --- a/docs/decisions-architecture.md +++ b/docs/decisions-architecture.md @@ -119,6 +119,28 @@ sont les seules vérifiables. | **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10..0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168..0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10..(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/preparer-un-site-hebergeur.md` | **P23** | +| **D-78** | Un réseau d'underlay est soit une **destination**, soit un **chemin**. Les destinations gardent l'adressage dérivé (`10..0–15.x`) ; les chemins sortent de cet espace en **`192.168..0/24`, identiques à tous les sites** — décidée le 2026-08-12, **appliquée au déplacement physique** | D-77 sortait déjà le stockage, mais par une exception nommée plutôt que par une règle. Le critère n'est pas « y a-t-il des VM dedans » — le VLAN de gestion n'en a pas non plus — c'est : **ce réseau est-il jamais une destination, ou seulement un chemin ?** Transit (40) : rien que des prochains sauts, deux extrémités adjacentes en L2. Transport VXLAN (**VLAN 50**) : VTEP ↔ VTEP, destination de rien. Stockage (20/30/31) : baie ↔ hyperviseurs. **Gestion (10) : le poste de l'exploitant, un VPN, demain le lien inter-sites doivent l'atteindre** — elle reste dérivée et unique. Effet : sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs, et « unique » redevient signifiant — seul ce qui doit l'être l'est | `underlay.yml`, `docs/preparer-un-site-hebergeur.md` | P23 *(la borne de bande basse ne s'applique qu'aux destinations)* | + +> **Ce que D-78 coûte, et ce qui la renverserait.** Le jour où l'un de ces liens devrait +> **franchir un site**, il redeviendrait une destination et exigerait une adresse unique. +> Concrètement : un EVPN **multi-sites** (un VTEP en peering avec le VTEP d'un autre +> hébergeur), ou deux frontières échangeant des routes **par le tunnel** au lieu de routes +> statiques. Ni l'un ni l'autre n'est au plan — la fabric EVPN est mono-site par +> hébergeur, et le tunnel relie les frontières, pas les liens de transit. C'est néanmoins +> la seule chose qui forcerait un retour en arrière, et elle est écrite ici pour qu'on la +> reconnaisse si elle arrive. +> +> **Un site NEUF se monte directement au schéma final** : il n'a aucune transition à +> subir. Seuls les sites existants ont un déplacement à faire. +> +> **Pourquoi le transport VXLAN passe du VLAN 11 au VLAN 50.** Sous la règle +> `192.168.`, le VLAN 11 aurait produit `192.168.11.0/24` — **déjà occupé** par la +> gestion des hyperviseurs sur `vmbr0` (passerelle `.254`). Collision frontale. Le VLAN 11 +> se libérera bien lorsque cette gestion rejoindra `10..0.x`, mais faire dépendre +> un plan d'adressage de l'ORDRE d'une migration est exactement le genre de dette qui se +> paie un an plus tard. Le VLAN 50 est libre, son `192.168.50.0/24` aussi, et il ne +> dépend de rien. + > **Ce que D-77 rend possible, et ce qu'elle coûte.** Elle est la condition de la reprise > mutuelle : sans plages distinctes, aucun lien entre deux sites ne peut router. Elle est > **gratuite pour un site neuf** et **coûteuse pour un site vivant** — renuméroter, c'est diff --git a/docs/preparer-un-site-hebergeur.md b/docs/preparer-un-site-hebergeur.md index 4f5e5a6..f7933ee 100644 --- a/docs/preparer-un-site-hebergeur.md +++ b/docs/preparer-un-site-hebergeur.md @@ -29,14 +29,14 @@ listes de stockages et de ponts différentes. Un hébergeur décrit son matérie tenir : le seul seed de tout l'adressage reste l'`index`, et l'underlay occupe la **bande basse** du supernet — celle que la dérivation des tenants n'alloue jamais. -| Rôle | VLAN | Sous-réseau | MTU | Qui y vit | +| Rôle | VLAN | Sous-réseau | MTU | Nature | |---|---|---|---|---| -| Gestion | 10 | `10..0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | -| Sortie des tenants | 40 | `10..4.0/24` | 1500 | frontière `.1`, nœuds de sortie | -| Transport VXLAN | 11 | `10..5.0/24` | 1500 | hyperviseurs seulement | -| Stockage iSCSI | 20 | `192.168.20.0/24` | 9000 | baie ↔ hyperviseurs | -| Ceph public | 30 | `192.168.30.0/24` | 9000 | clients ↔ MON/OSD | -| Ceph cluster | 31 | `192.168.31.0/24` | 9000 | OSD ↔ OSD | +| **Gestion** | 10 | `10..0.0/24` | 1500 | **destination** — unique par site | +| Sortie des tenants | 40 | `192.168.40.0/24` | 1500 | chemin — identique partout | +| Transport VXLAN | 50 | `192.168.50.0/24` | 1500 | chemin — identique partout | +| Stockage iSCSI | 20 | `192.168.20.0/24` | 9000 | chemin — identique partout | +| Ceph public | 30 | `192.168.30.0/24` | 9000 | chemin — identique partout | +| Ceph cluster | 31 | `192.168.31.0/24` | 9000 | chemin — identique partout | Index 17 → gestion en `10.17.0.0/24` ; index 11 → `10.11.0.0/24`. Deux sites ne peuvent donc **pas** se chevaucher, sans qu'on ait rien de plus à décider. @@ -51,11 +51,20 @@ numéro de VLAN — `192.168.20.x` est sur le VLAN 20. > ne sont **jamais** alloués — c'est une propriété de la règle, pas une place restée > vide. L'underlay y tient largement. -> **Pourquoi le stockage sort de cet espace.** Ces réseaux sont jumbo, non routés, et ne -> quittent jamais leur site. Ils n'ont donc aucun besoin d'être uniques — et les rendre -> **identiques partout** épargne une coordination inutile. Contrepartie assumée : ils ne -> pourront jamais traverser un lien inter-sites. Sans conséquence, puisque ce qui voyage -> entre deux sites, c'est l'**état** (par le dépôt de sauvegarde), pas le stockage bloc. +> **Un seul réseau doit être unique, et c'est la gestion.** Le critère n'est pas « y a-t-il +> des machines dedans » — le VLAN de gestion n'en a pas plus qu'un autre — c'est : **ce +> réseau est-il jamais une destination, ou seulement un chemin ?** +> +> La gestion est une destination : le poste de l'exploitant, un VPN, demain un lien +> inter-sites doivent l'**atteindre**. Les autres ne sont que traversés — le transit ne +> porte que des prochains sauts entre deux voisins directs, le VXLAN va d'un hyperviseur +> à l'autre, le stockage de la baie aux hyperviseurs. Aucun n'est jamais joint depuis +> l'extérieur de son propre lien. +> +> D'où `192.168..0/24`, **identique chez tous les hébergeurs** : l'adresse dit son +> VLAN, et cinq réseaux sur six cessent d'exiger la moindre coordination. Contrepartie +> assumée : ils ne pourront jamais franchir un lien inter-sites. Sans conséquence — ce qui +> voyage entre deux sites, c'est l'**état** (par le dépôt de sauvegarde), pas la plomberie. Un hébergeur qui n'exploite lui-même **aucun** tenant prend quand même un `index` : c'est le seed de son site. Une seule règle, aucun cas particulier. @@ -77,7 +86,7 @@ l'intérieur. Set-OPS **pilote ses règles par API** : le boîtier reste à l'h n'y est installé. **Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10..0.1/24` ; le -transit en `10..4.1/24`, par où sortent les machines du tenant. +transit en `192.168.40.1/24`, par où sortent les machines du tenant. > **Un point de routage porte le même dernier octet partout** : `.1`, quel que soit > l'équipement qui l'assure. Invariant porté par la preuve `P23`. diff --git a/docs/runbooks-exploitation.md b/docs/runbooks-exploitation.md index 742ee45..647a7c6 100644 --- a/docs/runbooks-exploitation.md +++ b/docs/runbooks-exploitation.md @@ -173,12 +173,24 @@ défaut, et l'outil qui devait faire la bascule. ### Ce qui reste à déplacer, et dans quel ordre -1. le poste de l'exploitant — une seconde adresse `10.17.0.x/24` ; -2. les commutateurs (`10.0.0.3`, `.4`) et leur `ip default-gateway` ; -3. l'administration des hyperviseurs (`vmbr0`), l'OOB/IPMI ; -4. le transit (`10.0.4.x`) et le transport VXLAN (`10.0.5.x`) ; -5. le stockage vers `192.168..0/24` ; -6. **en dernier seulement**, retirer `10.0.0.1`. +| # | À déplacer | Vers | Nature (D-78) | +|---|---|---|---| +| 1 | le poste de l'exploitant | `10.17.0.x/24` (seconde adresse) | — | +| 2 | les commutateurs `10.0.0.3/.4` **et leur `ip default-gateway`** | `10.17.0.3/.4`, passerelle `10.17.0.1` | destination | +| 3 | l'administration des hyperviseurs (`vmbr0`, aujourd'hui `192.168.11.x`), l'OOB/IPMI | `10.17.0.41/.43/.47` | destination | +| 4 | le transit `10.0.4.x` | **`192.168.40.x`** | chemin | +| 5 | le transport VXLAN `10.0.5.x`, **VLAN 11 → 50** | **`192.168.50.x`** | chemin | +| 6 | le stockage `10.0.1–3.x` | **`192.168.20/30/31.x`** | chemin | +| 7 | **en dernier seulement**, retirer `10.0.0.1` | — | — | + +Les étapes 4 à 6 sortent définitivement de l'espace dérivé (D-78) : ces réseaux ne sont +jamais des destinations, seulement des chemins. Une fois faites, **seule la gestion** doit +rester unique d'un site à l'autre. + +> **L'étape 5 change aussi le numéro de VLAN**, côté commutateur (trunk) et côté +> hyperviseurs (`bond3.11` → `bond3.50`). Le 11 est écarté parce que `192.168.11.0/24` est +> occupé par l'étape 3 tant qu'elle n'est pas faite — et un plan d'adressage ne doit pas +> dépendre de l'ordre d'une migration. ### Ce qui ne dépend PAS de cette bascule diff --git a/scripts/underlay.py b/scripts/underlay.py index 379d79b..308e169 100644 --- a/scripts/underlay.py +++ b/scripts/underlay.py @@ -25,9 +25,18 @@ Le site declare son index par `underlay.index`. **Sans lui**, on retombe sur la stricte d'avant D-77 (aucun chevauchement) : c'est le comportement sur pour un underlay qui n'a pas encore migre. -Les reseaux de STOCKAGE sortent de cet espace (192.168..0/24, identiques a tous -les sites) : jumbo, non routes, ils ne quittent jamais leur site, donc ils n'ont aucun -besoin d'etre uniques. +DESTINATION OU CHEMIN (D-78). Ce qui sort de l'espace derive n'est pas « le stockage » +mais tout reseau qui n'est jamais une DESTINATION. Le critere n'est pas la presence de +machines — le VLAN de gestion n'en a pas plus qu'un autre : + + destination : on doit pouvoir l'ATTEINDRE depuis ailleurs (gestion : poste de + l'exploitant, VPN, lien inter-sites) -> 10..0-15.x, UNIQUE + chemin : seulement traverse, jamais joint depuis l'exterieur de son propre lien + (transit, transport VXLAN, stockage) -> 192.168..0/24, IDENTIQUE + a tous les sites — l'adresse dit son VLAN + +La borne de bande basse ne concerne donc que les DESTINATIONS : un reseau en 192.168 est +hors de tout supernet tenant et passe par la branche « hors de tout supernet ». EMPLACEMENT : l'underlay appartient a l'HEBERGEUR — ses switches, ses cables. Il vit donc dans SON depot, et le moteur le monte par symlink :