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 painel de visão geral, 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 obter mais informações, 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 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 obter mais informações, 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 obter mais informações, 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 obter mais informações, 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 obter mais informações, 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 obter mais informações, 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 o comando a seguir, substituindo OWNER pelo proprietário do repositório e REPOSITORY pelo nome do repositório.
ghe-spokes diagnose 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-spokes diagnose 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 -vv
e copie a saída para o tíquete. Para obter mais informações, confira "Utilitários de linha de comando". - Em cada nó afetado, crie um pacote de suporte para anexar ao tíquete. Para obter mais informações, confira "Fornecer dados para o GitHub Support".