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-01-22. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

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

You can monitor the availability of GitHub Enterprise Server by checking the status code that is returned for the https://HOSTNAME/status URL. An appliance that can service user traffic will return status code 200 (OK). An appliance may return a 503 (Service Unavailable) for a few reasons:

  • The appliance is a passive replica, such as the replica in a two-node high availability configuration.
  • The appliance is in maintenance mode.
  • The appliance is part of a geo-replication configuration, but is an inactive replica.

You can also use the Replication overview dashboard available at:

https://HOSTNAME/setup/replication

Leia mais

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato