Daniel Allaire
f69aea775f
Il y a bien un commutateur entre la fabric et la frontiere, comme a Chezlepro. `routeur` portait `portail` — la frontiere — parce qu on avait cru le contraire. - routeur : arche-1, le commutateur ; la frontiere ne fait que la bordure nord/sud - grappe-controle (vlan 1, 10.31.1.0/24) : l interface web et l API de Proxmox, a la meme place qu a Chezlepro. `proxmox_api_host` y pointe desormais. - underlay-vxlan (vlan 50, 10.31.50.0/24) : exige par `routage_tenants: sdn`, et il manquait. Adresse derive de l index du site, pas repris de Chezlepro (192.168.50) : les deux sites ont vocation a etre relies. - les hotes : le noeud sur ses quatre pattes, le commutateur, la passerelle amont `routage_tenants` reste `sdn` — c est aussi ce que fait Chezlepro. Verifie : le devis reseau vise arche-1 et emet les VLAN 1, 31-36, 40, 50 avec ZERO SVI, exactement la forme de Chezlepro ; le devis SDN est conforme, 1 zone, 6 VNets, aucune collision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
146 lines
8.2 KiB
YAML
146 lines
8.2 KiB
YAML
# Underlay de SITE-Technolibre — l'infrastructure PHYSIQUE de l'hébergeur.
|
|
#
|
|
# UN SEUL NŒUD PROXMOX, en version 9. C'est la différence de fond avec le site de
|
|
# Chezlepro : pas de Ceph, pas d'iSCSI, pas de migration, pas de fabric de stockage.
|
|
# Le gabarit et ses clones vivent sur la même machine — le SPOF est total, et assumé.
|
|
#
|
|
# Dérivé du modèle `exemples/modeles/socle` (« un seul commutateur, pas de fabric de
|
|
# stockage séparée — le point de départ honnête d'un petit hébergeur »), adapté.
|
|
#
|
|
# ⚠ TOUT CE QUI EST MARQUÉ <<…>> EST À RELEVER SUR PLACE. Voir COLLECTE.md.
|
|
---
|
|
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
|
|
|
|
# CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — `sdn`, COMME CHEZLEPRO.
|
|
#
|
|
# En EVPN, le routage ET le filtrage inter-zone d'un locataire vivent sur le nœud :
|
|
# aucun VLAN de locataire ne circule sur le fil, seulement du VXLAN encapsulé. Le devis
|
|
# switch cesse alors d'émettre VLAN de locataire, SVI et ACL — vérifié le 2026-09-13 :
|
|
# sept VLAN émis (les six du site plus le transit), zéro SVI.
|
|
#
|
|
# L'inter-locataire, lui, sort du VRF et passe par la frontière, qui le police.
|
|
routage_tenants: sdn
|
|
|
|
# LE COMMUTATEUR, ET C'EST UNE CORRECTION (2026-09-13). Ce champ portait `portail`, la
|
|
# frontière, parce qu'on avait cru qu'il n'y avait rien entre la fabric et l'OPNsense.
|
|
# Il y a bien un commutateur — comme à Chezlepro, et à la même place. C'est lui qui
|
|
# porte l'underlay ; la frontière ne fait que la bordure nord/sud.
|
|
routeur: arche-1
|
|
|
|
dialecte: binardat
|
|
mtu_overlay: 1450
|
|
|
|
# UN SEUL LOCATAIRE POUR L'INSTANT, et l'inter-locataire passe déjà par la frontière.
|
|
# Même valeur qu'à Chezlepro. À revoir le jour où un deuxième écosystème s'installe.
|
|
acl_inter_tenant: false
|
|
|
|
# `rstp` plutôt que `mstp` : un seul commutateur, donc aucune instance par VLAN à
|
|
# distinguer. La topologie reste l'étoile de Chezlepro — un centre, des feuilles.
|
|
stp:
|
|
mode: rstp
|
|
topologie: etoile
|
|
|
|
reseaux:
|
|
# PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
|
|
# `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.31.0.0/24
|
|
mtu: 1500
|
|
|
|
# LE PLAN DE CONTRÔLE DE PROXMOX — interface web et API du nœud.
|
|
# Chezlepro le porte sur `vmbr0` en VLAN 1 ; même place ici. C'est l'adresse que
|
|
# `proxmox-hebergeur.yml` désigne comme point de contact, et la seule que le poste
|
|
# de l'exploitant doit joindre pour matérialiser des VM.
|
|
- nom: grappe-controle
|
|
description: Interface web Proxmox et API du nœud
|
|
vlan: 1
|
|
sous_reseau: 10.31.1.0/24
|
|
pont: vmbr0
|
|
mtu: 1500
|
|
|
|
# LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour :
|
|
# elle serait routée jusqu'à la bordure puis muette — très difficile à diagnostiquer.
|
|
- nom: transit-frontiere
|
|
description: Lien nœud Proxmox <-> OPNsense, et sortie par défaut des locataires
|
|
vlan: 40
|
|
sous_reseau: 10.0.4.0/24
|
|
passerelle_sortie: 10.0.4.1
|
|
mtu: 1500
|
|
|
|
# LES SIX ZONES DU SITE. Une préoccupation par zone.
|
|
# 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: vmbr0, mtu: 1500 }
|
|
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.31.32.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.31.33.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.31.34.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: vmbr0, mtu: 1500 }
|
|
|
|
# TRANSPORT DU VXLAN ENTRE VTEP. Exigé par `routage_tenants: sdn` — c'est le réseau
|
|
# dans lequel les tunnels des locataires sont encapsulés. Il ne porte JAMAIS de
|
|
# trafic de gestion, et aucune machine de locataire ne le voit.
|
|
#
|
|
# Chezlepro l'adresse en 192.168.50.0/24 ; ici il DÉRIVE de l'index du site, comme
|
|
# tout le reste. Les deux sites ont vocation à être reliés : deux transports VXLAN
|
|
# au même adressage produiraient une panne dont le message ne parle pas d'adressage.
|
|
- nom: underlay-vxlan
|
|
description: Transport VXLAN entre VTEP — aucun trafic de gestion
|
|
vlan: 50
|
|
sous_reseau: 10.31.50.0/24
|
|
mtu: 1500
|
|
|
|
hotes:
|
|
# L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
|
|
- { nom: atelier, reseau: grappe-controle, ip: 10.31.1.41, role: hyperviseur, via: vmbr0 }
|
|
- { nom: atelier, reseau: management, ip: 10.31.0.41, role: hyperviseur }
|
|
- { nom: atelier, reseau: underlay-vxlan, ip: 10.31.50.41, role: hyperviseur, via: <<IFACE>> }
|
|
- { nom: atelier, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <<IFACE>> }
|
|
|
|
# LE COMMUTATEUR, entre la fabric et la frontière. Une seule patte, sur le plan de
|
|
# gestion : c'est par là qu'on le configure, et le devis n'a pas besoin d'autre chose.
|
|
- { nom: arche-1, reseau: management, ip: 10.31.0.3, role: switch }
|
|
|
|
# LA PASSERELLE AMONT — la boîte du fournisseur d'accès, en amont de la frontière.
|
|
# Déclarée pour que le devis sache où s'arrête notre responsabilité.
|
|
- { nom: routeur-site, reseau: grappe-controle, ip: 10.31.1.254, role: passerelle_amont }
|
|
|
|
# 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: portail, reseau: management, ip: 10.31.0.1, role: frontiere }
|
|
- { nom: portail, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere }
|
|
- { nom: portail, reseau: site-pilotage, ip: 10.31.31.1, role: frontiere }
|
|
- { nom: portail, reseau: site-autorite, ip: 10.31.32.1, role: frontiere }
|
|
- { nom: portail, reseau: site-genome, ip: 10.31.33.1, role: frontiere }
|
|
- { nom: portail, reseau: site-service, ip: 10.31.34.1, role: frontiere }
|
|
- { nom: portail, reseau: site-sauvegarde, ip: 10.31.35.1, role: frontiere }
|
|
- { nom: portail, 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.
|
|
materialisation:
|
|
# MÊME VMID QUE PARTOUT AILLEURS DANS LA FLOTTE. Le gabarit est le même actif d'un
|
|
# site à l'autre ; lui donner un numéro par site obligerait à le chercher.
|
|
vmid_modele: 99998
|
|
# `local-lvm` — le stockage que Proxmox pose à l'installation. Sur un nœud unique il
|
|
# n'y a rien d'autre, et c'est honnête de le dire : quinze clones complets y tiennent
|
|
# ou n'y tiennent pas, et c'est la première chose à mesurer sur place.
|
|
stockage: local-lvm
|
|
clone_complet: true
|