Sobre a configuração de alta disponibilidade

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 "Como acessar o console de gerenciamento".

O GitHub Enterprise Server dá suporte a uma configuração ativa/passiva, em que o appliance réplica é executado 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. Se você acessar o endereço IP da réplica ou nome do host na porta 8443, verá uma mensagem "Servidor no modo de replicação", o que indica que o dispositivo está atualmente configurado como uma réplica.

Observação: há, no máximo, oito réplicas de alta disponibilidade (réplicas passivas e ativas/geográficas) 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.
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 replicação geográfica".
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, consulte "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 "Como habilitar o 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 "Usando GitHub Enterprise Server com um 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 poderá retornar o código de status 503 (Serviço Indisponível) 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

Para gerenciar a replicação no GitHub Enterprise Server, use estes utilitários de linha de comando ao se conectar ao appliance réplica usando SSH.

ghe-repl-setup

O comando ghe-repl-setup coloca um dispositivo do GitHub Enterprise Server em modo de espera de réplica.

Um túnel VPN WireGuard criptografado é configurado para comunicação entre os dois aparelhos.
Os serviços de banco de dados são configurados para replicação e iniciados.
Os serviços de aplicativos ficam desabilitados. As tentativas de acessar o appliance réplica por HTTP, Git ou outros protocolos com suporte levarão a uma página de manutenção "appliance em modo de réplica" ou a uma mensagem de erro.

admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

O comando ghe-repl-start ativa a replicação ativa de todos os armazenamentos de dados.

admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

O comando ghe-repl-status retorna um status OK, WARNING ou CRITICAL para cada fluxo de replicação do armazenamento de dados. Quando qualquer um dos canais de replicação estiver em um estado WARNING, o comando será encerrado com o código 1. Da mesma forma, quando qualquer um dos canais estiver em um estado CRITICAL, o comando será encerrado com o código 2.

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

As opções -v e -vv fornecem detalhes sobre o estado de replicação de cada repositório de dados:

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-stop

O comando ghe-repl-stop desabilita temporariamente a replicação para todos os armazenamentos de dados e interrompe os serviços de replicação. Para retomar a replicação, use o comando ghe-repl-start.

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Success: replication was stopped for all services.

ghe-repl-promote

O comando ghe-repl-promote desabilita a replicação e converte o dispositivo de réplica em um primário. O appliance é configurado com as mesmas configurações do primário original, e todos os serviços ficam ativados.

Promover uma réplica não configura automaticamente a replicação para appliances existentes. Depois de promover uma réplica, se desejar, você pode configurar a replicação do novo principal para os appliances existentes e o principal anterior.

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

O comando ghe-repl-teardown desabilita completamente o modo de replicação, removendo a configuração da réplica.