05 — OPÉRATION : piloter le cluster au quotidien

Où suis-je ? Le système est installé (04). Ici : les commandes du quotidien — contrôle des cartes, clés USB, déploiement de LLM, règles à respecter.

1. Contrôle des cartes mères — `node-control.sh`

Première fois : copier le registre, puis remplir chaque carte (voir nodes.conf.example).

cp scripts/nodes.conf.example scripts/nodes.conf
# → remplir : adb_serial / ssh / mac / pmm_gpio_pwr / pmm_gpio_rst

Commandes types :

bash scripts/node-control.sh status   phone-01         # état ADB + version
bash scripts/node-control.sh power-on pc-01            # PC : WoL puis PMM en secours
bash scripts/node-control.sh power-off pc-01           # PC : ssh shutdown, PMM en secours
bash scripts/node-control.sh reboot   phone-01         # adb reboot
bash scripts/node-control.sh format   phone-02         # fastboot format userdata (efface le PIN)
bash scripts/node-control.sh install  pc-02 /mnt/keys/1/soft.bin

Actions par type de carte

Action	Android (adb/fastboot)	PC (ssh/WoL/PMM)
status	`adb get-state`	ping + `uptime`
power-on	réveil USB-C / `fastboot reboot`	WoL → PMM PWR
power-off	`adb reboot -p`	`shutdown -h now` → PMM long
reboot	`adb reboot`	`reboot` → PMM RST
format	`fastboot format userdata`	ISO + preseed/kickstart
install	`adb install .apk` / `fastboot flash`	scp + script

Smartphone sans écran ou verrouillé PIN

Cas	Solution
Débogage USB déjà activé	ADB fonctionne sans écran, même avec PIN
Écran mort / jamais configuré	Boutons physiques → fastboot → `format userdata` (efface le PIN) → flash
Bootloader verrouillé (OEM lock)	❌ Impossible — seule vraie limite

Préparer chaque téléphone UNE FOIS (déblocage OEM + débogage USB) → pilotable à 100 % pour toujours.

2. Clés USB (logiciels + LLM)

Montées automatiquement sous /mnt/keys/<n> par hub-keys.sh.

Clé	Contenu	Montage	Usage
LLM « llm-orchestrator » (autonome)	L’app `llm-orchestrator` (gestion LLM : catalogue, fit, runtimes, déploiement, monitoring) + les poids des modèles (7B, 13B, 70B)	lecture-écriture `/mnt/keys/app/` + `/mnt/keys/app/models/`	L’app démarre depuis cette clé ; gestion, déploiement, monitoring et modèles dans la même app, la même clé ; réglages/catalogue/journaux survivent aux redémarrages. L’Agent IA n’y est pas : c’est une extension de Winux
PLAYSTORE	Logithèque TUTORIAD : logiciels portables open source	lecture `/mnt/keys/playstore/`	Logiciels prêts à l’emploi, lancés depuis la clé sans installation
#1	Système (scripts, helm, charts)	lecture `/mnt/keys/1`	/mnt/keys/1

⚠️ La clé LLM est l’exception à la règle « jamais exécutées » : elle est montée en lecture-écriture et c’est elle qui exécute la chaîne LLM (gestion + déploiement + monitoring) et qui fournit les poids des modèles à deploy-llm.sh. L’extension Agent IA, elle, vit dans l’implémentation Winux sur la carte maître. Toutes deux restent distinctes de la clé de boot (démarrage de Winux).

2bis. Réinstaller l’OS d’un esclave à distance (PXE)

Le maître peut réinstaller l’OS de n’importe quel esclave sans clé USB ni contact : Boot PXE (serveur de provisioning sur le maître — install : voir Installation).

Le scénario en 4 étapes

# 1. Préparation (sur le maître) : « au prochain boot, esclave n°2 → Debian au lieu d'Ubuntu »
#    → modifier la config PXE de l'esclave (FOG/Cobbler web, ou MAAS)

# 2. Reset de l'esclave (depuis le maître — bouton Reset à distance)
bash scripts/node-control.sh reboot pc-02      # ou power-off puis PMM long

# 3-4. Boot PXE + installation autonome : l'esclave redémarre, télécharge le
#      nouvel OS depuis le maître et s'installe 100 % automatiquement, puis reboote

En résumé (ce que le maître héberge)

Service	Rôle
DHCP	Donne une IP à l’esclave au boot + « va chercher ton système chez le maître »
TFTP/HTTP	Héberge les images d’OS (Ubuntu, Debian, Rocky…)
Config auto	Kickstart (RedHat/Rocky) ou Autoinstall/Cloud-Init (Ubuntu)

⚠️ Prérequis BIOS : Boot Réseau (PXE) en 1re priorité dans le BIOS de chaque esclave ; les esclaves doivent être sur le réseau Ethernet (switch), pas en USB4/USB seul. ⚠️ Sans PXE : on garde l’ancien chemin — clé USB + install de node-control.sh (ISO + preseed/kickstart).

3. Déployer un LLM sur la RAM des nœuds

Le concept

Clé USB (LLM .gguf) → hub-keys.sh → Bassin de RAM des nœuds
                        → deploy-llm.sh → Pod llama.cpp → modèle en RAM → API

RAM combinée (exemple)

Nœuds	RAM	Résultat
10 smartphones × 8 Go	80 Go	7B/13B confortable
2 PCs × 32 Go	64 Go	70B shardé
Total	144 Go	plusieurs LLM simultanés

Petit/moyen modèle (7B–13B) — un pod par nœud

bash scripts/deploy-llm.sh /mnt/keys/2/llama-3-8b.Q4_K_M.gguf phone-01

Gros modèle (70B) — sharding multi-nœuds (`--rpc`)

Un pod vit sur UN nœud : la RAM ne se « fusionne » pas seule. Pour un modèle trop grand, le script découpe le modèle en couches réparties sur N nœuds, le nœud principal servant l’API :

bash scripts/deploy-llm-distributed.sh \
  /mnt/keys/4/llama-3-70b.Q4_K_M.gguf \
  pc-01 smartphone-01 smartphone-02 smartphone-03

⚠️ Goulot d’étranglement : à chaque token, les couches s’échangent par le réseau → préférer Ethernet Gigabit, pas WiFi. ⚠️ RAM agrégée ≠ RAM partagée : un pod utilise la RAM de SON nœud. Fusion de RAM magique (RDMA/CCIX) = impossible sur cartes standard.

4. État du cluster

bash scripts/status.sh                   # vision globale
kubectl get nodes -o wide                # nœuds + arch + état
kubectl get pods -A                      # workloads répartis
kubectl apply -f k8s/llm-serve.yaml      # service LLM utilisant la RAM
curl http://llm-api:8080/v1/chat/completions   # test LLM

5. Les règles d’or (à toujours respecter)

Proxmox VE uniquement sur les nœuds PC (amd64-only), jamais sur le boîtier ARM.
Le boîtier est control-plane uniquement (taint NoSchedule) : pas de workload.
Ports serveurs = host-mode (le SoC n’a qu’un contrôleur OTG → pas de gadget USB multiple).
Ports clés : montés/indexés, jamais exécutés sur le boîtier.
WiFi/BT = optionnels (plugins). Control-plane exige Ethernet filaire.
Multi-arch : pods séparés ARM64/amd64, images multi-arch.
RAM agrégée ≠ RAM partagée : gros modèles = sharding --rpc.
Le calcul se distribue par câble (USB4 ou Ethernet switch), jamais par WiFi (saturation immédiate). L’OS du maître ne « voit » pas la RAM/CPU des esclaves : on délègue du code (k3s/MPI/Spark), pas de fusion physique.
Réinstallation d’OS : Boot PXE via le maître (switch Ethernet) si le BIOS le permet ; sinon clé USB + install.
Variante « 2 clusters » : les smartphones en WiFi = nœuds SLM individuels (modèle local, trafic léger). Ils ne participent pas au sharding LLM (goulot réseau) — les gros modèles restent sur le cluster PC en Ethernet. Leur provisioning (fastboot/flash) ne passe que par USB. Voir Architecture.

6. Pour aller plus loin

Schémas réseau/ports : Architecture
Composants, câblage, checklist : Matériel
Contrôleur intelligent : BISCUIT
Scripts détaillés : chaque commande .sh est commentée en tête de fichier