Daniel Allaire
2e223f135a
- Carte au schema actuel (index 31, zones derivees, publication VLAN 37), equipements reels : frontiere requin, noeud maurice, commutateur caillou. - Neuf machines, memes noms et VMID qu'au site de Chezlepro ; runner des deux locataires. - maurice : vmbr0 administration (nic0), vmbr1 VLAN-aware pour les VM (nic2) ; stockages nvme et miroir (ZFS 2 x 12 To, site-backup-01). - opnsense.yml : optN mesures (opt1 transit, opt2..opt8 zones, opt9 RELAIS) ; face publique par le relais (opt9, RELAIS_GW), adresse du site et pool des locataires ; silence du relais. - underlay.yml : reseau `relais` (tunnel WireGuard 10.31.60.0/30), hote relais (VPS OVH) et cles publiques des deux bouts. - plan/domaines.yml et plan/mainteneurs.yml ; documentation (README, PREMIERE-HEURE, COLLECTE) a jour du releve sur place. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
112 lines
5.4 KiB
Markdown
112 lines
5.4 KiB
Markdown
# SITE-TechnoLibre — site de reprise
|
||
|
||
> **Pour qui :** l'**exploitant**, quand il prépare ou joue une reprise.
|
||
|
||
Ce site **n'héberge aucune production**. Celle de Chezlepro vit chez Chezlepro, celle de
|
||
TechnoLibre aussi — les deux écosystèmes habitent `SITE-Chezlepro`. Ce site-ci existe pour
|
||
les **reprendre**, lors d'un exercice ou d'un sinistre.
|
||
|
||
C'est pourquoi son `underlay.yml` déclare **les deux index** : 17 et 23.
|
||
|
||
## Ce qu'une reprise demande
|
||
|
||
Un écosystème se reconstitue depuis son propre dépôt. Reprendre, c'est :
|
||
|
||
1. faire pointer le symlink `underlay.yml` du moteur vers ce site ;
|
||
2. reprendre les sept intrants par `make site-intrants` ;
|
||
3. redéployer depuis le dépôt du locataire.
|
||
|
||
**Le plan du locataire ne change pas.** Seul change le site qu'il habite.
|
||
|
||
## Ce que ce site doit porter pour qu'une reprise aboutisse
|
||
|
||
Les mêmes services prêtés que le site de production — cache, forge, noms, dépôt — plus la
|
||
fabrique. Un site de reprise qui n'a pas de forge ne peut pas servir le génome ; un site
|
||
qui n'a pas de cache fait sortir chaque machine sur Internet.
|
||
|
||
## Ce qui n'est pas encore résolu
|
||
|
||
**Les sauvegardes ne sont pas ici.** Chaque écosystème dépose sur le dépôt de son site de
|
||
production. Si ce site brûle, ses sauvegardes brûlent avec lui — et il ne resterait ici que
|
||
de quoi reconstruire des machines vides.
|
||
|
||
Un site de reprise sans la donnée reprend l'infrastructure, pas le service. C'est la
|
||
question à trancher avant de qualifier ce site de « site de reprise » devant quiconque.
|
||
|
||
## Refait le 2026-10-12 sur le modèle de `SITE-Chezlepro`
|
||
|
||
Le dépôt de septembre ne suivait plus les méthodes du moteur : schéma de la carte
|
||
(`nature`, `segment_physique`), zone de publication, edge et DNS public du site,
|
||
`domaines.yml`, `mainteneurs.yml`, réglages de la frontière. Il porte désormais **les mêmes
|
||
fichiers, les mêmes zones et les mêmes noms de VM** qu'au site de Chezlepro — un exploitant
|
||
qui connaît l'un connaît l'autre. Seuls changent l'index (`31`), le domaine
|
||
(`socle.internal`), les noms des équipements (`requin`, `maurice`, `caillou`) et ce que
|
||
seul le matériel peut dire (`<<…>>`, voir `COLLECTE.md`).
|
||
|
||
On le juge **sans toucher au lien** `underlay.yml` du moteur :
|
||
|
||
```
|
||
SETOPS_UNDERLAY=../SITE-Technolibre/underlay.yml python3 scripts/prouver.py
|
||
```
|
||
|
||
Quatre écarts y restent, et ils sont **attendus** pour un site de reprise : les locataires
|
||
désignent encore le site de Chezlepro, où ils tournent (P37, P69, P73, P79).
|
||
|
||
## Ce qui le distingue du site de Chezlepro
|
||
|
||
| | Chezlepro | TechnoLibre |
|
||
|---|---|---|
|
||
| Nœuds Proxmox | 3 (asgard, gandalf, vishnu) | **1** — `maurice`, ASUS Z10PE-D16 WS, 2 CPU, **2 × 128 Go** |
|
||
| Version | PVE 8.4 | **PVE 9** |
|
||
| Stockage | Ceph NVMe + TrueNAS iSCSI | **local au nœud** : `nvme` (VM), `miroir` ZFS 2 × 12 To (sauvegardes) |
|
||
| Clones | liés, sur stockage partagé | **complets** — pas d'autre nœud pour porter le gabarit |
|
||
| Frontière | OPNsense (`bifrost-1`) | OPNsense sur **QOTOM** (`requin`) — 5 × 2,5G, 4 × SFP+ 10G |
|
||
| Adresse publique | fixe (pool de quatre) | **dynamique** — face fixe : le relais (VPS), à confirmer |
|
||
|
||
Trois conséquences directes :
|
||
|
||
1. **Le point unique de panne est total et assumé.** Perdre le nœud, c'est tout perdre —
|
||
d'où le dépôt de sauvegarde hors nœud dès le premier jour.
|
||
2. **`clone_complet: true`.** Un clone lié dépend à vie de son gabarit ; sans second nœud,
|
||
ce lien n'achète rien.
|
||
3. **Proxmox 9 n'a jamais été éprouvé ici.** Surveiller le pare-feu (`proxmox-firewall`
|
||
nftables) et le SDN.
|
||
|
||
## Le chiffre
|
||
|
||
```
|
||
SITE 9 VM 23 Go RAM 816 Go provisionnés
|
||
OPS-Chezlepro ~14 VM ~37 Go RAM ~460 Go \ reprise : l'un, l'autre,
|
||
OPS-Technolibre ~14 VM ~37 Go RAM ~460 Go / ou les deux
|
||
───────────────────────────────
|
||
TOTAL ~37 VM ~97 Go RAM ~1,7 To
|
||
```
|
||
|
||
Avec 256 Go, **la mémoire n'est plus la contrainte** : le site peut reprendre les deux
|
||
locataires à la fois. Le disque, lui, est à mesurer (`vgs ; df -h`).
|
||
|
||
## L'adressage
|
||
|
||
- **Administration** : `10.31.0.0/24`, non étiquetée — frontière `.1` (`requin`), nœud
|
||
`.11` (`maurice`), poste de l'exploitant `.101`, commutateur `.111` (`caillou`).
|
||
- **Zones du site** : `10.31.31` à `10.31.37` (VLAN 31 à 37) — le 3e octet est le VLAN,
|
||
comme chez Chezlepro. `.1` = la frontière, mêmes derniers octets que chez Chezlepro pour les
|
||
VM (`site-forge-01` = `.33.11`, `site-edge-01` = `.37.11`…).
|
||
- **Transit** : `10.0.4.0/24` (VLAN 40) ; **VXLAN** : `10.31.50.0/24` (VLAN 50).
|
||
|
||
## L'ordre des gestes
|
||
|
||
1. `PREMIERE-HEURE.md` : adresses de la frontière et du nœud, comptes d'API et SSH.
|
||
2. Reporter dans `opnsense.yml` les **dix** noms `optN`, et dans `underlay.yml` les cartes du
|
||
nœud (`<<IFACE>>`).
|
||
3. Voûte : les quatre jetons (Proxmox, OPNsense) — les quatorze autres secrets y sont.
|
||
4. `make underlay`, puis le harnais (ci-dessus) — il refuse ce qui ne concorde pas.
|
||
5. `make site-creer CONFIRMER=true`, puis le socle et les services.
|
||
6. Une fois `site-pki-01` en place : `scripts/frontiere_pki.py` (autorité de la frontière,
|
||
syslog, exportateur, interface), puis `opnsense_api_verifier_certs: true`.
|
||
|
||
## Voir aussi
|
||
|
||
- `docs/preparer-un-site-hebergeur.md` — ce qu'un hébergeur doit fournir
|
||
- `docs/implanter-un-tenant-sur-un-site.md` — y poser un locataire
|
||
- `docs/hebergeur-exploitation.md` — l'exploitation courante
|