Guides

Répartition de charge

VIP NAT à backends surveillés, bascule VRRP et actif-actif BGP.

SiHA répartit la charge avec NATLBMapping : un couple VIP:port → un ensemble de backends, implémenté sur le NAT à états nat44_ed de VPP. Il prend en charge le twice-NAT (SNAT) pour que le backend voie SiHA comme client, des poids par backend, l’affinité de session, et des backends surveillés par sondes. C’est le même dataplane que les règles NAT du pare-feu — une seule table de sessions, un seul modèle mental L4.

L’ensemble des backends actifs est filtré par les sondes du démon probed. La politique de surveillance se déclare dans la ressource ; probed publie des ressources BackendHealthCheckStatus que le contrôleur lit pour construire la liste vivante avant chaque appel VPP.

Sélection du backend

Il n’y a pas d’algorithme d’ordonnancement configurable — ni Maglev, ni round-robin, ni least-connections. La sélection du backend est le schéma probabiliste pondéré natif de VPP dans nat44_ed : chaque backend porte un poids (1–255), et VPP choisit un backend par session proportionnellement à ce poids. Le weight de la spec correspond directement à cette probabilité ; les poids sont relatifs, donc 10/10 répartit les sessions à parts égales et 30/10 envoie ~3× plus de sessions au premier backend. Le choix est fait une fois par session, puis figé par la table de sessions NAT pour toute la durée du flux.

Le seul paramètre de réglage est le weight par backend ; la politique de sélection elle-même n’est pas configurable.

NATLBMapping

type: NATLBMappings.lb.siha
metadata:
  namespace: lb
  id: web
spec:
  vipAddress: 203.0.113.10
  vipPort: 443
  protocol: tcp        # nom (tcp, udp) ou numéro brut
  twiceNat: true       # SNAT : le backend voit l'IP d'interface de SiHA en source
  backends:
    - name: backend-1
      address: 10.0.1.11
      port: 8443
      weight: 10
    - name: backend-2
      address: 10.0.1.12
      port: 8443
      weight: 10
  healthCheck:
    type: HTTP
    port: 8443
    httpPath: /healthz
    httpExpectedStatus: 200
    intervalMs: 5000
    timeoutMs: 2000
    healthyThreshold: 2
    unhealthyThreshold: 3
    failOpen: false

La VIP répond nativement à l’ARP (l’adresse externe rejoint l’ensemble des adresses possédées par le plugin NAT) : une VIP sur le sous-réseau client ne demande ni route supplémentaire ni proxy-ARP.

Twice-NAT (SNAT)

Avec twiceNat: true, VPP réécrit aussi l’adresse source des paquets transférés vers l’IP d’interface de SiHA. Le backend voit SiHA comme client ; ses réponses reviennent naturellement vers SiHA sans routage par politique côté backend.

L’adresse source du SNAT est toujours l’IP de l’interface de sortie du LB. VPP ne répond pas à l’ARP pour une adresse de pool arbitraire en mode twice-NAT — si vous pointez une adresse qui n’est pas déjà configurée sur l’interface de sortie, le trafic retour sera perdu.

Affinité

affinityTimeoutSec active l’affinité de session par IP source (sessions persistantes). 0 (défaut) pour désactiver.

Haute disponibilité

Deux formes de déploiement validées :

Actif/passif — deux équipements partagent la VIP via VRRP ; le twice-NAT rend la bascule transparente pour les backends (le secours reprend la VIP et l’identité SNAT suit).
Actif/actif — chaque équipement annonce la VIP en BGP et la fabrique répartit les flux par ECMP.

Limite connue de l’actif/actif : le placement des flux est un hachage 5-tuple par flux. Quand la topologie ECMP change (un équipement rejoint ou quitte), la fabrique re-hache les flux sur les survivants, et une session TCP qui atterrit en cours de route sur un autre équipement est réinitialisée — l’état de session NAT ne la suit pas. Prévoyez des re-tentatives côté client à la bascule, ou préférez l’actif/passif VRRP quand la bascule sans coupure compte plus que la montée en charge horizontale.

Sondes de santé

Trois types de sonde :

`type`	Ce que probed teste
`DISABLED`	Aucune sonde ; tous les backends sont considérés vivants
`TCP`	Poignée de main complète vers `address:port`
`HTTP`	Requête HTTP complète ; code comparé à `httpExpectedStatus`

failOpen: true considère les backends sains quand probed ne les atteint pas du tout (utile pour tolérer une partition réseau passagère). failOpen: false (défaut) draine immédiatement les backends injoignables — la VIP reste programmée et jette les nouveaux flux tant que tout est down.

Seuils : un backend est déclaré sain après healthyThreshold succès consécutifs, défaillant après unhealthyThreshold échecs consécutifs.

Les sondes passent par la pile hôte de VPP : les backends des sous-réseaux possédés par VPP sont joignables — la configuration dataplane de l’équipement doit activer la session layer (machine.dataplane.hostStack: true dans la config de flotte).

Exploitation

S="sihactl --sihaconfig ~/.siha/config --addr <ip-du-noeud>:6443"

$S get natlb                      # liste des NATLBMappings
$S get natlb web -o yaml          # spec + status complets (backends programmés, santé)

# Détail de santé par backend
$S get bhcs                       # BackendHealthCheckStatuses de tous les mappings
$S get bhcs natlb:web -o yaml     # compteurs de santé par backend

Le bloc status rapporte :

programmedBackends — backends actifs dans VPP (après filtrage santé).
backendHealth — par backend : healthy, consecutiveSuccesses, consecutiveFailures, lastProbeUnixSec, lastError, et les cumuls failedChecks / downCount / downtimeSec.
lastError — dernière erreur de réconciliation du contrôleur.

Notes et limites

Valeurs sentinelles d’énumération

healthCheck.type a une sentinelle _UNSPECIFIED à l’index 0. Omettre le champ (ou la valeur zéro) échoue à la validation — donnez toujours un DISABLED, TCP ou HTTP explicite.

Coexistence avec les règles NAT

NATLBMapping s’appuie sur nat44_ed_lb_static_mapping. Les règles NAT classiques (NATPool, NATStaticMapping, NATInterfaceMode) partagent la même table de sessions et coexistent sur la même interface sans conflit, tant que l’adresse de la VIP n’est pas aussi une adresse du pool NAT.

Visibilité de l’IP client

Avec le twice-NAT, le backend voit l’équipement, pas le client. Sans twice-NAT, l’adresse client est préservée mais le backend doit faire revenir ses réponses par l’équipement. Pour une préservation de l’IP client façon PROXY protocol sur des backends qui ne peuvent faire ni l’un ni l’autre, une ressource LB en mode proxy est sur la feuille de route.