Cos'è il sistema Google Borg?
(credenziali più complete - ho passato cinque anni nel team di Google Borg, di cui diversi come capo tecnico dell'agente del nodo)
Borg è un sistema operativo cluster che Google usa per gestire i carichi di lavoro interni.
Quando si ha un computer standard, e si vogliono eseguire più processi su di esso, il sistema operativo è quello che si occupa della programmazione - determina quale processo ha accesso a quale processore in un dato momento, quale processo ha accesso a quali parti di memoria, decide quali processi devono essere congelati o morire nel caso in cui ci sia una carenza di risorse.
Borg fa la stessa cosa sulla scala di un cluster - migliaia di macchine con un'ottima connettività di rete interna. Quando si vuole eseguire un "servizio" - che è l'equivalente di un "demone" su una macchina normale, qualcosa che dovrebbe rimanere attivo tutto il tempo - lo si "esegue su Borg" - cioè, si dice allo scheduler del cluster Borg che si vogliono, diciamo, 200 copie del binario che determina il servizio. Lo scheduler Borg identifica le macchine nel cluster che avranno la capacità di riserva per eseguire il vostro servizio (eventualmente sfrattando i carichi di lavoro a bassa priorità, se necessario), e invia una richiesta per eseguire il servizio agli agenti di nodo su queste macchine (si noti che più di una copia del vostro servizio potrebbe atterrare sulla stessa macchina, anche se lo scheduler si assicura che non troppe copie atterrino su una macchina, o - in generale - in un dominio di fallimento, per proteggersi da fallimenti correlati).
Gli agenti del nodo impostano l'ambiente per il vostro servizio (abbastanza simile a un contenitore docker, fatto con cgroup, chroot e un mucchio di supporti), innescano il processo, e poi monitorano il suo utilizzo delle risorse (perché reagire alla carenza di risorse a breve termine deve avvenire sul nodo, per ragioni di latenza) e reagiscono se le risorse - CPU o memoria - iniziano a scarseggiare (o perché qualcuno supera i loro limiti prestabiliti, o perché lo scheduler ha sovraccaricato la macchina).
Una cosa simile accade per un carico di lavoro "batch" - che è, un pezzo di calcolo che si suppone venga eseguito fino al completamento; tranne che lo scheduler è molto più aggressivo nello schedulare il batch, e l'agente del nodo è molto più aggressivo nello sfrattarlo / congelarlo; l'assunto è che il batch è lì per assorbire la "capacità di riserva" dei servizi mentre i servizi non ne hanno bisogno, ma va bene sfrattarlo e ritardare il completamento per un po' se i servizi finiscono per avere bisogno delle riserve. Questo trucco funziona, perché i servizi hanno tipicamente bisogno di essere overprovisionati (perché è necessario prepararsi per i picchi della domanda), mentre i lavori batch sono tenuti a fare il checkpoint del loro lavoro periodicamente, quindi non perdono tutto se sfrattati ogni tanto; e significa che o i servizi pagano solo per quello che usano (e non per quello che hanno bisogno di riservare), o che il batch è effettivamente gratuito (a seconda di come le rispettive richieste giocano fuori).
Più dettagli possono essere trovati in questo documento: Gestione di cluster su larga scala a Google con Borg
Articoli simili
- Cos'è Borg a Google?
- Il sistema operativo Windows potrà mai superare il sistema operativo Android o il sistema operativo Apple nei dispositivi mobili?
- Cos'è un file .dex? Cos'è dexopt? Che cos'è odex? Cos'è dexoat? Cos'è ELF? Come funziona tutto questo?
- Google è pagato per fornire il sistema operativo Android ai telefoni? Il costo del sistema operativo è alla fine addebitato al cliente?