Daniel Allaire
912a84483f
Un seul noeud Proxmox en version 9, une frontiere OPNsense. Trois consequences ecrites dans le README : le SPOF est total, les clones sont complets (un clone lie n achete rien sans second noeud), et rien n a jamais tourne contre un PVE 9. Le chiffre a verifier avant de cabler : 57 Go de RAM pour le site et son locataire sur la meme machine. La RAM est la contrainte dure. Adressage au statu quo : gestion en 10.23.0.0/24, zones du site en 10.0.31-36 comme chez Chezlepro. Consequence connue et ecrite : les deux sites ne pourront pas etre relies tant qu aucun n est renumerote. COLLECTE.md liste dans l ordre ce qui doit etre releve sur place, dont la question de forme : ce qu il y a entre le noeud et l OPNsense decide du mode de routage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
84 lines
4.9 KiB
YAML
84 lines
4.9 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.
|
|
tenants:
|
|
OPS-Technolibre: 23
|
|
|
|
# CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — à trancher devant le matériel.
|
|
# `switch` : un commutateur porte les SVI et les ACL (mode par défaut du moteur)
|
|
# `sdn` : EVPN sur le nœud, un VRF par locataire (éprouvé à 3 nœuds, jamais à 1)
|
|
# Voir COLLECTE.md §4 : la réponse dépend de ce qu'il y a entre le nœud et l'OPNsense.
|
|
routage_tenants: <<SWITCH_OU_SDN>>
|
|
routeur: <<NOM_DU_ROUTEUR>> # le commutateur, ou la frontière si elle route tout
|
|
dialecte: <<cisco|binardat>> # dicte la forme des ACL et des routes du devis
|
|
mtu_overlay: 1450
|
|
# À `false` quand le matériel ne sait pas lier une ACL à une interface de routage.
|
|
acl_inter_tenant: <<true|false>>
|
|
|
|
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 23 : la bande basse du supernet du locataire, que la
|
|
# dérivation des zones n'alloue jamais (elles commencent à .16).
|
|
- nom: management
|
|
description: Gestion du nœud, OOB/IPMI, poste de l'exploitant
|
|
vlan: null
|
|
sous_reseau: 10.23.0.0/24
|
|
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.
|
|
# ⚠ 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 }
|
|
|
|
hotes:
|
|
# L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
|
|
- { nom: <<NOEUD>>, reseau: management, ip: <<IP_NOEUD>>, role: hyperviseur }
|
|
- { nom: <<NOEUD>>, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <<IFACE>> }
|
|
|
|
# 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: 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 }
|
|
|
|
# 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:
|
|
vmid_modele: <<VMID_GABARIT>>
|
|
stockage: <<STOCKAGE>>
|
|
clone_complet: true
|