Cloudflare Load Balancer: setup multi-origine con health check
Cloudflare Load Balancer permette di distribuire il traffico HTTP/HTTPS tra più server origine con strategia configurabile (round-robin, weighted, geo-steering, random), health check attivi e failover automatico. È utile per garantire alta disponibilità, scalare orizzontalmente, fare canary deploy o instradare utenti verso il datacenter più vicino. Disponibile come add-on su tutti i piani a partire da 5 dollari/mese.
Componenti principali
Il Load Balancer Cloudflare ha tre concetti chiave: Origin Pools raggruppano server origine con configurazione comune. Health Checks verificano periodicamente se ciascuna origine è disponibile e in stato healthy. Load Balancers sono le istanze attaccate a un'hostname (es. app.tuosito.it) che inviano richieste ai pool secondo regole. Si possono creare load balancer multipli per hostname diversi nella stessa zona.
Procedura passo-passo
- Vai sul dashboard Cloudflare → Traffic → Load Balancing.
- Abilita il servizio (5 dollari/mese base + costi per origin/health check).
- Crea un Origin Pool con almeno 2 origini (IP/hostname + porta).
- Assegna pesi (weight) per bilanciamento weighted.
- Configura health check: URL endpoint (/health), method GET, expected status 200, intervallo 60s.
- Crea un Load Balancer e associalo a un'hostname.
- Aggiungi i pool in ordine di priorità (Primary, Fallback).
- Scegli strategia: Off (failover), Random, Geo, Dynamic Steering.
- Salva e attendi convergenza (1-2 minuti).
- Verifica con curl ripetuti che il traffico sia distribuito.
Strategie di steering
Off (Failover): usa sempre Primary, fallback solo se Primary unhealthy. Random: distribuzione casuale uniforme. Geo Steering: regola manuale mappa region -> pool. Dynamic Steering: Cloudflare sceglie il pool con minor RTT verso l'utente (richiede misurazione attiva). Proximity Steering: basato su geolocalizzazione dell'utente. Per la maggior parte dei casi Dynamic Steering offre il miglior bilanciamento performance/affidabilità.
Health Check avanzati
I health check possono essere semplici (HTTP GET status 200) o sofisticati (header check, body match, custom port). La best practice: crea un'endpoint dedicato /health sull'applicazione che verifica stato interno (DB connection, cache, dipendenze) e restituisce 200 solo se tutto è ok. Intervallo consigliato: 30-60 secondi, retry 2-3, soglia di unhealthy 2 fail consecutivi. Setup troppo aggressivo causa flapping.
Session affinity (sticky sessions)
Per applicazioni stateful che richiedono che lo stesso utente vada sempre alla stessa origine, attiva Session Affinity. Cloudflare imposta un cookie __cf_bm o custom che mantiene affinity. Opzioni: cookie-based o IP-based. Durata configurabile (1 ora di default, fino a 24 ore). Utile per: e-commerce con cart locale, applicazioni che cachano dati utente in memoria, sessioni websocket.
Errori comuni e come risolverli
- Health check failing ma origine ok: l'endpoint /health non esiste o richiede auth. Crea endpoint pubblico dedicato.
- Tutto traffico va a una sola origine: pesi sbagliati o pool secondari unhealthy. Verifica dashboard.
- Latenza alta su Dynamic Steering: misurazioni RTT richiedono tempo. Aspetta 24h per dati stabili.
- Affinity non funziona: cookie bloccati dal browser. Verifica configurazione SameSite.
- Costi alti: health check su molte origini si sommano. Aggrega quando possibile.
Use case pratici
Hybrid cloud: bilancia tra origine on-premise e cloud (AWS/Azure). Multi-region active-active: server EU + US con Geo Steering. Blue-green deploy: switch atomico tra due environment. Disaster recovery: primary in DC1, fallback in DC2 con failover automatico. Maintenance window: drain di un'origin pool senza downtime. A/B testing infrastruttura: traffico split per testare nuovo stack.
Costo dettagliato
Il piano Load Balancing base costa 5 dollari/mese e include 500.000 DNS query/mese e 2 origin pools. Origin aggiuntivi 5 dollari/mese cad. Health check 0.30 dollari/mese cad. Pacchetti più grandi con sconti volume su Pro+. Geo Steering richiede Geo Routing add-on. Confrontato con AWS ELB o Google Cloud LB, Cloudflare è economico per traffico moderato; per scala massive valuta soluzioni native cloud.
Domande frequenti
D: Posso bilanciare origini fuori da Cloudflare?
R: Sì, qualsiasi IP o hostname pubblicamente raggiungibile.
D: LB supporta WebSocket?
R: Sì, sessione affinity raccomandata.
D: Health check costoso in banda?
R: No, è poche centinaia di byte ogni 60 secondi.
D: Posso disattivare un'origine manualmente?
R: Sì, dal pool drain l'origine prima di maintenance.
Considerazioni operative finali
Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.
Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.
Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.
Hai bisogno di aiuto?
Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.