Configurar alta disponibilidade de replicação de um cluster

Sobre a alta disponibilidade de replicação de clusters

Você pode configurar uma implantação de cluster de GitHub Enterprise Server para alta disponibilidade, em que um conjunto idêntico de nós passivos estejam sincronizados com os nós no seu cluster ativo. Se falhas no hardware ou software afetarem o centro de dados com o seu cluster ativo, você poderá transferir a falha manualmente para os nós da réplica e continuar processando as solicitações do usuário, minimizando o impacto da interrupção.

Em modo de alta disponibilidade, cada nó ativo é sincronizado regularmente com um nó passivo correspondente. O nó passivo é executado em modo de espera e não atende a aplicativos nem processa solicitações de usuário.

Recomendamos configurar uma alta disponibilidade como parte de um plano de recuperação de desastres abrangente para GitHub Enterprise Server. Também recomendamos realizar backups regulares. Para obter mais informações, confira "Como configurar backups no seu dispositivo".

Pré-requisitos

Hardware e software

Para cada nó existente no seu cluster ativo, você precisará fornecer uma segunda máquina virtual com recursos de hardware idênticos. Por exemplo, se o cluster tiver 11 nós e cada nó tiver 12 vCPUs, 96 GB de RAM e 750 GB de armazenamento anexado, você precisará fornecer 11 novas máquinas virtuais, tendo cada uma 12 vCPUs, 96 GB de RAM e 750 GB de armazenamento anexado.

Em cada nova máquina virtual, instale a mesma versão do GitHub Enterprise Server que é executada nos nós do seu cluster ativo. Você não precisa fazer o upload de uma licença ou executar qualquer configuração adicional. Para obter mais informações, confira "Como configurar uma instância do GitHub Enterprise Server".

Observação: os nós que você pretende usar para a replicação de alta disponibilidade devem ser instâncias independentes do GitHub Enterprise Server. Não inicialize os nós passivos como um segundo cluster.

Rede

Você deve atribuir um endereço IP estático a cada novo nó que você fornecer e você deve configurar um balanceador de carga para aceitar conexões e direcioná-las para os nós na sua camada frontal do cluster.

Não recomendamos configurar um firewall entre a rede com o seu cluster ativo e a rede com o seu cluster passivo. A latência entre a rede com os nós ativos e a rede com os nós passivos deve ser inferior a 70 milissegundos. Para obter mais informações sobre a conectividade de rede entre os nós no cluster passivo, confira "Configuração da rede de cluster".

Criar uma alta réplica de disponibilidade para um cluster

Como atribuir nós ativos ao datacenter primário
Como adicionar nós passivos ao arquivo de configuração do cluster
Configuração de exemplo

Atribuindo nós ativos ao centro de dados primário

Antes de definir um centro de dados secundário para seus nós passivos, certifique-se de atribuir seus nós ativos para o centro de dados primário.

SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Como acessar o shell administrativo (SSH)".
Abra o arquivo de configuração de cluster em /data/user/common/cluster.conf em um editor de texto. Por exemplo, você pode usar o Vim.
```
sudo vim /data/user/common/cluster.conf
```
Observe o nome do centro de dados primário do seu cluster. A seção [cluster] no início do arquivo de configuração do cluster define o nome do datacenter primário usando o par chave-valor primary-datacenter. Por padrão, o datacenter primário do cluster é chamado default.
```
[cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = default
```
- Opcionalmente, altere o nome do datacenter primário para algo mais descritivo ou preciso editando o valor de primary-datacenter.
O arquivo de configuração do cluster lista cada nó sob um título [cluster "HOSTNAME"]. Embaixo do cabeçalho de cada nó, adicione um novo par chave-valor para atribuir o nó a um centro de dados. Use o mesmo valor de primary-datacenter da etapa 3 acima. Por exemplo, caso você deseje usar o nome padrão (default), adicione o par chave-valor a seguir � seção de cada nó.
```
datacenter = default
```
Ao concluir, a seção para cada nó no arquivo de configuração de cluster deve parecer-se com o exemplo a seguir. A ordem dos pares chave-valor não importa.
```
[cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP ADDRESS
  ...
...
```
Observação: se você alterou o nome do datacenter primário na etapa 3, localize o par chave-valor consul-datacenter na seção de cada nó e altere o valor para o datacenter primário renomeado. Por exemplo, se você nomeou o datacenter primário primary, use o par chave-valor a seguir para cada nó.
```
consul-datacenter = primary
```
Aplique a nova configuração. Esse comando pode levar algum tempo para ser concluído. Portanto, recomendamos executar o comando em um multiplexador de terminal como screen ou tmux.
```
ghe-cluster-config-apply
```
Após a conclusão da configuração executada, GitHub Enterprise Server exibe a mensagem a seguir.
```
Finished cluster configuration
```

Após GitHub Enterprise Server encaminhar você para a instrução, isso significa que você terminou de atribuir seus nós para o centro de dados primário do cluster.

Adicionar nós passivos ao arquivo de configuração do cluster

Para configurar a alta disponibilidade, você deve definir um nó passivo correspondente para cada nó ativo no seu cluster. As instruções a seguir criam uma nova configuração de cluster que define tanto nós ativos quanto passivos. Você terá a oportunidade de:

Criar uma cópia do arquivo de configuração do cluster ativo.
Editar a cópia para definir nós passivos que correspondem aos nós ativos, adicionando os endereços IP das novas máquinas virtuais que você forneceu.
Mescle a cópia modificada da configuração do cluster de volta � sua configuração ativa.
Aplique a nova configuração para iniciar a replicação.

Para ver um exemplo de configuração, confira "Exemplo de configuração".

Para cada nó no seu cluster, forneça uma máquina virtual correspondente com especificações idênticas, executando a mesma versão do GitHub Enterprise Server. Observe o endereço de host e endereço IPv4 para cada novo nó de cluster. Para obter mais informações, confira "Pré-requisitos".

Observação: se você estiver reconfigurando a alta disponibilidade após um failover, use os nós antigos do datacenter primário.
SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Como acessar o shell administrativo (SSH)".

Faça o backup da sua configuração de cluster existente.

cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

Crie uma cópia do arquivo de configuração de cluster existente em um local temporário, como /home/admin/cluster-passive.conf. Exclua os pares chave-valor exclusivos de endereços IP (ipv*), os UUIDs (uuid) e as chaves públicas do WireGuard (wireguard-pubkey).
```
grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
```
Remova a seção [cluster] do arquivo de configuração temporário do cluster que você copiou na etapa anterior.
```
git config -f ~/cluster-passive.conf --remove-section cluster
```
Defina um nome para o centro de dados secundário onde você forneceu seus nós passivos e, em seguida, atualize o arquivo de configuração temporário do cluster com o novo nome do centro de dados. Substitua SECONDARY pelo nome escolhido.
```
sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-passive.conf
```
Defina um padrão para os nomes de host dos nós passivos.

Aviso: os nomes do host dos nós passivos precisam ser exclusivos e diferentes do nome do host do nó ativo correspondente.
Abra o arquivo de configuração temporário do cluster da etapa 3 em um editor de texto. Por exemplo, você pode usar o Vim.
```
sudo vim ~/cluster-passive.conf
```
Em cada seção dentro do arquivo de configuração temporária, atualize as configurações do nó. O arquivo de configuração do cluster lista cada nó sob um título [cluster "HOSTNAME"].
- Altere o nome do host citado no título da seção e o valor para hostname na seção do nome do host do nó passivo pelo padrão escolhido na etapa 7 acima.
- Adicione uma nova chave chamada ipv4 e defina o valor como o endereço IPv4 estático do nó passivo.
- Adicione um novo par chave-valor, replica = enabled.
```
[cluster "NEW PASSIVE NODE HOSTNAME"]
  ...
  hostname = NEW PASSIVE NODE HOSTNAME
  ipv4 = NEW PASSIVE NODE IPV4 ADDRESS
  replica = enabled
  ...
...
```
Adicione o conteúdo do arquivo de configuração de cluster temporário que você criou na etapa 4 ao arquivo de configuração ativo.
```
cat ~/cluster-passive.conf >> /data/user/common/cluster.conf
```
Nomeie os nós primários do MySQL e Redis no centro de dados secundário. Substitua REPLICA MYSQL PRIMARY HOSTNAME e REPLICA REDIS PRIMARY HOSTNAME pelos nomes do host do nó passivo que você provisionou para corresponder aos primários existentes do MySQL e do Redis.
```
git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA MYSQL PRIMARY HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA REDIS PRIMARY HOSTNAME
```
Aviso: revise o arquivo de configuração do cluster antes de prosseguir.
- Na seção [cluster] de nível superior, verifique se os valores de mysql-master-replica e redis-master-replica são os nomes do host corretos dos nós passivos no datacenter secundário servirão como os primários do MySQL e do Redis após um failover.
- Em cada seção de um nó ativo chamado [cluster "ACTIVE NODE HOSTNAME"], verifique novamente os pares chave-valor a seguir.
  - datacenter deve corresponder ao valor de primary-datacenter na seção [cluster] de nível superior.
  - consul-datacenter deve corresponder ao valor de datacenter, que deve ser o mesmo que o valor de primary-datacenter na seção [cluster] de nível superior.
- Verifique se, para cada nó ativo, a configuração tem uma seção correspondente para um nó passivo com as mesmas funções. Em cada seção para um nó passivo, verifique novamente cada par de chave-valor.
  - datacenter deve corresponder a todos os outros nós passivos.
  - consul-datacenter deve corresponder a todos os outros nós passivos.
  - hostname deve corresponder ao nome do host no título da seção.
  - ipv4 deve corresponder ao endereço IPv4 estático exclusivo do nó.
  - replica deve ser configurado como enabled.
- Aproveite a oportunidade para remover seções para nós off-line que não estão mais sendo usados.
Para revisar um exemplo de configuração, confira "Exemplo de configuração".
Inicializar a nova configuração de cluster. Esse comando pode levar algum tempo para ser concluído. Portanto, recomendamos executar o comando em um multiplexador de terminal como screen ou tmux.
```
ghe-cluster-config-init
```
Após a conclusão da inicialização , GitHub Enterprise Server exibirá a seguinte mensagem.
```
Finished cluster initialization
```
Aplique a nova configuração. Esse comando pode levar algum tempo para ser concluído. Portanto, recomendamos executar o comando em um multiplexador de terminal como screen ou tmux.
```
ghe-cluster-config-apply
```
Após a conclusão da configuração executada, GitHub Enterprise Server exibe a mensagem a seguir.
```
Finished cluster configuration
```
Configure um balanceador de carga que aceitará conexões de usuários se você gerar uma falha para os nós passivos. Para obter mais informações, confira "Configuração da rede de cluster".

Você terminou de configurar uma replicação de alta disponibilidade para os nós do seu cluster. Cada nó ativo começa a replicar a configuração e os dados para o seu nó passivo correspondente e você pode direcionar o tráfego para o balanceador de carga para o centro de dados secundário em caso de falha. Para obter mais informações sobre o failover, confira "Como iniciar um failover para o cluster de réplica".

Configuração de exemplo

A configuração de [cluster] de nível superior será parecida com o exemplo a seguir.

[cluster]
  mysql-master = HOSTNAME OF ACTIVE MYSQL MASTER
  redis-master = HOSTNAME OF ACTIVE REDIS MASTER
  primary-datacenter = PRIMARY DATACENTER NAME
  mysql-master-replica = HOSTNAME OF PASSIVE MYSQL MASTER
  redis-master-replica = HOSTNAME OF PASSIVE REDIS MASTER
  mysql-auto-failover = false
...

A configuração para um nó ativo no nível de armazenamento do seu grupo deve parecer o seguinte exemplo.

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE ACTIVE NODE HOSTNAME
  ipv4 = IPV4 ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  vpn = IPV4 ADDRESS SET AUTOMATICALLY
  uuid = UUID SET AUTOMATICALLY
  wireguard-pubkey = PUBLIC KEY SET AUTOMATICALLY
...

A configuração para o nó passivo correspondente no nível de armazenamento deve parecer-se com o seguinte exemplo.

Diferenças importantes do nó ativo correspondente são destacadas em negrito.
O GitHub Enterprise Server atribui valores para vpn, uuid e wireguard-pubkey automaticamente, ou seja, você não deve definir os valores para os nós passivos que serão inicializados.
As funções do servidor, definidas pelas chaves *-server, correspondem ao nó ativo correspondente.

...
[cluster "UNIQUE PASSIVE NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE PASSIVE NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  vpn = DO NOT DEFINE
  uuid = DO NOT DEFINE
  wireguard-pubkey = DO NOT DEFINE
...

Monitoramento de replicação entre nós de cluster ativos e passivos

A replicação inicial entre os nós ativos e passivos do seu cluster leva tempo. A quantidade de tempo depende da quantidade de dados para a replicação e dos níveis de atividade para GitHub Enterprise Server.

Você pode monitorar o progresso em qualquer nó do cluster, usando ferramentas de linha de comando disponíveis através do shell administrativo do GitHub Enterprise Server. Para obter mais informações sobre o shell administrativo, confira "Como acessar o shell administrativo (SSH)".

Monitorar replicação dos bancos de dados:

/usr/local/share/enterprise/ghe-cluster-status-mysql

Monitorar replicação do repositório e dos dados do Gist:
```
ghe-spokes status
```
Monitorar replicação dos anexo e dos dados de LFS:
```
ghe-storage replication-status
```
Monitorar replicação dos dados das páginas:
```
ghe-dpages replication-status
```

Use ghe-cluster-status para analisar a integridade geral do cluster. Para obter mais informações, confira "Utilitários de linha de comando".

Reconfigurar a replicação de alta disponibilidade após um failover

Após gerar um failover dos nós ativos do cluster para os nós passivos do cluster, você pode reconfigurar a replicação de alta disponibilidade de duas maneiras.

Provisionamento e configuração de novos nós passivos

Após um failover, você pode reconfigurar alta disponibilidade de duas maneiras. O método escolhido dependerá da razão pela qual você gerou o failover e do estado dos nós ativos originais.

Forneça e configure um novo conjunto de nós passivos para cada um dos novos nós ativos no seu centro de dados secundário.
Use os antigos nós ativos como os novos nós passivos.

O processo de reconfiguração de alta disponibilidade é idêntico � configuração inicial de alta disponibilidade. Para obter mais informações, confira "Como criar uma réplica de alta disponibilidade para um cluster".

Desabilitar a replicação de alta disponibilidade para um cluster

Você pode parar a replicação nos nós passivos para a sua implantação de cluster de GitHub Enterprise Server.

SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Como acessar o shell administrativo (SSH)".
Abra o arquivo de configuração de cluster em /data/user/common/cluster.conf em um editor de texto. Por exemplo, você pode usar o Vim.
```
sudo vim /data/user/common/cluster.conf
```
Na seção [cluster] de nível superior, exclua os pares chave-valor redis-master-replica e mysql-master-replica.
Exclua cada seção para um nó passivo. Para os nós passivos, replica é configurado como enabled.
Aplique a nova configuração. Esse comando pode levar algum tempo para ser concluído. Portanto, recomendamos executar o comando em um multiplexador de terminal como screen ou tmux.
```
ghe-cluster-config-apply
```
Após a conclusão da configuração executada, GitHub Enterprise Server exibe a mensagem a seguir.
```
Finished cluster configuration
```

Após GitHub Enterprise Server encaminhar você para a instrução, isso significa que você terminou de desabilitar a replicação de alta disponibilidade.