From 0c93569dd7e1d4a344017d3da3a3b5cb594be73a Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Wed, 12 Aug 2026 15:49:29 -0400 Subject: [PATCH] D-77 : l'underlay derive du meme index que son tenant, le stockage sort en 192.168 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mon « numero de site » etait un SECOND SEED a tenir et a synchroniser, alors que tout derive deja d'index (D-17). Rejete au profit de la proposition de l'exploitant, meilleure : l'underlay occupe la BANDE BASSE du supernet du tenant, 10.(10+index).0-15.x. La bande basse est sure PAR LA REGLE, pas par chance : les zones valent 10.(10+index).(15+categorie).0/24, donc 3e octet >= 16. Les octets 0 a 15 ne sont JAMAIS alloues. Consequence heureuse : les 3e et derniers octets de l'underlay actuel sont preserves — seul le 2e change, et l'invariant .1 (D-04) survit. Verifie sur les quatre cas qui comptent : Technolibre sur l'underlay de Chezlepro, Technolibre chez Mathieu (meme /16, bandes disjointes), Chezlepro restaure chez Mathieu, et le lien entre les deux sites. Aucun recouvrement. Le STOCKAGE en sort : jumbo, non route, il ne quitte jamais son site, donc aucun besoin d'etre unique. Identique partout en 192.168..0/24 — l'adresse dit son VLAN. Contrepartie assumee : ces reseaux ne traverseront jamais un lien inter-sites ; sans consequence, puisque ce qui voyage entre deux sites est l'ETAT, par le depot de sauvegarde, pas le stockage bloc. Calendrier : applique tout de suite la ou c'est gratuit (site neuf), differe a froid pour Chezlepro — 10.0.x.x et 10.21.x.x ne se chevauchent pas entre-temps. Reste a outiller : borner le 3e octet de l'underlay sous OCTET_ZONE + 1 (P23). Co-Authored-By: Claude Opus 5 --- docs/decisions-architecture.md | 9 +++++ docs/preparer-un-site-hebergeur.md | 58 +++++++++++++++++------------- 2 files changed, 42 insertions(+), 25 deletions(-) diff --git a/docs/decisions-architecture.md b/docs/decisions-architecture.md index 453ed3f..5283df0 100644 --- a/docs/decisions-architecture.md +++ b/docs/decisions-architecture.md @@ -117,6 +117,15 @@ sont les seules vérifiables. | **D-71** | **Une PKI et un DNS fonctionnels avant toute chose** ; puis, par VM : socle → enrôlement PKI → enregistrement DNS (A **et** PTR) | `deployer-tout` déroule par COUCHES — correct, mais chaque VM réclame alors un certificat à une autorité pas encore debout, et l'échec se lit comme un défaut du rôle et non d'ordre. Les deux hôtes d'amorçage se **dérivent** de `applications..hote` : déplacer l'autorité déplace l'amorçage. **Deux exceptions structurelles assumées** — l'AC s'auto-signe, le DNS pose son propre enregistrement | `Makefile` `_amorcer-socle`, `scripts/socle_amorcage.py` | — | | **D-76** | Le **gabarit doit se FABRIQUER par le dépôt**, pas se façonner à la main — décidée le 2026-08-12, **volontairement différée** après Technolibre | tout dérive d'un plan et se prouve ; le gabarit est la **seule pièce faite à la main** — 853 lignes de procédure manuelle — et il est en amont des quatorze VM. Le 2026-08-09 l'a démontré : l'ancien portait une **clé privée d'hôte SSH** et un `/etc/resolv.conf` figé, recopiés dans chaque clone, et il a fallu le recapturer. La preuve de reconstruction s'arrête donc un cran trop tôt : on reconstruit la flotte, pas ce dont elle est clonée. **Cible** : image cloud Debian officielle → signature vérifiée contre une empreinte épinglée (`verifier_signature.py`, déjà écrit) → import, réglages, conversion. **Coût honnête** : la recette doit être COMPARÉE au gabarit courant avant bascule — un réglage oublié serait hérité par les quatorze VM, et découvert loin de sa cause. **En attendant**, un gabarit se transporte d'un cluster à l'autre par `vzdump` / `qmrestore` | `docs/procedure-template-debian13-proxmox.md`, `scripts/verifier_signature.py` | — *(à construire)* | +| **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.(10+index).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.(10+index).(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`, `docs/preparer-un-site-hebergeur.md`, `scripts/inventory_rules.py` (`OCTET_ZONE`) | **P23** *(à étendre : borner le 3ᵉ octet sous `OCTET_ZONE + 1`)* | + +> **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 +> toucher la frontière, les commutateurs, l'IPMI, `vmbr0`. D'où le calendrier retenu : +> **appliquée immédiatement là où elle est gratuite**, différée à froid ailleurs. Rien ne +> presse, puisque `10.0.x.x` et `10.21.x.x` ne se chevauchent pas entre-temps. + > **Ce que D-76 retourne.** Le gabarit était tenu pour un « actif central, jamais jetable ». > C'est exactement le problème : **un artefact qu'on ne sait pas refaire est un artefact > qu'on ne peut pas se permettre de perdre.** Le rendre reproductible le fait passer diff --git a/docs/preparer-un-site-hebergeur.md b/docs/preparer-un-site-hebergeur.md index 1d66935..43f5c9b 100644 --- a/docs/preparer-un-site-hebergeur.md +++ b/docs/preparer-un-site-hebergeur.md @@ -25,35 +25,40 @@ listes de stockages et de ponts différentes. Un hébergeur décrit son matérie ## 2. Le plan d'adressage — la seule chose à respecter à la lettre -**Chaque site porte un numéro**, et tout son adressage en dérive : `10..x.0/24`. -Le premier hébergeur est le site `0`, le deuxième le site `1`, et ainsi de suite. +**Un site dérive du même `index` que son tenant.** Il n'y a pas de second registre à +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 | |---|---|---|---|---| -| Gestion | 10 | `10..0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | -| Transport VXLAN | 11 | `10..5.0/24` | 1500 | hyperviseurs seulement | -| Stockage iSCSI | 20 | `10..1.0/24` | 9000 | baie ↔ hyperviseurs | -| Sortie des tenants | 40 | `10..4.0/24` | 1500 | frontière `.1`, nœuds de sortie | +| Gestion | 10 | `10.(10+index).0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | +| Sortie des tenants | 40 | `10.(10+index).4.0/24` | 1500 | frontière `.1`, nœuds de sortie | +| Transport VXLAN | 11 | `10.(10+index).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 | -Les **VLAN ne changent pas** d'un site à l'autre : ils sont locaux, ils ne traversent -jamais un lien inter-sites. Un seul modèle mental vaut mieux qu'une seconde table à -retenir. Seules les plages L3 diffèrent. +Index 17 → gestion en `10.27.0.0/24` ; index 11 → `10.21.0.0/24`. Deux sites ne peuvent +donc **pas** se chevaucher, sans qu'on ait rien de plus à décider. -> **Pourquoi ce numéro de site, alors qu'un seul hébergeur n'en a pas besoin.** Le jour -> où deux sites doivent se joindre — reprise après sinistre mutuelle, sauvegardes -> croisées, exploitation à distance — deux sites qui portent `10.0.0.0/24` **ne peuvent -> pas être reliés** : chaque routeur croit que le réseau est chez lui. Décider ce chiffre -> coûte une minute avant de câbler ; renuméroter un site vivant, c'est refaire les baies, -> les hyperviseurs et la frontière. **C'est la décision la moins chère et la plus -> irréversible de tout ce document.** +**Les VLAN ne changent jamais** d'un site à l'autre : ils sont locaux, ils ne traversent +aucun lien inter-sites. Un seul modèle mental, et l'adresse de stockage porte son propre +numéro de VLAN — `192.168.20.x` est sur le VLAN 20. -Deux invariants portés par la preuve `P23` : +> **Pourquoi la bande basse est sûre, et non pas seulement libre aujourd'hui.** Les zones +> d'un tenant sont dérivées en `10.(10+index).(15+categorie).0/24` : leur troisième octet +> vaut donc **16 au minimum**, et croît avec le nombre de zones. Les octets `0` à `15` +> 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. -- **Un point de routage porte le même dernier octet partout** : `.1`. La passerelle d'un - sous-réseau garde cette adresse, quel que soit l'équipement qui l'assure. -- **Chaque tenant occupe `10.(10+index).0.0/16`.** Index 11 → `10.21.0.0/16`, index 17 → - `10.27.0.0/16`. Aucun réseau de l'hébergeur ne doit chevaucher ces blocs : le symptôme - d'une collision est un service qui « ne répond pas » sans aucune erreur nulle part. +> **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 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. ### Le MTU n'est pas un détail @@ -71,8 +76,11 @@ C'est le seul équipement qui route, et l'unique point de passage entre l'extér l'intérieur. Set-OPS **pilote ses règles par API** : le boîtier reste à l'hébergeur, rien 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. +**Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10.(10+index).0.1/24` ; le +transit en `10.(10+index).4.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`. **Un compte pour l'exploitant :** un utilisateur `ansible` avec sa clé publique. **Aucun `sudo` n'est nécessaire** — l'outil lit et appelle l'API. Un compte qui ne peut @@ -147,7 +155,7 @@ est écrite (`docs/procedure-template-debian13-proxmox.md`). | Modèle du commutateur | dicte le dialecte de CLI (`cisco` \| `binardat`) | | Domaine public prévu | `exemple.ca` | | Gabarit | fait, ou à faire | -| Numéro de site | `0`, `1`… — voir §2, à décider **avant** de câbler | +| `index` du site | le même que son tenant — voir §2, à fixer **avant** de câbler | | Accès de l'exploitant | sur place, ou lien vers le VLAN de gestion (voir §8) | **Et deux paires de secrets**, par un canal chiffré et séparément du reste : le Token ID +