Nós principais dedicados no Amazon OpenSearch Service - Amazon OpenSearch Service

Nós principais dedicados no Amazon OpenSearch Service

O Amazon OpenSearch Service usa nós principais dedicados para aumentar a estabilidade do cluster. Um nó principal dedicado executa tarefas de gerenciamento de cluster, mas não mantém dados nem responde a solicitações de upload de dados. Essa transferência de tarefas de gerenciamento de cluster aumenta a estabilidade do seu domínio. Assim como todos os outros tipos de nó, você paga uma taxa por hora para cada nó principal dedicado.

Nós principais dedicados executam as seguintes tarefas de gerenciamento de cluster:

  • Rastreiam todos os nós no cluster.

  • Rastreiam o número de índices no cluster.

  • Rastreiam o número de fragmentos pertencentes a cada índice.

  • Mantêm informações de roteamento para nós no cluster.

  • Atualizam o estado do cluster após alterações de estado, como criação de um índice e adição ou remoção de nós no cluster.

  • Replicam alterações no estado do cluster em todos os nós no cluster.

  • Monitoram a integridade de todos os nós do cluster, enviando sinais de pulsação, sinais periódicos que monitoram a disponibilidade de nós de dados no cluster.

O exemplo a seguir mostra um domínio do OpenSearch Service com dez instâncias. Sete das instâncias são nós de dados e três são nós principais dedicados. Somente um dos nós principais dedicados está ativo. Os dois nós principais dedicados de cor cinza aguardam como backup em caso de falha do nó principal dedicado ativo. Todas as solicitações de carregamento de dados são atendidas por sete nós de dados, e todas as tarefas de gerenciamento de cluster são transferidas para o nó principal dedicado ativo.

Como escolher o número de nós principais dedicados

Recomenda-se adicionar três nós principais dedicados a cada domínio do OpenSearch Service de produção. Nunca escolha um número par de nós principais dedicados. Considere o seguinte ao escolher o número de nós principais dedicados:

  • Um nó principal dedicado é explicitamente proibido pelo OpenSearch Service porque você não terá backup em caso de falha. Você receberá uma exceção de validação se tentar criar um domínio com apenas um nó principal dedicado.

  • Se você tiver dois nós principais dedicados, seu cluster não terá o quorum necessário de nós para escolher um novo nó principal em caso de falha.

    Um quorum é o número de nós principais dedicados/2+1 (arredondado para o número inteiro mais próximo). Neste caso, 2/2 + 1 = 2. Como um nó principal dedicado falhou e existe apenas um backup, o cluster não tem um quorum e não pode selecionar um novo principal.

  • Três nós principais dedicados, o número recomendado, fornecem dois nós de backup em caso de falha de um nó principal e o quorum necessário (2) para selecionar um novo principal.

  • Ter quatro nós principais dedicados não é melhor do que ter três, e isso poderá causar problemas se você usar várias zonas de disponibilidade.

    • Se um nó principal falhar, você tem o quorum (3) para escolher um novo principal. Se dois nós falharem, você perderá esse quorum, da mesma forma com três nós principais dedicados.

    • Em uma configuração de três zonas de disponibilidade, duas AZs têm um nó principal dedicado e uma AZ tem dois. Se essa AZ sofrer uma interrupção, as duas AZs restantes não terão o quorum necessário (3) para escolher um novo principal.

  • Ter cinco nós principais dedicados funciona tão bem quanto ter três e permite que você perca dois nós enquanto mantém um quorum. No entanto, como apenas um nó principal dedicado está ativo a qualquer momento, essa configuração significa que você pagará por quatro nós ociosos. Muitos usuários acham esse nível de proteção de failover excessivo.

Se um cluster tiver um número par de nós qualificáveis para principais, o OpenSearch e o Elasticsearch versões 7.x e posterior ignorarão um nó para que a configuração de votação seja sempre um número ímpar. Nesse caso, quatro nós principais dedicados são essencialmente equivalentes a três (e dois a um).

nota

Se o cluster não tiver o quorum necessário para escolher um novo nó principal, ocorrerão falhas nas solicitações de gravação e leitura para o cluster. Esse comportamento é diferente do padrão do OpenSearch.

Escolher tipos de instâncias para nós principais dedicados

Embora os nós principais dedicados não processem solicitações de pesquisa e consulta, seu tamanho está amplamente correlacionado ao número de instâncias, índices e fragmentos que podem gerenciar. Para clusters de produção, recomendamos os seguintes tipos de instâncias para nós principais dedicados.

Essas recomendações se baseiam em workloads usuais e podem variar de acordo com suas necessidades. Clusters com muitos fragmentos ou mapeamentos de campo podem se beneficiar de tipos de instância maiores. Monitore as métricas do nó principal dedicado para ver se será necessário usar um tipo de instância maior.

Contagem de instâncias

Tamanho da RAM do nó principal Contagem máxima de fragmentos aceita

Mínimo recomendado de tipo de instância principal dedicada

1 – 10

8 GiB 10 mil

m5.large.search ou m6g.large.search

11 – 30

16 GiB 30 mil

c5.2xlarge.search ou c6g.2xlarge.search

37 – 75 32 GiB 40K

c5.4xlarge.search ou c6g.4xlarge.search

76 – 125 64 GiB 75 mil

r5.2xlarge.search ou r6g.2xlarge.search

126 – 200

128 GiB 75 mil

r5.4xlarge.search ou r6g.4xlarge.search