Adicionando nós a uma configuração de alta disponibilidade

Adicione nós ao datacenter primário de alta disponibilidade (HA). Isso visa descarregar tarefas que exigem muito da CPU do nó primário, permitindo o escalonamento horizontal da instância do GitHub Enterprise Server.

Neste artigo

Observação

A capacidade de adicionar nós de processamento adicionais à HA encontra-se em versão prévia pública e está sujeita a alterações. Durante a prévia, compartilhe suas opiniões com sua equipe de atendimento ao cliente.

Para clientes do GitHub Enterprise Server que desejam escalar horizontalmente, migrar e operar um cluster é uma opção, mas consome muitos recursos e tempo. Como alternativa, recomendamos adicionar nós a uma configuração de HA.

Os termos "nó adicional" e "nó sem estado" são usados de forma intercambiável ao longo deste artigo. Nodos sem estado só podem ser adicionados a implantações de alta disponibilidade (HA) que contêm pelo menos uma réplica.

Nós adicionais

De todos os serviços em execução em um appliance do GitHub Enterprise Server, o Unicorn geralmente é o que mais consome CPU e memória, seguido de perto por Aqueduct, Git e MySQL. Como o Unicorn e o Aqueduct são serviços sem estado, eles são adequados para escalonamento horizontal e podem ser executados em um conjunto separado de nós. Os serviços restantes podem continuar operando com uma única instância por datacenter.

Nós adicionais permitem escalar horizontalmente as workloads da web e de tarefas. Eles também podem descarregar o Unicorn e o Aqueduct do nó primário, liberando recursos substanciais de computação e memória para os serviços com estado restantes. Se você estiver enfrentando interrupções relacionadas ao desempenho devido ao alto uso da CPU por instâncias do Unicorn, é recomendável adicionar nós adicionais. Não há restrições significativas sobre o número desses nós que você pode adicionar em um datacenter.

Critérios

Se você estiver enfrentando um desempenho degradado devido a um nó primário sobrecarregado em uma configuração de HA, considere adicionar nós adicionais ao seu ambiente de HA. Ao dimensionar as funções web e de trabalho horizontalmente além do nó primário, esses nós extras podem ajudar a reduzir a carga no host primário.

Por exemplo, se você observar pendências em filas de Unicórnio ou Aqueduto ou estiver enfrentando outros tipos de contenção de recursos, considere essa abordagem. Mesmo que não haja filas visíveis, a falta de CPU no nó primário é outro sinal claro. Nesses casos, você pode adicionar nós adicionais e reduzir o número de trabalhadores por nó, para que o nó primário lide com uma parcela menor da workload geral.

Adicionando um nó

Cada nó adicionado a uma implantação de alta disponibilidade é uma máquina virtual (VM) executando o software GitHub Enterprise Server. Ele deve estar executando o mesmo software que o primário. Geralmente, um nó sem estado não precisa corresponder às especificações de memória, CPU ou armazenamento do nó primário. No entanto, tanto o nó sem estado quanto a instância primária exigem conectividade em menos de um milissegundo. Os requisitos de conectividade de réplica permanecem inalterados.

Para adicionar nós ao datacenter primário em uma configuração de HA, use o ghe-add-node comando. O ghe-add-node comando configura o dispositivo atual como um nó dentro da implantação de HA e destina-se a descarregar tarefas com uso intensivo de CPU do nó de dados primário, permitindo o dimensionamento horizontal. Esses nós são projetados para lidar com workloads web e de tarefas, permitindo uma distribuição e gerenciamento de workload mais eficientes. Esse comando assume a forma:

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

  •         `PRIMARY_IP`: o endereço IP do nó primário.

  •         `HOSTNAME` (opcional): nome do host desejado para o host adicionado.

Por exemplo, para adicionar um nó com o hostname ghes-node-1 à instância primária de HA com o endereço IP 192.168.1.1 no datacenter primário de HA, você executaria o seguinte comando:

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

Em seguida, no nó primário, você deve executar os seguintes comandos:

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

O ghe-config-apply comando é um requisito para adicionar nós sem estado.

Para a visualização pública, não testamos especificamente o tempo de inatividade e não está claro se uma janela de manutenção é necessária.

Removendo um nó adicional

Para remover um nó, execute ghe-remove-node no nó que deseja remover. Em seguida, no nó primário, você deve executar:

Shell
ghe-config-apply

O comando ghe-config-apply é um requisito para remover nós desnecessários.

Para a visualização pública, não testamos especificamente o tempo de inatividade e não está claro se uma janela de manutenção é necessária.

Reprovisionando um nó que anteriormente hospedava GitHub Enterprise Server

Você pode usar um nó que anteriormente hospedava e executava GitHub Enterprise Server como um nó sem estado. Para fazer isso, o nó deve ser atualizado para a versão 3.18 ou superior e todos os nós na implantação devem estar executando a mesma versão. Nesse nó, verifique se /data/user/common/cluster.conf já existe. Se isso acontecer, você precisará realizar uma limpeza antes de executar o comando ghe-add-node no nó sem estado.

Por exemplo:

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

Limites e comportamento

Não há limite teórico para o número de nós que você pode adicionar. No entanto, na prática, adicionar muitos nós pode causar problemas e afetar a estabilidade ou o desempenho. Neste momento, os nós recém-adicionados processarão um conjunto predefinido de tarefas. Você não pode escolher qual tipo de tarefas são descarregadas. Todas as APIs podem ser processadas pelo nó adicional.

Se uma operação Git estiver no caminho, haverá lógica para processar as operações do Git somente no nó primário. As operações Git não são tratadas pelo nó adicional. Por exemplo, a exclusão de ramificação é uma operação Git e não será tratada pelo nó sem estado.

Nodos sem estado não executam cargas de trabalho do Elasticsearch, mas executam o kafka-lite.

Requisitos de sistema e rede

Geralmente, um nó sem estado não precisa corresponder à memória, à CPU e às especificações de armazenamento do nó primário. Os requisitos do sistema devem levar em conta o consumo de recursos existentes de serviços Web e de trabalho no nó primário e se o nó primário descarregará completamente essas cargas de trabalho para o novo nó.

O nó sem estado e a instância primária requerem conectividade em submilissegundos. Em geral, todos os nós dentro do datacenter primário demandam conectividade inferior a um milissegundo. Os requisitos de conectividade de réplica permanecem inalterados.

Roteamento de tráfego e tratamento de solicitações

A instância primária roteia o tráfego para os nós adicionais. No caso de vários nós sem estado, o primário envia novas conexões para o servidor com o menor número de conexões ativas nesse momento.

Atualizando uma implantação de HA com nós adicionais

Veja a seguir um exemplo de sequência de atualização:

  • Iniciar a janela de manutenção.
  • Parar réplicas.
  • Atualize nós sem estado em paralelo.
  • Atualize o nó primário.
  • Atualize as réplicas. Eles podem ser atualizados em paralelo ou sequencialmente, dependendo das preferências de recuperação de desastre.
  • Iniciar réplicas.
  • Remova a janela de manutenção.

Os nós adicionais não devem causar tempo de inatividade adicional durante as atualizações.

Comportamento de failover e recuperação de desastres

Não é necessário "derrubar" nós adicionais, pois eles não contêm dados.

Durante o failover, o nó de réplica é removido da implantação original e convertido em um nó autônomo. Os nós sem estado devem ser reconectados à réplica promovida, de forma semelhante à reconexão das réplicas adicionais após um failover.

Se o nó primário estiver funcional e você quiser promover uma réplica para ser primária, você deverá remover nós sem estado do primário com o ghe-remove-node comando, antes de adicioná-los novamente ao nó promovido.

Se o nó primário estiver inacessível e irrecuperável, os nós sem estado podem ser adicionados novamente sem serem removidos da instância primária original.

Monitoramento, logs e pacotes de suporte

No nó primário, os painéis de monitoramento do Console de Gerenciamento exibem métricas para todos os nós, incluindo os nós sem estado. Comandos como ghe-cluster-nodes e ghe-cluster-status contêm detalhes sobre nós sem estado. Todas as solicitações do Console de Gerenciamento são atendidas pelo nó primário.

Os logs são armazenados localmente nos nós sem estado. Eles podem ser exportados desses nós para serviços de gerenciamento de log de terceiros.

Você pode usar os comandos ghe-cluster-support-bundle e ghe-support-bundle para gerar e carregar pacotes de cluster ou de nó único.

Limitações conhecidas

Este recurso não foi projetado para repositórios, mas a adição de novos nós sem estado pode melhorar indiretamente as operações do monorepo, reduzindo as workloads da web e de tarefas no nó primário. Não há recursos de dimensionamento automático e redução de escala.