un site prend son propre index, et la garde les compte enfin
Decision de l exploitant : sites et locataires se partagent la classe A, chacun avec son propre index. L exception du guide — un site derive du meme index que son tenant — disparait. Ce qu elle cachait : le plan d administration du site vit dans 10.17.0.0/24, a l interieur du supernet du locataire OPS-Chezlepro. Pas dangereux, mais 10.17.0.0/16 designait deux choses. Et les zones du site ne derivaient de rien — le site etait la seule partie du systeme sans seed. La seconde liste nait avec cette decision : un site et un locataire peuvent desormais reclamer le meme nombre, et make instances ne voyait que les depots OPS-*. La decouverte lit maintenant SITE-*/underlay.yml et son champ index. Un site sans index declare reste hors du compte. SITE-Technolibre : squelette du deuxieme site pour la visite du 14. Un seul noeud Proxmox en version 9, meme forme que Chezlepro, adresse depuis l index 31. COLLECTE.md liste les 35 valeurs a relever. Reste a l exploitant : OPS-Chezlepro passe a 37, ce qui libere 17 pour le site qui l utilise deja. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
This commit is contained in:
parent
912a84483f
commit
28d278111c
4 changed files with 44 additions and 37 deletions
|
|
@ -59,7 +59,7 @@ Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :
|
|||
## 5. Cohabitation d'adressage
|
||||
|
||||
- [ ] `ip route` sur le poste de Mathieu — quelles plages `10.x` sont déjà prises ?
|
||||
- [ ] Son réseau bureautique / son VPN utilisent-ils `10.0.3x` ou `10.23.x` ? ______
|
||||
- [ ] Son réseau bureautique / son VPN utilisent-ils `10.31.x` ou `10.23.x` ? ______
|
||||
- [ ] Docker présent sur ses machines d'administration ? (`172.17`+ déjà pris)
|
||||
|
||||
## 6. Le gabarit
|
||||
|
|
@ -93,6 +93,5 @@ Par un canal chiffré, **séparément du reste**, et jamais dans git :
|
|||
(`proxmox-firewall` nftables en 9) et le SDN (passé GA).
|
||||
- [ ] **Nœud unique** — pas de Ceph, pas de migration, le gabarit et les clones sont sur
|
||||
la même machine. Le SPOF est total et assumé.
|
||||
- [ ] **Deuxième site** — `10.0.31–36` est déjà l'adressage du site de Chezlepro. Les
|
||||
réutiliser ici ferme la possibilité de relier les deux sites (§8 du guide) tant
|
||||
qu'aucun n'est renuméroté.
|
||||
- [ ] **Index 31** — celui du SITE. Vérifier qu'aucune plage `10.31.x` n'existe déjà chez
|
||||
Mathieu (`ip route | grep 10.31`). `make instances` garde la fédération.
|
||||
|
|
|
|||
13
README.md
13
README.md
|
|
@ -41,13 +41,12 @@ dessous de 64 Go, il faut décider de réduire avant de câbler, pas pendant le
|
|||
|
||||
## L'adressage
|
||||
|
||||
- **Gestion** : `10.23.0.0/24` — la bande basse du supernet de son locataire, que la
|
||||
dérivation des zones n'alloue jamais (elles commencent à `.16`).
|
||||
- **Zones du site** : `10.0.31` à `10.0.36` — **identiques à celles de Chezlepro**.
|
||||
Statu quo décidé le 2026-09-12 : un index se redéploie assez facilement pour qu'une
|
||||
collision ne justifie pas de revoir la méthode.
|
||||
> Conséquence connue : les deux sites ne peuvent pas être reliés (§8 du guide de
|
||||
> préparation) tant qu'aucun des deux n'est renuméroté.
|
||||
- **Gestion** : `10.31.0.0/24` — l'index du SITE, distinct de celui de son locataire
|
||||
(23). Le plan d'administration de l'hébergeur ne vit plus chez un de ses clients.
|
||||
- **Zones du site** : `10.31.31` à `10.31.36` — **même forme que Chezlepro** (le 3e octet
|
||||
reste le numéro de VLAN), avec l'index du site au 2e octet.
|
||||
> Décision du 2026-09-12 : sites et locataires se partagent la classe A, chacun avec son
|
||||
> propre index. Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
|
||||
- **Chemins** (transit) : `10.0.4.0/24`, comme chez Chezlepro.
|
||||
|
||||
## L'ordre des gestes, le jour J
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ serveurs:
|
|||
site-ops-01:
|
||||
etat: actif
|
||||
reseau: site-pilotage
|
||||
ip: 10.0.31.11
|
||||
ip: 10.31.31.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 4096, disque: 40G }
|
||||
vmid: 9001
|
||||
|
|
@ -67,7 +67,7 @@ serveurs:
|
|||
site-cache-01:
|
||||
etat: actif
|
||||
reseau: site-genome
|
||||
ip: 10.0.33.21
|
||||
ip: 10.31.33.21
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 2048, disque: 120G }
|
||||
vmid: 9002
|
||||
|
|
@ -77,7 +77,7 @@ serveurs:
|
|||
site-forge-01:
|
||||
etat: actif
|
||||
reseau: site-genome
|
||||
ip: 10.0.33.11
|
||||
ip: 10.31.33.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 4096, disque: 80G }
|
||||
vmid: 9003
|
||||
|
|
@ -113,7 +113,7 @@ serveurs:
|
|||
site-pki-01:
|
||||
etat: actif
|
||||
reseau: site-autorite
|
||||
ip: 10.0.32.11
|
||||
ip: 10.31.32.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 2048, disque: 32G }
|
||||
vmid: 9004
|
||||
|
|
@ -133,7 +133,7 @@ serveurs:
|
|||
site-dns-01:
|
||||
etat: actif
|
||||
reseau: site-service
|
||||
ip: 10.0.34.11
|
||||
ip: 10.31.34.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 2048, disque: 40G }
|
||||
vmid: 9005
|
||||
|
|
@ -175,7 +175,7 @@ serveurs:
|
|||
site-backup-01:
|
||||
etat: actif
|
||||
reseau: site-sauvegarde
|
||||
ip: 10.0.35.11
|
||||
ip: 10.31.35.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 2048, disque: 400G }
|
||||
vmid: 9010
|
||||
|
|
@ -192,7 +192,7 @@ serveurs:
|
|||
site-mon-01:
|
||||
etat: actif
|
||||
reseau: site-supervision
|
||||
ip: 10.0.36.11
|
||||
ip: 10.31.36.11
|
||||
noeud: <<NOEUD>>
|
||||
gabarit: { vcpu: 2, memoire: 4096, disque: 64G }
|
||||
vmid: 9011
|
||||
|
|
|
|||
47
underlay.yml
47
underlay.yml
|
|
@ -12,6 +12,13 @@
|
|||
underlay:
|
||||
# Le locataire que ce site hébergera. Son index est déjà fédéré (23) et il ne
|
||||
# change pas : c'est lui qui porte l'adressage d'OPS-Technolibre, ses VLAN et ses VMID.
|
||||
# L'INDEX DU SITE LUI-MÊME. Déclaré ici, et pas seulement porté par les adresses :
|
||||
# c'est ce qui le rend visible à la garde des collisions (`make instances`).
|
||||
# Depuis le 2026-09-12, SITES et OPS partagent la classe A — deux écosystèmes ne
|
||||
# peuvent donc plus prendre le même nombre, quel que soit leur genre.
|
||||
index: 31
|
||||
|
||||
# Le locataire que ce site hébergera, avec SON index à lui.
|
||||
tenants:
|
||||
OPS-Technolibre: 23
|
||||
|
||||
|
|
@ -32,12 +39,14 @@ underlay:
|
|||
|
||||
reseaux:
|
||||
# PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
|
||||
# `10.<index>.0.0/24`, index 23 : la bande basse du supernet du locataire, que la
|
||||
# dérivation des zones n'alloue jamais (elles commencent à .16).
|
||||
# `10.<index>.0.0/24`, index 31 : celui du SITE, distinct de celui de son
|
||||
# locataire (23). Décision du 2026-09-12 : SITES et OPS partagent la classe A,
|
||||
# chacun avec son propre index — le plan d'administration de l'hébergeur ne vit
|
||||
# plus dans le supernet d'un de ses locataires.
|
||||
- nom: management
|
||||
description: Gestion du nœud, OOB/IPMI, poste de l'exploitant
|
||||
vlan: null
|
||||
sous_reseau: 10.23.0.0/24
|
||||
sous_reseau: 10.31.0.0/24
|
||||
mtu: 1500
|
||||
|
||||
# LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour :
|
||||
|
|
@ -50,15 +59,15 @@ underlay:
|
|||
mtu: 1500
|
||||
|
||||
# LES SIX ZONES DU SITE. Une préoccupation par zone.
|
||||
# ⚠ Identiques à celles du site de Chezlepro (statu quo décidé le 2026-09-12).
|
||||
# Conséquence connue : les deux sites ne pourront pas être reliés (§8 du guide)
|
||||
# tant qu'aucun des deux n'est renuméroté.
|
||||
- { nom: site-pilotage, description: Runner et pilotage, vlan: 31, sous_reseau: 10.0.31.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.0.32.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.0.33.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.0.34.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.0.35.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.0.36.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
# Même FORME que le site de Chezlepro — le 3e octet reste le numéro de VLAN.
|
||||
# Ce qui change : le 2e octet porte l'index du site (31) au lieu de 0.
|
||||
# Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
|
||||
- { nom: site-pilotage, description: Runner et pilotage, vlan: 31, sous_reseau: 10.31.31.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.31.32.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.31.33.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.31.34.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: <<PONT>>, mtu: 1500 }
|
||||
|
||||
hotes:
|
||||
# L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
|
||||
|
|
@ -67,14 +76,14 @@ underlay:
|
|||
|
||||
# LA FRONTIÈRE, patte par patte. Une ligne par zone qu'elle sert : c'est de là que
|
||||
# le devis dérive les interfaces d'arrivée des règles (D-61 raisonne en ARRIVÉE).
|
||||
- { nom: <<FRONTIERE>>, reseau: management, ip: 10.23.0.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: management, ip: 10.31.0.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-pilotage, ip: 10.0.31.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-autorite, ip: 10.0.32.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-genome, ip: 10.0.33.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-service, ip: 10.0.34.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-sauvegarde, ip: 10.0.35.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-supervision, ip: 10.0.36.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-pilotage, ip: 10.31.31.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-autorite, ip: 10.31.32.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-genome, ip: 10.31.33.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-service, ip: 10.31.34.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-sauvegarde, ip: 10.31.35.1, role: frontiere }
|
||||
- { nom: <<FRONTIERE>>, reseau: site-supervision, ip: 10.31.36.1, role: frontiere }
|
||||
|
||||
# LE GABARIT ET SON STOCKAGE. Sur un nœud unique, `clone_complet` est le choix sûr :
|
||||
# un clone lié dépend à vie du gabarit, et il n'y a pas d'autre nœud pour le porter.
|
||||
|
|
|
|||
Loading…
Reference in a new issue