Quando você configura alta disponibilidade, há uma configuração automatizada de replicação assíncrona e unidirecional de todos os armazenamentos de dados (repositórios do Git, MySQL, Redis e Elasticsearch) do appliance primário para o appliance réplica. A maioria das configurações de GitHub Enterprise Server também são replicadas, incluindo a senha de Console de Gerenciamento. Para obter mais informações, confira "Administrar sua instância por meio da interface do usuário da Web".
O GitHub Enterprise Server é compatível com uma configuração ativa/passiva, em que os dispositivos de réplica são executados em espera com os serviços de banco de dados em execução no modo de replicação, mas os serviços de aplicativos são interrompidos.
Após a replicação ser estabelecida, o Console de Gerenciamento se torna inacessível nos dispositivos da réplica. Caso navegue até o endereço IP da réplica ou o nome do host na porta 8443, você verá uma mensagem "Servidor no modo de replicação", o que indica que o dispositivo está atualmente configurado como uma réplica.
Os dispositivos de réplica aceitam solicitações de cliente Git, e essas solicitações são encaminhadas para o dispositivo ativo.
Note
Há um máximo de oito réplicas de alta disponibilidade (réplicas passivas e ativas e geográficas, bem como instâncias de cache do repositório) permitidas para o GitHub Enterprise Server.
Cenários de falha
Use a configuração de alta disponibilidade para proteção contra:
- Falha de software, devido a uma falha do sistema operacional ou a aplicativos irrecuperáveis.
- Falhas de hardware, incluindo hardware de armazenamento, CPU, RAM, adaptadores de rede etc.
- Falhas no sistema host de virtualização, incluindo eventos de manutenção não planejada e agendada na AWS, no Azure ou no GCP.
- Rede interrompida lógica ou fisicamente, se o dispositivo de failover estiver em uma rede separada não afetada pela falha.
A configuração de alta disponibilidade não é uma boa solução para:
- Expansão. Embora você possa distribuir o tráfego geograficamente usando a replicação geográfica, o desempenho das gravações fica limitado à velocidade e à disponibilidade do dispositivo primário. Para obter mais informações, confira "Sobre a replicação geográfica".
- Carga de CI/CD. Se você tiver um grande número de clientes de CI que estão geograficamente distantes da sua instância principal, você pode beneficiar-se de configurar um cache de repositório. Para obter mais informações, confira "Sobre o cache do repositório".
- Fazendo backup do seu dispositivo primário. Uma réplica de alta disponibilidade não substitui os backups externos do seu plano de recuperação de desastres. Algumas formas de violação ou perda de dados podem ser replicadas de imediato do appliance primário para o de réplica. Para garantir a reversão segura a um estado anterior estável, você deve fazer backups regulares com instantâneos de histórico.
- Atualizações sem tempo de inatividade. Para evitar a perda de dados e situações de split-brain em cenários de promoção controlados, deixe o appliance primário em modo de manutenção e aguarde a conclusão de todas as gravações antes de promover o de réplica.
Estratégias de failover no tráfego de rede
Durante o failover, você deve configurar e gerenciar separadamente o redirecionamento do tráfego de rede do appliance primário para o de réplica.
Failover DNS
Com o failover DNS, use valores curtos de TTL nos registros DNS que apontam para o appliance primário GitHub Enterprise Server. Recomenda-se um TTL entre 60 segundos e cinco minutos.
Durante o failover, você deve deixar o appliance primário no modo de manutenção e redirecionar seus registros DNS para o endereço IP do appliance réplica. O tempo para redirecionar o tráfego do appliance primário para o de réplica dependerá da configuração do TTL e do tempo necessário para atualizar os registros DNS.
Se estiver usando replicação geográfica, você deverá configurar o DNS de localização geográfica para direcionar o tráfego à réplica mais próxima. Para obter mais informações, confira "Sobre a replicação geográfica".
Balanceador de carga
Um design de balanceador de carga usa um dispositivo de rede para direcionar o Git e o tráfego HTTP para appliances individuais GitHub Enterprise Server. Você pode usar um balanceador de carga para restringir o tráfego direto para o appliance para fins de segurança, ou redirecionar o tráfego se necessário sem alterações no registro de DNS. Recomendamos fortemente usar um balanceador de carga baseado em TCP que suporte o protocolo PROXY. Buscas de DNS para o nome de host GitHub Enterprise Server devem se resolver para o balanceador de carga. Recomendamos que você ative o isolamento de subdomínio. Se o isolamento do subdomínio estiver ativado, um registro de curinga adicional (*.HOSTNAME) também será resolvido para o balanceador de carga. Para obter mais informações, confira "Habilitar isolamento de subdomínio".
Durante o failover, você deve deixar o appliance principal em modo de manutenção. É possível configurar o balanceador de carga para detectar automaticamente quando o de réplica for promovido a primário, ou ele pode exigir uma alteração manual na configuração. Antes que o de réplica responda ao tráfego do usuário, você deve promovê-lo manualmente a primário. Para obter mais informações, confira "Usar o GitHub Enterprise Server com balanceador de carga".
Você pode monitorar a disponibilidade do GitHub Enterprise Server verificando o código de status retornado para a URL https://HOSTNAME/status. Um dispositivo que pode atender ao tráfego do usuário retornará o código de status 200 (OK). Um dispositivo pode retornar 503 (Serviço Indisponível) para essa URL e outras solicitações da Web ou de API por alguns motivos:
- O appliance é uma réplica passiva, como a réplica em uma configuração de alta disponibilidade de dois nós.
- O appliance está no modo de manutenção.
- O appliance é parte de uma configuração de geo-replicação, mas é uma réplica inativa.
Você também pode usar o painel de visualização de réplica disponível em:
https://HOSTNAME/setup/replication
Utilitários para o gerenciamento de replicações
Pessoas com acesso SSH administrativo a uma instância em uma configuração de alta disponibilidade podem usar utilitários de linha de comando para gerenciar a replicação. Para obter mais informações, confira "Utilitários de linha de comando".