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-valorprimary-datacenter
. Por padrão, o datacenter primário do cluster é chamadodefault
.[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
.
- Opcionalmente, altere o nome do datacenter primário para algo mais descritivo ou preciso editando o valor de
-
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 deprimary-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árioprimary
, 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
outmux
.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 ... ...
- Altere o nome do host citado no título da seção e o valor para
-
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
eREPLICA 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 demysql-master-replica
eredis-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 deprimary-datacenter
na seção[cluster]
de nível superior.consul-datacenter
deve corresponder ao valor dedatacenter
, que deve ser o mesmo que o valor deprimary-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 comoenabled
.
- 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".
- Na seçã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
outmux
.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
outmux
.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
ewireguard-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-valorredis-master-replica
emysql-master-replica
. -
Exclua cada seção para um nó passivo. Para os nós passivos,
replica
é configurado comoenabled
. -
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
outmux
.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.