Em grandes sistemas em nuvem, a questão do balanceamento automático ou nivelamento da carga nos recursos de computação é especialmente grave. A Tionix (desenvolvedora e operadora de serviços em nuvem, parte do grupo de empresas Rostelecom) também cuidou dessa questão.
E, como nossa principal plataforma de desenvolvimento é o Openstack, e nós, como todas as pessoas, somos preguiçosos, optou-se por selecionar algum módulo pronto que já vem incluso na plataforma. A nossa escolha recaiu sobre o Watcher, que decidimos utilizar para as nossas necessidades.
Primeiro, vamos examinar os termos e definições.
Termos e definições
Meta é um resultado final legível, observável e mensurável que deve ser alcançado. Existem uma ou mais estratégias para atingir cada objetivo. Uma estratégia é a implementação de um algoritmo capaz de encontrar uma solução para um determinado objetivo.
Ação é uma tarefa elementar que altera o estado atual do recurso gerenciado de destino do cluster OpenStack, como: migrar uma máquina virtual (migração), alterar o estado de energia de um nó (change_node_power_state), alterar o estado do serviço nova (change_nova_service_state) ), alteração de sabor (redimensionamento), registro de mensagens NOP (nop), falta de ação por um determinado período de tempo - pausa (suspensão), transferência de disco (volume_migrate).
Plano de ação - um fluxo específico de ações realizadas em uma determinada ordem para atingir um objetivo específico. O Plano de Acção também contém um desempenho global medido com um conjunto de indicadores de desempenho. Um plano de ação é gerado pelo Watcher após uma auditoria bem-sucedida, a partir do qual a estratégia utilizada encontra uma solução para atingir o objetivo. Um plano de ação consiste em uma lista de ações sequenciais.
Auditoria é uma solicitação para otimizar o cluster. A otimização é realizada para atingir um objetivo em um determinado cluster. Para cada auditoria bem-sucedida, o Watcher gera um Plano de Ação.
Escopo de auditoria é um conjunto de recursos dentro dos quais a auditoria é executada (zonas de disponibilidade, agregadores de nós, nós de computação individuais ou nós de armazenamento, etc.). O escopo da auditoria é definido em cada modelo. Se um escopo de auditoria não for especificado, todo o cluster será auditado.
Modelo de auditoria — um conjunto salvo de configurações para iniciar uma auditoria. Os modelos são necessários para executar auditorias várias vezes com as mesmas configurações. O modelo deve necessariamente conter o objetivo da auditoria; se as estratégias não forem especificadas, serão selecionadas as estratégias existentes mais adequadas.
Conjunto é uma coleção de máquinas físicas que fornecem recursos de computação, armazenamento e rede e são gerenciadas pelo mesmo nó de gerenciamento OpenStack.
Modelo de dados de cluster (CDM) é uma representação lógica do estado atual e da topologia dos recursos gerenciados pelo cluster.
Indicador de Eficiência - um indicador que indica como é executada a solução criada com esta estratégia. Os indicadores de desempenho são específicos para um objectivo específico e são normalmente utilizados para calcular a eficácia global do plano de acção resultante.
Especificação de eficácia é um conjunto de características específicas associadas a cada Objectivo que define os vários indicadores de desempenho que uma estratégia para atingir o Objectivo correspondente deve alcançar na sua solução. Na verdade, cada solução proposta pela estratégia será verificada em relação às especificações antes de calcular a sua eficácia global.
Mecanismo de pontuação é um arquivo executável que possui entradas e saídas bem definidas e executa uma tarefa puramente matemática. Dessa forma, o cálculo é independente do ambiente em que é realizado – dará o mesmo resultado em qualquer lugar.
Planejador de observador - parte do mecanismo de tomada de decisão do Watcher. Este módulo pega um conjunto de ações geradas por uma estratégia e cria um plano de fluxo de trabalho que especifica como agendar essas diferentes ações no tempo e para cada ação, quais são as pré-condições.
Metas e estratégias do observador
Meta
estratégia
Gol fictício
Estratégia fictícia
Estratégia fictícia usando mecanismos de pontuação de amostra
Estratégia fictícia com redimensionamento
A poupança de energia
Estratégia de poupança de energia
Consolidação de Servidores
Consolidação básica de servidores offline
Estratégia de consolidação de carga de trabalho de VM
Balanceamento de carga de trabalho
Estratégia de migração de equilíbrio de carga de trabalho
Estratégia de equilíbrio de capacidade de armazenamento
Estabilização da carga de trabalho
vizinho barulhento
vizinho barulhento
Otimização Térmica
Estratégia baseada na temperatura de saída
Otimização do fluxo de ar
Estratégia uniforme de migração de fluxo de ar
Manutenção de hardware
Migração de zona
Não classificados
Atuador
Gol fictício — objetivo reservado que é usado para fins de teste.
Estratégias relacionadas: Estratégia Dummy, Estratégia Dummy usando mecanismos de pontuação de amostra e Estratégia Dummy com redimensionamento. Estratégia fictícia é uma estratégia fictícia usada para testes de integração por meio do Tempest. Esta estratégia não fornece nenhuma otimização útil, seu único propósito é usar testes Tempest.
Estratégia fictícia usando motores de pontuação de amostra - a estratégia é semelhante à anterior, a única diferença é a utilização de um “mecanismo de pontuação” de amostra que realiza cálculos usando métodos de aprendizado de máquina.
Estratégia Dummy com redimensionamento - a estratégia é semelhante à anterior, a única diferença é a utilização de alteração do sabor (migração e redimensionamento).
Não usado na produção.
A poupança de energia — minimizar o consumo de energia. A Estratégia de Economia de Energia dessa meta, juntamente com a Estratégia de Consolidação de Carga de Trabalho de VM (Consolidação de Servidor), é capaz de recursos de gerenciamento dinâmico de energia (DPM) que economizam energia consolidando dinamicamente cargas de trabalho mesmo durante períodos de baixa utilização de recursos: máquinas virtuais são movidas para menos nós e nós desnecessários são desabilitados. Após a consolidação, a estratégia oferece uma decisão sobre ligar/desligar nós de acordo com os parâmetros especificados: “min_free_hosts_num” - o número de nós livres habilitados que estão aguardando carga, e “free_used_percent” - a porcentagem de hosts livres habilitados para o número de nós ocupados por máquinas. Para que a estratégia funcione, deve haver habilitou e configurou o Ironic para lidar com o ciclo de energia nos nós.
Parâmetros de estratégia
parâmetro
тип
por padrão
описание
free_used_percent
Sessão
10.0
proporção entre o número de nós de computação livres e o número de nós de computação com máquinas virtuais
min_free_hosts_num
int
1
número mínimo de nós de computação livres
A nuvem deve ter pelo menos dois nós. O método utilizado é alterar o estado de energia do nó (change_node_power_state). A estratégia não requer coleta de métricas.
Consolidação de servidores - minimize o número de nós de computação (consolidação). Possui duas estratégias: Consolidação de Servidor Offline Básica e Estratégia de Consolidação de Carga de Trabalho de VM.
A estratégia Basic Offline Server Consolidation minimiza o número total de servidores usados e também minimiza o número de migrações.
A estratégia básica requer as seguintes métricas:
Métricas
serviço
plug-ins
comentário
computar.node.cpu.percent
Nenhum
cpu_util
Nenhum
Parâmetros de estratégia: migração_attempts - número de combinações para procurar potenciais candidatos para desligamento (padrão, 0, sem restrições), período - intervalo de tempo em segundos para obter agregação estática da fonte de dados métricos (padrão, 700).
Métodos utilizados: migração, alteração do estado do serviço nova (change_nova_service_state).
A Estratégia de Consolidação de Carga de Trabalho de VM é baseada em uma heurística de primeiro ajuste que se concentra na carga medida da CPU e tenta minimizar os nós que têm muita ou pouca carga, dadas as restrições de capacidade dos recursos. Essa estratégia fornece uma solução que resulta no uso mais eficiente dos recursos do cluster usando as quatro etapas a seguir:
- Fase de descarregamento - processamento de recursos sobreutilizados;
- Fase de consolidação – tratamento de recursos subutilizados;
- Otimização da solução – redução do número de migrações;
- Desativando nós de computação não utilizados.
A estratégia requer as seguintes métricas:
Métricas
serviço
plug-ins
comentário
memória
Nenhum
disco.root.size
Nenhum
As seguintes métricas são opcionais, mas melhorarão a precisão da estratégia, se disponíveis:
Métricas
serviço
plug-ins
comentário
memória.residente
Nenhum
cpu_util
Nenhum
Parâmetros de estratégia: período — intervalo de tempo em segundos para obter agregação estática da fonte de dados métrica (padrão, 3600).
Usa os mesmos métodos da estratégia anterior. Mais detalhes .
Balanceamento de carga de trabalho — equilibrar a carga de trabalho entre nós de computação. O objetivo tem três estratégias: Estratégia de Migração de Balanceamento de Carga de Trabalho, Estabilização de Carga de Trabalho, Estratégia de Balanceamento de Capacidade de Armazenamento.
A Estratégia de Migração de Balanceamento de Carga de Trabalho executa migrações de máquinas virtuais com base na carga de trabalho da máquina virtual host. Uma decisão de migração é tomada sempre que a % de utilização de CPU ou RAM de um nó excede o limite especificado. Nesse caso, a máquina virtual movida deve aproximar o nó da carga de trabalho média de todos os nós.
Requisitos
- Uso de processadores físicos;
- Pelo menos dois nós de computação física;
- Instalou e configurou o componente Ceilometer - ceilometer-agent-compute, em execução em cada nó de computação, e a API Ceilometer, além de coletar as seguintes métricas:
Métricas
serviço
plug-ins
comentário
cpu_util
Nenhum
memória.residente
Nenhum
Parâmetros de estratégia:
parâmetro
тип
por padrão
описание
métrica
Tanga
'cpu_util'
As métricas subjacentes são: 'cpu_util', 'memory.resident'.
limiar
Sessão
25.0
Limite de carga de trabalho para migração.
significativo
Sessão
300
Período de tempo cumulativo Ceilômetro.
O método utilizado é a migração.
A estabilização da carga de trabalho é uma estratégia que visa estabilizar a carga de trabalho usando migração ao vivo. A estratégia é baseada em um algoritmo de desvio padrão e determina se há congestionamento no cluster e responde a isso acionando a migração da máquina para estabilizar o cluster.
Requisitos
- Uso de processadores físicos;
- Pelo menos dois nós de computação física;
- Instalou e configurou o componente Ceilometer - ceilometer-agent-compute, em execução em cada nó de computação, e a API Ceilometer, além de coletar as seguintes métricas:
Métricas
serviço
plug-ins
comentário
cpu_util
Nenhum
memória.residente
Nenhum
Estratégia de equilíbrio de capacidade de armazenamento (estratégia implementada a partir do Queens) - a estratégia transfere discos dependendo da carga nos pools Cinder. Uma decisão de transferência é tomada sempre que a taxa de utilização do pool excede um limite especificado. O disco que está sendo movido deve aproximar o pool da carga média de todos os pools Cinder.
Requisitos e restrições
- Mínimo de duas piscinas Cinder;
- Possibilidade de migração de disco.
- Modelo de dados de cluster - Coletor de modelo de dados de cluster Cinder.
Parâmetros de estratégia:
parâmetro
тип
por padrão
описание
limite_volume
Sessão
80.0
Valor limite de discos para balanceamento de volumes.
O método utilizado é a migração de disco (volume_migrate).
Vizinho Noisy - Identifique e migre um “vizinho barulhento” - uma máquina virtual de baixa prioridade que está impactando negativamente o desempenho de uma máquina virtual de alta prioridade em termos de IPC pelo uso excessivo do cache de último nível. Estratégia própria: Noisy Neighbour (o parâmetro de estratégia usado é cache_threshold (o valor padrão é 35), quando o desempenho cai para o valor especificado, a migração é iniciada. Para que a estratégia funcione, habilitada Métricas LLC (Cache de Último Nível), mais recente servidor Intel com suporte CMT, bem como coletar as seguintes métricas:
Métricas
serviço
plug-ins
comentário
cpu_l3_cache
Nenhum
Intel necessária .
Modelo de dados de cluster (padrão): Coletor de modelo de dados de cluster Nova. O método utilizado é a migração.
Trabalhar com esse objetivo por meio do Dashboard não está totalmente implementado no Queens.
Otimização Térmica — otimizar o regime de temperatura. A temperatura de saída (ar de exaustão) é um dos sistemas de telemetria térmica importantes para medir o status térmico/da carga de trabalho de um servidor. O destino tem uma estratégia, a estratégia baseada na temperatura de saída, que decide migrar cargas de trabalho para hosts termicamente favoráveis (temperatura de saída mais baixa) quando a temperatura de saída dos hosts de origem atinge um limite configurável.
Para que a estratégia funcione, você precisa de um servidor com Intel Power Node Manager instalado e configurado , bem como coletar as seguintes métricas:
Métricas
serviço
plug-ins
comentário
hardware.ipmi.node.outlet_temperature
IPMI
Parâmetros de estratégia:
parâmetro
тип
por padrão
описание
limiar
Sessão
35.0
Limite de temperatura para migração.
significativo
Sessão
30
O intervalo de tempo, em segundos, para obter a agregação estatística da fonte de dados métrica.
O método utilizado é a migração.
Otimização do fluxo de ar — otimizar o modo de ventilação. Estratégia própria - Uniform Airflow usando migração ao vivo. A estratégia aciona a migração da máquina virtual sempre que o fluxo de ar do ventilador do servidor excede um limite especificado.
Para que a estratégia funcione você precisa:
- Hardware: nós de computação <suportando NodeManager 3.0;
- Pelo menos dois nós de computação;
- O componente ceilometer-agent-compute e Ceilometer API instalado e configurado em cada nó de computação, que pode relatar com sucesso métricas como fluxo de ar, potência do sistema, temperatura de entrada:
Métricas
serviço
plug-ins
comentário
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperatura
IPMI
hardware.ipmi.node.power
IPMI
Para que a estratégia funcione, você precisa de um servidor com Intel Power Node Manager 3.0 ou posterior instalado e configurado.
Limitações: O conceito não se destina à produção.
Propõe-se a utilização deste algoritmo com auditorias contínuas, uma vez que apenas uma máquina virtual está planejada para ser migrada por iteração.
Migrações ao vivo são possíveis.
Parâmetros de estratégia:
parâmetro
тип
por padrão
описание
limite_fluxo de ar
Sessão
400.0
O limite de fluxo de ar para unidade de migração é 0.1CFM
limite_inlet_t
Sessão
28.0
Limite de temperatura de entrada para decisão de migração
limite_potência
Sessão
350.0
Limite de energia do sistema para decisão de migração
significativo
Sessão
30
O intervalo de tempo, em segundos, para obter a agregação estatística da fonte de dados métrica.
O método utilizado é a migração.
Manutenção de hardware - manutenção de hardware. A estratégia relacionada a este objetivo é a migração de Zona. A estratégia é uma ferramenta para migração efetiva, automática e mínima de máquinas virtuais e discos em caso de necessidade de manutenção de hardware. A estratégia constrói um plano de ação de acordo com os pesos: um conjunto de ações que tiver mais peso será planejado antes dos demais. Existem duas opções de configuração: action_weights e paralelização.
Limitações: pesos de ação e paralelização precisam ser configurados.
Parâmetros de estratégia:
parâmetro
тип
por padrão
описание
nós de computação
ordem
nenhum
Nós de computação para migração.
pools de armazenamento
ordem
nenhum
Nós de armazenamento para migração.
paralelo_total
número inteiro
6
O número total de atividades que devem ser executadas em paralelo.
paralelo_por_nó
número inteiro
2
O número de ações executadas em paralelo para cada nó de computação.
paralelo_per_pool
número inteiro
2
O número de ações executadas em paralelo para cada pool de armazenamento.
prioridade
objeto
nenhum
Lista de prioridades para máquinas virtuais e discos.
com_volume_anexado
booleano
Falso
Falso — as máquinas virtuais serão migradas depois que todos os discos forem migrados. Verdadeiro: as máquinas virtuais serão migradas depois que todos os discos conectados forem migrados.
Elementos da matriz de nós de computação:
parâmetro
тип
por padrão
описание
nó_src
corda
nenhum
O nó de cálculo do qual as máquinas virtuais estão sendo migradas (obrigatório).
dst_node
corda
nenhum
Calcule o nó para o qual as máquinas virtuais estão migrando.
Elementos da matriz do nó de armazenamento:
parâmetro
тип
por padrão
описание
pool_src
corda
nenhum
O pool de armazenamento do qual os discos estão sendo migrados (obrigatório).
dst_pool
corda
nenhum
O pool de armazenamento para o qual os discos são migrados.
tipo_src
corda
nenhum
Tipo de disco original (obrigatório).
tipo_dst
corda
nenhum
O tipo de disco resultante (obrigatório).
Elementos de prioridade do objeto:
parâmetro
тип
por padrão
описание
projeto
ordem
nenhum
Nomes de projetos.
nó_de_computação
ordem
nenhum
Calcule nomes de nós.
pool_de_armazenamento
ordem
nenhum
Nomes de conjuntos de armazenamento.
computar
enumerar
nenhum
Parâmetros da máquina virtual [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
armazenamento
enumerar
nenhum
Parâmetros do disco [“tamanho”, “criado_em”].
Os métodos utilizados são migração de máquina virtual, migração de disco.
Não classificados - uma meta auxiliar utilizada para facilitar o processo de desenvolvimento da estratégia. Não contém especificações e pode ser utilizado sempre que a estratégia ainda não esteja associada a um objetivo existente. Este objetivo também pode ser usado como ponto de transição. Uma estratégia relacionada a esse objetivo é o Atuador.
Criando uma nova meta
Mecanismo de decisão do observador possui uma interface de plugin de “objetivo externo” que permite integrar um objetivo externo que pode ser alcançado por meio de uma estratégia.
Antes de criar uma nova meta, certifique-se de que nenhuma meta existente atenda às suas necessidades.
Criando um novo plugin
Para criar um novo alvo, você deve: estender a classe alvo, implementar um método de classe get_name() para retornar o ID exclusivo do novo destino que você deseja criar. Esse identificador exclusivo deve corresponder ao nome do ponto de entrada que você declarar posteriormente.
Em seguida, você precisa implementar o método de classe get_nome_display() para retornar o nome de exibição traduzido do destino que você deseja criar (não use uma variável para retornar a string traduzida para que ela possa ser coletada automaticamente pela ferramenta de tradução).
Implementar um método de classe get_translatable_display_name()para retornar a chave de tradução (na verdade, o nome de exibição em inglês) do seu novo alvo. O valor de retorno deve corresponder à string traduzida em get_display_name().
Implemente seu método get_eficácia_especificação()para retornar a especificação de eficiência para seu alvo. O método get_efficacy_specification() retorna a instância Unclassified() fornecida pelo Watcher. Esta especificação de desempenho é útil no processo de desenvolvimento do seu objetivo porque corresponde à especificação vazia.
→
Arquitetura do observador (mais detalhes) ).
Componentes
API do observador - um componente que implementa a API REST fornecida pelo Watcher. Mecanismos de interação: CLI, plugin Horizon, Python SDK.
Banco de dados do observador — Banco de dados do observador.
Aplicador Observador — um componente que implementa a execução de um plano de ação criado pelo componente Watcher Decision Engine.
Mecanismo de decisão do observador - O componente responsável por calcular um conjunto de possíveis ações de otimização para atingir o objetivo da auditoria. Se uma estratégia não for especificada, o componente seleciona independentemente a mais apropriada.
Editor de métricas do observador - Um componente que coleta e calcula algumas métricas ou eventos e os publica no endpoint CEP. A funcionalidade do componente também pode ser fornecida pelo editor Ceilometer.
Mecanismo de processamento de eventos complexos (CEP) — mecanismo para processamento de eventos complexos. Por motivos de desempenho, pode haver diversas instâncias do CEP Engine em execução simultaneamente, cada uma processando um tipo específico de métrica/evento. No sistema Watcher, o CEP desencadeia dois tipos de ações: - registrar os eventos/métricas correspondentes no banco de dados de séries temporais; - enviar eventos apropriados ao Watcher Decision Engine quando este evento puder afetar o resultado da estratégia de otimização atual, uma vez que o cluster Openstack não é um sistema estático.
Os componentes interagem usando o protocolo AMQP.
→
Esquema de interação com Watcher
Resultados do teste do observador
- Na página Otimização - Planos de ação 500 (tanto no Queens puro quanto no estande com módulos Tionix), ele aparece somente após o lançamento da auditoria e a geração de um plano de ação; o vazio abre normalmente.
- Existem erros na aba Detalhes da ação, não é possível obter o objetivo e a estratégia da auditoria (tanto no Queens puro quanto no estande com módulos Tionix).
- Auditorias com finalidade de Dummy (teste) são criadas e lançadas normalmente, são gerados planos de ação.
- As auditorias para a meta Não classificado não são criadas porque a meta não é funcional e se destina à configuração intermediária ao criar novas estratégias.
- As auditorias para fins de balanceamento de carga de trabalho (estratégia de equilíbrio de capacidade de armazenamento) são criadas com êxito, mas um plano de ação não é gerado. Não é necessária otimização do pool de armazenamento.
- As auditorias para a meta de balanceamento de carga de trabalho (estratégia de migração de balanceamento de carga de trabalho) são criadas com êxito, mas um plano de ação não é gerado.
- As auditorias para balanceamento de carga de trabalho (estratégia de estabilização de carga de trabalho) falham.
- As auditorias para o alvo Noisy Neighbor são criadas com êxito, mas um plano de ação não é gerado.
- As auditorias para efeito de manutenção de Hardware são criadas com sucesso, o plano de ação não é gerado na íntegra (são gerados indicadores de desempenho, mas a lista de ações em si não é gerada).
- As edições nas configurações do nova.conf (na seção padrão compute_monitors = cpu.virt_driver) nos nós de cálculo e controle não corrigem os erros.
- As auditorias direcionadas à consolidação de servidores (estratégia básica) também falham.
- As auditorias para fins de consolidação de servidores (estratégia de consolidação de carga de trabalho de VM) falham com um erro. Nos logs há um erro na obtenção dos dados de origem. Discussão do erro, em particular .
Tentamos especificar o Watcher no arquivo de configuração (não ajudou - como resultado de um erro em todas as páginas de Otimização, retornar ao conteúdo original do arquivo de configuração não corrige a situação): [watcher_strategies.basic] fonte de dados = ceilômetro, nhoque - As auditorias para poupança de energia falham. A julgar pelos logs, o problema ainda é a ausência do Ironic; ele não funcionará sem o serviço baremetal.
- As auditorias para otimização térmica falham. O rastreamento é o mesmo da consolidação de servidores (estratégia de consolidação de carga de trabalho de VM) (erro de dados de origem)
- As auditorias para fins de otimização do fluxo de ar falham com um erro.
Os seguintes erros de conclusão de auditoria também são encontrados. Traceback nos logs do Decision-engine.log (o estado do cluster não está definido).
→ Discussão do erro
Conclusão
O resultado de nossa pesquisa de dois meses foi a conclusão inequívoca de que, para obter um sistema de balanceamento de carga completo e funcional, teremos, nesta parte, que trabalhar em estreita colaboração no refinamento das ferramentas para a plataforma Openstack.
O Watcher provou ser um produto sério e de rápido desenvolvimento, com enorme potencial, cuja plena utilização exigirá muito trabalho sério.
Mas falaremos mais sobre isso nos próximos artigos da série.
Fonte: habr.com