Configurer Amazon OpenSearch Service pour une haute disponibilité | Services Web Amazon

Configurer Amazon OpenSearch Service pour une haute disponibilité | Services Web Amazon

Horodatage: 31 mai 2023 12:56
Nœud source: 2691649

Service Amazon OpenSearch est un moteur de recherche et d'analyse entièrement open source qui déverrouille en toute sécurité la recherche, la surveillance et l'analyse en temps réel des données commerciales et opérationnelles pour des cas d'utilisation tels que les moteurs de recommandation, les sites de commerce électronique et la recherche de catalogue. Pour réussir dans votre entreprise, vous avez besoin que vos systèmes soient hautement disponibles et performants, minimisant les temps d'arrêt et évitant les pannes. Lorsque vous utilisez OpenSearch Service comme principal moyen de surveillance de votre infrastructure, vous devez également vous assurer de sa disponibilité. Les temps d'arrêt pour OpenSearch Service peuvent avoir un effet significatif sur les résultats de votre entreprise, tels que la perte de revenus, la perte de productivité, la perte de valeur de la marque, etc.

La standard de l'industrie pour mesurer la disponibilité est la classe des neuf. OpenSearch Service fournit 3 9 de disponibilité, lorsque vous suivez les meilleures pratiques, ce qui signifie qu'il garantit moins de 43.83 minutes d'indisponibilité par mois. Dans cet article, vous apprendrez comment configurer votre domaine OpenSearch Service pour une haute disponibilité et des performances en suivant les meilleures pratiques et recommandations lors de la configuration de votre domaine.

Deux éléments essentiels influencent la disponibilité de votre domaine : l'utilisation des ressources de votre domaine, qui est principalement déterminée par votre charge de travail, et les événements externes tels que les pannes d'infrastructure. Bien que le premier puisse être contrôlé grâce à une surveillance continue des performances et de la santé du domaine et à la mise à l'échelle du domaine en conséquence, le second ne le peut pas. Pour atténuer l'impact d'événements externes tels qu'une panne de zone de disponibilité, une panne d'instance ou de disque, ou des problèmes de mise en réseau sur votre domaine, vous devez fournir une capacité supplémentaire, répartie sur plusieurs zones de disponibilité, et conserver plusieurs copies des données. Le non-respect de cette consigne peut entraîner une dégradation des performances, une indisponibilité et, dans le pire des cas, une perte de données.

Examinons les options qui s'offrent à vous pour vous assurer que le domaine est disponible et performant.

Configuration du cluster

Dans cette section, nous parlerons des différentes options de configuration dont vous disposez pour configurer correctement votre cluster, notamment la spécification du nombre d'AZ pour le déploiement, la configuration des nœuds maître et de données, la configuration des index et des partitions.

Déploiement multi-AZ

Les nœuds de données sont responsables du traitement des requêtes d'indexation et de recherche dans votre domaine. Le déploiement de vos nœuds de données sur plusieurs zones de disponibilité améliore la disponibilité de votre domaine en ajoutant un stockage et un traitement de données redondants par zone. Avec un déploiement multi-AZ, votre domaine peut rester disponible même lorsqu'une zone de disponibilité complète devient indisponible. Pour les charges de travail de production, AWS recommande d'utiliser trois zones de disponibilité pour votre domaine. Utilisez deux zones de disponibilité pour les régions qui n'en prennent en charge que deux pour une meilleure disponibilité. Cela garantit que votre domaine est disponible en cas de panne Single-AZ.

Gestionnaire de cluster dédié (nœuds maîtres)

AWS recommande d'utiliser trois nœuds de gestionnaire de cluster (CM) dédiés pour toutes les charges de travail de production. Les nœuds CM suivent la santé du cluster, l'état et l'emplacement de ses index et fragments, le mappage de tous les index et la disponibilité de ses nœuds de données, et il maintient une liste des tâches au niveau du cluster en cours. Sans nœuds CM dédiés, le cluster utilise des nœuds de données, ce qui rend le cluster vulnérable aux demandes de charge de travail. Vous devez dimensionner les nœuds CM en fonction de la taille de la tâche, principalement le nombre de nœuds de données, le nombre d'index et le nombre de fragments. Le service OpenSearch déploie toujours des nœuds CM sur trois zones de disponibilité, lorsqu'elles sont prises en charge par la région (deux dans une zone de disponibilité et une dans d'autres zones de disponibilité si les régions n'ont que deux zones de disponibilité). Pour un domaine en cours d'exécution, un seul des trois nœuds CM fonctionne en tant que leader élu. Les deux autres nœuds CM participent à une élection si le nœud CM élu échoue.

Le tableau suivant présente les recommandations d'AWS pour le dimensionnement CM. Les nœuds CM fonctionnent en fonction du nombre de nœuds, d'index, de fragments et de mappage. Plus vous travaillez, plus vous avez besoin de calcul et de mémoire pour conserver et travailler avec l'état du cluster.

Nombre d'instances Taille de la RAM du nœud du gestionnaire de cluster Nombre maximal de fragments pris en charge Type d'instance minimale recommandée du gestionnaire de cluster dédié
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

Index et partitions

Les index sont une construction logique qui abrite une collection de documents. Vous partitionnez votre index pour le traitement parallèle en spécifiant un nombre de partitions principales, où les partitions représentent une unité physique pour le stockage et le traitement des données. Dans OpenSearch Service, une partition peut être une partition principale ou une réplique. Vous utilisez des répliques pour la durabilité (si la partition principale est perdue, OpenSearch Service promeut l'une des répliques en primaire) et pour améliorer le débit de recherche. Le service OpenSearch garantit que les fragments principaux et répliqués sont placés dans différents nœuds et dans différentes zones de disponibilité, s'ils sont déployés dans plusieurs zones de disponibilité. Pour une haute disponibilité, AWS recommande de configurer au moins deux réplicas pour chaque index dans une configuration à trois zones afin d'éviter toute interruption des performances et de la disponibilité. Dans une configuration multi-AZ, si un nœud échoue ou, dans le pire des cas, une zone de disponibilité échoue, vous aurez toujours une copie des données.

Suivi et gestion des clusters

Comme indiqué précédemment, la sélection de votre configuration en fonction des meilleures pratiques ne représente que la moitié du travail. Nous devons également surveiller en permanence l'utilisation des ressources et les performances pour déterminer si le domaine doit être mis à l'échelle. Un domaine sous-approvisionné ou surutilisé peut entraîner une dégradation des performances et éventuellement une indisponibilité.

Utilisation de l'UC

Vous utilisez le processeur de votre domaine pour exécuter votre charge de travail. En règle générale, vous devez viser une utilisation moyenne du processeur de 60 % pour n'importe quel nœud de données, avec des pics à 80 %, et tolérer de petits pics jusqu'à 100 %. Lorsque vous considérez la disponibilité, et surtout compte tenu de l'indisponibilité d'une zone complète, il existe deux scénarios. Si vous avez deux zones de disponibilité, chaque zone gère 50 % du trafic. Si une zone devient indisponible, l'autre zone prendra tout ce trafic, doublant l'utilisation du processeur. Dans ce cas, vous devez être à environ 30 à 40 % d'utilisation moyenne du processeur dans chaque zone pour maintenir la disponibilité. Si vous exécutez trois zones de disponibilité, chaque zone absorbe 33 % du trafic. Si une zone devient indisponible, chaque autre zone gagnera environ 17 % de trafic. Dans ce cas, vous devez cibler une utilisation moyenne du processeur de 50 à 60 %.

Utilisation de la mémoire

Le service OpenSearch prend en charge deux types de récupération de place. Le premier est le ramasse-miettes G1 (G1GC), qui est utilisé par les nœuds du service OpenSearch, alimenté par AWS Graviton 2. Le second est Concurrent Mark Sweep (CMS), qui est utilisé par tous les nœuds alimentés par d'autres processeurs. Sur toute la mémoire allouée à un nœud, la moitié de la mémoire (jusqu'à 32 Go) est affectée au tas Java, et le reste de la mémoire est utilisé par d'autres tâches du système d'exploitation, le cache du système de fichiers, etc. Pour maintenir la disponibilité d'un domaine, nous vous recommandons de maintenir l'utilisation maximale de la JVM à environ 80 % dans CMS et 95 % dans G1GC. Tout ce qui dépasse cela aurait un impact sur la disponibilité de votre domaine et rendrait votre cluster non sain. Nous vous recommandons également d'activer le réglage automatique, qui surveille activement l'utilisation de la mémoire et déclenche le ramasse-miettes.

Utilisation du stockage

OpenSearch Service publie plusieurs lignes directrices pour dimensionnement des domaines. Nous fournissons une formule empirique afin que vous puissiez déterminer la bonne quantité de stockage requise pour vos besoins. Cependant, il est important de garder un œil sur l'épuisement du stockage avec le temps et les changements dans les caractéristiques de la charge de travail. Pour vous assurer que le domaine ne manque pas d'espace de stockage et peut continuer à indexer les données, vous devez configurer Amazon Cloud Watch alarmes et surveillez votre espace de stockage gratuit.

AWS recommande également de choisir un nombre de partitions principales afin que chaque partition se situe dans une plage de taille optimale. Vous pouvez déterminer la taille de partition optimale grâce à des tests de preuve de concept avec vos données et votre trafic. Nous utilisons des tailles de partitions principales de 10 à 30 Go pour les cas d'utilisation de recherche et des tailles de partitions principales de 45 à 50 Go pour les cas d'utilisation d'analyse de journaux à titre indicatif. Étant donné que les partitions sont les nœuds de calcul de votre domaine, elles sont directement responsables de la répartition de la charge de travail sur les nœuds de données. Si vos partitions sont trop volumineuses, vous constaterez peut-être des contraintes dans votre tas Java dues à de grandes agrégations, à de moins bonnes performances des requêtes et à de moins bonnes performances sur les tâches au niveau du cluster telles que le rééquilibrage des partitions, les instantanés et les migrations de chaud à chaud. Si vos partitions sont trop petites, elles peuvent saturer l'espace de tas Java du domaine, aggraver les performances des requêtes en raison d'une mise en réseau interne excessive et ralentir les tâches au niveau du cluster. Nous vous recommandons également de maintenir le nombre de partitions par nœud proportionnel au tas disponible (la moitié de la RAM de l'instance jusqu'à 32 Go) : 25 partitions par Go de tas Java. Cela constitue une limite pratique de 1,000 XNUMX partitions sur n'importe quel nœud de données de votre domaine.

Conclusion

Dans cet article, vous avez appris divers trucs et astuces pour configurer un domaine hautement disponible à l'aide du service OpenSearch, qui vous aide à maintenir le service OpenSearch performant et disponible en l'exécutant sur trois zones de disponibilité.

Restez à l'écoute pour une série d'articles axés sur les différentes caractéristiques et fonctionnalités d'OpenSearch Service. Si vous avez des commentaires sur cet article, soumettez-les dans la section des commentaires. Si vous avez des questions sur ce post, démarrez un nouveau fil sur le Forum du service OpenSearch ou contacter Prise en charge d'AWS.

À propos des auteurs

Rohin Bhargava est chef de produit senior au sein de l'équipe Amazon OpenSearch Service. Sa passion chez AWS est d'aider les clients à trouver la bonne combinaison de services AWS pour atteindre leurs objectifs commerciaux.

Prashant Agrawal est un architecte de solutions spécialiste de la recherche senior avec Amazon OpenSearch Service. Il travaille en étroite collaboration avec les clients pour les aider à migrer leurs charges de travail vers le cloud et aide les clients existants à affiner leurs clusters pour obtenir de meilleures performances et réduire les coûts. Avant de rejoindre AWS, il a aidé divers clients à utiliser OpenSearch et Elasticsearch pour leurs cas d'utilisation de recherche et d'analyse de journaux. Lorsqu'il ne travaille pas, vous pouvez le trouver en train de voyager et d'explorer de nouveaux endroits. Bref, il aime faire Manger → Voyager → Répéter.

Horodatage:

Plus de Big Data AWS