Predictive and Adaptive Resource Scheduling for Kubernetes–Ceph Hyperconverged Infrastructure on Proxmox VE

Imagine uma cidade movimentada onde as estradas, a rede elétrica e o abastecimento de água vivem dentro do mesmo bairro. No mundo da computação moderna, isso é chamado de "infraestrutura hiperconvergente". Em vez de ter edifícios separados para servidores (computação), discos rígidos (armazenamento) e cabos de rede, tudo é compactado densamente nos mesmos equipamentos físicos. É eficiente e economiza espaço, mas cria um problema de tráfego complicado. Se um caminhão de entrega enorme (um programa com muitos dados) tenta dirigir por uma rua enquanto uma equipe de construção (uma tarefa de armazenamento) está trabalhando logo ao lado, tudo fica travado.

Para gerenciar esta cidade digital, usamos um sistema chamado Kubernetes. Pense no Kubernetes como o controlador de tráfego da cidade. Seu trabalho é decidir qual edifício (servidor) recebe qual novo caminhão de entrega (programa de software, ou "pod"). No entanto, o controlador de tráfego padrão é um pouco antiquado. Ele olha apenas para o que está acontecendo agora. Ele vê que um edifício está vazio e diz: "Ótimo, envie o caminhão para lá!". Ele não percebe que a rede elétrica daquele edifício já está sofrendo devido a um projeto de construção próximo, ou que o caminhão está prestendo chegar com uma carga que causará um congestionamento em cinco minutos. Esse estilo reativo frequentemente leva a alguns edifícios sendo esmagados sob excesso de trabalho enquanto outros ficam ociosos, e as "estradas" (armazenamento de dados) ficam congestionadas, atrasando tudo.

Este é o quebra-cabeça que uma equipe de pesquisadores de universidades do Uzbequistão e da Romênia decidiu resolver. Eles perguntaram: E se o nosso controlador de tráfego pudesse espiar o futuro? E se ele pudesse prever onde os congestionamentos ocorrerão antes que aconteçam e mover os caminhões de acordo? Em seu artigo, eles construíram um sistema mais inteligente, "preditivo e adaptável", que não apenas reage ao presente, mas planeja para o futuro imediato. Ao combinar uma ferramenta de previsão simples com uma nova forma de posicionamento de software, eles conseguiram suavizar o caos em sua cidade de teste, provando que, às vezes, um pouco de previsão é melhor do que um cérebro supercomplexo.

O Problema: O Controlador de Tráfego Reativo

No mundo digital, os pesquisadores configuraram um ambiente de teste "hiperconvergente" usando três ferramentas principais: Proxmox VE (a fundação que sustenta os servidores), Ceph (o sistema de armazenamento que atua como um gigantesco disco rígido compartilhado) e Kubernetes (o controlador de tráfego).

Em uma configuração padrão, o Kubernetes joga pelo seguro. Ele espera até que um servidor esteja executando um programa, verifica quanto de CPU (poder de processamento) e memória (memória de curto prazo) está sendo usado e, então, decide onde colocar o próximo programa. É como um guarda de trânsito que só vê os carros que estão atualmente na estrada. Se um servidor parece livre, o guarda envia um novo carro para lá. Mas em um sistema hiperconvergente, o "carro" pode precisar acessar o "armazenamento" (o disco rígido) naquele mesmo servidor. Se o guarda não souber que o armazenamento do servidor já está ocupado, o novo carro ficará preso, causando um atraso.

Os pesquisadores descobriram que essa abordagem "reativa" gera três grandes dores de cabeça:

1. Contenção de Recursos: Muitos programas lutando pela mesma CPU ou armazenamento ao mesmo tempo.
2. Desequilíbrio de Carga: Alguns servidores estão suando baldes (rodando a 95% de capacidade) enquanto outros estão tirando uma soneca (rodando a 40% de capacidade).
3. Latência de Armazenamento: O tempo necessário para ler ou gravar dados torna-se mais lento porque o sistema de armazenamento está sobrecarregado.

A Solução: Uma Bola de Cristal e um Mapa Flexível

A equipe propôs um novo modelo que atua como um controlador de tráfego com uma bola de cristal e um mapa flexível. O sistema deles possui quatro partes principais trabalhando em conjunto em um ciclo:

1. A Bola de Cristal (Previsão): Em vez de apenas olhar para o momento atual, o sistema usa um truque matemático chamado "Média Móvel Ponderada Exponencialmente" (EWMA). Pense nisso como um meteorologista que observa a chuva dos últimos dias para adivinhar se você precisará de um guarda-chuva amanh-anhã. Ele prevê quanta CPU e armazenamento um programa precisará nos próximos minutos. Eles descobriram que uma configuração específica para esta "previsão" funcionou melhor, prevendo as necessidades de CPU com cerca de 8,4% de erro, memória com 5,1% de erro e necessidades de armazenamento com 12,3% de erro.
2. O Mapa Flexível (Escalonamento Adaptativo): Uma vez que o sistema sabe o que está por vir, ele não apenas despeja o programa no primeiro servidor vazio. Ele calcula a "carga prevista" para cada servidor. Ele pergunta: "Se eu colocar este programa aqui, o servidor ficará sobrecarregado em cinco minutos?". Se a resposta for sim, ele pula esse servidor e encontra um lugar melhor.
3. A Decisão Consciente do Armazenamento: Este é o ingrediente secreto. O sistema não olha apenas para a CPU; ele também verifica a saúde do armazenamento Ceph (os daemons "OSD" ou de armazenamento). Se um servidor tem um disco de armazenamento ocupado, o sistema sabe que deve enviar os programas pesados de dados para outro lugar, mesmo que a CPU pareça livre.
4. O Ajuste Dinâmico: Se um programa subitamente precisar de mais potência do que o esperado, o sistema pode ajustar automaticamente seus limites sem travar ou reiniciar, mantendo o fluxo suave.

O Experimento: Um Teste em Três Cidades

Para ver se isso funcionava, os pesquisadores construíram uma cidade real de pequena escala usando três computadores físicos (nós). Cada nó possuía um processador potente, 32 GB de RAM e dois SSDs NVMe rápidos (discos rígidos supervelozes). Eles preencheram esta cidade com diferentes tipos de tráfego:

• Caminhões pesados de CPU: Programas que apenas processam números (como o stress-ng).
• Caminhões pesados de Armazenamento: Programas que leem e escrevem quantidades massivas de dados (como o fio).
• Tráfego misto: Bancos de dados e aplicações web que fazem um pouco de tudo (como o YCSB).

Eles executaram dois cenários lado a lado por 3 / 30 minutos.

• Cenário A (O Jeito Antigo): Kubernetes padrão, sem previsão.
• Cenário B (O Jeito Novo): O modelo preditivo e adaptativo deles.

Os Resultados: Ruas Mais Suaves, Entrega Mais Rápida

Os resultados foram uma vitória clara para o novo modelo, e os números contam uma história vívida de melhoria.

1. Equilibrando a Carga:
No jeito antigo, o tráfego era extremamente desigual. Um servidor estava gritando sob pressão, rodando a 95,64% de capacidade, enquanto outro mal estava trabalhando, a 39,73%. O "desequilíbrio" (a diferença entre o servidor mais ocupado e o menos ocupado) era um caos de 53,29%.
Com o novo modelo, o tráfego suavizou perfeitamente. O servidor mais ocupado caiu para 67,41%, e o mais calmo acordou para 56,33%. O desequilíbrio despencou para apenas 10,98%. Isso é uma redução de 79,4% no caos. O novo sistema manteve todos os servidores em uma faixa estreita e feliz de uso, entre 54% e 68%, o que significa que ninguém estava sobrecarregado e ninguém estava entediado.

2. Acelerando o Armazenamento:
Como o novo sistema sabia onde o armazenamento estava ocupado, ele evitou o congestionamento das estradas. O tempo médio para aplicar mudanças de armazenamento (latência) caiu de 1,11 ms para 1,00 ms. Embora pareça uma diferença minúscula, no mundo dos dados, isso significa que o sistema é mais consistente e confiável. O atraso do "pior caso" (o percentil 95) também melhorou de 1,15 ms para 1,00 ms, mostrando que o sistema lidou muito melhor com o tráfego pesado.

3. Sem Custo Extra:
Os pesquisadores fizeram questão de notar que não precisaram reconstruir toda a cidade ou usar cérebros de IA complexos e caros. Eles usaram ferramentas padrão (Kubernetes e APIs do Prometheus) e um método de previsão simples. Eles provaram que não é necessário um algoritmo supercomplexo para obter ótimos resultados; basta conectar os pontos entre computação e armazenamento.

A Conclusão: Integração sobre Complexidade

A parte mais emocionante deste artigo não é apenas que funcionou, mas por que funcionou. Os pesquisadores argumentam que o problema não era que o antigo controlador de tráfego era muito burro; era que ele estava olhando para o problema em apenas uma dimensão. Ele via a CPU, mas ignorava o armazenamento.

Ao simplesmente adicionar uma camada de "previsão" e "consciência de armazenamento" ao sistema existente, eles alcançaram ganhos massivos. Eles mostraram que a integração arquitetônica (fazer a computação e o armazenamento conversarem entre si) é mais poderosa do que apenas tornar os algoritmos mais complicados. Mesmo uma ferramenta de previsão simples e leve, quando combinada com um posicionamento inteligente, pode corrigir os maiores gargalos em um sistema hiperconvergente.

No fim, este artigo sugere que o futuro da computação eficiente não é necessariamente construir cérebros maiores e mais inteligentes, mas garantir que as diferentes partes do sistema estejam de mãos dadas e olhando para frente juntas. O controlador de tráfego não precisa ser um gênio; ele só precisa saber o que está vindo pela próxima esquina.