# M3U96a — Porte d'entrée (gateway) du cluster MacLustr

**Principe.** Pour un projet lourd destiné au cluster, on ne le pousse **qu'une seule fois**
depuis le laptop vers **M3U96a** (le nœud le plus puissant : 32 cœurs / 96 Go, gardé vide
pour ce rôle depuis le nettoyage du 2026-07-31). M3U96a le **diffuse ensuite aux autres
nœuds en parallèle via le réseau local** (192.168.2.x) — pas par internet. Le projet se
retrouve au **même chemin sur tous les nœuds** : `~/cluster-projects/<nom>/`.

```
laptop ──(Tailscale, 1 seul envoi)──▶ M3U96a:~/cluster-projects/<nom>/
                                         │
                                         └──(LAN 192.168.2.x, 18 rsync parallèles)──▶ tous les nœuds
```

## Outil : `cluster-gateway.sh`

`~/Desktop/cluster-skill/cluster-gateway.sh` (testé 18/18 nœuds le 2026-07-31, checksums vérifiés).

| Commande | Effet |
|---|---|
| `cluster-gateway.sh push <dir> [nom]` | **le raccourci habituel** : stage + fanout vers tous les nœuds |
| `cluster-gateway.sh stage <dir> [nom]` | laptop → M3U96a uniquement |
| `cluster-gateway.sh fanout <nom> [nœud …]` | M3U96a → nœuds (défaut : tous sauf M3U96a et M2U64) |
| `cluster-gateway.sh list` | projets stagés sur M3U96a |
| `cluster-gateway.sh where <nom>` | présence + taille du projet sur chacun des 20 nœuds |
| `cluster-gateway.sh clean <nom> [--everywhere]` | efface de M3U96a (ou de partout) |

- `[nom]` par défaut = basename du dossier. Re-exécuter `push`/`fanout` fait une mise à jour incrémentale (`rsync --delete` : les nœuds deviennent le miroir exact du staging).
- **M2U64 (prod) est exclu par défaut** ; l'inclure avec `--include-m2u64`.
- Un fanout partiel se rattrape nœud par nœud : `cluster-gateway.sh fanout <nom> M3BA24`.

## Détails techniques (pourquoi c'est fait comme ça)

1. **SSH inter-nœuds via Tailscale est bloqué** (timeout port 22, vraisemblablement ACL
   tailnet) alors que laptop → nœud passe. Le fanout utilise donc les **IP LAN 192.168.2.x**,
   où SSH nœud-à-nœud fonctionne (auth par agent forwarding, jamais de clé privée sur les nœuds).
2. **Les IP LAN sont en DHCP** → le script les résout **en live** à chaque fanout
   (le laptop demande à chaque nœud son IP du sous-réseau `192.168.2.` sur *toutes* les
   interfaces — certains MacBooks sont branchés par dongle Ethernet, pas en0/en1).
   Conséquence : le host-key checking est désactivé pour ces rsync LAN (IP volatiles,
   réseau privé).
3. Le fanout tourne **sur M3U96a** (ssh -A + heredoc), 18 rsync en parallèle ; ~20 Mo
   vers 18 nœuds ≈ 8 s au premier passage, ~1 s en incrémental.
4. Si un nœud est éteint/hors LAN, il est marqué `FAIL` avec la raison — le reste continue.

## Convention d'usage pour les jobs distribués

- Chemin standard sur tous les nœuds : `~/cluster-projects/<nom>/` — les scripts de
  calcul distribué peuvent s'y fier (`cd ~/cluster-projects/<nom> && …`).
- Workflow type : `push` → lancer le job (`/cluster-run` ou `/cluster-compute`) →
  récupérer les résultats → `clean <nom> --everywhere` quand le projet est fini.
- Gros artefacts communs en lecture (datasets, modèles) : alternative possible via les
  NAS montés partout (`~/nas_clustr`, `~/nas2_clustr`), mais le fanout LAN reste plus
  rapide pour l'exécution (disque local).

## Garder M3U96a « propre »

M3U96a est réservé à ce rôle de passerelle/staging (+ éventuels jobs de calcul) :
**ne pas y déployer d'apps/servies persistants** — les apps web vivent sur M2U64 (prod)
ou un nœud choisi. Sur M3U96a ne doivent vivre que `~/cluster-projects/` et les
services de base (nasmount, tailscale, caffeinate).