Nodes mestres dedicados no Amazon OpenSearch Service

O Amazon OpenSearch Service usa nós mestres 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 carregamento 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.

A ilustração a seguir mostra um domínio OpenSearch de serviço com 10 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

Recomendamos que você use o Multi-AZ com Standby, que adiciona três nós mestres dedicados a cada domínio do OpenSearch Serviço de produção. Se você implantar com multi-AZ sem modo de espera ou com single-AZ (uma única zona de disponibilidade), ainda recomendamos três nós principais dedicados. 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 Serviço porque você não tem backup no caso de uma 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 elegíveis como mestre, OpenSearch e as versões 7 do Elasticsearch. x e posteriores ignoram 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 OpenSearch padrão.

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 tamanho da instância e ao número de instâncias, índices e fragmentos que podem gerenciar. Para clusters de produção, recomendamos pelo menos 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	r5.xlarge.search ou r6g.xlarge.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

• Para obter informações sobre como determinadas alterações de configuração podem afetar os nós principais dedicados, consulte Fazendo alterações de configuração no Amazon OpenSearch Service.

• Para obter esclarecimentos sobre os limites de contagem de instâncias, consulte Domínio do OpenSearch serviço e cotas de instância.

• Para obter mais informações sobre tipos específicos de instâncias, incluindo vCPU, memória e preços, consulte os preços do Amazon OpenSearch Service.