Tipos e recursos de réplica
Quais são os tipos de réplicas usadas em uma implantação de HA?
Há três tipos de réplicas em uma implantação de alta disponibilidade (HA):
-
Réplicas passivas
-
Réplica ativa
-
Réplicas de cache (conhecidas como caches de repositório).
**As réplicas passivas** simplesmente sincronizam dados da instância primária e não lidam com nenhum tráfego GitHub . No entanto, os operadores podem promover uma réplica passiva para primária caso seja necessário.
Uma réplica geográfica é um exemplo de uma réplica ativa (esses termos geralmente são usados de forma intercambiável). As réplicas ativas sincronizam os dados do primário. Uma réplica ativa também pode processar diretamente o tráfego do GitHub ou encaminhá-los para o primário.
**As réplicas de cache** sincronizam os dados do Git e o Armazenamento de Arquivos Grande do Git (LFS do Git na sigla em inglês) do primário. As réplicas de cache são feitas para cenários de leitura pesada, como farms de CI. Eles só aceitam leituras/buscas/clones para repositórios dos quais têm uma cópia local. Para quaisquer outros repositórios, eles retornarão um erro. Eles sempre rejeitam envios com uma mensagem de erro.
Todos os tipos de réplica podem ser promovidos a primário?
Somente réplicas passivas e ativas podem ser promovidas a primário. As réplicas de cache não podem ser promovidas a primário.
Uma única implantação pode ter todas as réplicas?
Uma única implantação pode incluir réplicas ativas, réplicas passivas e réplicas de cache de uma só vez.
A instância primária aguarda réplicas antes de concluir as gravações?
A instância primária não aguarda réplicas antes de concluir as gravações. Na HA, um push é gravado no primário, bem como em todas as réplicas passivas e ativas. No entanto, como o nó primário é o único nó de votação, o push é considerado aceito quando executado nos primários.
Requisitos de comunicação e rede
Quais entidades podem se comunicar com réplicas ativas?
A instância primária se comunica com réplicas ativas para sincronizar os dados e lidar com qualquer solicitação que as réplicas ativas façam ao primário como proxy. GitHub tráfego da Web, API e Git (de humanos e automação) pode ser roteado diretamente para réplicas ativas. É por isso que é importante configurar o DNS para que o tráfego destinado a uma réplica ativa realmente o atinja.
Quais entidades podem se comunicar com réplicas passivas?
A instância primária se comunica com réplicas passivas para sincronizar dados. As réplicas passivas não recebem nem processam nenhum outro tráfego GitHub .
Quais entidades podem se comunicar com réplicas de cache?
O tráfego Git em modo somente-leitura, principalmente proveniente de automações, como farms de CI, pode ser direcionado e processado por réplicas de cache. Para habilitar isso, você deve configurar o DNS para direcionar o tráfego relevante para a réplica de cache. As réplicas de cache não foram criadas para atender ao tráfego do usuário ou enviar o tráfego por push.
As réplicas devem estar localizadas junto com a primária?
Não há nenhum requisito para que as réplicas sejam localizadas junto ao primário. Por definição, uma réplica geográfica está geograficamente distante do primário e não no mesmo data center. As réplicas de cache também não têm requisitos de co-localização.
No entanto, é recomendável que pelo menos uma réplica passiva seja co-localizada com a primária no mesmo data center para failover mais rápido durante uma interrupção primária. No caso de uma interrupção completa do data center, você pode promover uma réplica passiva distribuída geograficamente.
Quais são os requisitos de latência entre o primário e as réplicas?
Réplicas primárias e ativas têm requisitos de latência estritos. Réplicas primárias e passivas, bem como réplicas primárias e de cache, têm requisitos de latência recomendados. Para saber mais, confira Criar réplica de alta disponibilidade e Monitorar uma configuração de alta disponibilidade. Latências de rede além dos valores necessários e recomendados podem fazer com que as réplicas fiquem para trás constantemente.
Acesso administrativo e monitoramento
O Console de Gerenciamento está disponível em réplicas?
O Console de Gerenciamento não está disponível em réplicas passivas ou de memória cache. Ele está disponível apenas em réplicas ativas (elas encaminham a maioria das solicitações para o primário).
É possível usar o SSH em réplicas?
Um operador com acesso de shell administrativo pode usar SSH para acessar qualquer uma das réplicas. Os operadores podem adicionar suas chaves públicas à nova réplica por meio do Console de Gerenciamento antes que a réplica seja adicionada ao cluster. Para saber mais, confira Acessar o shell administrativo (SSH).
Como os pacotes de suporte funcionam para réplicas?
Você pode gerar um pacote de cluster ou um pacote específico do nó. Um pacote de cluster inclui pacotes de todos os nós na implantação de HA, enquanto um pacote específico de nó contém dados de apenas um nó.
As réplicas podem ser monitoradas e como?
Todas as réplicas podem ser monitoradas. O Console de Gerenciamento na instância primária fornece painéis para todos os nós, incluindo os de réplica passivos e ativos na implantação.
Além disso, você pode exportar métricas e logs de todos os nós de uma implantação para plataformas de monitoramento de terceiros.
Para saber como monitorar o status da replicação de dados entre nós de réplica, consulte Monitorar uma configuração de alta disponibilidade.
Diferença entre réplicas e backups
Réplicas e backups são iguais?
Réplicas e backups não são os mesmos. Eles servem a propósitos diferentes.
Os backups são utilizados para criar cópias de seus dados, que podem ser restauradas em outro ambiente GitHub Enterprise Server. Os clientes geralmente usam backups para se recuperar de desastres ou criar novas instalações. Em suma, os dados de backup são usados para restaurar outra instância GitHub Enterprise Server, enquanto as réplicas são projetadas para alta disponibilidade e redundância em tempo real.
As réplicas em si são instâncias GitHub Enterprise Server. O host de backup não é uma instalação de GitHub Enterprise Server.
Qual software está sendo executado em réplicas?
As réplicas são uma instalação independente do GitHub Enterprise Server. A instância primária e todas as réplicas devem estar executando a mesma versão do GitHub Enterprise Server.
Operações de manutenção
Qual é a sequência recomendada de operações para atualizações?
- Inicie a janela de manutenção no primário e em todas as réplicas.
- Pare a replicação em todas as réplicas.
- Atualize o primário para a versão de destino.
- Atualize as réplicas para a mesma versão de destino. Todas as réplicas podem ser atualizadas em paralelo.
- Depois que todas as atualizações forem concluídas, reinicie o processo de replicação.
- Feche a janela de manutenção.
Às vezes, os clientes podem querer adiar a atualização das réplicas para um momento posterior. Nesse caso, remova o nó de réplica da implantação e converta-o em um nó autônomo. Atualize-a para a mesma versão que a primária e, em seguida, adicione-a de volta à implantação.
Qual é a sequência recomendada de operações para hotpatching?
O patch dinâmico pode ser executado com interrupção mínima. Você pode fazer o hotpatch do servidor primário primeiro e, em seguida, dos servidores réplicas.
Escolhendo o tipo de réplica correto
Quando usar réplicas passivas?
Se você precisar de alta disponibilidade e quiser que uma instância atualizada realize failover caso o primário falhe, as réplicas passivas serão a melhor opção. A maioria dos nossos clientes usa réplicas passivas.
Quando usar réplicas geográficas?
Se você tiver uma força de trabalho de desenvolvedor distribuída geograficamente, a configuração de réplicas geográficas poderá ajudar os usuários em regiões específicas. Por exemplo, imagine uma empresa multinacional com equipes de engenharia na América do Norte, Europa e Ásia. Se a instância primária estiver localizada nos EUA, a implantação de uma réplica geográfica na Europa poderá melhorar significativamente o desempenho das operações de leitura para usuários europeus. No entanto, o mesmo não pode ser dito para operações de escrita. Todas as gravações devem ser confirmadas nas réplicas geográficas e no primário antes da conclusão da operação. A distância geográfica entre o primário e as réplicas aumenta a latência, o que pode reduzir as operações de gravação.
Quando usar réplicas de cache?
Se seus casos de uso forem intensivos em leitura, como farms de CI, as réplicas de cache serão mais adequadas. Aqui estão alguns cenários em que as réplicas de cache fazem sentido:
- Uma empresa com um pequeno escritório satélite em uma região com largura de banda limitada para o data center principal, onde os desenvolvedores precisam de acesso mais rápido a repositórios, mas não exigem acesso de gravação.
- Uma organização que executa trabalhos de CI/CD em um data center remoto que precisa clonar repositórios com frequência e deseja minimizar o tráfego de rede para a instância primária.
As réplicas de cache vêm com compensações. As réplicas de cache são consistentes e nem sempre fornecem o conteúdo mais recente do repositório. No entanto, há webhooks para quando as alterações mais recentes chegam à réplica, permitindo que os trabalhos de CI/CD relevantes sejam iniciados. Muito poucos clientes GitHub usam réplicas de cache.