↓ Skip to main content
u-random
u-random
  1. Concetti/

Load Balancer - Active-Active, Active-Passive e Session Affinity

·5 mins
intermedio
Network-Defense Cloud-Security
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Load Balancer - Active-Active, Active-Passive e Session Affinity

Cos'e'
#

Un Load Balancer e' un dispositivo (fisico o virtuale) che distribuisce il traffico in ingresso tra piu' server backend, esponendo un unico Virtual IP (VIP) pubblico. Il suo scopo e' garantire alta disponibilita' e scalabilita': se un server cade, gli altri continuano a servire le richieste senza interruzione.

TL;DR
#

  1. Il client si connette al VIP del Load Balancer (es. 85.10.10.1)
  2. Il LB sceglie un server backend in base all'algoritmo configurato
  3. La richiesta arriva al backend, la risposta torna al client tramite il LB
  4. Se un backend non risponde all'health check, viene rimosso dal pool automaticamente

load-balancing-gibson-figure-9-2.webp

Distribuisce il traffico tra piu' server backend tramite un Virtual IP pubblico, garantendo alta disponibilita' e scalabilita'

Active-Active vs Active-Passive
#

Le due modalita' operative definiscono come i server nel pool vengono utilizzati e come avviene il failover.

load-balancer-active-active.webp

In Active-Active tutti i server sono operativi e ricevono traffico simultaneamente. Il failover e' trasparente: il LB smette semplicemente di inviare richieste al server irraggiungibile, gli altri assorbono il carico extra.

load-balancer-active-passive.webp

In Active-Passive il server primario gestisce tutto. Il server secondario e' in standby: non riceve traffico finche' il primario e' operativo. Quando il primario cade, il LB attiva il passivo. Piu' semplice da gestire ma meno efficiente (il passivo e' una risorsa sprecata in condizioni normali).

ConfigurazioneCome funzionaFailoverEfficienza
Active-activeTutti i server attiviLB smette di inviare al server cadutoMassima
Active-passivePrimario attivo, secondario in standbyIl passivo viene attivato al guasto del primarioMinore

Scheduling Algorithms
#

Gli algoritmi di scheduling determinano quale server backend riceve ogni nuova richiesta. La scelta dipende dal tipo di applicazione e dai requisiti di bilanciamento.

Session Affinity (Sticky Sessions)
#

La Session Affinity e' la funzionalita' che garantisce che tutte le richieste di uno stesso utente vengano instradate sempre allo stesso server backend. E' critica per le applicazioni che salvano lo stato della sessione localmente sul server.

Il meccanismo puo' essere implementato tramite:

  • Cookie: il LB inserisce un cookie nella risposta (es. AWSALB in AWS ALB) con un identificatore del backend. Ad ogni richiesta successiva, il LB legge il cookie e instrada al backend corretto
  • IP hash: l'IP del client viene usato come chiave per selezionare deterministicamente il backend

Dev parallel (PHP/Symfony): In PHP con session.save_handler = files, le sessioni sono salvate come file locali su ciascun server. Con un LB senza sticky sessions, la stessa sessione potrebbe arrivare a due server diversi — uno ha il file di sessione, l'altro no: risultato, l'utente viene sloggato a intermittenza. La soluzione corretta e' centralizzare le sessioni su Redis o Memcached (session.save_handler = redis). Con un session store condiviso, tutti i backend vedono la stessa sessione e si puo' usare round-robin puro senza sticky sessions.

Dev parallel (AWS): AWS ALB gestisce la Session Affinity tramite il cookie AWSALB con durata configurabile. In Symfony Cloud o Vercel, il meccanismo e' trasparente, ma e' fondamentale capire che le variabili di sessione non persistono tra i backend senza uno store centralizzato. Il passaggio da sticky sessions a Redis e' esattamente il tipo di ottimizzazione richiesta quando si scala orizzontalmente.

Health Checks
#

Il Load Balancer verifica periodicamente che ogni backend sia raggiungibile e funzionante. Un backend che non risponde viene rimosso dal pool di routing automaticamente.

flowchart LR
    LB["Load Balancer\n(VIP: 85.10.10.1)"]

    S1["Web Server A\n10.0.1.10\nActive"]
    S2["Web Server B\n10.0.1.11\nActive"]
    S3["Web Server C\n10.0.1.12\nPassive / Standby"]

    U1((User 1)) -->|Req 1| LB
    U2((User 2)) -->|Req 2| LB
    U3((User 3)) -->|Req 3| LB

    LB -->|Bilancia su A| S1
    LB -->|Bilancia su B| S2
    LB -.->|Health check - non invia traffico| S3

    classDef lb fill:#e67e22,stroke:#d35400,color:#fff
    classDef active fill:#27ae60,stroke:#2ecc71,color:#fff
    classDef standby fill:#7f8c8d,stroke:#95a5a6,color:#fff
    classDef user fill:#2c3e50,stroke:#34495e,color:#fff

    LB:::lb
    S1:::active; S2:::active; S3:::standby
    U1:::user; U2:::user; U3:::user

Lettura diagramma: Tre utenti inviano richieste al Virtual IP del Load Balancer. Il LB distribuisce il traffico tra Server A e Server B (entrambi attivi). Server C e' in standby: riceve health check periodici ma non traffico reale. Se A o B cadono, il LB attiva automaticamente C.

I tipi di health check piu' comuni sono:

  • TCP check: verifica che la porta sia aperta (es. TCP 80 o 443)
  • HTTP check: fa una GET a un endpoint specifico (es. /health) e verifica il codice di risposta (200 OK)
  • HTTPS check: come HTTP ma verifica anche il certificato TLS

Layer 4 vs Layer 7
#

Il layer su cui opera il LB determina quanto "capisce" del traffico che gestisce.

LayerVisibilita'Velocita'Funzionalita' tipiche
L4IP + portaAltaPort forwarding, TCP passthrough
L7Header HTTP, URL, cookieMediaContent switching, SSL offloading, WAF integrato

SSL/TLS Offloading
#

Il Load Balancer gestisce la sessione TLS al posto dei backend. I server ricevono il traffico HTTP in chiaro, senza dover gestire la crittografia.

Vantaggi:

  • Riduce il carico CPU sui backend (la crittografia e' onerosa)
  • Hardware dedicato per TLS sull'appliance LB (acceleratori crittografici)
  • Certificati gestiti in un unico punto
Tip

Exam trap SSL offloading: il traffico tra Load Balancer e server backend viaggia in HTTP in chiaro all'interno della rete interna. Un attaccante con accesso alla LAN interna puo' vedere il traffico gia' decifrato. Per ambienti ad alta sicurezza si usa end-to-end encryption senza offloading: il backend gestisce TLS autonomamente.

Scenario Reale Blue Team
#

In un ambiente cloud (AWS), il Load Balancer espone metriche e log che sono fondamentali per il Blue Team.

# Log di accesso AWS ALB (CloudWatch Logs)
# Formato: timestamp elb client:port target:port request ...
2026-07-19T08:23:41.123456Z app/my-alb/abc123 192.168.1.50:54321 10.0.1.10:80 GET https://example.com:443/api/login HTTP/1.1

# Identificare backend con alto tasso di errori 5xx
aws elbv2 describe-target-health --target-group-arn arn:aws:...

# Health check status dei target
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:eu-west-1:123456:targetgroup/my-tg/abc \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State]'

Indicatori di attacco rilevabili dai log ALB:

  • Alto volume di 403/401 → brute force o scan di autenticazione
  • Richieste con User-Agent anomali o mancanti → scanner automatici
  • Picco di richieste da un singolo IP → potenziale DoS
  • Path traversal (../) nei log URL → tentativo di path traversal

Collegato a
#

  • ssl-tls — SSL offloading, gestione certificati TLS
  • reverse-proxy — il reverse proxy e' la categoria che include il LB a L7
  • proxy — proxy forward vs reverse, differenze concettuali
  • zero-trust — HA aumenta superficie di attacco, principio minimo privilegio sui backend

Related