Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para acessar as informações mais atualizadas, visite a Documentação em inglês.
� 

� 

Esta versão do GitHub Enterprise foi descontinuada em 2022-10-12. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Configurar o agrupamento

Saiba mais sobre clustering e diferenças com alta disponibilidade.

  • Sobre clustering

    Com o clustering do GitHub Enterprise Server, os servi�os que comp�em o GitHub Enterprise Server podem ser dimensionados em v�rios n�s.

  • Diferenças entre agrupamento e alta disponibilidade (HA)

    A configura��o de alta disponibilidade do GitHub Enterprise Server � uma configura��o de failover prim�rio/secund�rio que fornece redund�ncia, enquanto o cluster fornece redund�ncia e dimensionamento distribuindo a carga de leitura e grava��o em v�rios n�s.

  • Sobre nós de cluster

    N�s s�o inst�ncias do GitHub Enterprise Server que operam em um cluster. Cada n� executa um conjunto de servi�os fornecidos para o cluster e, consequentemente, para os usu�rios.

  • Configuração de rede de cluster

    O funcionamento correto do clustering do GitHub Enterprise Server depende da resolu��o adequada de nome DNS, do balanceamento de carga e da comunica��o entre os n�s.

  • Inicializar o cluster

    Um cluster do GitHub Enterprise Server deve ser configurado com uma licen�a e inicializado usando o shell administrativo (SSH).

  • Atualizar o cluster

    Use o shell administrativo (SSH) para atualizar o cluster do GitHub Enterprise Server para a vers�o mais recente.

  • Monitorar nós de cluster

    Um cluster do GitHub Enterprise Server � formado por servi�os redundantes distribu�dos em dois ou mais n�s. Em caso de falha de um servi�o ou de um n� inteiro, a falha n�o ser� aparente de imediato para os usu�rios do cluster. No entanto, como o desempenho e a redund�ncia s�o afetados, � importante monitorar a integridade de um cluster do GitHub Enterprise Server.

  • Substituir um nó de cluster

    Para substituir um n� do GitHub Enterprise Server, voc� dever� marcar os n�s afetados offline no arquivo de configura��o do cluster (cluster.conf) e adicionar os n�s de substitui��o. Fazer isso pode ser necess�rio em caso de falha de algum n� ou para adicionar n�s com mais recursos a fim de melhorar o desempenho.

  • Remover um nó de cluster

    � poss�vel remover servi�os de dados em um n� do cluster.

  • Configurar alta disponibilidade de replicação de um cluster

    Voc� pode configurar uma r�plica passiva de todo o seu cluster de GitHub Enterprise Server em um local diferente, permitindo que o seu cluster falhe em n�s redundantes.

  • Iniciar uma failover no seu cluster de réplicas

    Se seu cluster de GitHub Enterprise Server falhar, voc� poder� gerar uma falha na r�plica passiva.