Informações sobre as topologias de implantação para GitHub Enterprise Server
Você pode implantar as máquinas virtuais para uma instância do GitHub Enterprise Server em diferentes topologias, dependendo das necessidades do seu ambiente e do usuário.
-
Para dar suporte a um plano de recuperação de desastre e backups complementares ou para melhorar o desempenho de rede e gravação para usuários distribuídos geograficamente, você pode configurar a alta disponibilidade. Em uma configuração de alta disponibilidade, um nó atua como primário, enquanto outros atuam como réplicas. Para saber mais, confira Sobre a configuração de alta disponibilidade.
-
Para fornecer escala horizontal para ambientes com dezenas de milhares de desenvolvedores, uma topologia de cluster está disponível. O clustering aborda situações em que um único nó primário experimentaria rotineiramente um esgotamento de recursos. Essa configuração requer um planejamento cuidadoso e sobrecarga administrativa adicional. A GitHub trabalhará com você para determinar sua qualificação para clustering. Para saber mais, confira Sobre agrupamento (clustering).
Cenários de falha
Tanto a alta disponibilidade (HA) quanto o clustering fornecem redundância por meio da eliminação de nós únicos como pontos de falha. Ambos podem fornecer disponibilidade nos seguintes cenários:
- Falha de software, devido a uma falha do sistema operacional ou a aplicativos irrecuperáveis.
- Falhas de hardware, incluindo hardware de armazenamento, CPU, RAM, adaptadores de rede etc.
- Falhas no sistema host de virtualização, incluindo eventos de manutenção não planejada e agendada na AWS, no Azure ou no GCP.
- Rede interrompida lógica ou fisicamente, se o dispositivo de failover estiver em uma rede separada não afetada pela falha.
Escalabilidade
O clustering fornece melhor escalabilidade distribuindo a carga em vários nós. Esta escala horizontal pode ser preferível para algumas organizações com dezenas de milhares de desenvolvedores. Na alta disponibilidade (HA), a dimensão do appliance depende exclusivamente do nó primário, e a carga não é distribuída para o servidor réplica.
Diferenças no método de failover e configuração
| Recurso | Configuração de failover | Método de failover |
|---|---|---|
| Configuração de alta disponibilidade | Registro DNS com TTL baixo, apontado para o dispositivo principal ou para o balanceador de carga. | É preciso promover manualmente o appliance réplica nas configurações de Load Balancer e failover de DNS. |
| Agrupamento | O registro de DNS deve apontar para um balanceador de carga. | Se um nó por trás do balanceador de carga falhar, o tráfego será automaticamente enviado para os outros nós em funcionamento. |
Backup e recuperação de desastre
Nem o clustering nem a HA devem ser considerados como substitutos para as medidas regulares de backup. Para saber mais, confira Como configurar backups em sua instância usando Utilitários de Backup.
Monitoramento
Recursos de disponibilidade, especialmente os que possuem failover automático, como o clustering, podem mascarar uma falha, já que o serviço geralmente não é interrompido quando ocorre uma falha. Seja qual for a opção em uso (HA ou cluster), é importante monitorar a integridade de cada instância para você se manter a par das possíveis falhas. Para saber mais sobre o monitoramento, confira Limites de alerta recomendados e Monitorar a saúde do cluster.