SPB Git forge
spboucher.ai ↗

spb/cluster-skill

Public
3commits 1branches 0releases
2.9 MBsize
maindefault branch
1 h agolast push
HTML 57.2% Shell 19.1% Python 11.2% CSS 7.4% JavaScript 5.1%
3.6 KB
View source Raw Blame History

# 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>/.

text
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).