Case study · High Availability
BnB Genius: alta affidabilità e load balancing a tre server
Un’architettura a tre nodi progettata per distribuire il traffico, mantenere sincronizzati dati e file e continuare a servire il portale anche in caso di indisponibilità di un backend.
Topologia
1 frontend + 2 backend
Database
MySQL master-master
File
Sincronizzazione Unison
Risultato storico
620 giorni continuativi
Il problema
Un portale pubblico non può dipendere da un solo server.
Per bgenius Srl l’obiettivo era ridurre al minimo il downtime e distribuire il carico tra più nodi. L’architettura originale è stata quindi progettata con un frontend di bilanciamento e due server applicativi posteriori.
FRONT
Frontend / load balancer
Il server frontale riceve le richieste e le distribuisce verso i due backend, mantenendo il portale raggiungibile anche quando uno dei nodi posteriori ha un problema.
NODE A
Backend applicativo A
Uno dei due nodi esegue il carico applicativo e mantiene dati e file sincronizzati con il secondo backend.
NODE B
Backend applicativo B
Il secondo nodo lavora in parallelo e può assorbire le richieste quando l’altro backend non è disponibile.
Architettura originale
Tre server, con ruoli distinti e ridondanza sui dati.
La soluzione documentata nel progetto storico utilizzava un server frontale e due backend. Le tecnologie sotto sono quelle dell’implementazione originale e vanno lette nel loro contesto temporale, non come una raccomandazione “2026”.
ENTRY
Client / Internet
Le richieste arrivano al punto di ingresso pubblico del portale.
LB
Frontend
Il nodo frontale smista il traffico e decide verso quale backend inoltrare ogni richiesta.
APP
Backend A / B
I due server applicativi condividono il carico e garantiscono continuità se uno dei nodi viene escluso.
SYNC
Dati e file
MySQL master-master e Unison mantengono allineati database e contenuti applicativi.
Implementazione
Ridondanza anche dentro i singoli nodi.
La progettazione non si fermava al bilanciamento del traffico. Anche storage e sincronizzazione erano stati impostati per ridurre i punti singoli di guasto.
Frontend
Xeon E3 1230, 16 GB RAM, due dischi in RAID1 e collegamento di rete Gigabit.
Backend
Due server Xeon E3 1230 con 16 GB RAM e quattro dischi ciascuno in RAID10.
Gestione
ISPConfig in configurazione master/slave tra i server posteriori.
Sincronizzazione
MySQL master-master per i dati e Unison per i file dei siti web.
620 giorni consecutivi up & running.
Il dato riportato nel case study originale è particolarmente significativo: i tre server rimasero operativi per 620 giorni consecutivi. Non è una promessa di uptime universale, ma un risultato storico concreto ottenuto da quell’architettura e da quel contesto operativo.
Nel documento originale il frontend è indicato come basato su Xrctl. Manteniamo qui il riferimento storico così come documentato, senza reinterpretarlo retroattivamente.
Alta disponibilità significa eliminare i punti singoli di guasto che contano davvero.
Il progetto BnB Genius mostra un principio ancora valido: bilanciamento, replica e ridondanza funzionano soltanto quando vengono pensati come un’unica architettura.