As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
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 quórum necessário de nós para escolher um novo nó principal em caso de falha.
Um quórum é 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 quórum 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 quórum 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 quórum (3) para escolher um novo principal. Se dois nós falharem, você perderá esse quórum, 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 esse AZ sofrer uma interrupção, os dois restantes AZs não terão o quórum necessário (3) para eleger um novo mestre.
-
-
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 quórum. 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 quórum 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
OpenSearch Cotas de domínio e instância do serviço
A tabela a seguir lista as cotas relacionadas aos domínios de OpenSearch serviço
| Nome | Padrão | Ajustável | Descrição |
|---|---|---|---|
| Instâncias mestre dedicadas por domínio | Cada região suportada: 3 ou 5 | Não |
O número máximo de instâncias mestras dedicadas em um único domínio do Amazon OpenSearch Service. |
| Domínios por região | Cada região suportada: 100 | Sim |
O número máximo de domínios do Amazon OpenSearch Service que você pode criar em cada AWS região. |
| Instância por domínio | Cada região suportada: 80 | Sim |
O número máximo de instâncias em um único domínio do Amazon OpenSearch Service. Você pode solicitar um aumento de até 1002 instâncias por domínio. |
| Instância por domínio (tipo de instância T2) | Cada região suportada: 10 | Sim |
O número máximo de instâncias T2 em um único domínio do Amazon OpenSearch Service. |
| Instâncias de alta atividade por domínio | Cada região suportada: 150 | Não |
O número máximo de nós quentes em um único domínio do Amazon OpenSearch Service. Você pode solicitar um aumento de até 750 instâncias por domínio. |
| Número de conexões entre clusters por domínio | 40 | Não | |
| Instância de coordenador dedicada por AZ | Cada região suportada: 200 | Sim |
O número deve estar entre 1 e 200. A contagem de nós coordenadores não pode exceder a contagem de nós de dados. |
| Armazenamento total por domínio | 25 LIBRAS | Não |
Esse máximo é a soma de todos os nós de dados e nós de alta atividade. Por exemplo, seu domínio pode ter 45 instâncias e 140 instâncias para um total de 2,88 PiB de armazenamento. Os novos limites são 10 PB para nós de dados e 15 PB para nós quentes. |
| Pacotes personalizados por região | 25 | Não | |
| Pacotes personalizados por domínio | 20 | Não |
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 |
RAMTamanho 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 |
|
|
11 – 30 |
16 GiB | 30 mil |
|
| 37 – 75 | 32 GiB | 40K |
|
| 76 – 125 | 64 GiB | 75 mil |
|
|
126 – 200 |
128 GiB | 75 mil |
|
-
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
.
