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á.
# Escolha dos tipos de instância e testes
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](limits.md) 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](https://aws.amazon.com/opensearch-service/pricing/).
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 principais). Se você tiver três [nós principais dedicados](managedomains-dedicatedmasternodes.md), 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](petabyte-scale.md).
## Etapa 3: Executar o teste de representatividade
Depois de configurar o cluster, você pode [adicionar seus índices](indexing.md) 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](managedomains-cloudwatchmetrics.md) 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](cloudwatch-alarms.md) 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.
Os clusters de produção ou os clusters com estados complexos se beneficiam de [nós principais dedicados](managedomains-dedicatedmasternodes.md), que melhoram a performance e a confiabilidade do cluster.