Substituir um nó de cluster

Sobre a substituição dos nós de cluster do GitHub Enterprise Server

Você pode substituir um nó funcional em um cluster do GitHub Enterprise Server, ou pode substituir um nó que falhou inesperadamente.

Após a substituição de um nó, o sua instância do GitHub Enterprise Server não distribui automaticamente tarefas para o novo nó. Você pode forçar sua instância a balancear trabalhos entre os nós. Para saber mais, confira AUTOTITLE.

Substituir um nó funcional

É possível substituir um nó já funcional existente no cluster. Por exemplo, talvez você queira fornecer uma VM (máquina virtual) com recursos adicionais de CPU, memória ou armazenamento.

Para substituir um nó funcional, instale o dispositivo do GitHub Enterprise Server em uma nova VM, configure um endereço IP, adicione o novo nó ao arquivo de configuração do cluster, inicialize o cluster, aplique a configuração e coloque o nó substituído offline.

1. Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.

2. Usando o shell administrativo ou o DHCP, configure apenas o endereço IP do nó de substituição. Não altere nenhuma outra configuração.

3. Para adicionar o nó de substituição recém-provisionado, em qualquer nó, modifique o arquivo cluster.conf para remover o nó com falha e adicione o nó de substituição. Por exemplo, este arquivo cluster.conf modificado substitui ghe-data-node-3 pelo nó recém-provisionado, ghe-replacement-data-node-3:

   [cluster "ghe-replacement-data-node-3"]
     hostname = ghe-replacement-data-node-3
     ipv4 = 192.168.0.7
     # ipv6 = fd12:3456:789a:1::7
     consul-datacenter = PRIMARY-DATACENTER
     git-server = true
     pages-server = true
     mysql-server = true
     elasticsearch-server = true
     redis-server = true
     memcache-server = true
     metrics-server = true
     storage-server = true
   

   Você pode optar por adiar a propagação do banco de dados de um novo nó de réplica do MySQL, resultando na capacidade de abrir seu dispositivo ao tráfego mais cedo. Para saber mais, confira Adiar a semeadura do banco de dados.

4. No shell administrativo do nó com o cluster.conf modificado, execute ghe-cluster-config-init. Isto irá inicializar o nó recém-adicionado no cluster.

5. No mesmo nó, execute ghe-cluster-config-apply. Isso vai validar o arquivo de configuração, copiá-lo para cada nó no cluster e configurar cada nó de acordo com o arquivo cluster.conf modificado.

6. Para colocar o nó que você está substituindo offline, no nó MySQL principal do seu cluster, execute o seguinte comando.

   ghe-remove-node NODE-HOSTNAME
   

   Esse comando evacuará os dados de qualquer serviço de dados em execução no nó, marcará o nó como offline em sua configuração e interromperá o tráfego que está sendo roteado para o nó. Para saber mais, confira AUTOTITLE.

Substituir um nó em caso de emergência

É possível substituir um nó com falha no cluster. Por exemplo, um problema de software ou hardware pode afetar a disponibilidade de um nó.

Para substituir um nó em uma emergência, você colocará o nó com falha offline, adicionará o nó de substituição ao cluster e vai executar comandos para remover referências a serviços de dados no nó removido.

1. Para remover o nó com problemas do cluster, a partir do nó MySQL primário, execute o seguinte comando. Substitua NODE-HOSTNAME pelo nome do host do nó que você está colocando offline.

   ghe-remove-node --no-evacuate NODE-HOSTNAME
   

   Esse comando irá marcar o nó como offline em sua configuração e interromperá o tráfego que está sendo roteado para o nó. Você pode executar esse comando no modo agora porque, mais adiante neste procedimento, você vai executar comandos que instruem os serviços de dados no nó a copiar quaisquer réplicas para os outros nós disponíveis no cluster. Para saber mais, confira AUTOTITLE.

2. Adicione o nó de substituição ao cluster.

   1. Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.

3. Usando o shell administrativo ou o DHCP, configure apenas o endereço IP do nó de substituição. Não altere nenhuma outra configuração.

   1. Para adicionar o novo nó de substituição recém-provisionado, em qualquer nó, modifique o arquivo [nome do arquivo] para adicionar o nó de substituição. Por exemplo, este arquivo modificado adiciona o nó recém-provisionado:

      [cluster "ghe-replacement-data-node-3"]
        hostname = ghe-replacement-data-node-3
        ipv4 = 192.168.0.7
        # ipv6 = fd12:3456:789a:1::7
        git-server = true
        pages-server = true
        mysql-server = true
        elasticsearch-server = true
        redis-server = true
        memcache-server = true
        metrics-server = true
        storage-server = true
      

   2. No shell administrativo do nó com o cluster.conf modificado, execute ghe-cluster-config-init. Isto irá inicializar o nó recém-adicionado no cluster.

4. No mesmo nó, execute ghe-cluster-config-apply. Isso vai validar o arquivo de configuração, copiá-lo para cada nó no cluster e configurar cada nó de acordo com o arquivo cluster.conf modificado.

5. Remova referências a serviços de dados no nó que você removeu.

   1. Encontre o UUID do nó que você removeu. Para localizar o UUID, execute o seguinte comando: substitua pelo nome de host do nó. Você usará este UUID na próxima etapa.

      ghe-config cluster.HOSTNAME.uuid
      

   2. Para remover referências a serviços de dados, execute os comandos a seguir. Substitua pelo UUID do nó.

      Esses comandos indicam a cada serviço que o nó foi removido permanentemente. Os serviços recriarão todas as réplicas contidas no nó nos nós disponíveis no cluster.

      Observação

      Esses comandos podem causar um aumento de carga no servidor enquanto os dados são rebalanceados entre as réplicas.

      Para o serviço (usado para dados do repositório):

      ghe-spokesctl server destroy git-server-UUID
      

      Para o serviço (usado para criações de site GitHub Pages):

      ghe-dpages remove pages-server-UUID
      

      Para o serviço (usado para dados Git LFS, imagens de avatar, anexos de arquivos e arquivos de lançamento):

      ghe-storage destroy-host storage-server-UUID --force
      

6. Opcionalmente, exclua a entrada para o nó removido no seu arquivo. Isso irá manter seu arquivo organizado e economizará tempo durante execuções futuras .

   1. Para remover a entrada do arquivo, execute o seguinte comando, substituindo pelo nome do host do nó removido.

      ghe-config --remove-section "cluster.HOSTNAME"
      

   2. Para copiar a configuração para outros nós no cluster, a partir do shell administrativo do nó onde você fez a modificação, execute.

Substituição do nó principal do banco de dados (MySQL ou MySQL e MSSQL)

Para fornecer serviços de banco de dados, seu cluster requer um nó MySQL primário e, pelo menos, um nó MySQL de réplica. Para saber mais, confira AUTOTITLE.

Se o cluster tem o GitHub Actions habilitado, você também precisará considerar o MSSQL nas etapas a seguir.

Se você precisar alocar mais recursos ao nó mySQL primário (ou MySQL e MSSQL) ou substituir um nó com falha, poderá adicionar um novo nó ao cluster. Para minimizar o tempo de inatividade, adicione o novo nó, replique os dados MySQL (ou MySQL e MSSQL) e promova-os para o nó primário. É necessário algum tempo de inatividade durante o processo de promoção.

1. Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.

2. Usando o shell administrativo ou o DHCP, configure apenas o endereço IP do nó de substituição. Não altere nenhuma outra configuração.

3. Para se conectar ao sua instância do GitHub Enterprise Server, acesse via SSH qualquer um dos nós do cluster. Na estação de trabalho, execute o comando a seguir. Substituir HOSTNAME pelo nome do host do nó. Para saber mais, confira Acesar o shell administrativo (SSH).

   Shell

   ssh -p 122 admin@HOSTNAME
   

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

5. O arquivo de configuração do cluster lista cada nó sob um título [cluster "HOSTNAME"]. Adicione um novo título para o nó e insira os pares de valores-chave para configuração, substituindo os espaços reservados por valores reais.

   • Inclua o par de valores-chave .
   • Se o GitHub Actions estiver habilitado no cluster, você também precisará incluir o par chave-valor .
   • A seção a seguir é um exemplo, e a configuração do seu nó pode ser diferente.

   ...
   [cluster "HOSTNAME"]
     hostname = HOSTNAME
     ipv4 = IPV4-ADDRESS
     # ipv6 = IPV6-ADDRESS
     consul-datacenter = PRIMARY-DATACENTER
     datacenter = DATACENTER
     mysql-server = true
     redis-server = true
     ...
   ...
   

6. No shell administrativo do nó com o cluster.conf modificado, execute ghe-cluster-config-init. Isto irá inicializar o nó recém-adicionado no cluster.

7. No shell administrativo do nó onde realizou modificações, execute. O nó adicionado recentemente se transformará em um nó MySQL de réplica e outros serviços configurados serão executados nesse nó.

   Observação

   O snippet anterior não pressupõe que o GitHub Actions esteja habilitado no cluster.

8. Aguarde a conclusão da replicação do MySQL. Para monitorar a replicação do MySQL por meio de qualquer nó do cluster, execute .

   Se o GitHub Actions estiver habilitado no cluster, você precisará aguardar a conclusão da replicação de MSSQL.

   Pouco após adicionar o nó ao cluster, você poderá ver um erro no status da replicação até que a replicação se normalize. O processo de duplicação pode demorar horas, dependendo da carga da instância, da quantidade de dados do banco de dados e da última vez em que a instância gerou uma posição inicial de banco de dados.

9. Durante a janela de manutenção agendada, habilite o modo de manutenção. Para saber mais, confira AUTOTITLE.

10. Verifique se a replicação do MySQL (ou do MySQL e MSSQL) foi concluída a partir de qualquer nó do cluster, executando o comando apropriado.

    Aviso

    Se você não aguardar a replicação de MySQL (ou MySQL e MSSQL) terminar, correrá o risco de perder dados na instância.

11. Para definir o nó primário atual do MySQL como o modo somente leitura, execute o comando a seguir no nó primário do MySQL.

    Shell

    echo "SET GLOBAL super_read_only = 1;" | sudo mysql
    

12. Aguarde até que os Identificadores de Transação Global (GTIDs) definidos nos nós MySQL primário e de réplica sejam idênticos. Para verificar os GTIDs, execute o comando a seguir em qualquer nó de cluster.

    Shell

    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    

    • Para verificar se a variável MySQL global foi definida com êxito, execute o comando a seguir.
    Shell

     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
    

13. Se o GitHub Actions estiver habilitado no cluster, acesse por SSH o nó que se tornará o novo nó MSSQL primário.

    Shell

    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    

    • Em uma sessão, execute o comando a seguir para promover o MSSQL ao novo nó.
    Shell

    /usr/local/share/enterprise/ghe-mssql-repl-promote
    

    Isso tentará acessar o nó MSSQL primário atual e executar um failover controlado.

14. Depois que os GTIDs nos nós MySQL primário e de réplica estiverem iguais, atualize a configuração do cluster abrindo o arquivo de configuração do cluster em um editor de texto.

    • Crie um backup do arquivo antes de editá-lo.
    • Na seção de nível superior, remova o nome do host do nó que você substituiu do par chave-valor e, em seguida, atribua o novo nó. Se o novo nó também for um nó Redis primário, ajuste o par chave-valor.
    • Se o GitHub Actions estiver habilitado no cluster, você também precisará incluir o par chave-valor .

    [cluster]
      mysql-master = NEW-NODE-HOSTNAME
      redis-master = NEW-NODE-HOSTNAME
      primary-datacenter = primary
    ...
    

15. No shell administrativo do nó em que você modificou , inicie uma sessão e execute . Esse comando reconfigura o cluster, promovendo o nó recém-adicionado ao nó MySQL primário e convertendo o nó MySQL primário original em uma réplica.

    Observação

    O snippet anterior não pressupõe que o GitHub Actions esteja habilitado no cluster.

16. Verifique o status da replicação MySQL (ou MySQL e MSSQL) em qualquer nó do cluster executando .

17. Se o GitHub Actions estiver habilitado no cluster, execute o seguinte comando no novo nó MySQL e MSSQL.

    Shell

    /usr/local/share/enterprise/ghe-repl-post-failover-mssql
    

18. Quando a replicação MySQL (ou MySQL e MSSQL) for concluída, desabilite o modo de manutenção a partir de qualquer nó do cluster. Consulte AUTOTITLE