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".
-
Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.
-
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.
-
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 arquivocluster.conf
modificado substituighe-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 obter mais informações, confira "Adiar a propagação do banco de dados".
-
No shell administrativo do nó com o
cluster.conf
modificado, executeghe-cluster-config-init
. Isto irá inicializar o nó recém-adicionado no cluster. -
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 arquivocluster.conf
modificado. -
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 obter mais informações, confira "Utilitários de linha de comando".
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, 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.
-
Para remover o nó que está enfrentando problemas do cluster, do nó MySQL primário do cluster, 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
no-evacuate
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 obter mais informações, confira "Utilitários de linha de comando". -
Adicione o nó de substituição ao cluster.
- Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.
-
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.
-
Para adicionar o nó de substituição recém-provisionado, em qualquer nó, modifique o arquivo
cluster.conf
para adicione o nó de substituição. Por exemplo, este arquivocluster.conf
modificado adiciona pelo nó recém-provisionadoghe-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
-
No shell administrativo do nó com o
cluster.conf
modificado, executeghe-cluster-config-init
. Isto irá inicializar o nó recém-adicionado no cluster.
-
-
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 arquivocluster.conf
modificado. -
Remova referências a serviços de dados no nó que você removeu.
-
Encontre o UUID do nó que você removeu. Para localizar o UUID, execute o seguinte comando, substituindo
HOSTNAME
pelo nome do host do nó. Você usará este UUID na próxima etapa.ghe-config cluster.HOSTNAME.uuid
-
Para remover referências a serviços de dados, execute os comandos a seguir. Substitua
UUID
pelo UUID do nó.Esses comandos indicam a cada serviço que o nó é removido permanentemente. Os serviços recriarão todas as réplicas contidas no nó nos nós disponíveis no cluster.
Nota: Esses comandos podem causar aumento de carga no servidor enquanto os dados são rebalanceados entre réplicas.
Para o serviço
git-server
(usado para dados do repositório):ghe-spokesctl server destroy git-server-UUID
Para o serviço
pages-server
(usado para criações de site GitHub Pages):ghe-dpages remove pages-server-UUID
Para o serviço
storage-server
(usado para dados Git LFS, arquivos de imagem de avatar, anexos de arquivos e arquivos de lançamento):ghe-storage destroy-host storage-server-UUID --force
-
-
Opcionalmente, exclua a entrada do nó removido no arquivo
cluster.conf
. Isso irá manter seu arquivocluster.conf
organizado e economizará tempo durante execuções futurasconfig-apply
.-
Para remover a entrada do arquivo, execute o seguinte comando, substituindo
HOSTNAME
pelo nome do host do nó removido.ghe-config --remove-section "cluster.HOSTNAME"
-
Para copiar a configuração para outros nós no cluster, a partir do shell administrativo do nó onde você modificou
cluster.conf
, executeghe-cluster-config-apply
.
-
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 de réplica. 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.
-
Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.
-
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.
-
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
ssh -p 122 admin@HOSTNAME
-
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 arquivocluster.conf
antes de editá-lo.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
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 ... ...
- Inclua o par de valores-chave
-
No shell administrativo do nó com o
cluster.conf
modificado, executeghe-cluster-config-init
. Isto irá inicializar o nó recém-adicionado no cluster. -
No shell administrativo do nó em que você modificou
cluster.conf
, executeghe-cluster-config-apply
. O nó adicionado recentemente se transformará em um nó MySQL de réplica e outros serviços configurados serão executados nesse nó. -
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. 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.
-
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".
-
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.
-
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
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
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 um dos nós da instância.
Shell ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
-
Depois que os GTIDs nos nós MySQL primário e de réplica estiverem iguais, atualize a configuração do cluster ao abrir o arquivo de configuração do cluster em
/data/user/common/cluster.conf
com 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-chavemysql-master
e atribua o novo nó. Se o novo nó também for um nó Redis primário, ajuste o par de valores-chaveredis-master
.
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- Crie um backup do arquivo
-
No shell de administração do nó no qual a modificação
cluster.conf
foi realizada, executeghe-cluster-config-apply
. Com isso, o cluster será reconfigurado para que o nó adicionado recentemente se torne o nó MySQL primário e o nó MySQL primário original se converta em um nó MySQL de réplica. -
Verifique o status da duplicação MySQL usando qualquer nó no cluster ao fazer a execução de
ghe-cluster-status -v
. -
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".