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á.
# Dimensionamento
O dimensionamento ajuda você a determinar o tipo de instância, a quantidade de nós de dados e os requisitos de armazenamento corretos para seu ambiente de destino. Recomendamos que você dimensione primeiro pelo armazenamento e depois por CPUs. Se você já estiver usando o Elasticsearch or OpenSearch, o tamanho geralmente permanecerá o mesmo. No entanto, você precisa identificar o tipo de instância equivalente ao seu ambiente atual. Para ajudar a determinar o tamanho certo, recomendamos o uso das diretrizes a seguir.
## Armazenamento
O dimensionamento do cluster começa com a definição dos requisitos de armazenamento. Identifique o armazenamento bruto de que você precisa para seu cluster. Isso é determinado pela avaliação dos dados gerados pelo sistema de origem (por exemplo, servidores gerando logs ou tamanho bruto do catálogo de produtos). Depois de identificar a quantidade de dados brutos que você tem, use a fórmula a seguir para calcular os requisitos de armazenamento. Depois, você pode usar o resultado como ponto de partida para sua PoC.
`storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained`
A fórmula leva em consideração o seguinte:
+ O tamanho de um índice no disco varia, mas normalmente é 10% maior do que os dados de origem.
+ A sobrecarga do sistema operacional de 5% é reservada pelo Linux para recuperação do sistema e para proteção contra problemas de desfragmentação de disco.
+ OpenSearch reserva 20% do espaço de armazenamento de cada instância para mesclagens de segmentos, registros e outras operações internas.
+ Recomendamos manter 10% de armazenamento adicional para ajudar a minimizar o impacto da falha nos nós e das interrupções nas zonas de disponibilidade.
Combinadas, essas reservas e despesas gerais exigem 45% de espaço adicional com base nos dados brutos reais na origem. É por isso que você multiplica os dados de origem por 1,45. Em seguida, multiplique pelo número de cópias dos dados (por exemplo, uma primária mais o número de réplicas que você usará). A contagem de réplicas depende de seus requisitos de resiliência e throughput. Para um caso de uso comum, você começa com um primário e uma réplica. Por fim, multiplique pelo número de dias pelos quais você deseja reter dados em uma camada de armazenamento quente.
O Amazon OpenSearch Service oferece níveis de armazenamento quente, quente e frio. O nível de armazenamento quente usa UltraWarm armazenamento. UltraWarm fornece uma maneira econômica de armazenar grandes quantidades de dados somente para leitura no Amazon Service. OpenSearch Os nós de dados padrão usam o armazenamento quente, que assume a forma de armazenamentos de instâncias ou volumes do Amazon Elastic Block Store (Amazon EBS) anexados a cada nó. O armazenamento dinâmico fornece o desempenho mais rápido possível para indexar e pesquisar novos dados. UltraWarm os nós usam o Amazon Simple Storage Service (Amazon S3) como armazenamento e uma solução sofisticada de armazenamento em cache para melhorar o desempenho. Para índices nos quais você não está escrevendo ativamente ou consultando com menos frequência e não têm os mesmos requisitos de desempenho, UltraWarm oferece custos significativamente mais baixos por GiB de dados. Para obter mais informações sobre UltraWarm, consulte a [documentação da AWS](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html).
Ao criar um domínio OpenSearch de serviço e usar armazenamento dinâmico, talvez seja necessário definir o tamanho do volume do EBS. Depende do tipo de instância escolhido para os nós de dados. Você pode usar a mesma fórmula de requisitos de armazenamento para determinar o tamanho do volume das instâncias baseadas no Amazon EBS. Recomendamos usar volumes gp3 para famílias de instâncias T3, R5, R6G, M5, M5g, C5 e C6g de última geração. Usando os volumes gp3 do Amazon EBS, você pode provisionar a performance independentemente da capacidade de armazenamento. Os volumes gp3 do Amazon EBS também oferecem melhor desempenho básico, a um custo 9,6% menor por GB do que os volumes gp2 existentes em serviço. OpenSearch Com o gp3, você também obtém um armazenamento mais denso nas famílias de instâncias R5, R6g, M5 e M6g, o que pode ajudar a otimizar ainda mais seus custos. Você pode criar volumes do EBS até a cota máxima permitida. Para obter mais informações sobre cotas, consulte Cotas [do Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html).
Para nós de dados que têm unidades NVM Express (NVMe), como instâncias i3 e r6gd, o tamanho do volume é fixo, portanto, os volumes do EBS não são uma opção.
## Número de nós e tipos de instância
O número de nós é baseado no número de nós CPUs necessários para operar sua carga de trabalho. O número de CPUs é baseado na contagem de fragmentos. Um índice em OpenSearch é composto por vários fragmentos. Quando você cria um índice, você especifica o número de fragmentos do índice. Portanto, você precisa fazer o seguinte:
1. Calcule a contagem total de fragmentos que você pretende armazenar no domínio.
1. Determine a CPU.
1. Encontre o tipo e a contagem de nós mais econômicos que oferecem o número CPUs e o armazenamento necessários.
Geralmente, este é um ponto de partida. Execute testes para determinar se o tamanho estimado está atendendo aos seus requisitos funcionais e não funcionais.
## Determinação da estratégia de indexação e contagem de fragmentos
Depois de conhecer os requisitos de armazenamento, você pode decidir de quantos índices precisa e identificar a contagem de fragmentos de cada um. Geralmente, os casos de uso de pesquisa têm um ou alguns índices, cada um representando uma entidade pesquisável ou um catálogo. Para casos de uso de analytics de logs, um índice pode representar um arquivo de logs diários ou semanais. Depois de decidir a quantidade de índices, comece com a seguinte orientação de escala e determine a contagem de fragmentos apropriada:
+ Casos de uso de pesquisa: 10 a 30 GB/fragmento
+ Casos de uso de analytics de logs: 50 GB/fragmento
Você pode dividir o volume total de dados em um único índice pelo tamanho do fragmento que você almeja em seu caso de uso. Isso lhe dará o número de fragmentos do índice. Identificar o número total de fragmentos ajudará você a encontrar os tipos de instância adequados à sua workload. Esses fragmentos não devem ser muito grandes nem muito numerosos. Fragmentos grandes podem dificultar OpenSearch a recuperação de falhas, mas como cada fragmento usa uma certa quantidade de CPU e memória, ter muitos fragmentos pequenos pode causar problemas e erros de desempenho. out-of-memory Além disso, o desequilíbrio na alocação de fragmentos aos nós de dados pode levar à distorção. Quando tiver índices com vários fragmentos, tente fazer a contagem de fragmentos em um múltiplo par da contagem de nós de dados. Isso ajuda a garantir que os fragmentos sejam distribuídos uniformemente entre os nós de dados e evita os nós quentes. Por exemplo, se você tiver 12 fragmentos primários, sua contagem de nós de dados deverá ser 2, 3, 4, 6 ou 12. No entanto, a contagem de fragmentos é secundária ao tamanho do fragmento. Se você tiver 5 GiB de dados, ainda deverá usar um único fragmento. Equilibrar uniformemente o número de fragmentos de réplicas em toda a zona de disponibilidade também ajuda a melhorar a resiliência.
## Utilização da CPU
A próxima etapa é identificar quantos CPUs você precisa para sua carga de trabalho. Recomendamos começar com uma contagem de CPU 1,5 vez maior que a de seus fragmentos ativos. Um fragmento ativo é qualquer fragmento de um índice que está recebendo gravações substanciais. Use a contagem primária de fragmentos para determinar fragmentos ativos para índices que estão recebendo solicitações substanciais de leitura ou gravação. Para analytics de logs, somente o índice atual geralmente está ativo. Para casos de uso de pesquisa, todos os fragmentos primários serão considerados fragmentos ativos. Embora recomendemos 1,5 CPU por fragmento ativo, isso depende muito da workload. Certifique-se de testar e monitorar a utilização da CPU e escalar adequadamente.
Uma prática recomendada para manter a utilização da CPU é garantir que o domínio do OpenSearch serviço tenha recursos suficientes para realizar suas tarefas. Um cluster com alta utilização consistente da CPU pode degradar a estabilidade do cluster. Quando seu cluster estiver sobrecarregado, o OpenSearch Serviço bloqueará as solicitações recebidas, o que resulta em rejeições de solicitações. Isso é para proteger o domínio contra falhas. As diretrizes gerais sobre o uso da CPU serão cerca de 60% em média, e 80% no máximo de utilização da CPU. Picos ocasionais de 100% ainda são aceitáveis e podem não exigir escalabilidade ou reconfiguração.
## Tipos de instância
O Amazon OpenSearch Service oferece a opção de vários tipos de instância. Você pode escolher os tipos de instância de acordo com seu caso de uso. O Amazon OpenSearch Service oferece suporte às famílias de instâncias R, C, M, T e I. Você escolhe uma família de instâncias com base na workload: otimizada para memória, otimizada para computação ou mista. Depois de identificar uma família de instâncias, escolha o tipo de instância de última geração. Geralmente, recomendamos o Graviton e as gerações posteriores porque eles foram criados para oferecer melhor performance com custos mais baixos em comparação com as instâncias da geração anterior.
Com base em vários testes realizados para analytics de logs e casos de uso de pesquisa, recomendamos o seguinte:
+ Para casos de uso de analytics de logs, uma diretriz geral é começar com a família R de instâncias [Graviton](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html) para nós de dados. Recomendamos que você execute testes, estabeleça avaliações comparativas para seus requisitos e identifique o tamanho de instância apropriado para sua workload.
+ Para casos de uso de pesquisa, recomendamos usar instâncias Graviton da família R e C para nós de dados, porque os casos de uso de pesquisa exigem mais CPU em comparação com os casos de uso de analytics de logs. Para workloads menores, você pode usar instâncias Graviton da família M para pesquisa e logs. As instâncias da família I oferecem NVMe drives e são usadas por clientes com requisitos de pesquisa de indexação rápida e baixa latência.
O cluster é composto por nós de dados e nós gerenciadores de clusters. 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. [A documentação da AWS fornece uma matriz](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-dedicatedmasternodes.html#dedicatedmasternodes-instance) que recomenda o tipo mínimo de instância dedicada do gerenciador de clusters.
[A AWS oferece uso geral (m6g), otimizado para computação (C6g) e otimizado para memória (R6g e R6gd) para o Amazon OpenSearch Service versão 7.9 ou posterior, com tecnologia de processadores AWS Graviton2.](https://aws.amazon.com/ec2/graviton/) Essas instâncias são criadas usando chip personalizado projetado pela Amazon. São inovações de hardware e software projetadas pela Amazon que permitem a entrega de serviços de nuvem eficientes, flexíveis e seguros com multilocação isolada, rede privada e armazenamento local rápido.
A família de instâncias Graviton2 reduz a latência de indexação em até 50% e melhora o desempenho das consultas em até 30% em comparação com as instâncias baseadas em Intel da geração anterior disponíveis em OpenSearch serviço (M5, C5, R5).