Configurar Amazon OpenSearch Service para alta disponibilidade | Amazon Web Services

Configurar Amazon OpenSearch Service para alta disponibilidade | Amazon Web Services

Nó Fonte: 2691649

Serviço Amazon OpenSearch é um mecanismo de pesquisa e análise totalmente de código aberto que desbloqueia com segurança pesquisa, monitoramento e análise em tempo real de dados comerciais e operacionais para casos de uso como mecanismos de recomendação, sites de comércio eletrônico e pesquisa de catálogo. Para ter sucesso em seus negócios, você precisa que seus sistemas sejam altamente disponíveis e tenham alto desempenho, minimizando o tempo de inatividade e evitando falhas. Quando você usa o OpenSearch Service como seu principal meio de monitorar sua infraestrutura, também precisa garantir sua disponibilidade. O tempo de inatividade do OpenSearch Service pode ter um efeito significativo nos resultados de seus negócios, como perda de receita, perda de produtividade, perda de valor de marca e muito mais.

A padrão da indústria para medir a disponibilidade é classe de noves. O serviço OpenSearch fornece 3 9's de disponibilidade, quando você segue melhores práticas, o que significa que garante menos de 43.83 minutos de inatividade por mês. Nesta postagem, você aprenderá como configurar seu domínio do serviço OpenSearch para alta disponibilidade e desempenho seguindo as melhores práticas e recomendações ao configurar seu domínio.

Existem dois elementos essenciais que influenciam a disponibilidade de seu domínio: a utilização de recursos de seu domínio, que é principalmente impulsionada por sua carga de trabalho, e eventos externos, como falhas de infraestrutura. Embora o primeiro possa ser controlado por meio do monitoramento contínuo do desempenho e integridade do domínio e do dimensionamento do domínio de acordo, o segundo não pode. Para atenuar o impacto de eventos externos, como uma interrupção da zona de disponibilidade, falha de instância ou disco ou problemas de rede em seu domínio, você deve fornecer capacidade adicional, distribuída em várias zonas de disponibilidade e manter várias cópias de dados. Não fazer isso pode resultar em desempenho degradado, indisponibilidade e, na pior das hipóteses, perda de dados.

Vejamos as opções disponíveis para garantir que o domínio esteja disponível e tenha bom desempenho.

Configuração de cluster

Nesta seção, falaremos sobre várias opções de configuração necessárias para configurar seu cluster adequadamente, o que inclui especificar o número de AZ para a implantação, configurar os nós principais e de dados, configurar índices e shards.

Implantação Multi-AZ

Os nós de dados são responsáveis ​​pelo processamento de solicitações de indexação e pesquisa em seu domínio. A implantação de seus nós de dados em várias zonas de disponibilidade melhora a disponibilidade de seu domínio adicionando armazenamento e processamento de dados redundantes por zona. Com uma implantação Multi-AZ, seu domínio pode permanecer disponível mesmo quando uma zona de disponibilidade completa ficar indisponível. Para cargas de trabalho de produção, A AWS recomenda o uso de três zonas de disponibilidade para seu domínio. Use duas zonas de disponibilidade para regiões que suportam apenas duas para melhorar a disponibilidade. Isso garante que seu domínio esteja disponível em caso de falha do Single-AZ.

Gerenciador de cluster dedicado (nós mestres)

A AWS recomenda o uso de três nós dedicados do gerenciador de cluster (CM) para todas as cargas de trabalho de produção. Os nós CM rastreiam a integridade do cluster, o estado e a localização de seus índices e shards, o mapeamento de todos os índices e a disponibilidade de seus nós de dados, além de manter uma lista de tarefas em nível de cluster em andamento. Sem nós CM dedicados, o cluster usa nós de dados, o que torna o cluster vulnerável a demandas de carga de trabalho. Você deve dimensionar os nós CM com base no tamanho da tarefa — principalmente, as contagens de nós de dados, as contagens de índices e as contagens de estilhaços. O Serviço OpenSearch sempre implanta nós CM em três Zonas de Disponibilidade, quando suportado pela Região (dois em uma Zona de Disponibilidade e um em outras Zonas de Disponibilidade se as regiões tiverem apenas duas Zonas de Disponibilidade). Para um domínio em execução, apenas um dos três nós CM funciona como um líder eleito. Os outros dois nós CM participam de uma eleição se o nó CM eleito falhar.

A tabela a seguir mostra as recomendações da AWS para dimensionamento CM. Os nós CM funcionam com base no número de nós, índices, shards e mapeamento. Quanto mais trabalho, mais computação e memória você precisa para manter e trabalhar com o estado do cluster.

Contagem de instância Tamanho da RAM do nó do gerenciador de cluster Contagem Máxima de Fragmentos Suportados Tipo de instância mínima recomendada do gerenciador de cluster dedicado
1-10 8 GiB 10,000 m5.large.search ou m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search ou c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search ou c6g.4xlarge.search
76 – 125 64 GiB 75,000 r5.2xlarge.search ou r6g.2xlarge.search
126 – 200 128 GiB 75,000 r5.4xlarge.search ou r6g.4xlarge.search

Índices e estilhaços

Os índices são uma construção lógica que abriga uma coleção de documentos. Você particiona seu índice para processamento paralelo especificando uma contagem primária de fragmentos, em que os fragmentos representam uma unidade física para armazenar e processar dados. No OpenSearch Service, um estilhaço pode ser um estilhaço primário ou um estilhaço de réplica. Você usa réplicas para durabilidade — se o fragmento principal for perdido, o OpenSearch Service promove uma das réplicas para primária — e para melhorar o rendimento da pesquisa. O OpenSearch Service garante que os shards primários e de réplica sejam colocados em nós diferentes e em diferentes zonas de disponibilidade, se implantados em mais de uma zona de disponibilidade. Para alta disponibilidade, a AWS recomenda configurar pelo menos duas réplicas para cada índice em uma configuração de três zonas para evitar interrupções no desempenho e na disponibilidade. Em uma configuração Multi-AZ, se um nó falhar ou, no pior dos casos, uma zona de disponibilidade falhar, você ainda terá uma cópia dos dados.

Monitoramento e gerenciamento de clusters

Conforme discutido anteriormente, selecionar sua configuração com base nas melhores práticas é apenas metade do trabalho. Também precisamos monitorar continuamente a utilização e o desempenho dos recursos para determinar se o domínio precisa ser dimensionado. Um domínio subprovisionado ou superutilizado pode resultar em degradação do desempenho e, eventualmente, indisponibilidade.

Utilização da CPU

Você usa a CPU em seu domínio para executar sua carga de trabalho. Como regra geral, você deve atingir 60% de utilização média da CPU para qualquer nó de dados, com picos de 80% e tolerar pequenos picos de 100%. Quando você considera a disponibilidade, e especialmente considerando a indisponibilidade de uma zona completa, existem dois cenários. Se você tiver duas zonas de disponibilidade, cada zona lidará com 50% do tráfego. Se uma zona ficar indisponível, a outra zona receberá todo esse tráfego, dobrando a utilização da CPU. Nesse caso, você precisa estar em torno de 30 a 40% de utilização média da CPU em cada zona para manter a disponibilidade. Se você estiver executando três zonas de disponibilidade, cada zona ocupará 33% do tráfego. Se uma zona ficar indisponível, cada outra zona ganhará aproximadamente 17% do tráfego. Nesse caso, você deve atingir uma utilização média da CPU de 50 a 60%.

Utilização de memória

O OpenSearch Service oferece suporte a dois tipos de coleta de lixo. A primeira é a coleta de lixo G1 (G1GC), que é usada pelos nós do serviço OpenSearch, alimentado por AWS Graviton 2. O segundo é Concurrent Mark Sweep (CMS), que é usado por todos os nós alimentados por outros processadores. De toda a memória alocada para um nó, metade da memória (até 32 GB) é atribuída ao heap Java e o restante da memória é usado por outras tarefas do sistema operacional, o cache do sistema de arquivos e assim por diante. Para manter a disponibilidade de um domínio, recomendamos manter a utilização máxima da JVM em torno de 80% no CMS e 95% no G1GC. Qualquer coisa além disso afetaria a disponibilidade de seu domínio e tornaria seu cluster não saudável. Também recomendamos ativar o ajuste automático, que monitora ativamente a utilização da memória e aciona o coletor de lixo.

Utilização do armazenamento

OpenSearch Service publica várias diretrizes para dimensionamento de domínios. Fornecemos uma fórmula empírica para que você possa determinar a quantidade certa de armazenamento necessária para suas necessidades. No entanto, é importante ficar atento ao esgotamento do armazenamento com o tempo e às mudanças nas características da carga de trabalho. Para garantir que o domínio não fique sem armazenamento e possa continuar a indexar dados, você deve configurar Amazon CloudWatch alarmes e monitorar seu espaço de armazenamento livre.

A AWS também recomenda escolher uma contagem de estilhaços principal para que cada estilhaço esteja dentro de uma faixa de tamanho ideal. Você pode determinar o tamanho ideal do shard por meio de testes de prova de conceito com seus dados e tráfego. Usamos tamanhos de fragmentos primários de 10 a 30 GB para casos de uso de pesquisa e tamanhos de fragmentos primários de 45 a 50 GB para casos de uso de análise de log como diretriz. Como os fragmentos são os trabalhadores em seu domínio, eles são diretamente responsáveis ​​pela distribuição da carga de trabalho nos nós de dados. Se seus estilhaços forem muito grandes, você poderá ver estresse em seu heap Java devido a grandes agregações, pior desempenho de consulta e pior desempenho em tarefas no nível do cluster, como rebalanceamento de estilhaços, instantâneos e migrações hot-to-warm. Se seus shards forem muito pequenos, eles podem sobrecarregar o espaço de heap Java do domínio, piorar o desempenho da consulta por meio de rede interna excessiva e tornar lentas as tarefas no nível do cluster. Também recomendamos manter o número de estilhaços por nó proporcional ao heap disponível (metade da RAM da instância até 32 GB) — 25 estilhaços por GB de heap Java. Isso cria um limite prático de 1,000 fragmentos em qualquer nó de dados em seu domínio.

Conclusão

Nesta postagem, você aprendeu várias dicas e truques para configurar um domínio altamente disponível usando o serviço OpenSearch, que ajuda a manter o desempenho e a disponibilidade do serviço OpenSearch, executando-o em três zonas de disponibilidade.

Fique atento a uma série de postagens com foco nos vários recursos e funcionalidades do OpenSearch Service. Se você tiver comentários sobre esta postagem, envie-os na seção de comentários. Se você tiver dúvidas sobre esta postagem, inicie um novo tópico no Fórum do serviço OpenSearch ou contato Suporte AWS.


Sobre os autores

Rohin Bhargava é gerente de produto sênior da equipe do Amazon OpenSearch Service. Sua paixão na AWS é ajudar os clientes a encontrar a combinação correta de serviços da AWS para alcançar o sucesso de suas metas de negócios.

Prashant Agrawal é Arquiteto de Soluções Especialista em Pesquisa Sênior no Amazon OpenSearch Service. Ele trabalha em estreita colaboração com os clientes para ajudá-los a migrar suas cargas de trabalho para a nuvem e ajuda os clientes existentes a ajustar seus clusters para obter melhor desempenho e economizar custos. Antes de ingressar na AWS, ele ajudou vários clientes a usar o OpenSearch e o Elasticsearch para seus casos de uso de pesquisa e análise de log. Quando não está trabalhando, você pode encontrá-lo viajando e explorando novos lugares. Resumindo, ele gosta de fazer Comer → Viajar → Repetir.

Carimbo de hora:

Mais de Grandes dados da AWS