В conversamos sobre nossas tentativas de usar o Watcher e fornecemos um relatório de teste. Periodicamente realizamos esses testes para balanceamento e outras funções críticas de uma grande empresa ou operadora de nuvem.
A alta complexidade do problema a ser resolvido 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.
Alguma terminologia
A empresa VMware introduziu o utilitário DRS (Distributed Resource Scheduler) para equilibrar a carga do ambiente de virtualização que desenvolveu e ofereceu.
Conforme
“VMware DRS (Distributed Resource Scheduler) é um utilitário que equilibra cargas de computação com recursos disponíveis em um ambiente virtual. O utilitário faz parte de um conjunto de virtualização chamado VMware Infrastructure.
Com o VMware DRS, os usuários definem regras para distribuição de recursos físicos entre máquinas virtuais (VMs). O utilitário pode ser configurado para controle 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 em uma ou mais máquinas virtuais mudar drasticamente, o VMware DRS redistribuirá as máquinas virtuais entre servidores físicos. Se a carga de trabalho geral diminuir, alguns servidores físicos poderão ficar temporariamente off-line e a carga de trabalho consolidada."
Por que o equilíbrio é necessário?
Em nossa opinião, o DRS é um recurso de nuvem obrigatório, embora isso não signifique que o DRS deva ser usado sempre e em qualquer lugar. Dependendo da finalidade e das necessidades da nuvem, pode haver diferentes requisitos para DRS e métodos de balanceamento. Pode haver situações em que o equilíbrio não seja necessário. Ou até prejudicial.
Para entender melhor onde e para quais clientes o DRS é necessário, vamos considerar suas metas e objetivos. As nuvens podem ser divididas em públicas e privadas. Aqui estão as principais diferenças entre essas nuvens e os objetivos do cliente.
Nuvens privadas/clientes de grandes empresas
Nuvens públicas / Médias e pequenas empresas, pessoas
O principal critério e objetivos da operadora
Fornecer um serviço ou produto confiável
Reduzindo o custo dos serviços na luta em um mercado competitivo
Requisitos de serviço
Confiabilidade em todos os níveis e em todos os elementos do sistema
Desempenho garantido
Priorize máquinas virtuais em diversas categorias
Segurança da informação e dos dados físicos
SLA e suporte XNUMX horas por dia, XNUMX dias por semana
Máxima facilidade de receber o serviço
Serviços relativamente simples
A responsabilidade pelos dados é do cliente
Não é necessária priorização de VM
Segurança da informação ao nível dos serviços standard, responsabilidade do cliente
Pode haver falhas
Sem SLA, qualidade não garantida
Suporte por e-mail
Backup não é necessário
Recursos do cliente
Gama muito ampla de aplicações.
Aplicativos legados herdados na empresa.
Arquiteturas personalizadas complexas para cada cliente.
Regras de afinidade.
O software funciona sem parar no modo 7x24.
Ferramentas de backup instantâneas.
Carga cíclica previsível do cliente.
Aplicações típicas – balanceamento de rede, Apache, WEB, VPN, SQL
O aplicativo pode parar por um tempo
Permite distribuição arbitrária de VMs na nuvem
Backup do cliente
Carga média estatisticamente previsível com um grande número de clientes.
Implicações para a arquitetura
Geoclustering
Armazenamento centralizado ou distribuído
IBS reservado
Armazenamento de dados locais em nós de computação
Equilibrando metas
Distribuição uniforme de carga
Capacidade máxima de resposta do aplicativo
Tempo mínimo de atraso para balanceamento
Balanceamento apenas quando claramente necessário
Trazendo alguns equipamentos para manutenção preventiva
Reduzindo custos de serviço e custos de operadora
Desativando alguns recursos em caso de carga baixa
Poupando energia
Reduzindo custos de pessoal
Tiramos as seguintes conclusões para nós mesmos:
Para nuvens privadasfornecido a grandes clientes corporativos, o DRS pode ser usado sujeito às seguintes restrições:
- segurança da informação e consideração de regras de afinidade no balanceamento;
- disponibilidade de recursos suficientes de reserva em caso de acidente;
- os dados da máquina virtual estão localizados em um sistema de armazenamento centralizado ou distribuído;
- escalonamento de procedimentos de administração, backup e balanceamento ao longo do tempo;
- balanceamento apenas dentro de um agregado de hosts clientes;
- equilibrar apenas quando há um forte desequilíbrio, as migrações de VM mais eficazes e seguras (afinal, a migração pode falhar);
- equilibrar máquinas virtuais relativamente “silenciosas” (a migração de máquinas virtuais “ruidosas” pode levar muito tempo);
- balanceamento levando em consideração “custo” - carga no sistema de armazenamento e rede (com arquiteturas customizadas para grandes clientes);
- balanceamento levando em consideração as características individuais de comportamento de cada VM;
- O balanceamento é feito preferencialmente em horário não comercial (noites, finais de semana, feriados).
Para nuvens públicasprestando serviços a pequenos clientes, o DRS pode ser usado com muito mais frequência, com recursos avançados:
- ausência de restrições de segurança da informação e regras de afinidade;
- equilíbrio dentro da nuvem;
- equilibrar em qualquer momento razoável;
- balancear qualquer VM;
- equilibrar máquinas virtuais “barulhentas” (para não incomodar outras pessoas);
- os dados da máquina virtual geralmente estão localizados em discos locais;
- levando em consideração o desempenho médio dos sistemas e redes de armazenamento (a arquitetura em nuvem é unificada);
- balanceamento de acordo com regras gerais e estatísticas de comportamento do data center disponíveis.
Complexidade do problema
A dificuldade de balanceamento é que o DRS deve trabalhar com um grande número de fatores incertos:
- comportamento dos utilizadores dos sistemas de informação de cada um dos clientes;
- algoritmos para operação de servidores de sistemas de informação;
- comportamento de servidores SGBD;
- carga em recursos de computação, sistemas de armazenamento, rede;
- interação dos servidores entre si na luta pelos recursos da nuvem.
A carga de um grande número de servidores de aplicativos virtuais e bancos de dados em recursos da nuvem ocorre ao longo do tempo, as consequências podem se manifestar e se sobrepor com um efeito imprevisível em um tempo imprevisível. Mesmo para controlar processos relativamente simples (por exemplo, para controlar um motor, um sistema de aquecimento de água em casa), os sistemas de controlo automático necessitam de utilizar sistemas complexos. algoritmos com feedback.
Nossa tarefa é muitas ordens de grandeza mais complexa, e existe o risco de o sistema não conseguir equilibrar a carga aos valores estabelecidos em um tempo razoável, mesmo que não haja influências externas dos usuários.
História dos nossos desenvolvimentos
Para resolver este problema, decidimos não começar do zero, mas sim aproveitar a experiência existente, e começámos a interagir com especialistas com experiência nesta área. Felizmente, nossa compreensão do problema coincidiu completamente.
estágio 1
Utilizamos um sistema baseado em tecnologia de redes neurais e tentamos otimizar nossos recursos com base nele.
O interesse desta fase era testar uma nova tecnologia, e a sua importância residia na aplicação de uma abordagem não padronizada para resolver um problema onde, em igualdade de condições, as abordagens padronizadas estavam praticamente esgotadas.
Lançamos o sistema e realmente começamos a equilibrar. A escala da nossa nuvem não nos permitiu obter os resultados otimistas declarados pelos desenvolvedores, mas ficou claro que o equilíbrio estava funcionando.
Ao mesmo tempo, tínhamos limitações bastante sérias:
- Para treinar uma rede neural, as máquinas virtuais precisam funcionar sem alterações significativas durante semanas ou meses.
- O algoritmo é projetado para otimização com base na análise de dados “históricos” anteriores.
- Treinar uma rede neural requer uma quantidade bastante grande de dados e recursos computacionais.
- A otimização e o balanceamento podem ser feitos relativamente raramente - uma vez a cada poucas horas, o que claramente não é suficiente.
estágio 2
Como não estávamos satisfeitos com a situação, decidimos modificar o sistema e, para isso, respondemos questão principal – para quem estamos fazendo isso?
Primeiro - para clientes corporativos. Isto significa que precisamos de um sistema que funcione rapidamente, com aquelas restrições corporativas que apenas simplificam a implementação.
Segunda pergunta – o que você quer dizer com a palavra “imediatamente”? Como resultado de um breve debate, decidimos que poderíamos começar com um tempo de resposta de 5 a 10 minutos, para que surtos de curto prazo não introduzissem ressonância no sistema.
Terceira pergunta – que tamanho do número balanceado de servidores escolher?
Este problema foi resolvido sozinho. Normalmente, os clientes não fazem agregações de servidores muito grandes, e isso é consistente com as recomendações do artigo para limitar as agregações a 30 a 40 servidores.
Além disso, ao segmentar o pool de servidores, simplificamos a tarefa do algoritmo de balanceamento.
Quarta questão – quão adequada é uma rede neural para nós com seu longo processo de aprendizagem e raro balanceamento? Decidimos abandoná-lo em favor de algoritmos operacionais mais simples para obter resultados em segundos.
Uma descrição de um sistema que utiliza tais algoritmos e suas desvantagens pode ser encontrada
Implementamos e lançamos este sistema e obtivemos resultados encorajadores - agora ele analisa regularmente a carga da nuvem e faz recomendações para a movimentação de máquinas virtuais, que estão amplamente corretas. Mesmo agora, está claro que podemos conseguir uma liberação de recursos de 10 a 15% para novas máquinas virtuais, ao mesmo tempo que melhoramos a qualidade do trabalho das existentes.
Quando um desequilíbrio na RAM ou CPU é detectado, o sistema emite 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 passou de um host (superior) para outro (inferior) e liberou memória no host superior (destacado em círculos amarelos), ocupando-a respectivamente no host inferior (destacado em branco círculos).
Agora estamos tentando avaliar com mais precisão a eficácia do algoritmo atual e tentando encontrar possíveis erros nele.
estágio 3
Parece que podemos nos acalmar com isso, aguardar a eficácia comprovada e encerrar o assunto.
Mas somos levados a realizar uma nova etapa pelas seguintes oportunidades óbvias de otimização
- As estatísticas, por exemplo, и mostra que os sistemas de dois e quatro processadores têm desempenho significativamente inferior ao dos sistemas de processador único. Isso significa que todos os usuários recebem significativamente menos saída de CPU, RAM, SSD, LAN, FC adquiridos em sistemas multiprocessadores em comparação com sistemas de processador único.
- Os próprios agendadores de recursos podem ter erros graves, sobre este assunto.
- As tecnologias oferecidas pela Intel e AMD para monitoramento de RAM e cache permitem estudar o comportamento das máquinas virtuais e posicioná-las de forma que vizinhos “ruidosos” não interfiram nas máquinas virtuais “silenciosas”.
- Ampliação do conjunto de parâmetros (rede, sistema de armazenamento, prioridade da máquina virtual, custo da migração, sua prontidão para migração).
No total
O resultado do nosso trabalho para melhorar os algoritmos de balanceamento foi a conclusão clara de que usando algoritmos modernos é possível obter uma otimização significativa dos recursos do data center (25-30%) e ao mesmo tempo melhorar a qualidade do atendimento ao cliente.
Um algoritmo baseado em redes neurais é certamente uma solução interessante, mas que necessita de maior desenvolvimento, e devido às limitações existentes, não é adequado para resolver este tipo de problema nos volumes típicos de nuvens privadas. Ao mesmo tempo, o algoritmo apresentou bons resultados em nuvens públicas de tamanho significativo.
Contaremos mais sobre os recursos de processadores, escalonadores e balanceamento de alto nível nos artigos a seguir.
Fonte: habr.com