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.
O DNS geográfico, como o serviço Rota 53 da Amazon, é necessário para que a replicação geográfica funcione perfeitamente. 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. Isso significa que o desempenho de todas as gravações é limitado pela réplica mais lenta, embora novas georréplicas possam semear a maioria de seus dados a partir de georréplicas colocalizadas existentes, ao invés das primárias.
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. Para reduzir a latência e a largura de banda causadas por equipes distribuídas e grandes fazendas de CI, sem afetar a taxa de gravação, você pode configurar o armazenamento em cache de repositório. Para saber mais, confira Sobre o cache do repositório.
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.
Note
Há um máximo de oito réplicas de alta disponibilidade (réplicas passivas e ativas e geográficas, bem como instâncias de cache do repositório) permitidas para o GitHub Enterprise Server.
Monitorar a configuração da replicação geográfica
Você pode monitorar a disponibilidade do GitHub Enterprise Server verificando o código de status retornado para a URL https://HOSTNAME/status. Um dispositivo que pode atender ao tráfego do usuário retornará o código de status 200 (OK). Um dispositivo pode retornar 503 (Serviço Indisponível) para essa URL e outras solicitações da Web ou de API 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