Dimensionamento

O dimensionamento ajuda você a determinar o tipo de instância, o número 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 registros 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. Em seguida, 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 em disco de um índice varia, mas geralmente é 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 do nó e das interrupções na zona de disponibilidade.

Combinadas, essas despesas gerais e reservas exigem 45 por cento de espaço adicional com base nos dados brutos reais na fonte. É por isso que você multiplica os dados de origem por 1,45. Em seguida, multiplique isso 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 taxa de transferência. 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 em que você deseja reter dados em uma camada de armazenamento dinâmico.

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 armazenamento dinâmico, 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.

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 suportadas pelo 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 volumes gp3 do Amazon EBS, você pode provisionar desempenho independente 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 ajudá-lo a otimizar ainda mais seus custos. Você pode criar volumes do EBS até a cota suportada. Para obter mais informações sobre cotas, consulte Cotas do Amazon OpenSearch Service.

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. Ao criar um índice, você especifica o número de fragmentos para o índice. Portanto, você precisa fazer o seguinte:

1. Calcule a contagem total de fragmentos que você pretende armazenar no domínio.

2. Determine a CPU.

3. Encontre o tipo e a contagem de nós mais econômicos que oferecem o número CPUs e o armazenamento necessários.

Isso geralmente é um ponto de partida. Execute testes para determinar se o tamanho estimado está atendendo aos seus requisitos funcionais e não funcionais.

Determinando a estratégia de indexação e a contagem de fragmentos

Depois de conhecer os requisitos de armazenamento, você pode decidir 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 análise de log, um índice pode representar um arquivo de log diário ou semanal. Depois de decidir quantos índices, comece com a seguinte orientação de escala e determine a contagem de fragmentos apropriada:

• Pesquisar casos de uso — 10—30 GB/fragmento

• Casos de uso de análise de registros — 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 fornecerá 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 carga de trabalho. Os fragmentos não devem ser muito grandes ou 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 para os 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 vezes 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 análise de registros, 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 carga de trabalho. 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 que melhor se adequam ao 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 carga de trabalho: 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 desempenho com custos mais baixos em comparação com as instâncias da geração anterior.

Com base em vários testes realizados para análise de registros e casos de uso de pesquisa, recomendamos o seguinte:

• Para casos de uso de análise de registros, uma diretriz geral é começar com a família R de instâncias Graviton para nós de dados. Recomendamos que você execute testes, estabeleça benchmarks para seus requisitos e identifique o tamanho de instância apropriado para sua carga de trabalho.

• 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 análise de log. Para cargas de trabalho menores, você pode usar instâncias Graviton da família M para pesquisa e registros. 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 cluster. 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 que recomenda o tipo mínimo de instância dedicada do gerenciador de cluster.

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. Essas instâncias são criadas usando silício 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).