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á.
Depois de calcular os requisitos de armazenamento e escolher o número de fragmentos de que precisa, você pode começar a tomar decisões quanto ao hardware. Os requisitos de hardware variam drasticamente por workload, mas ainda podemos fazer algumas recomendações básicas.
Em geral, os limites de armazenamento para cada tipo de instância são mapeados para a quantidade de CPU e memória que pode ser necessária para workloads leves. Por exemplo, uma instância m6g.large.search tem um tamanho máximo de volume do EBS de 512 GiB, 2 núcleos de vCPUs e 8 GiB de memória. Se o seu cluster tiver muitos fragmentos, executar agregações desgastantes, atualizar os documentos com frequência ou processar um grande número de consultas, esses recursos poderão ser insuficientes para suas necessidades. Se o cluster estiver em uma dessas categorias, tente começar com uma configuração mais próxima de dois núcleos de vCPU e 8 GiB de memória para cada 100 GiB de seu requisito de armazenamento.
dica
Para obter um resumo dos recursos de hardware que são alocados para cada tipo de instância, consulte os preços do Amazon OpenSearch Service
No entanto, até mesmo esses recursos podem ser insuficientes. Alguns OpenSearch usuários relatam que muitas vezes precisam desses recursos para atender às suas necessidades. Para localizar o hardware certo para sua workload, é necessário fazer uma estimativa inicial embasada, testar workloads representativas, ajustar e testar novamente.
Etapa 1: Fazer uma estimativa inicial
Para começar, recomendamos um mínimo de três nós para evitar possíveis OpenSearch problemas, como um estado cerebral dividido (quando um lapso na comunicação leva a um cluster com dois nós gerenciadores). Se você tiver três nós gerenciadores dedicados, ainda recomendamos um mínimo de dois nós de dados para replicação.
Etapa 2: Calcular os requisitos de armazenamento por nó
Se você tiver um requisito de 184 GiB de armazenamento e o número mínimo recomendado for de três nós, use a equação 184/3 = 61 GiB para determinar a quantidade de armazenamento necessária para cada nó. Nesse exemplo, é possível selecionar três instâncias m6g.large.search, em que cada uma usa um volume de armazenamento do EBS de 90 GiB, para que você tenha uma rede de segurança e espaço para crescimento ao longo do tempo. Essa configuração fornece 6 núcleos de vCPU e 24 GiB de memória, portanto, é adequada para workloads mais leves.
Para obter um exemplo mais substancial, considere um requisito de armazenamento de 14 TiB (14.336 GiB) e uma workload pesada. Nesse caso, você pode optar por iniciar testes com 2 * 144 = 288 núcleos de vCPU e 8 * 144 = 1.152 GiB de memória. Esses números funcionam para aproximadamente 18 instâncias do i3.4xlarge.search. Se você não precisar do armazenamento local rápido, também poderá testar 18 instâncias r6g.4xlarge.search, cada uma usando um volume de armazenamento do EBS de 1 TiB.
Se o cluster incluir centenas de terabytes de dados, consulte Escala de petabytes no Amazon Service OpenSearch .
Etapa 3: Executar o teste de representatividade
Depois de configurar o cluster, você pode adicionar seus índices usando o número de fragmentos calculados anteriormente, realizar alguns testes representativos do cliente usando um conjunto de dados realista e monitorar CloudWatch métricas para ver como o cluster lida com a carga de trabalho.
Etapa 4: Sucesso ou iteração
Se o desempenho satisfizer suas necessidades, os testes forem bem-sucedidos e CloudWatch as métricas estiverem normais, o cluster estará pronto para uso. Lembre-se de definir CloudWatch alarmes para detectar o uso insalubre de recursos.
Se a performance não for aceitável, os testes falharem ou CPUUtilization ou JVMMemoryPressure estiverem altas, poderá ser necessário escolher um tipo de instância diferente (ou adicionar instâncias) e continuar o teste. Conforme você adiciona instâncias, reequilibra OpenSearch automaticamente a distribuição dos fragmentos em todo o cluster.
Como é mais fácil medir a capacidade em excesso de um cluster sobrecarregado do que o déficit de um cluster não sobrecarregado, recomendamos começar com um cluster maior do que você imagina ser necessário. Depois, teste e reduza para um cluster eficiente que tenha os recursos adicionais a fim de garantir operações estáveis durante períodos de maior atividade.
Clusters de produção ou clusters com estados complexos se beneficiam de nós gerenciadores dedicados, que melhoram o desempenho e a confiabilidade do cluster.
