hbal - Online na nuvem

PROGRAMA:

NOME

hbal - balanceador de cluster para Ganeti

SINOPSE

hbal {opções de backend ...} [opções de algoritmo ...] [opções de relatórios ...]

hbal --versão

Opções de back-end:

{ -m cacho | -EU[ caminho ] [-X] | -t arquivo de dados | -I caminho }

Opções de algoritmo:

[ --max-cpu proporção de CPU ] [ --min-disco proporção de disco ] [ -l limitar ] [ -e Ponto ] [ -g delta ] [
--min-ganho-limite limiar ] [ -O nome... ] [ --no-disk-move ] [ --no-instance-moves ] [
-U arquivo util ] [ --ignore-dynu ] [ --ignore-soft-erros ] [ --mond sim | não ] [ --mond-xen ]
[ --exit-on-missing-mond-data ] [ --modo de evacuação ] [ - migração restrita ] [
--select-instâncias inst ... ] [ --exclude-instâncias inst ... ]

Opções de relatório:

[ -C [ lima ] ] [ -p [ Campos ] ] [ --print-instâncias ] [ -S lima ] [ -v ... | -q ]

DESCRIÇÃO

hbal é um balanceador de cluster que olha para o estado atual do cluster (nós com
seu disco total e livre, memória, etc.) e colocação de instância e calcula uma série de
etapas destinadas a melhorar o estado do cluster.

O algoritmo usado é projetado para ser estável (ou seja, ele lhe dará os mesmos resultados quando
reiniciá-lo no meio da solução) e razoavelmente rápido. Não é, no entanto,
projetado para ser um algoritmo perfeito: é possível fazê-lo ir para um canto a partir do qual
não pode encontrar nenhuma melhoria, porque olha apenas um "passo" à frente.

O programa acessa o estado do cluster via Rapi ou Luxi. Ele também solicita dados sobre o
rede de todos os MonDs com a opção --mond. Atualmente, ele usa apenas dados produzidos por
Coletor de CPUload.

Por padrão, o programa mostrará a solução de forma incremental conforme ela é calculada, em um
formato um tanto enigmático; para obter a lista de comandos Ganeti real, use o -C opção.

ALGORITMO
O programa funciona em etapas independentes; em cada etapa, calculamos o melhor movimento de instância
que reduz a pontuação do cluster.

O tipo de movimentação possível para uma instância são combinações de failover / migração e
substituir os discos, de modo que mudamos um dos nós da instância e o outro permanece
(mas possivelmente com a função alterada, por exemplo, do primário se torna secundário). A lista é:

· Failover (f)

· Substituir secundário (r)

· Substituir o primário, um movimento composto (f, r, f)

· Failover e substituição secundária, também composta (f, r)

· Substituir secundário e failover, também composto (r, f)

Não fazemos a única possibilidade restante de substituir ambos os nós (r, f, r, f ou o
equivalente f, r, f, r) uma vez que esses movimentos precisam de uma pesquisa exaustiva sobre ambos os candidatos
nós primários e secundários, e é O (n * n) no número de nós. Além disso,
não parece dar melhores pontuações, mas resultará em mais substituições de disco.

INVESTIMENTO RESTRIÇÕES
Em cada etapa, evitamos a movimentação de uma instância se isso causasse:

· Um nó para entrar em estado de falha N + 1

· Uma instância para mover para um nó offline (nós offline são lidos do cluster
ou declarado com -O; nós drenados são considerados offline)

· Um conflito baseado em tag de exclusão (as tags de exclusão são lidas do cluster e / ou definidas
via --tags de exclusão opção)

· Uma proporção máxima de vcpu / pcpu a ser excedida (configurada via --max-cpu)

· Porcentagem mínima de disco livre para ir abaixo do limite configurado (configurado via --min-disco)

CLUSTER PONTUAÇÃO
Como dito antes, o algoritmo tenta minimizar a pontuação do cluster em cada etapa. Atualmente
esta pontuação é calculada como uma soma ponderada dos seguintes componentes:

· Desvio padrão da porcentagem de memória livre

· Desvio padrão da porcentagem de memória reservada

· A soma das porcentagens de memória reservada

· Desvio padrão da porcentagem de disco livre

· Contagem de nós com falha na verificação N + 1

· Contagem de instâncias que vivem (como primárias ou secundárias) em nós offline; no
sentido de hbal (e outros htools) nós drenados são considerados offline

· Contagem de instâncias que vivem (como primárias) em nós offline; isso difere do anterior
métrica, ajudando a failover de tais instâncias em clusters de 2 nós

· Desvio padrão da proporção de cpus virtual para físico (para instâncias primárias de
o nó)

· Desvio padrão da fração dos fusos disponíveis (no modo dedicado,
fusos representam fusos físicos; caso contrário, esta medida de superinscrição para IO
carga, e o fator de excesso de inscrições é levado em consideração ao calcular o número de
fusos disponíveis)

· Desvio padrão da carga dinâmica nos nós, para cpus, memória, disco e rede

· Desvio padrão da carga da CPU fornecida pela MonD

· A contagem de instâncias com primário e secundário no mesmo domínio de falha

Os valores de memória livre e disco livre ajudam a garantir que todos os nós sejam um tanto equilibrados em
seu uso de recursos. A memória reservada ajuda a garantir que os nós sejam de alguma forma
equilibrado na retenção de instâncias secundárias, e nenhum nó mantém muita memória reservada
para N + 1. E, finalmente, a porcentagem N + 1 ajuda a orientar o algoritmo no sentido de eliminar
Falhas N + 1, se possível.

Exceto para as falhas N + 1, contagens de instâncias offline e violação de domínio de falha
contagens, usamos o desvio padrão, pois quando usados ​​com valores dentro de um intervalo fixo (nós
use porcentagens expressas como valores entre zero e um) dá resultados consistentes em
todas as métricas (há alguns pequenos problemas relacionados aos diferentes meios, mas funciona
geralmente bem). Os valores do tipo 'contagem' terão pontuação mais alta e, portanto, serão mais importantes
para balanceamento; portanto, estes são melhores para restrições rígidas (como evacuação de nós e
corrigindo N + 1 falhas). Por exemplo, a contagem de instâncias offline (ou seja, o número de
instâncias que vivem em nós offline) fará com que o algoritmo mova ativamente as instâncias
longe de nós offline. Isso, juntamente com a restrição de colocação dada por offline
nós, irá causar a evacuação de tais nós.

Os valores de carga dinâmica precisam ser lidos de um arquivo externo (a Ganeti não fornece
eles), e são calculados para cada nó como: soma da carga da CPU da instância primária, soma da carga da CPU primária
carga de memória da instância, soma da carga do disco da instância primária e secundária (conforme o DRBD gera
escrever carga em nós secundários também no caso normal e em cenários degradados também ler
carga) e a soma da carga da rede da instância primária. Um exemplo de como gerar estes
os valores de entrada para hbal seriam rastrear a lista xm para instâncias ao longo de um dia e por
computar o delta dos valores de cpu e alimentar isso por meio do -U opção para todas as instâncias
(e manter as outras métricas como uma). Para que o algoritmo funcione, tudo o que é necessário é
que os valores são consistentes para uma métrica em todas as instâncias (por exemplo, todas as instâncias usam
cpu% para relatar o uso da CPU, e não algo relacionado ao número de segundos de CPU usados ​​se o
CPUs são diferentes), e que são normalizados entre zero e um. Observe que é
recomendado não ter zero como o valor de carga para qualquer métrica de instância desde então
as instâncias secundárias não são bem balanceadas.

A carga da CPU do coletor de dados do MonD será usada apenas se todos os MonDs estiverem em execução,
caso contrário, não afetará a pontuação do cluster. Uma vez que não podemos encontrar a carga da CPU de cada
instância, podemos supor que a carga da CPU de uma instância é proporcional ao número de
seu vcpus. Com esta heurística, instâncias de nós com alta carga de CPU tendem a se mover
para nós com menos carga de CPU.

Em um cluster perfeitamente equilibrado (todos os nós do mesmo tamanho, todas as instâncias do mesmo tamanho e
espalhados pelos nós igualmente), os valores para todas as métricas seriam zero, com o
exceção da porcentagem total de memória reservada. Isso não acontece com muita frequência em
prática :)

OFFLINE INSTÂNCIAS
Uma vez que as versões atuais do Ganeti não relatam a memória usada por instâncias offline (inativas),
ignorar o status de execução das instâncias causará cálculos errados. Por esse motivo, o
algoritmo subtrai o tamanho da memória de instâncias inativas da memória do nó livre de seus
nó primário, com efeito, simulando a inicialização de tais instâncias.

EXCLUSÃO TAGS
O mecanismo de tags de exclusão é projetado para evitar instâncias que executam a mesma carga de trabalho
(por exemplo, dois servidores DNS) para pousar no mesmo nó, o que tornaria o respectivo nó um
SPOF para o serviço prestado.

Ele funciona marcando instâncias com certas marcas e, em seguida, construindo mapas de exclusão com base em
esses. As marcas que são realmente usadas são configuradas através da linha de comando (opção
--tags de exclusão) ou adicionando-os às tags do cluster:

--exclusion-tags = a, b
Isso fará com que todas as tags de instância do formulário uma:*, b: * ser considerado para o
mapa de exclusão

cacho Tag htools: iextags: a, htools: iextags: b
Isso tornará as tags de instância uma:*, b: * ser considerado para o mapa de exclusão. Mais
precisamente, o sufixo das tags de cluster começando com htools: iextags: vai se tornar o
prefixo das tags de exclusão.

Ambas as formas acima significam que duas instâncias, ambas tendo (por exemplo) a tag a: foo or b: bar
não terminará no mesmo nó.

MIGRAÇÃO TAGS
Se o Ganeti for implantado em um cluster heterogêneo, a migração pode não ser possível entre
todos os nós de um grupo de nós. Um exemplo de tal situação é a atualização do hipervisor
nó por nó. Para tornar o hbal ciente dessas restrições, as seguintes tags de cluster são
usava.

cacho Tag htools: migração: a, htools: migração: b, etc.
Isso faz com que as tags de nó do formulário uma:*, b: *, etc, ser considerada migração
restrição. Mais precisamente, o sufixo das tags de cluster começando com
htools: migração: se tornará o prefixo das tags de migração. Só aqueles
migrações serão levadas em consideração onde todas as tags de migração da fonte
nós também estão presentes no nó de destino.

cacho Tag htools: allowmigration: x :: y para migração Tag x e y
Isso afirma que um nó testado y é capaz de receber instâncias da mesma forma como se
eles tinham um x tag.

Portanto, no caso simples de uma atualização do hipervisor, marcar todos os nós que foram
atualizado com uma tag de migração é suficiente. Em situações mais complicadas, é sempre
possível usar uma tag de migração diferente para cada hipervisor usado e declarar explicitamente o
direções de migração permitidas por meio de htools: allowmigration: Tag.

LOCALIZAÇÃO TAGS
Dentro de um grupo de nós, certos nós podem ter maior probabilidade de falhar simultaneamente devido a um
causa comum de erro (por exemplo, se eles compartilham a mesma fonte de alimentação). Ganeti pode ser
alertado para essas causas comuns de falha por meio de tags.

cacho Tag htools: nlocation: a, htools: nlocation: b, etc.
Isso faz com que as tags de nó do formulário uma:*, b: *, etc deve ser considerado como tendo um comum
causa da falha.

Instâncias com nó primário e secundário com uma causa comum de falha são consideradas
mal colocado. Embora esses canais sejam sempre permitidos, eles contam muito para o
pontuação do cluster.

OPÇÕES

As opções que podem ser passadas ao programa são as seguintes:

-C, --print-comandos
Imprima a lista de comandos no final da execução. Sem isso, o programa irá apenas
mostram uma saída mais curta, mas enigmática.

Observe que a lista de movimentos será dividida em etapas independentes, chamadas "jobsets",
mas apenas para inspeção visual, não para paralelização de fato. Não é
possível paralelizá-los diretamente quando executado por meio de comandos "gnt-instance",
uma vez que um comando composto (por exemplo, failover e substituir discos) deve ser executado
em série. A execução paralela só é possível ao usar o backend Luxi e o
-L opção.

O algoritmo para dividir os movimentos em conjuntos de tarefas é acumulando movimentos até
o próximo movimento é tocar nós já tocados pelos movimentos atuais; isso significa que nós
não pode ser executado em paralelo (devido à alocação de recursos no Ganeti) e, portanto, começamos
um novo jobset.

-p, --print-nodes
Imprime o status do nó antes e depois, em um formato projetado para permitir que o usuário
entender os parâmetros mais importantes do nó. Veja a página de manual ferramentas(1) para
mais detalhes sobre esta opção.

--print-instâncias
Imprime o mapa da instância antes e depois. Isso é menos útil como o status do nó,
mas pode ajudar na compreensão de movimentos de instância.

-O nome
Esta opção (que pode ser fornecida várias vezes) marcará os nós como sendo modo offline.
Isso significa algumas coisas:

· As instâncias não serão colocadas nesses nós, nem mesmo temporariamente; por exemplo, o substituir
primário mover não está disponível se o nó secundário estiver offline, uma vez que este movimento
requer um failover.

· Esses nós não serão incluídos no cálculo da pontuação (exceto para o
porcentagem de instâncias em nós offline)

Observe que o algoritmo também marcará como offline quaisquer nós relatados por RAPI
como tal, ou que tenham "?" na entrada baseada em arquivo em quaisquer campos numéricos.

-e Ponto, --min-score = * score *
Este parâmetro denota quanto acima do limite N + 1 a pontuação do cluster pode para nós
ficar satisfeito e alterar o cálculo de duas maneiras:

· Se o cluster tem a pontuação inicial inferior a este valor, então não entramos
o algoritmo e sai com sucesso

· Durante o processo iterativo, se atingirmos uma pontuação inferior a este valor, saímos
o algoritmo

O valor padrão do parâmetro é atualmente 1e-9 (escolhido empiricamente).

-g delta, --min-gain = * delta *
Uma vez que o algoritmo de balanceamento às vezes pode resultar em apenas pequenas melhorias,
que trazem menos ganho do que custam em tempo de realocação, este parâmetro (padrão
a 0.01) representa o ganho mínimo que exigimos durante uma etapa, para continuar
balanceamento.

--min-gain-limit = * limiar *
A opção de ganho mínimo acima só terá efeito se a pontuação do cluster já estiver
abaixo limiar (o padrão é 0.1). A lógica por trás dessa configuração é que em
altas pontuações de cluster (clusters mal balanceados), não queremos abortar o rebalanceamento
muito rapidamente, pois os ganhos posteriores ainda podem ser significativos. No entanto, sob o
limite, o ganho total é apenas o valor do limite, portanto, podemos sair mais cedo.

--no-disk-move
Este parâmetro evita que o hbal use a movimentação do disco (ou seja, "gnt-instance
substituir discos "). Isso resultará em um balanceamento muito mais rápido, mas de
claro que as melhorias são limitadas. Cabe ao usuário decidir quando usar
um ou outro.

--no-instance-moves
Este parâmetro evita que o hbal use movimentos de instância (ou seja, "gnt-instance
operações de migração / failover "). Isso só usará a substituição lenta de disco
operações, e também fornecerá um equilíbrio pior, mas pode ser útil ao mover
instâncias ao redor é considerada insegura ou não preferida.

--modo de evacuação
Este parâmetro restringe a lista de instâncias consideradas para mover para aquelas
vivendo em nós offline / drenados. Ele pode ser usado como um substituto (em massa) para
Do próprio ganeti nó gnt evacuar, com a observação de que não garante total
evacuação.

- migração restrita
Este parâmetro não permite quaisquer movimentos de substituição primária (frf), bem como aqueles
movimentos de substituição e failover (rf) onde o nó primário da instância não é
drenado. Se usado junto com a opção --evac-mode, as únicas migrações que
hbal fará são migrações de instâncias de um nó drenado. Isso pode ser útil se
durante a reinstalação do sistema operacional de base, a migração só é possível a partir do
antigo sistema operacional para o novo sistema operacional. Observe, no entanto, que geralmente o uso de tags de migração é o
melhor escolha.

--select-instances = * instances *
Este parâmetro marca as instâncias fornecidas (como uma lista separada por vírgulas) como as únicas
aqueles sendo movidos durante o reequilíbrio.

--exclude-instances = * instances *
Este parâmetro marca as instâncias fornecidas (como uma lista separada por vírgulas) de serem
movido durante o rebalanceamento.

-U arquivo util
Este parâmetro especifica um arquivo que contém informações de utilização dinâmica da instância
que será usado para ajustar o algoritmo de balanceamento para equalizar a carga nos nós
(em oposição ao uso de recursos estáticos). O arquivo está no formato "instance_name
cpu_util mem_util disk_util net_util "onde os parâmetros" _util "são interpretados
como números e o nome da instância deve corresponder exatamente à instância lida de
Ganeti. No caso de nomes de instância desconhecidos, o programa será abortado.

Se não for fornecido, os valores padrão são um para todas as métricas e, portanto, dinâmicos
a utilização tem apenas um efeito no algoritmo: a equalização do secundário
instâncias entre nós (esta é a única métrica que não é rastreada por outra,
valor dedicado e, portanto, a carga do disco de instâncias fará com que a instância secundária
equalização). Observe que o valor de um também influenciará ligeiramente o principal
contagem de instâncias, mas isso já é rastreado por meio de outras métricas e, portanto, o
a influência da utilização dinâmica será praticamente insignificante.

--ignore-dynu
Se fornecido, todas as informações de utilização dinâmica serão ignoradas, assumindo que seja
0. Esta opção terá precedência sobre quaisquer dados passados ​​pela opção -U ou por
os MonDs com as opções --mond e --mond-data.

--ignore-soft-erros
Se fornecido, todas as verificações de erros de software serão omitidas ao considerar o balanceamento
movimentos. Desta forma, o progresso pode ser feito em um cluster onde todos os nós estão em um
mau estado em termos de política, como ultrapassar as taxas de excesso de inscrições na CPU ou eixos.

-S nome do arquivo, --save-cluster = * nome do arquivo *
Se fornecido, o estado do cluster antes do balanceamento é salvo no arquivo fornecido
mais a extensão "original" (ou seja, nome do arquivo.original) e o estado no final
do balanceamento é salvo no arquivo fornecido mais a extensão "balanceado" (ou seja,
nome do arquivo.equilibrado). Isso permite realimentar o estado do cluster para o próprio hbal
ou por exemplo hspace através da opção -t.

-t arquivo de dados, --text-data = * arquivo de dados *
Especificação de back-end: o nome do nó que contém o arquivo e as informações da instância
(se não for coletar via RAPI ou LUXI). Este ou um dos outros back-ends deve ser
selecionado. A opção está descrita na página de manual ferramentas(1).

--mond = * sim | não *
Se fornecido, o programa consultará todos os MonDs para buscar dados dos dados suportados
coletores pela rede.

--mond-xen
Se fornecido, também consulta os coletores específicos de Xen do MonD, desde que o monitoramento
daemons são consultados em tudo.

--exit-on-missing-mond-data
Se fornecido, aborta se os dados obtidos na consulta de MonDs estiverem incompletos. O
o comportamento padrão é continuar com uma melhor estimativa com base nas informações estáticas.

--mond-dados arquivo de dados
O nome do arquivo que contém os dados fornecidos por MonD, para substituir a consulta de MonDs
pela rede. Isso é usado principalmente para depuração. O arquivo deve estar em JSON
formatar e apresentar uma matriz de objetos JSON, um para cada nó, com dois membros.
O primeiro membro denominado nó é o nome do nó e o segundo membro denominado
reports é uma matriz de objetos de relatório. Os objetos do relatório devem estar no mesmo
formato conforme produzido pelo agente de monitoramento.

-m cacho
Especificação de back-end: colete dados diretamente do cacho dado como um argumento
via RAPI. A opção está descrita na página de manual ferramentas(1).

-L [caminho]
Especificação de back-end: colete dados diretamente do daemon mestre, que deve ser
contatado via LUXI (um protocolo Ganeti interno). A opção é descrita no
página do homem ferramentas(1).

-X Ao usar o backend Luxi, o hbal também pode executar os comandos fornecidos. O
método de execução é executar os conjuntos de tarefas individuais (consulte o -C opção para
detalhes) em estágios separados, abortando se a qualquer momento um conjunto de tarefas não tiver todas as tarefas
bem sucedido. Cada etapa da solução de balanceamento será traduzida exatamente
um trabalho Ganeti (tendo entre um e três OpCodes), e todas as etapas em um
jobset será executado em paralelo. Os próprios jobsets são executados em série.

A execução da série de trabalhos pode ser interrompida, veja abaixo para tratamento de sinais.

-l N, --max-length = * N *
Restrinja a solução a este comprimento. Isso pode ser usado, por exemplo, para automatizar o
execução do balanceamento.

--max-cpu = * cpu-ratio *
A proporção máxima de CPU virtual para física, como um número de ponto flutuante maior que
ou igual a um. Por exemplo, especificando proporção de CPU as 2.5 significa que, para um 4-cpu
máquina, um máximo de 10 cpus virtuais devem estar em uso para o primário
instâncias. Um valor de exatamente um significa que não haverá excesso de assinatura de CPU
(exceto para o tempo de CPU usado pelo próprio nó), e valores abaixo de um não fazem
sentido, pois isso significa que outros recursos (por exemplo, disco) não serão totalmente utilizados devido a
Restrições de CPU.

--min-disk = * proporção do disco *
A quantidade mínima de espaço livre em disco restante, como um número de ponto flutuante. Para
exemplo, especificando proporção de disco as 0.25 significa que pelo menos um quarto do disco
o espaço deve ser deixado livre nos nós.

-G uuid, --group = * uuid *
Em um cluster de vários grupos, selecione este grupo para processamento. Caso contrário, o hbal irá
abortar, pois não pode balancear vários grupos ao mesmo tempo.

-dentro, --verbose
Aumente o detalhamento da saída. Cada uso desta opção aumentará o
verbosidade (atualmente mais de 2 não faz sentido) do padrão de um.

-q, --quieto
Diminua o detalhamento da saída. Cada uso desta opção diminuirá o
verbosidade (menos que zero não faz sentido) do padrão de um.

-V, --versão
Basta mostrar a versão do programa e sair.

SINAL MANIPULAÇÃO

Ao executar tarefas via LUXI (usando a opção -X), normalmente hbal executará todas as tarefas
até que um erro seja eliminado ou todos os trabalhos sejam concluídos com êxito.

Como o balanceamento pode levar muito tempo, é possível interromper o hbal precocemente de duas maneiras:

· Enviando um SIGINT (^ C), o hbal registrará a solicitação de rescisão e aguardará
até que os trabalhos enviados atualmente terminem, ponto em que ele sairá (com o código de saída 0
se todos os trabalhos foram concluídos corretamente, caso contrário, com o código de saída 1, como de costume)

· Enviando um SIGTERM, o hbal sairá imediatamente (com o código de saída 2); é o
responsabilidade do usuário acompanhar a Ganeti e verificar o resultado do
trabalhos atualmente em execução

Observe que, em qualquer situação, é perfeitamente seguro matar hbal, seja por meio dos sinais acima
ou através de qualquer outro sinal (por exemplo, SIGQUIT, SIGKILL), uma vez que os próprios trabalhos são processados
por Ganeti enquanto hbal (após a submissão) apenas observa sua progressão. Nesse caso,
o usuário terá que consultar o Ganeti para obter os resultados do trabalho.

SAIR STATUS

O status de saída do comando será zero, a menos que por algum motivo o algoritmo falhou
(por exemplo, dados de nó ou instância errados), opções de linha de comando inválidas ou (no caso de trabalho
execução) um dos trabalhos falhou.

Uma vez que a execução do trabalho via Luxi foi iniciada (-X), se o balanceamento foi interrompido antecipadamente (via
SIGINT, ou via --max-length), mas todos os trabalhos foram executados com sucesso, então o status de saída é
zero; um código de saída diferente de zero significa que o estado do cluster deve ser investigado, uma vez que um
trabalho falhou ou não foi possível calcular seu status e isso também pode apontar para um problema no
Lado de Ganeti.

Use hbal online usando serviços onworks.net