2026-09-13 19:09:14 -04:00
|
|
|
# SITE-TechnoLibre — site de reprise
|
2026-09-12 14:16:58 -04:00
|
|
|
|
2026-09-13 19:09:14 -04:00
|
|
|
> **Pour qui :** l'**exploitant**, quand il prépare ou joue une reprise.
|
2026-09-12 14:16:58 -04:00
|
|
|
|
2026-09-13 19:09:14 -04:00
|
|
|
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.
|
2026-09-12 14:16:58 -04:00
|
|
|
|
|
|
|
|
## Ce qui le distingue du site de Chezlepro
|
|
|
|
|
|
|
|
|
|
| | Chezlepro | Technolibre |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| Nœuds Proxmox | 3 (asgard, gandalf, vishnu) | **1** |
|
|
|
|
|
| Version | PVE 8.4 | **PVE 9** |
|
|
|
|
|
| Stockage partagé | Ceph NVMe + TrueNAS iSCSI | **local au nœud** |
|
|
|
|
|
| Clones | liés, sur stockage partagé | **complets** — pas d'autre nœud pour porter le gabarit |
|
|
|
|
|
| Frontière | OPNsense | OPNsense |
|
|
|
|
|
|
|
|
|
|
Trois conséquences directes :
|
|
|
|
|
|
|
|
|
|
1. **Le SPOF est total et assumé.** Le gabarit, ses clones et le site entier sont sur la
|
|
|
|
|
même machine. Perdre le nœud, c'est tout perdre — d'où l'importance du 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 et coûte une dépendance.
|
|
|
|
|
3. **Proxmox 9 n'a jamais été éprouvé.** Le moteur n'analyse aucune version et n'appelle
|
|
|
|
|
que des chemins d'API stables, mais c'est la première fois. Surveiller le pare-feu
|
|
|
|
|
(`proxmox-firewall` nftables depuis la 9) et le SDN (passé GA).
|
|
|
|
|
|
|
|
|
|
## Le chiffre à vérifier en premier
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
SITE 7 VM 20 Go RAM 776 Go provisionnés
|
|
|
|
|
tenant 14 VM 37 Go RAM 460 Go provisionnés
|
|
|
|
|
─────────────────────────────────────────
|
|
|
|
|
TOTAL 21 VM 57 Go RAM ~1,2 To
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Sur un seul nœud, la même machine porte tout, et **la RAM est la contrainte dure**. En
|
|
|
|
|
dessous de 64 Go, il faut décider de réduire avant de câbler, pas pendant le déploiement.
|
|
|
|
|
|
|
|
|
|
## L'adressage
|
|
|
|
|
|
2026-09-12 14:31:52 -04:00
|
|
|
- **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.
|
2026-09-12 14:16:58 -04:00
|
|
|
- **Chemins** (transit) : `10.0.4.0/24`, comme chez Chezlepro.
|
|
|
|
|
|
|
|
|
|
## L'ordre des gestes, le jour J
|
|
|
|
|
|
|
|
|
|
1. Remplir `COLLECTE.md` **en entier** — une ligne vide bloque plus tard, ailleurs.
|
|
|
|
|
2. Reporter les valeurs dans `underlay.yml`, `plan/10-intrants.yml`, `opnsense.yml`.
|
|
|
|
|
3. Trancher le mode de routage devant le matériel (`COLLECTE.md` §4).
|
|
|
|
|
4. Gabarit : vérifier ou fabriquer (`docs/procedure-template-debian13-proxmox.md`).
|
|
|
|
|
5. Voûte : y déposer les deux paires de secrets, jamais dans git.
|
|
|
|
|
6. `make underlay` — le devis lit le site réel et refuse ce qui ne concorde pas.
|
|
|
|
|
7. `make site-creer CONFIRMER=true`, puis le socle.
|
|
|
|
|
|
|
|
|
|
## 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 `OPS-Technolibre` ensuite
|
|
|
|
|
- `docs/hebergeur-exploitation.md` — l'exploitation courante
|