Conceitos
Escalonamento de cluster (estilo Borg)
Intuição
Imagine um estacionamento enorme onde chegam carros de dois tipos: os que não podem ficar sem vaga de jeito nenhum (ambulâncias) e os que aceitam esperar ou sair se for preciso. Alguém na entrada decide em qual vaga cada carro entra, de modo a ocupar o máximo de espaço sem deixar buracos inúteis. Quando o lugar aperta, os carros menos importantes cedem a vaga para os importantes. O escalonador de cluster é esse porteiro: ele decide onde cada programa roda numa frota de máquinas e como aproveitar a folga que ninguém está usando.
Como funciona
No Borg, o usuário submete jobs compostos por tasks, que rodam como processos Linux em containers dentro de uma célula (conjunto de máquinas gerenciado como uma unidade). Cada job tem uma prioridade e consome quota (um vetor de recursos por prioridade e período), e a quota é checada no admission control: um job sem quota suficiente é rejeitado na submissão. O Borgmaster, replicado cinco vezes com estado em um store baseado em Paxos, mantém o estado da célula e consulta cada Borglet (agente por máquina) por polling. O scheduler é um processo separado que varre de forma assíncrona a fila de tasks pendentes, da prioridade mais alta para a mais baixa, em duas fases: a checagem de viabilidade filtra máquinas que atendem às restrições e têm recursos, e o scoring escolhe uma entre as viáveis. O scoring híbrido tenta reduzir recursos presos (stranded), evitando tanto o worst fit do E-PVM original quanto o best fit puro. Para escalar, usa score caching, equivalence classes (avalia uma vez um grupo de tasks idênticas) e randomização relaxada (examina máquinas em ordem aleatória até achar viáveis suficientes). Se faltam recursos, uma task de prioridade maior pode fazer preempção de uma menor, mas tasks de produção não preemptam umas às outras, para evitar cascatas. Por fim, o Borgmaster estima a reserva de cada task (uso real mais uma margem de segurança) e recupera a folga entre o limite pedido e essa reserva, que é entregue a tasks non-prod, as quais são mortas ou limitadas se a estimativa falhar, nunca as prod.
Na prática
O ganho prático é utilização: segundo o paper, separar prod e non-prod em células distintas exigiria 20 a 30% mais máquinas na célula mediana, e cerca de 20% do workload roda em recursos recuperados. Escolha esse modelo quando muitos times compartilham uma frota grande com serviços sensíveis a latência e jobs batch tolerantes, e você precisa de prioridade, quota e reaproveitamento de folga. Note também que as tasks em execução continuam rodando mesmo se o Borgmaster inteiro cair, então o plano de controle pode falhar sem derrubar as aplicações.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.