← overview

Worker auto-routing latence

VIP unique · master enrôle · master décide reroute selon /24 réseau · sans intervention DSI

Worker employé Lyon PC poste de travail 192.168.1.250 (/24=192.168.1) VIP cluster keepalived 10.0.0.251 (entry unique) Pool MASTER (Paris) 10.0.0.199 /24 = 10.0.0 enrôle worker, évalue latence Pool PEER bonded (Lyon) 192.168.1.86 /24 = 192.168.1 ✓ match worker cible reroute 1. WS 2. accept 3. /24 worker (192.168.1) ≠ self (10.0.0) 4. find_optimal() match peer /24 5. cmd: migrate_pool target_url=peer 6. drain 60s + persist worker.json + reconnect Doctrine David 2026-05-02 PM "Workers natifs rejoignent le pool virtuel et le pool virtuel se débrouille à ce qu'ils rejoignent le pool le plus efficace pour eux (latence)." Flag DSI : WORKERS_AUTO_ LATENCY_ROUTING default OFF opt-in après stabilité cluster
VIP keepalived (entry unique cluster)
Pool master (élu par admin)
Pool peer bonded (latence-optimal)
Ordre migrate (Ed25519 signed)
Drain + reconnect

Heuristique /24 (MVP)

Le master extrait le sous-réseau /24 du worker (depuis ws.client.host) et le compare contre federation_self.url et chaque peer bonded (trust_level ≥ 2). Match = candidat reroute.

Migration permanente

Le worker patche worker.json côté disque (atomic write no-BOM) avant de close son WS. Au prochain reconnect (et reboot), il pointe directement sur le peer cible. Pas de retour automatique vers l'ancien master.

Garde-fous anti-flap

Idempotence via PK migration_order_id (table worker_migration_orders). 1 ordre par worker (ON CONFLICT DO NOTHING). L'ordre suivant n'est émis que si le worker se reconnecte ailleurs et que le calcul redonne un meilleur peer.

DSI multi-sites : 1 employé Lyon, 1 cluster Paris+Lyon. L'employé installe le worker en pointant la VIP centrale. Le pool virtuel détecte qu'il est physiquement à Lyon, le redirige automatiquement vers le pool Lyon. Latence LAN, aucune intervention.