Durabilidade da Busca em GHES com CCR

Introdução: A Essência da Busca no GitHub Enterprise Server

A funcionalidade de busca é fundamental para a experiência no GitHub, estendendo-se além das barras de pesquisa para incluir páginas de Issues, Releases, Projects e contadores de Pull Requests. Dada essa importância, a AITY, como parceira e especialista em soluções de infraestrutura, entende que a durabilidade da busca no GitHub Enterprise Server (GHES) é crucial para nossos clientes. Nosso foco está em garantir que a gestão do GHES consuma menos tempo, permitindo que as equipes se concentrem no que realmente agrega valor aos seus clientes.

Historicamente, administradores de GHES, especialmente em configurações de Alta Disponibilidade (HA), enfrentavam desafios significativos com os índices de busca. Erros na sequência de manutenção ou atualização poderiam danificar os índices, exigir reparos ou travá-los, causando problemas durante upgrades.

Desafios Históricos com Elasticsearch e Alta Disponibilidade

Em configurações de HA, o GHES opera com um nó primário que lida com todas as escritas e tráfego, e nós de réplica que permanecem sincronizados e podem assumir em caso de falha. A dificuldade surgia da integração de versões anteriores do Elasticsearch, nosso banco de dados de busca.

• Padrão Líder/Seguidor (Leader/Follower): As instalações HA do GHES utilizam um padrão líder/seguidor, onde o servidor primário (líder) recebe todas as escritas e atualizações, e as réplicas (seguidores) são projetadas para serem somente leitura.
• Limitação do Elasticsearch: Como o Elasticsearch, em suas versões anteriores, não suportava nativamente um nó primário e um nó de réplica dentro do seu próprio cluster de maneira compatível com o padrão do GHES, a engenharia do GitHub precisou criar um cluster Elasticsearch abrangendo os nós primário e de réplica.
• Consequências do Cluster Distribuído:
  • Facilitou a replicação de dados.
  • Ofereceu benefícios de desempenho, pois cada nó podia lidar localmente com as requisições de busca.
  • No entanto, os problemas superaram os benefícios:
    • Elasticsearch poderia mover um primary shard (responsável por escritas) para uma réplica.
    • Se essa réplica fosse desligada para manutenção, o GHES poderia entrar em um estado de bloqueio, esperando pelo Elasticsearch saudável, que por sua vez, não se tornaria saudável sem a réplica.

Por anos, tentou-se estabilizar este modo, implementando verificações de saúde do Elasticsearch e processos para corrigir estados instáveis, chegando a desenvolver um sistema de "espelhamento de busca". Contudo, a replicação de bancos de dados é complexa e exigia consistência.

A Virada: Cross Cluster Replication (CCR) do Elasticsearch

A solução para esses desafios veio com a adoção do recurso Cross Cluster Replication (CCR) do Elasticsearch para suportar o HA do GitHub Enterprise.

• Nova Arquitetura: O GHES está migrando para o uso de vários "clusters de nó único" do Elasticsearch. Isso significa que cada instância do servidor Enterprise operará como clusters Elasticsearch independentes de nó único.
• Replicação Controlada: O CCR permite o compartilhamento de dados de índice entre os nós de forma cuidadosamente controlada e nativamente suportada pelo Elasticsearch.
• Durabilidade de Dados: A replicação ocorre após os dados serem persistidos nos Lucene segments (o armazenamento de dados subjacente do Elasticsearch), garantindo que os dados replicados sejam duravelmente persistidos.
• Resolução do Problema Líder/Seguidor: Com o suporte nativo do Elasticsearch a um padrão líder/seguidor, os administradores do GHES não se encontrarão mais em estados onde dados críticos acabam em nós somente leitura.

Mecanismo Interno do CCR

A implementação do CCR no GHES envolve fluxos de trabalho personalizados, pois o Elasticsearch's auto-follow API se aplica apenas a índices criados após a política existir. Instalações HA do GHES possuem índices de longa duração, exigindo um passo de bootstrap.

• Processo de Bootstrap: Anexa seguidores a índices existentes e então habilita o auto-follow para índices futuros.

function bootstrap_ccr(primary, replica):
    # Fetch the current indexes on each
    primary_indexes = list_indexes(primary)
    replica_indexes = list_indexes(replica)

    # Filter out the system indexes
    managed = filter(primary_indexes, is_managed_ghe_index)

    # For indexes without follower patterns we need to
    # initialize that contract
    for index in managed:
        if index not in replica_indexes:
            ensure_follower_index(replica, leader=primary, index=index)
        else:
            ensure_following(replica, leader=primary, index=index)

    # Finally we will setup auto-follower patterns
    # so new indexes are automatically followed
    ensure_auto_follow_policy(
        replica,
        leader=primary,
        patterns=[managed_index_patterns],
        exclude=[system_index_patterns]
    )

Este é apenas um dos novos fluxos de trabalho criados. O GitHub também desenvolveu lógicas personalizadas para failover, exclusão de índices e upgrades, pois o Elasticsearch lida apenas com a replicação de documentos, sendo o restante do ciclo de vida do índice responsabilidade da plataforma.

Como Começar com o Modo CCR

Para usufruir do novo modo CCR, siga os passos abaixo:

• Contato com o Suporte: Entre em contato com support@github.com e solicite a habilitação do novo modo HA para GitHub Enterprise Server. Eles configurarão sua organização para que você possa baixar a licença necessária.
• Configuração: Após baixar a nova licença, defina ghe-config app.elasticsearch.ccr true.
• Atualização: Execute um config-apply ou um upgrade para a versão 3.19.1 do GHES (a primeira a suportar esta nova arquitetura).
• Migração: Durante o restart do GitHub Enterprise Server, o Elasticsearch migrará sua instalação para usar o novo método de replicação, consolidando dados em nós primários, quebrando o clustering entre nós e reiniciando a replicação via CCR. Este processo pode levar tempo dependendo do tamanho da sua instância.

Embora o novo método HA seja opcional por enquanto, ele será o padrão nos próximos dois anos. Este período permite que os administradores forneçam feedback valioso, tornando este o momento ideal para experimentá-lo.

Impacto Prático e Futuro

A adoção do Cross Cluster Replication do Elasticsearch representa um avanço significativo para a durabilidade e estabilidade da busca no GitHub Enterprise Server. Para administradores, isso significa menos tempo gasto com gerenciamento de índices, diagnósticos de problemas de HA e manutenções complexas. A AITY está entusiasmada com o potencial de uma experiência de gerenciamento mais fluida, permitindo que nossas equipes e clientes foquem na inovação e no desenvolvimento de produtos, em vez de na manutenção de infraestrutura. A busca mais robusta e confiável diretamente impacta a produtividade e a satisfação do usuário.

Quer maximizar a eficiência da busca em seu ambiente GitHub Enterprise Server de Alta Disponibilidade? Entre em contato com o suporte para configurar nossa nova arquitetura de busca e liberte o potencial de sua equipe!