Arquitetura de clustering
O GitHub Enterprise Server é formado por um conjunto de serviços. Em um cluster, esses serviços são executados em vários nós e as solicitações são balanceadas por carga entre eles. As alterações são armazenadas automaticamente com cópias redundantes em nós separados. A maioria dos serviços são pares iguais com outras instâncias do mesmo serviço. As exceções são os serviços mysql-server e redis-server, que operam em um único nó primário com um ou mais nós réplica.
Saiba mais sobre os serviços necessários para os agrupamentos.
Clustering é a opção ideal para a minha organização?
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. No entanto, configurar um cluster redundante e dimensionável pode ser uma tarefa complexa e requer planejamento cuidadoso. A complexidade adicional deve ser planejada para a instalação, os cenários de recuperação de desastre e as atualizações.
O GitHub Enterprise Server requer baixa latência entre os nós e não foi feito para a redundância entre locais geográficos.
O clustering fornece redundância, mas não foi feito para substituir uma configuração de alta disponibilidade. Para obter mais informações, consulte Configuração de alta disponibilidade. A configuração de um failover primário/secundário é muito mais simples do que o clustering e funcionará perfeitamente para várias organizações. Para obter mais informações, consulte Diferenças entre clustering e alta disponibilidade.
Observação: GitHub Package Registry em GitHub Enterprise Server não é compatível com clustering atualmente.
Como faço para obter acesso ao clustering?
O clustering foi feito para situações específicas de dimensionamento e não se aplica a todas as organizações. Se você está pensando em usar o clustering, converse com seu representante exclusivo ou Equipe de Vendas do GitHub.