Comment reconnaître et résoudre les problèmes de d’état d'un cluster contenant trop de partitions ?

Brève description

La maintenance de chaque partition consomme une certaine quantité de ressources CPU/JVM. Lorsque vous avez trop de partitions, vous pouvez constater une grave dégradation des performances du cluster. Dans certains cas, lorsqu'il y a trop de partitions, l'ensemble de votre cluster peut ne plus répondre.

Pour vous assurer que vos clusters sont sains et fonctionnent comme prévu, suivez les meilleures pratiques d’OpenSearch Service.

Symptômes d'un trop grand nombre de partitions

Si votre cluster présente un ou plusieurs des symptômes suivants, suivez les étapes de résolution. Pour vérifier si votre domaine est affecté par un trop grand nombre de partitions, examinez les tendances des métriques d’état de votre cluster au fil du temps.

• Plus de 1 000 partitions par nœud.
• Indices contenant des partitions de petite taille, chacune inférieure à 10 Go.
• Suppressions de nœuds constantes.
• Métriques de ressources JVM/CPU élevées.
• Complications des déploiements bleus et verts.
• L'état du cluster est extrêmement difficile à gérer pour le maître élu.
• Les types d'instances T sont utilisés. Ou des types d'instances plus petits sont utilisés. Par exemple, le type d'instance c5.large est utilisé.

Résolution

Passez en revue les tendances de votre domaine

Utilisez la fourchette 3/6/12/14 pour examiner les métriques Amazon CloudWatch de votre domaine. Si les créations de partitions ont lieu à intervalles réguliers, augmentez la fenêtre temporelle du graphique. Sinon, vous ne verrez pas l'historique complet des tendances en matière d’état. Remarque : Vous devez modifier la période des métriques en choisissant 1 heure pour que les métriques se chargent correctement dans les plages de temps plus longues.

Les événements suivants se produisent dans un domaine contenant trop de partitions :

• Augmentation du nombre deShards.active. Une fois que le nombre de partitions dépasse 1 000 partitions au total par nœud, l’état du cluster est menacé lorsqu'il fait face à une augmentation du trafic. Ce risque augmente lorsque le trafic provenant des demandes de recherche se produit sur un nombre accru de partitions.
• Les suppressions de nœuds se produisent lorsque la métrique nœuds du cluster n'est pas une ligne continue dans la statistique min/max/avg. Le processus OpenSearch Service ne s'exécute pas sur les nœuds lorsque les limites de mémoire de JVM sont atteintes. Ensuite, le service géré redémarre automatiquement le processus.
• Augmentation de JVMMemoryPressure. Les valeurs min/avg/max convergent à mesure que la collecte des déchets G1 (G1GC) devient plus fréquente et moins efficace. Dans un état idéal, cette métrique oscille entre 0 et 75 % selon un schéma en dents de scie. Si JVMMemoryPressure dépasse 75 % en cas d'aggravation et que JVMMemoryPressure moyen dépasse 75 % en moyenne, l'impact initial se produit. Pour en savoir plus sur JVM et le récupérateur de mémoire dans OpenSearch Service, consultez Comprendre les modifications apportées à la métrique JVMMemoryPressure dans Amazon OpenSearch Service. Pour plus d'informations, consultez Comment résoudre les problèmes de pression de mémoire élevée sur la machine virtuelle Java sur mon cluster OpenSearch Service ?
• Augmentation de CPUUtilization. Le cluster consacre plus de ressources et de temps au récupérateur de mémoire pour les partitions qu'il gère.

Résolution des problèmes liés à un trop grand nombre de partitions

Pour résoudre votre problème de trop grand nombre de partitions, choisissez l'une des méthodes de résolution suivantes :

Réduction du nombre de partitions

L'une des meilleures pratiques d'OpenSearch consiste à limiter le nombre de partitions par nœud en fonction de la mémoire de tas JVM disponible. Assurez-vous que vous ne disposez pas de plus de 20 à 25 partitions par GiB de tas de JVM. Dans le service géré OpenSearch, la taille du tas JVM est limitée à 32 GiB. Cette limite signifie que vous pouvez avoir un maximum de 640 à 800 partitions par nœud. Il existe une limite de 1 000 partitions par nœud qui peuvent être modifiées via les paramètres du cluster.

Si les données ne sont pas nécessaires, supprimez les anciens index. Prenez des instantanés manuels des anciennes données d'index avant de les supprimer.

Notez les points suivants lorsque des indices rotatifs sont utilisés avec ISM :

• Vérifiez que votre stratégie de partition place les indices dans la plage de taille de partition conforme aux meilleures pratiques (10 à 50 Go). Supposons, par exemple, que vous utilisiez des indices ISM quotidiens et un partitionnement 5:1. Cette pratique permet d'obtenir 10 partitions par jour et jusqu'à 300 partitions par mois.
• Utilisez un modèle d'index pour réduire le nombre de partitions d'indices quotidiens plus petits. Pour plus d'informations, consultez la section Index templates sur le site Web d’OpenSearch. Notez que cela n'affecte que les index nouvellement créés dans le cluster et n'améliore pas immédiatement l’état du cluster.
• Utilisez l'API OpenSearch de réindexation pour combiner d'anciens indices quotidiens et hebdomadaires en un index mensuel. Pour plus d'informations, consultez la section Combine one or more indexes sur le site Web d’OpenSearch. Modifiez ensuite la période de rotation de vos indices ISM pour éviter la création d'indices trop petits.

Mise à l’échelle de vos instances

Notez les points suivants :

• Il ne s'agit pas d'une solution viable à long terme pour l’augmentation verticale ou horizontale. Assurez-vous de suivre les meilleures pratiques d'OpenSearch Services.
• Lorsque vous augmentez verticalement le type d'instance, les ressources disponibles par nœud et le nombre total de partitions que le nœud peut gérer augmentent.
• Lorsque vous augmentez horizontalement le nombre de nœuds de données, le nombre de partitions par nœud diminue. Cette diminution atténue l'effet sur les autres nœuds.

Informations connexes

Optimize OpenSearch index shard sizes sur le site Web d’OpenSearch