Facebook non è nuova, come anche altri big di Internet, a rilasciare applicazioni che ha sviluppato per necessità interne in open source.

Che sia software, o hardware, Facebook sembra sempre molto aperta a rilasciare codice, e ne è dimostrazione il rilascio in questi giorni di Katran, un bilanciatore network da lei sviluppato.

In pratica, come lungamente raccontato nell’articolo di presentazione pubblicato da Facebook stesso, Katran è un bilanciatore layer 4 (nella pila ISO/OSI), ovvero si occupa del trasporto operando sui singoli pacchetti (tipicamente TCP), invece che a livello applicativo (layer 7, come HTTP).

In parole povere, Facebook ha distribuito in tutto il mondo dei Point of Presence (PoP), ovvero dei proxy che accettano le richieste pubblicando VIP (Virtual IP) differenti per locazioni geografiche, e che distribuiscono il traffico sui server di backend: sono solo questi che si occupano, realmente, di gestire le richieste e rispondere ai client.

E fino a qui, nulla di nuovo sotto il sole; ed allora per quale motivo Facebook si è sviluppato un proprio sistema invece di utilizzare uno degli innumerevoli disponibili (sia open source che non)? Beh, probabilmente proprio perché è Facebook, ed il traffico che si trova a gestire è decisamente superiore rispetto a quello di molti altri player del settore.

Inoltre Katran è un Software Defined Load Balancer -ovvero un’architettura distribuita di load balancer definita però a livello di codice in un punto centralizzato- il che sicuramente ha parecchi vantaggi in architetture così estese e, tendenzialmente, così automatizzate come quelle di Facebook; infine, l’azienda aveva dei requisiti ben specifici a riguardo:

• Doveva girare su server Linux accessori, magari già utilizzati per altro, non essere legato ad hardware particolari
• Poter coesistere con altri servizi sullo stesso server
• Permettere il disservizio (in caso di aggiornamento o manutenzione) minimizzando l’impatto o l’effort necessario alla gestione, il tutto per evolvere rapidamente nel tempo.
• Essere facilmente monitorato e debuggato con strumenti semplici e sempre disponibili, quali tcpdump

Il funzionamento di questo bilanciatore, seppure spiegato nel dettaglio nell’articolo, è abbastanza classico, ma il dover gestire una mole considerevole di traffico ha portato Facebook ad applicare alcuni accorgimenti per ottimizzarne il funzionamento, nonché l’utilizzo di feature recenti del kernel Linux. Ecco alcuni esempi:

• l’applicazione di metodologie di gestione degli hash, che permettono di non dover sincronizzare lo stato delle connessioni tra le varie istanze del bilanciatore
• la gestione del traffico in modalità DSR (Direct Server Return), in modo da non passare dal bilanciatore anche per la risposta ed evitare quindi che diventi un collo di bottiglia
• con una combinazione di XDP (eXpress Data Path) ed eBPF (extended Berkeley Packet Filter) per accedere e gestire il pacchetto network appena entrato nella scheda di rete e prima che il kernel lo intercetti.

Insomma, tante tecnologie e tante idee: se anche non dovessimo utilizzare questa soluzione, alcune note possono stuzzicare la fantasia per migliorare quanto già gestiamo.

Potete comunque scaricate il sorgente del balancer direttamente dalla pagina GitHub del progetto. Buona lettura!

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.