Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Configurar alta disponibilidade de replicação de um cluster

Você pode configurar uma réplica de todo o seu cluster do GitHub Enterprise Server em um data center à parte, permitindo que seu cluster faça failover em nós redundantes.

Neste artigo

Sobre a alta disponibilidade de replicação de clusters

Você pode fornecer proteção contra interrupções em um datacenter ou uma região de nuvem configurando uma implantação de cluster do GitHub Enterprise Server para alta disponibilidade. Em uma configuração de alta disponibilidade, um conjunto idêntico de nós de réplica é sincronizado com os nós do 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 uma configuração de alta disponibilidade, os nós que hospedam serviços de dados sincronizam regularmente com o cluster de réplica. Nós de réplica são executados em modo de espera e não atendem 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 clustering do GitHub Enterprise Server. Também recomendamos realizar backups regulares. Para saber mais, confira Como configurar backups em sua instância.

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 13 nós e cada nó tiver 12 vCPUs, 96 GB de RAM e 750 GB de armazenamento anexado, você precisará fornecer 13 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 saber mais, confira Configurar uma instância do GitHub Enterprise Server.

Note

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 de réplica 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.

A latência entre os nós primário e de réplica deve ser inferior a 70 milissegundos. Não recomendamos configurar um firewall entre as duas redes de nós. Para obter mais informações sobre a conectividade de rede entre os nós no cluster de réplica, confira Configuração de rede de cluster.

Criar uma alta réplica de disponibilidade para um cluster

Para criar uma réplica de alta disponibilidade para o cluster, você deve concluir as tarefas a seguir. Você também pode revisar uma configuração de exemplo.

  1. Atribua nodes ativos ao datacenter primário.
  2. Adicione nodes de réplica ao arquivo de configuração do cluster
  3. Veja esta configuração de exemplo.

1. Atribua nodes ativos ao datacenter primário

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

  1. SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Acesar o shell administrativo (SSH)".

  2. Em um editor de texto, abra o arquivo de configuração do cluster em /data/user/common/cluster.conf. Por exemplo, você pode usar o Vim. Crie um backup do arquivo cluster.conf antes de editá-lo.

    Shell
    sudo vim /data/user/common/cluster.conf

  3. 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.

    [cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
    • Opcionalmente, altere o nome do datacenter primário para algo mais descritivo ou preciso editando o valor de primary-datacenter.

  4. 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 = primary

    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
  ...
...

    Note

    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

  5. 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

  6. 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.

2. Adicione nodes de réplica ao arquivo de configuração do cluster

Para configurar a alta disponibilidade, você deve definir um nó de réplica correspondente para cada nó ativo no seu cluster. Para criar uma nova configuração de cluster que defina nós ativos e de réplica, você concluirá as tarefas a seguir.

  • Criar uma cópia do arquivo de configuração do cluster ativo.
  • Editar a cópia para definir nós de réplica 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 Revise esta configuração de exemplo.

  1. 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, veja Pré-requisitos.

    Note

    Se você estiver reconfigurando a alta disponibilidade após um failover, use os nós antigos do datacenter primário.

  2. SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Acesar o shell administrativo (SSH)".

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

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

  4. Crie uma cópia do arquivo de configuração de cluster existente em um local temporário, como /home/admin/cluster-replica.conf.

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf

  5. Remova a seção [cluster] do arquivo de configuração temporário do cluster que você copiou na etapa anterior.

    git config -f ~/cluster-replica.conf --remove-section cluster

  6. Defina um nome para o centro de dados secundário onde você forneceu seus nós de réplica 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-replica.conf

  7. Defina um padrão para os nomes de host dos nós de réplica.

    Warning

    Os nomes do host dos nós de réplica precisam ser exclusivos e diferentes do nome do host do nó ativo correspondente.

  8. 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-replica.conf

  9. 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ó de réplica 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ó de réplica.
    • Adicione um novo par chave-valor, replica = enabled.
    [cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...

  10. 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-replica.conf >> /data/user/common/cluster.conf

  11. 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ó de réplica 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

    Warning

    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 de réplica 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ó de réplica com as mesmas funções. Em cada seção para um nó de réplica, verifique novamente cada par de chave-valor.
      • datacenter deve corresponder a todos os outros nós de réplica.
      • consul-datacenter deve corresponder a todos os outros nós de réplica.
      • 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 Revise esta configuração de exemplo.

  12. 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

  13. Após a conclusão da inicialização , GitHub Enterprise Server exibirá a seguinte mensagem.

    Finished cluster initialization

  14. 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

  15. Após a conclusão da execução da configuração, verifique se a replicação do cluster está corretamente configurada e funcionando.

    ghe-cluster-repl-status

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

    Finished cluster configuration

  17. Configure um balanceador de carga que aceitará conexões de usuários depois de fazer failover para os nós de réplica. Para saber mais, confira 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ó de réplica 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 failover, confira Iniciar failover no seu cluster de réplica.

3. Revise esta 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-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-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
  uuid = UUID SET AUTOMATICALLY
...

A configuração para o nó de réplica 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 uuid automaticamente, ou seja, você não deve definir esse valor para os nós de réplica que serão inicializados.
  • As funções do servidor, definidas pelas chaves *-server, correspondem ao nó ativo correspondente.
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA 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
  uuid = DO NOT DEFINE
...

Monitoramento de replicação entre nós de cluster ativos e de réplica

A replicação inicial entre os nós ativos e de réplica 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 Acesar o shell administrativo (SSH).

Para monitorar a replicação de todos os serviços, use o comando a seguir.

ghe-cluster-repl-status

Use ghe-cluster-status para analisar a integridade geral do cluster. Para saber mais, confira Utilitários de linha de comando.

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

Após fazer failover dos nós ativos do cluster para os nós de réplica do cluster, você poderá reconfigurar a 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 de réplica para cada um dos novos nós ativos no seu centro de dados secundário.
  • Use os nós ativos originais como os novos nós de réplica.

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.

Se você usar os nós ativos originais, depois de reconfigurar a alta disponibilidade, será necessário remover a definição do modo de manutenção nos nós. Para saber mais, confira Habilitar e programar o modo de manutenção.

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

Você pode parar a duplicação nos nodes de réplica para a sua implantação de cluster de GitHub Enterprise Server.

  1. SSH em qualquer nó no seu cluster. Para obter mais informações, confira "Acesar o shell administrativo (SSH)".

  2. Em um editor de texto, abra o arquivo de configuração do cluster em /data/user/common/cluster.conf. Por exemplo, você pode usar o Vim. Crie um backup do arquivo cluster.conf antes de editá-lo.

    Shell
    sudo vim /data/user/common/cluster.conf

  3. Na seção [cluster] de nível superior, exclua os pares chave-valor redis-master-replica e mysql-master-replica.

  4. Exclua cada seção para um nó de réplica. Para os nós de réplica, replica é configurado como enabled.

  5. 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

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

    Finished cluster configuration