Sobre topologias de implantação para GitHub Enterprise Server
Você pode implantar as máquinas virtuais para uma GitHub Enterprise Server instância em topologias diferentes, dependendo do seu ambiente e das necessidades 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. GitHub trabalhará com você para determinar sua elegibilidade para clusterização. 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 HA, a escala do dispositivo depende exclusivamente do nó primário e a carga não é distribuída para o servidor de 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 Sobre o serviço de backup do GitHub Enterprise Server.
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.