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, consulte "Configurar backups no appliance".

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 seu cluster tiver 11 nós e cada nó tem 12 vCPUs, 96 GB de RAM e 750 GB de armazenamento anexado, você deverá 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, consulte "Configurar instância do GitHub Enterprise Server".

Observação: Os nós que você pretende usar para alta disponibilidade devem ser instâncias independentes de 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 conectividade de rede entre os nós no cluster passivo, consulte "Configuração da rede do cluster".

Criar uma alta réplica de disponibilidade para um cluster

Atribuindo nós ativos ao centro de dados primário
Adicionar nós passivos ao arquivo de configuração do cluster
Exemplo de configuração

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, consulte "Acessar o shell administrativo (SSH)".
Abra o arquivo de configuração do 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] na parte superior do arquivo de configuração do cluster define o nome do centro de dados primário, usando o par de chave-valor primary-datacenter. Por padrão, o centro de dados primário para o seu cluster é denominado padrão.
```
[cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = default
```
- Opcionalmente, altere o nome do centro de dados primário para algo mais descritivo ou preciso, editando o valor do primary-datacenter.
O arquivo de configuração do cluster lista cada nó em um cabeçalho de [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 do primary-datacenter da etapa 3 acima. Por exemplo, se você quiser usar o nome-padrão (padrão) adicionar o seguinte par de chave-valor � seção para cada nó.
```
centro de dados = padrão
```
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 centro de dados primário no passo 3, encontre o par chave-valor consul-datacenter chave-valor na seção para cada nó e altere o valor para o centro de dados primário renomeado. Por exemplo, se você nomeou o centro de dados primário, use o seguinte par de chave-valor para cada nó.
```
consul-datacenter = primary
```
Aplique a nova configuração. Este comando pode levar algum tempo para terminar. Portanto, recomendamos executar o comando em um terminal multiplexer 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.
```
Configuração de cluster concluída
```

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ê irá:

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 uma exemplo de configuração, consulte "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, consulte "Pré-requisitos".

Observação: Se você estiver reconfigurando alta disponibilidade após um failover, você poderá usar os nós antigos do centro de dados principal.
SSH em qualquer nó no seu cluster. Para obter mais informações, consulte "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 seu arquivo de configuração de cluster existente em um local temporário, como /home/admin/cluster-passive.conf. Excluir pares de chave-valor únicos para endereços IP (ipv*), UUIDs (uid) e chaves públicas para 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 SEGUNDÁRIO 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 de host para nós passivos devem ser únicos e devem diferir do nome de host para o 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ó em um cabeçalho de [cluster "HOSTNAME"].
- Altere o nome de host citado no cabeçalho da seção e o valor para hostname dentro da seção para o nome do host do nó passivo pelo padrão escolhido na etapa 7 acima.
- Adicione uma nova chave denominada ipv4 e defina o valor para o endereço IPv4 estático do nó passivo.
- Adicione um novo par de chave-valor, réplica = habilitado.
```
[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 MYSQL REPLICA PRIMARY HOSTNAME e REPLICA REDIS PRIMARY HOSTNAME pelos nomes de host do nó passivo que você forneceu para corresponder aos seus MySQL e Redis primários.
```
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 seu arquivo de configuração de cluster antes de prosseguir.
- Na seção de nível superior [cluster], certifique-se de que os valores para mysql-master-replica e redis-master-replica são os nomes corretos para os nós passivos no centro de dados secundário que servirão como MySQL e Redis primários após um failover.
- Em cada seção para um nó ativo denominado [cluster "<em>ACTIVE NODE HOSTNAME</em>"], verifique novamente os seguintes pares de chave-valor.
  - O centro de dados deve corresponder ao valor de primary-datacenter na seção de nível superior [cluster].
  - consul-datacenter deve corresponder ao valor de centro de dados, que deve ser o mesmo que o valor para primary-datacenter na seção de nível superior [cluster].
- Certifique-se de que 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.
  - O centro de dados deve corresponder a todos os outros nós passivos.
  - consul-datacenter deve corresponder a todos os outros nós passivos.
  - O hostname deve coincidir com o nome de host no cabeçalho da seção.
  - ipv4 deve corresponder ao endereço IPv4 único e estático do nó.
  - A réplica deve ser configurada como habilitada.
- Aproveite a oportunidade para remover seções para nós off-line que não estão mais sendo usados.
Para revisar uma configuração de exemplo, consulte "Exemplo de confoguração".
Inicializar a nova configuração de cluster. Este comando pode levar algum tempo para terminar. Portanto, recomendamos executar o comando em um terminal multiplexer como screen ou tmux.
```
ghe-cluster-config-init
```
Após a conclusão da inicialização , GitHub Enterprise Server exibirá a seguinte mensagem.
```
Inicialização de cluster concluída
```
Aplique a nova configuração. Este comando pode levar algum tempo para terminar. Portanto, recomendamos executar o comando em um terminal multiplexer 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.
```
Configuração de cluster concluída
```
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, consulte "Configuração de 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 como gerar falha, consulte "Iniciar um failover no seu cluster de réplica".

Exemplo de configuração

A configuração de nível [cluster] deve parecer-se 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 estão em negrito.
GitHub Enterprise Server atribui valores para vpn, uuid e wireguard-pubkey automaticamente. Portanto, você não deve definir os valores para nós passivos que você inicializar.
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 administrativa, consulte "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
```

Você pode usar ghe-cluster-status para revisar a saúde geral do seu cluster. Para obter mais informações, consulte "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, consulte "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, consulte "Acessar o shell administrativo (SSH)".
Abra o arquivo de configuração do 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 de nível superior [cluster] exclua os pares chave-valorredis-master-replica e mysql-master-replica.
Exclua cada seção para um nó passivo. Para nódulos passivos, a réplica é configurada como habilitada.

1. Aplique a nova configuração. Este comando pode levar algum tempo para terminar. Portanto, recomendamos executar o comando em um terminal multiplexer como `screen` ou `tmux`. ghe-cluster-config-apply

1. Após a conclusão da configuração executada, GitHub Enterprise Server exibe a mensagem a seguir.

<pre><code class="hljs language-shell">Configuração de cluster concluída</code></pre></p>

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