Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

runbook : la frontiere porte deux adresses de gestion (transition D-77)

Browse source 
10.17.0.1/24 posee par l'API a cote de 10.0.0.1/24, qui reste active. Ajouter
AVANT de retirer : un point de routage qui change d'adresse d'un coup coupe
simultanement l'exploitant, les commutateurs qui l'ont en passerelle par defaut,
et l'outil qui devait faire la bascule.

Documente l'ordre du reste (poste, commutateurs, hyperviseurs, transit, VXLAN,
stockage, puis retrait) et surtout ce qui n'en depend PAS : le renumerotage du
TENANT est independant — la frontiere route son supernet vers le meme prochain
saut quelle que soit sa propre adresse de gestion.

prouver reste a 1 : P03 signale l'ecart plan/applique, qui est reel jusqu'au
renumerotage du tenant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-08-12 16:43:09 -04:00
parent 2c7849f6b3
commit 65fbb0aef4
1 changed files with 35 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
docs/runbooks-exploitation.md
View file

@ -156,3 +156,38 @@ Mesuré sur `forgejo` : rejeu en **0 erreur**, **130 tables**, et les comptes r
**Ne jamais rejouer un `pg_dumpall` entier sur un cluster vivant** : il contient les
`DROP DATABASE` de toutes les bases. Une restauration réelle se fait sur un cluster neuf.
## 6. La frontière porte deux adresses de gestion (transition D-77)
> Posée le 2026-08-12 par l'API (`interfaces/vip_settings`, mode `ipalias`). **Ce n'est
> pas une anomalie** : c'est une bascule d'adressage en cours.
```
10.0.0.1/24 adresse historique — TOUJOURS ACTIVE, rien ne l'a quittée
10.17.0.1/24 adresse cible (D-77 : underlay dans la bande basse du /16 du site)
```
**Ajouter avant de retirer**, jamais l'inverse. Un point de routage qui change d'adresse
d'un coup coupe simultanément l'exploitant, les commutateurs qui l'ont en passerelle par
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.<vlan>.0/24` ;
6. **en dernier seulement**, retirer `10.0.0.1`.
### Ce qui ne dépend PAS de cette bascule
**Le renumérotage du tenant** (`10.27` → `10.17`) est **indépendant**. La frontière route
le supernet du tenant vers le même prochain saut, quelle que soit sa propre adresse de
gestion : il suffit que la route et les alias suivent. Les deux chantiers peuvent donc
être menés séparément — et c'est préférable.
> **Longueur de préfixe.** Une fois les deux faits, la gestion (`10.17.0.0/24`) vit
> *à l'intérieur* du supernet du tenant (`10.17.0.0/16`). Aucun conflit : la route
> connectée du `/24` est plus spécifique que celle du `/16`. C'est la règle du préfixe le
> plus long, pas une coïncidence.