Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-07-09. 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.

Substituir um nó de cluster

Se um nó falhar em um cluster do GitHub Enterprise Server ou para adicionar um nó com mais recursos, marque todos os nós a serem substituídos como offline e, em seguida, adicione o novo nó.

Quem pode usar esse recurso?

A GitHub determina a qualificação para clustering e deve habilitar a configuração para a licença da instância. O clustering requer um planejamento cuidadoso e sobrecarga administrativa adicional. Para obter mais informações, confira "Sobre clustering".

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

É possível substituir um nó funcional em um cluster do GitHub Enterprise Server ou um nó que falhou inesperadamente.

Depois que você substituir um nó, o sua instância do GitHub Enterprise Server não distribuirá trabalhos automaticamente para o novo nó. É possível forçar a instância a equilibrar trabalhos entre os nós. Para obter mais informações, confira "Rebalancear as cargas de trabalho do cluster".

Aviso: para evitar conflitos, não reutilize um nome de host atribuído anteriormente a um nó no cluster.

Substituir um nó funcional

É possível substituir um nó 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 nó ao arquivo de configuração do cluster, inicialize o cluster, aplique a configuração e coloque o nó substituído offline.

Nota: Se você estiver substituindo o nó primário do MySQL, consulte "Substituindo o nó primário do MySQL".

  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
      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 obter mais informações, confira "Adiar a propagação 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. Se você estiver usando um nó offline que fornece serviços de dados, como git-server, pages-server ou storage-server, evacue o nó. Para obter mais informações, confira "Como evacuar um nó de cluster que executa serviços de dados".

  7. Para marcar o nó com falha offline, em qualquer nó, modifique o arquivo de configuração do cluster (cluster.conf) na seção de nó relevante para incluir o texto offline = true.

    Por exemplo, este cluster.conf modificado marcará o nó ghe-data-node-3 como offline:

    [cluster "ghe-data-node-3"]
    hostname = ghe-data-node-3
    offline = true
    ipv4 = 192.168.0.6
    # ipv6 = fd12:3456:789a:1::6
    
  8. No shell administrativo do nó em que você modificou cluster.conf, execute ghe-cluster-config-apply. Isso irá validar o arquivo de configuração, copiá-lo para cada nó do cluster e marcar o nó offline.

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

Nota: Se você estiver substituindo o nó primário do MySQL, consulte "Substituindo o nó primário do MySQL".

Para substituir um nó em uma emergência, instale o dispositivo do GitHub Enterprise Server em uma nova VM, configure um endereço IP, coloque o nó com falha offline, aplique a configuração, adicione o novo nó ao arquivo de configuração do cluster, inicialize o cluster, aplique a configuração e, opcionalmente, remova o nó com falha.

  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 marcar o nó com falha offline, em qualquer nó, modifique o arquivo de configuração do cluster (cluster.conf) na seção de nó relevante para incluir o texto offline = true.

    Por exemplo, este cluster.conf modificado marcará o nó ghe-data-node-3 como offline:

    [cluster "ghe-data-node-3"]
    hostname = ghe-data-node-3
    offline = true
    ipv4 = 192.168.0.6
    # ipv6 = fd12:3456:789a:1::6
    
  4. No shell administrativo do nó em que você modificou cluster.conf, execute ghe-cluster-config-apply. Isso irá validar o arquivo de configuração, copiá-lo para cada nó do cluster e marcar o nó offline.

  5. 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
      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 obter mais informações, confira "Adiar a propagação do banco de dados".

  6. Se você estiver substituindo o nó Redis principal no cluster.conf, modifique o redis-master valor ou pelo nome do nó de substituição.

    Nota: Se o nó Redis primário também for o nó principal do MySQL, consulte "Substituindo o nó primário do MySQL."

    Por exemplo, esse arquivo cluster.conf modificado especifica um nó de cluster recém-provisionado, ghe-replacement-data-node-1 como o nó do Redis principal:

    redis-master = ghe-replacement-data-node-1
    
  7. 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.

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

  9. Se você estiver usando um nó offline que fornece serviços de dados, como git-server, pages-server ou storage-server, evacue o nó. Para obter mais informações, confira "Como evacuar um nó de cluster que executa serviços de dados".

Substituir o nó MySQL primário

Para fornecer serviços de banco de dados, seu cluster requer um nó MySQL primário e pelo menos um nó MySQL secundário. Para obter mais informações, confira "Sobre nós de cluster".

Se quiser fornecer mais recursos à VM para seu nó MySQL primário ou se o nó falhar, você poderá substituí-lo. Para minimizar o tempo de inatividade, adicione o novo nó ao cluster, replique os dados do MySQL e promova o nó. É necessário algum tempo de inatividade durante a 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 obter mais informações, 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 mysql-server = true.
    • A seção a seguir é um exemplo, e a configuração do 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ó em que você modificou cluster.conf, execute ghe-cluster-config-apply. Isso irá validar o arquivo de configuração, copiá-lo para cada nó do cluster e marcar o nó offline.

  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 ghe-cluster-status -v.

    Pouco após adicionar o nó ao cluster, você poderá ver um erro no status da replicação enquanto a replicação é atualizada. A replicação pode levar horas, dependendo da carga da instância e da última vez que a instância gerou uma semente de banco de dados.

  9. Durante a janela de manutenção agendada, habilite o modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".

  10. Verifique se a replicação do MySQL foi concluída em qualquer nó do cluster, executando ghe-cluster-status -v.

    Aviso: se não esperar a replicação do MySQL terminar, você correrá o risco de perder dados em sua instância.

  11. Para definir o nó primário atual do MySQL para o modo somente leitura, execute o comando a seguir nos nós da instância.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql
    
  12. Aguarde até que os GTIDs (Identificadores de Transação Global) definidos nos nós primário e secundário do MySQL sejam idênticos. Para verificar os GTIDs, execute o comando a seguir em qualquer um dos nós da instância.

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    
  13. Depois que os GTIDs nos nós MySQL primário e secundário forem correspondentes, atualize a configuração do cluster abrindo o arquivo de configuração do cluster em /data/user/common/cluster.conf em um editor de texto.

    • Crie um backup do arquivo cluster.conf antes de editá-lo.
    • Na seção [cluster] de nível superior, remova o nome do host do nó que você substituiu do par de valores-chave mysql-master e atribua o novo nó. Se o novo nó também for um nó Redis primário, ajuste o par de valores-chave redis-master.
    [cluster]
      mysql-master = NEW-NODE-HOSTNAME
      redis-master = NEW-NODE-HOSTNAME
      primary-datacenter = primary
    ...
    
  14. No shell administrativo do nó em que você modificou cluster.conf, execute ghe-cluster-config-apply. Isso irá validar o arquivo de configuração, copiá-lo para cada nó do cluster e marcar o nó offline.

  15. Verifique o status da replicação MySQL por meio de qualquer nó no cluster, executando ghe-cluster-status -v.

  16. Se a replicação do MySQL for concluída, por meio de qualquer nó do cluster, desabilite o modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".