Configurando a replicação entre clusters do Elasticsearch para alta disponibilidade

Sobre a Replicação Entre Clusters do Elasticsearch

GitHub Enterprise Server usa o Elasticsearch para alimentar a pesquisa em problemas, solicitações de pull, repositórios, páginas de projetos e versões e as contagens mostradas em toda a interface da Web. Como a pesquisa é central para o produto, a confiabilidade do Elasticsearch afeta diretamente a administração diária de sua instância.

Em uma configuração de alta disponibilidade (HA), GitHub Enterprise Server usa um modelo de líder/seguidor. O equipamento primário recebe todas as operações de gravação e o tráfego, e os equipamentos de réplica permanecem sincronizados como instâncias de espera somente leitura que podem assumir o controle se o primário falhar. Para obter mais informações, consulte Sobre a configuração de alta disponibilidade.

Em versões anteriores, o Elasticsearch não deu suporte diretamente a esse modelo de líder/seguidor. Para replicar os dados de busca, GitHub Enterprise Server operava um único cluster do Elasticsearch que abrangia os dispositivos primário e de réplica. Essa abordagem funcionou, mas introduziu uma classe de problemas: o Elasticsearch poderia mover um fragmento primário (o fragmento responsável por receber e validar gravações) em um dispositivo de réplica. Se essa réplica tiver sido então retirada offline para manutenção, a instância poderá entrar em um estado bloqueado, pois a réplica esperou que o Elasticsearch ficasse íntegro enquanto o Elasticsearch não pudesse ficar íntegro até que a réplica voltasse.

A CCR (Replicação Entre Clusters) do Elasticsearch remove essa dependência. Em vez de um único cluster abranger todos os dispositivos, cada dispositivo funciona como um cluster Elasticsearch independente de nó único. O CCR replica os dados de índice entre esses clusters usando um padrão de líder/seguidor com suporte nativo. Os dados são copiados somente após terem sido persistidos de forma durável nos segmentos subjacentes do Lucene, portanto as réplicas sempre acompanham os dados que foram gravados com segurança. Como resultado, um fragmento primário crítico não pode mais acabar encalhado em uma réplica somente leitura.

Benefits

Menos upgrades bloqueados e janelas de manutenção. Remover a dependência circular entre os dispositivos primários e de réplica durante a manutenção reduz o risco de uma instância ficar paralisada.
Proteção de dados mais forte. Os dados são replicados somente depois que são salvos de maneira durável, o que ajuda a evitar a corrupção de índice durante failovers.
Operações mais simples. O padrão reduz a necessidade de reparos manuais nos índices, que antes eram necessários quando as etapas de manutenção eram executadas fora de ordem.

Availability

O CCR do Elasticsearch tem suporte a partir da GitHub Enterprise Server 3.19.1. O recurso é opcional. GitHub planeja tornar a CCR a arquitetura de pesquisa de HA padrão nos dois anos seguintes, portanto, você tem tempo para testá-la e fornecer comentários antes que ela se torne o padrão.

Requirements

Antes de habilitar o CCR, confirme o seguinte.

Sua instância executa a versão GitHub Enterprise Server 3.19.1 ou posterior.
Sua instância está configurada para alta disponibilidade com pelo menos dois dispositivos (um primário e uma ou mais réplicas).
Você tem uma licença GitHub Enterprise Server atualizada que inclui a permissão do Elasticsearch necessária para o CCR. Entre em contato com Equipe de vendas do GitHub ou Suporte do GitHub para habilitar sua empresa para a nova licença e, em seguida, baixe o arquivo de licença atualizado.

Aviso: Quando o CCR estiver habilitado, a verificação pré-voo da atualização requer uma licença válida com suporte a CCR. Se o sinalizador estiver habilitado e a verificação de licença falhar, a atualização não prosseguirá. Verifique se sua licença atualizada está instalada antes de habilitar o recurso ou a atualização. Se você não tiver certeza se sua licença inclui o direito de uso do Elasticsearch, entre em contato com Suporte do GitHub.

Habilitando a replicação entre clusters do Elasticsearch

Observação: A migração pode levar um tempo significativo dependendo do tamanho da instância, pois os dados de pesquisa são consolidados no primário antes da replicação ser reiniciada. Planeje habilitar o CCR durante uma janela de manutenção e teste o processo em um ambiente de não produção primeiro. Para obter mais informações, consulte ** Realizando a atualização da sua instância.

Entre em contato com Suporte do GitHub e solicite acesso à nova arquitetura de pesquisa de HA. GitHub permitirá que sua empresa baixe a licença necessária com CCR habilitado.
Baixe sua licença atualizada e carregue-a em sua instância. Para obter mais informações, consulte Baixando sua licença para GitHub Enterprise.
No dispositivo primário, habilite o recurso.
```
ghe-config app.elasticsearch.ccr true
```
Aplique a configuração executando uma execução de configuração ou atualizando a instância para 3.19.1 ou posterior.
```
ghe-config-apply
```
Quando a instância é reiniciada, o Elasticsearch migra a instalação para o novo método de replicação. Essa migração consolida os dados de pesquisa no primário, encerra o cluster que previamente abrange dispositivos e reinicia a replicação usando CCR. Durante a migração, GitHub Enterprise Server anexa seguidores aos índices de pesquisa existentes e habilita uma regra de acompanhamento automático para que todos os índices criados no futuro sejam seguidos automaticamente.

Usando a Replicação Entre Clusters do Elasticsearch

Verificando a replicação

Após a conclusão da migração, a pesquisa continua funcionando normalmente e nenhuma alteração é necessária na forma como os usuários pesquisam. Para confirmar a saúde da replicação, gere um pacote de suporte, que inclui informações sobre o status do CCR para revisão. Para obter mais informações, consulte Fornecendo dados para GitHub suporte.

Failover e recuperação de desastre

Você continua a usar os utilitários de replicação de alta disponibilidade padrão para gerenciar réplicas e fazer failover. Para obter mais informações, consulte Iniciar failover do appliance réplica e Recuperar configuração de alta disponibilidade.

Após um failover com o CCR habilitado, o appliance promovido se torna o novo líder das pesquisas, e as réplicas voltam a seguir seus índices como parte do processo padrão de recuperação. Se você encontrar erros relacionados à replicação de pesquisa durante ou após um failover, entre em contato Suporte do GitHub.

Desabilitando a replicação entre clusters do Elasticsearch

Aviso: Não desabilite o CCR em uma instância de produção sem diretrizes de Suporte do GitHub. Desabilitar o CCR não é uma operação de autoatendimento de rotina. Desativar o recurso pode acionar a remoção de dados de réplica do Elasticsearch como parte da volta ao modo anterior.

Se você precisar retornar à arquitetura de pesquisa anterior, entre em contato Suporte do GitHub antes de fazer alterações. GitHub ajudará você a confirmar se sua licença, o estado de replicação e o caminho de atualização são tratados com segurança.