Em Nós discutimos as tentativas de utilizar o Watcher e apresentamos um relatório de testes. Realizamos esses testes periodicamente para balanceamento e outras funções críticas de grandes nuvens corporativas ou de operadores.
A alta complexidade do problema em questão pode exigir vários artigos para descrever nosso projeto. Hoje publicamos o segundo artigo da série, dedicado ao balanceamento de máquinas virtuais na nuvem.
Um pouco de terminologia
A empresa VmWare introduziu a ferramenta DRS (Distributed Resource Scheduler) para balanceamento de carga no ambiente de virtualização que ela desenvolve e oferece.
Como escreve
«VMware DRS (Planejador de Recursos Distribuídos) é uma ferramenta que equilibra as cargas de computação com os recursos disponíveis em um ambiente virtual. A ferramenta faz parte do pacote de virtualização denominado VMware Infrastructure.
Com o VMware DRS, os usuários definem regras para a distribuição de recursos físicos entre as máquinas virtuais (VM). A ferramenta pode ser configurada para gerenciamento manual ou automático. Os pools de recursos VMware podem ser facilmente adicionados, removidos ou reorganizados. Se desejado, os pools de recursos podem ser isolados entre diferentes unidades de negócios. Se a carga de trabalho de uma ou mais máquinas virtuais mudar drasticamente, o VMware DRS redistribui as máquinas virtuais entre os servidores físicos. Se a carga de trabalho total diminuir, alguns servidores físicos podem ser desligados temporariamente, e a carga de trabalho pode ser consolidada.»
Por que é necessário o balanceamento?
Na nossa opinião, o DRS é uma funcionalidade obrigatória em nuvens, embora isso não signifique que o DRS deva ser usado sempre e em todos os lugares. Dependendo do propósito e das necessidades da nuvem, podem existir diferentes requisitos para o DRS e para os métodos de balanceamento. Pode haver situações em que o balanceamento não é necessário ou até mesmo prejudicial.
Para entender melhor onde e para quais clientes o DRS é necessário, vamos analisar seus objetivos e demandas. As nuvens podem ser divididas em públicas e privadas. Aqui estão as principais diferenças entre essas nuvens e os objetivos dos clientes.
Nuvens particulares / Grandes clientes corporativos
Nuvens públicas / Pequenas e médias empresas, pessoas
O principal critério e objetivo do operador
Fornecer um serviço ou produto confiável
Redução de custos dos serviços na disputa no mercado competitivo
Requisitos do serviço
Confiabilidade em todos os níveis e em todos os elementos do sistema
Desempenho garantido
Priorização das máquinas virtuais em várias categorias
Segurança da informação e segurança física dos dados
SLA e suporte 24 horas por dia
Máxima simplicidade para obter o serviço
Serviços relativamente simples
A responsabilidade pelos dados é do cliente
Priorização das VMs não é necessária
Segurança da informação ao nível de serviços padrão, responsabilidade do cliente
Podem ocorrer falhas
Sem SLA, qualidade não garantida
Suporte por e-mail
Backup não é obrigatório
Características do cliente
Uma gama muito ampla de aplicações.
Aplicações legadas herdadas pela empresa.
Arquiteturas complexas personalizadas para cada cliente.
Regras de afinidade.
Funcionamento contínuo do software em modo 7x24.
Meios de backup 'em tempo real'.
Carga cíclica previsível do cliente.
Aplicações padrão – balanceamento de rede, Apache, WEB, VPN, SQL
Pode haver interrupção temporária da aplicação
Distribuição arbitrária de VMs na nuvem é permitida
Backup realizado pelo cliente
Carga estatisticamente média previsível com um grande número de clientes.
Consequências para a arquitetura
Geoclasificação
Sistema de armazenamento de dados centralizado ou distribuído
SRK reservável
Armazenamento local de dados nos nós computacionais
Objetivos de balanceamento
Distribuição uniforme da carga
Máxima capacidade de resposta das aplicações
Mínimo tempo de latência no balanceamento
Balanceamento apenas em caso de necessidade explícita
Levantamento de parte do equipamento para manutenção preventiva
Redução dos custos do serviço e despesas do operador
Desconexão de parte dos recursos em caso de baixa carga
Economia de energia elétrica
Redução dos custos com pessoal
Chegamos às seguintes conclusões:
Para nuvens privadas, fornecidas a grandes clientes corporativos, o DRS pode ser aplicado com as seguintes restrições:
- segurança da informação e consideração das regras de afinidade no balanceamento;
- disponibilidade de recursos suficientes em reserva em caso de emergência;
- os dados das máquinas virtuais estão em um sistema de armazenamento centralizado ou distribuído;
- distribuição temporal de procedimentos de administração, backup e balanceamento;
- balanceamento apenas dentro do conjunto de hosts do cliente;
- balanceamento somente em caso de forte desequilíbrio, as migrações de VMs mais eficazes e seguras (pois a migração pode não ser bem-sucedida);
- balanceamento em relação a VMs 'tranquilas' (a migração de VMs 'ativas' pode demorar muito);
- balanceamento levando em conta o 'custo' — carga em armazenamento e rede (em arquiteturas personalizadas para grandes clientes);
- balanceamento considerando as particularidades do comportamento de cada VM;
- balanceamento preferencialmente fora do horário de operação (à noite, fins de semana, feriados).
Para nuvens públicas, que fornecem serviços a pequenos clientes, o DRS pode ser aplicado com muito mais frequência, com capacidades expandidas:
- ausência de restrições de segurança da informação e regras de afinidade;
- balanceamento dentro da nuvem;
- balanceamento a qualquer momento razoável;
- balanceamento de qualquer VM;
- balanceamento de VMs 'ativas' (para não interferir nas demais);
- os dados das máquinas virtuais geralmente estão em discos locais;
- consideração da performance média do armazenamento e da rede (a arquitetura da nuvem é unificada);
- balanceamento com base em regras generalizadas e na estatística de comportamento do data center.
A complexidade do problema
A complexidade do balanceamento reside no fato de que o DRS deve operar com uma grande quantidade de fatores incertos:
- o comportamento dos usuários de cada um dos sistemas de informação dos clientes;
- os algoritmos de funcionamento dos servidores dos sistemas de informação;
- o comportamento dos servidores do SGBD;
- carga sobre recursos computacionais, armazenamento, rede;
- a interação entre servidores na luta por recursos da nuvem.
A carga de um grande número de servidores virtuais de aplicativos e bancos de dados sobre os recursos da nuvem se distribui ao longo do tempo, com consequências que podem se manifestar e se sobrepor com efeitos imprevisíveis em momentos imprevisíveis. Mesmo para gerenciar processos relativamente simples (por exemplo, para controlar um motor, um sistema de aquecimento de água em uma casa), sistemas de controle automático precisam usar complexos com feedback.
Nossa tarefa é muito mais complexa e existe o risco de que o sistema não consiga equilibrar a carga em valores estáveis em um tempo razoável, mesmo que não ocorram influências externas por parte dos usuários.
A história de nossos desenvolvimentos
Para resolver esse problema, decidimos não começar do zero, mas sim basear-nos na experiência existente e começar a interagir com especialistas que já possuem experiência nesta área. Por sorte, nossa compreensão da problemática estava completamente alinhada.
Etapa 1
Utilizamos um sistema baseado em tecnologia de redes neurais e tentamos otimizar nossos recursos com base nele.
O interesse desta etapa estava na experimentação de uma nova tecnologia, e sua importância residia na aplicação de uma abordagem não convencional para resolver a tarefa, na qual, em condições equivalentes, as abordagens padrão praticamente se esgotaram.
Lançamos o sistema e realmente começou a balancear. A escala de nossa nuvem não nos permitiu obter os resultados otimistas anunciados pelos desenvolvedores, mas era evidente que o balanceamento estava funcionando.
Entretanto, tínhamos limitações bastante sérias:
- Para treinar a rede neural, é necessário que as máquinas virtuais operem sem alterações significativas durante semanas ou meses.
- O algoritmo é projetado para otimização com base na análise de dados 'históricos' anteriores.
- Para treinar a rede neural, é necessário um volume considerável de dados e recursos computacionais.
- A otimização e o balanceamento podem ser realizados relativamente raramente – uma vez a cada várias horas, o que é claramente insuficiente.
Etapa 2
Como não estávamos satisfeitos com a situação, decidimos modificar o sistema e, para isso, responder a a principal questão – para quem estamos fazendo isso?
Primeiramente – para clientes corporativos. Portanto, precisamos de um sistema que opere de forma ágil, com aquelas limitações corporativas que facilitam a implementação.
Segunda pergunta – o que entender por 'ágil'? Após breves debates, decidimos que poderíamos partir do tempo de resposta de 5 a 10 minutos, para que picos momentâneos não colocassem o sistema em ressonância.
A terceira pergunta – qual o tamanho da quantidade de servidores a ser balanceada?
Essa questão se resolveu sozinha. Normalmente, os clientes não tornam os aglomerados de servidores muito grandes, e isso está de acordo com as recomendações do artigo de limitar os aglomerados a 30-40 servidores.
Além disso, ao segmentar o pool de servidores, simplificamos a tarefa do algoritmo de balanceamento.
Quarta questão – até que ponto uma rede neural com seu longo processo de treinamento e raras balanceações nos convém? Decidimos abandoná-la em favor de algoritmos operacionais mais simples, para obter resultados em segundos.
Você pode se familiarizar com a descrição do sistema que utiliza esses algoritmos e suas desvantagens.
Implementamos e lançamos este sistema e obtivemos resultados promissores – atualmente, ele analisa regularmente a carga da nuvem e fornece recomendações para mover máquinas virtuais, que são em grande parte corretas. Mesmo agora, é visível que podemos conseguir uma liberação de 10-15% dos recursos para novas máquinas virtuais, melhorando a qualidade do trabalho das existentes.
Ao detectar um desbalanceamento de RAM ou CPU, o sistema envia comandos ao agendador Tionix para realizar a migração ao vivo das máquinas virtuais necessárias. Como pode ser visto no sistema de monitoramento, a máquina virtual foi transferida de um (superior) para outro (inferior) host, liberando memória no host superior (destacada em círculos amarelos), ocupando-a, respectivamente, no inferior (destacada em círculos brancos).
Atualmente, estamos tentando avaliar mais precisamente a eficácia do algoritmo em operação e tentando encontrar possíveis falhas.
Etapa 3
À primeira vista, poderia-se ficar satisfeito, esperar a eficácia comprovada e encerrar o assunto.
Mas somos levados a realizar uma nova fase pelas evidentes oportunidades de otimização.
- Estatísticas, por exemplo, e mostram que sistemas com dois e quatro processadores têm desempenho significativamente inferior aos de um único processador. Portanto, todos os usuários obtêm de CPUs, RAM, SSD, LAN e FC comprados em sistemas multiprocessadores um retorno significativamente menor em comparação com os de um único processador.
- Os próprios planejadores de recursos podem operar com erros sérios, sobre este tema.
- As tecnologias de monitoramento de RAM e cache oferecidas pelas empresas Intel e AMD permitem estudar o comportamento das máquinas virtuais e organizá-las de forma que os vizinhos "barulhentos" não atrapalhem as máquinas virtuais "tranquilas".
- Expansão do conjunto de parâmetros (rede, armazenamento de dados, prioridade da máquina virtual, custo da migração, prontidão para migração).
Total
O resultado do nosso trabalho para aperfeiçoar os algoritmos de balanceamento foi uma conclusão clara de que, por meio de algoritmos modernos, é possível alcançar uma otimização significativa dos recursos (25-30%) dos data centers e, ao mesmo tempo, melhorar a qualidade do atendimento ao cliente.
O algoritmo baseado em redes neurais é, sem dúvida, uma solução interessante, mas que precisa de desenvolvimento adicional e, devido às limitações existentes, não é adequado para resolver esse tipo de tarefa em volumes característicos de nuvens privadas. Entretanto, em nuvens públicas de grande porte, o algoritmo apresentou bons resultados.
Falaremos mais sobre as capacidades dos processadores, escalonadores e balanceamento em alto nível nos próximos artigos.
Fonte: habr.com
