Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Esta versão do GitHub Enterprise será descontinuada em Esta versão do GitHub Enterprise foi descontinuada em 2020-08-20. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

Versão do artigo: Enterprise Server 2.18

Sobre a replicação geográfica

A replicação geográfica no GitHub Enterprise Server usa várias réplicas ativas para atender às solicitações de datacenters distribuídos geograficamente.

Neste artigo

Usar várias réplicas ativas diminui a distância até a réplica mais próxima. Por exemplo, uma organização com escritórios em San Francisco, Nova York e Londres pode executar o appliance primário em um datacenter próximo a Nova York e duas réplicas em datacenters próximos a San Francisco e Londres. Ao usar um DNS compatível com localização geográfica, os usuários podem ser direcionados para o servidor mais próximo disponível e acessar os dados do repositório em menos tempo. Definir o appliance próximo a Nova York como o primário ajuda a reduzir a latência entre os hosts, em comparação a definir o appliance próximo a San Francisco como o principal, que tem maior latência para Londres.

Os proxies de réplica ativos informam que não podem processar a si mesmos para a instância principal. As réplicas funcionam como ponto de presença, encerrando todas as conexões SSL. O tráfego entre hosts é enviado por meio de uma conexão VPN criptografada, semelhante a uma configuração de alta disponibilidade de dois nós sem replicação geográfica.

As solicitações do Git e as solicitações específicas do servidor de arquivos, como LFS e uploads de arquivos, podem ser atendidas diretamente na réplica, sem carregar dados do servidor principal. As solicitações da web são sempre roteadas para o servidor principal. No entanto, se a réplica estiver mais próxima do usuário, as solicitações serão mais rápidas devido ao SSL mais próximo.

É necessário ter um DNS de localização geográfica, como o Amazon Route 53, para garantir o bom funcionamento da replicação geográfica. O nome de host da instância deve ser resolvido na réplica mais próxima do local do usuário.

Limitações

As solicitações de gravação para a réplica exigem o envio dos dados para o servidor principal e todas as réplicas. Ou seja, o desempenho de todas as gravações fica limitado pela réplica mais lenta , embora as novas réplicas geográficas possam propagar a maioria de seus dados das réplicas geográficas localizadas existentes, em vez de propagar a partir do principal . A replicação geográfica não aumentará a capacidade de uma instância do GitHub Enterprise Server nem resolverá problemas de desempenho relacionados a CPU ou recursos de memória insuficientes. Se o appliance primário estiver offline, as réplicas ativas não poderão atender a solicitações de leitura ou gravação.

Monitorar a configuração da replicação geográfica

Você pode monitorar a disponibilidade de GitHub Enterprise Server verificando o código de status que é retornado para a URL https://HOSTNAME/status. Um appliance que possa atender o tráfego do usuário retornará o código de status 200 (OK). Um appliance pode devolver 503 (Serviço Indisponível) por alguns motivos:

  • O appliance é uma réplica passiva, como a réplica em uma configuração de alta disponibilidade de dois nós.
  • O appliance está no modo de manutenção.
  • O appliance é parte de uma configuração de geo-replicação, mas é uma réplica inativa.

Você também pode usar o painel de visualização de réplica disponível em:

https://HOSTNAME/setup/replication

Leia mais

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato