Sobre a observabilidade para alta disponibilidade
A fim de dar suporte a um plano de recuperação de desastre e complementar seus backups ou para melhorar o desempenho de rede e gravação de usuários distribuídos geograficamente, é possível configurar a alta disponibilidade no sua instância do GitHub Enterprise Server. Para saber mais, confira Sobre a configuração de alta disponibilidade.
Depois de configurar a alta disponibilidade, é possível garantir a redundância de maneira proativa, monitorando a integridade geral da replicação e o status de cada um dos nós de réplica da instância. É possível usar utilitários de linha de comando na instância, um dashboard de visão geral, a API REST da instância ou um sistema de monitoramento remoto, como o Nagios.
Com alta disponibilidade, a instância usa diversas abordagens para replicar dados entre nós primários e de réplica. Os serviços de banco de dados que dão suporte a um mecanismo de replicação nativo, como o MySQL, fazem a replicação usando o mecanismo nativo do serviço. Outros serviços, como repositórios Git, fazem a replicação usando um mecanismo personalizado desenvolvido para o GitHub Enterprise Server ou ferramentas de plataforma, como o rsync.
Monitorar a replicação na instância
Para monitorar o status de replicação de um nó de réplica existente no sua instância do GitHub Enterprise Server, conecte-se ao console administrativo do nó (SSH) e execute o utilitário de linha de comando ghe-repl-status. Para saber mais, confira Utilitários de linha de comando.
Também é possível monitorar o status da replicação no painel de visão geral da instância. Em um navegador, acesse a URL a seguir, substituindo HOSTNAME pelo nome do host da instância.
http(s)://HOSTNAME/setup/replication
Monitorar a replicação usando a API REST
É possível monitorar o status de replicação na instância usando a API REST. Para saber mais, confira Gerenciar o GitHub Enterprise Server na documentação da API REST.
Monitorar a replicação por meio de um sistema remoto
A saída do utilitário de linha de comando ghe-repl-status está em conformidade com as expectativas do plug-in check_by_ssh do Nagios. Para saber mais, confira Utilitários de linha de comando.
Além disso, é possível monitorar a disponibilidade da instância analisando o código de status retornado por uma solicitação para a URL a seguir. Por exemplo, ao implantar um balanceador de carga como parte de sua estratégia de failover, é possível configurar verificações de integridade que analisam essa saída. Para saber mais, confira Usar o GitHub Enterprise Server com balanceador de carga.
Dependendo de onde e como você configurar o monitoramento, substitua HOST pelo nome do host da instância ou pelo endereço IP de um nó individual.
http(s)://HOST/status
Um nó ativo para replicação geográfica, que pode responder às solicitações do usuário, retornará o código de status 200 (OK). As solicitações para nós individuais ou para o nome do host da instância podem retornar um erro 503 (Serviço indisponível) devido aos motivos a seguir.
- O nó individual é um nó de réplica passivo, como o nó de réplica em uma configuração de alta disponibilidade de dois nós.
- O nó individual faz parte de uma configuração de replicação geográfica, mas é um nó de réplica passivo.
- A instância está no modo de manutenção. Para saber mais, confira Habilitar e programar o modo de manutenção.
Para saber mais sobre a replicação geográfica, confira Sobre a replicação geográfica.
Solução de problemas de replicação
Para solucionar problemas de replicação na instância, verifique se a replicação está em execução e se os nós podem se comunicar uns com os outros pela rede. Também é possível usar utilitários de linha de comando para investigar a replicação incompleta.
A replicação não é executada
É necessário iniciar a replicação em cada nó usando o utilitário de linha de comando ghe-repl-start. Se a replicação não estiver em execução, conecte-se ao nó afetado via SSH e execute ghe-repl-start. Para saber mais, confira Utilitários de linha de comando.
Problemas de comunicação entre nós
A replicação requer que o nó primário e todos os nós de réplica possam se comunicar uns com os outros pela rede. No mínimo, verifique se as portas 122/TCP e 1194/UDP estão abertas para comunicação bidirecional entre todos os nós da instância. Para saber mais, confira Portas de rede.
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. Você pode usar o ping ou outro utilitário de administração de rede para testar a conectividade de rede entre nós.
Replicação incompleta
Quando você executa o utilitário de linha de comando ghe-repl-status em um nó de réplica e os repositórios Git, as redes de repositório ou os objetos de armazenamento apresentam uma replicação incompleta, isso significa que um ou mais nós de réplica não estão totalmente sincronizados com o nó primário. A replicação incompleta pode ocorrer quando o nó primário não consegue se comunicar com os nós de réplica ou vice-versa.
Se você configurou recentemente a alta disponibilidade ou a replicação geográfica, a sincronização inicial levará algum tempo. A duração da sincronização inicial depende da quantidade de dados existentes e das condições da rede.
- Repositórios ou redes de repositórios com replicação incompleta
- Objetos de armazenamento com replicação incompleta
Repositórios ou redes de repositórios com replicação incompleta
É possível exibir o status de replicação de um repositório específico conectando-se a um nó e executando os comados a seguir, substituindo OWNER pelo proprietário do repositório e REPOSITORY pelo nome do repositório.
ghe-spokesctl check OWNER/REPOSITORY
ghe-spokesctl info OWNER/REPOSITORY
Como alternativa, para exibir o status de replicação de uma rede de repositórios, substitua NETWORK-ID/REPOSITORY-ID pela ID da rede e pelo número de ID do repositório.
ghe-spokesctl check NETWORK-ID/REPOSITORY-ID
ghe-spokesctl info NETWORK-ID/REPOSITORY-ID
Objetos de armazenamento com replicação incompleta
É possível exibir o status de um objeto de armazenamento específico conectando-se a um nó e executando o comando a seguir, substituindo OID pela ID do objeto.
ghe-storage info OID
Obter suporte da GitHub
Se você revisar os conselhos de solução de problemas para replicação e continuar a ter problemas na sua instância, colete as seguintes informações e entre em contato conosco acessando o Suporte do GitHub Enterprise.
- Em cada nó afetado, execute
ghe-repl-status -vve copie a saída para o tíquete. Para saber mais, confira Utilitários de linha de comando. - Em cada nó afetado, crie um pacote de suporte para anexar ao tíquete. Para saber mais, confira Fornecer dados para o GitHub Support.