Nœuds principaux dédiés dans Amazon OpenSearch Service - Amazon OpenSearch Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Nœuds principaux dédiés dans Amazon OpenSearch Service

Amazon OpenSearch Service utilise des nœuds maîtres dédiés pour améliorer la stabilité du cluster. Un nœud principal dédié effectue des tâches de gestion du cluster, mais qui ne stocke pas de données ni ne répond aux demandes de chargement de données. Ce déchargement des tâches de gestion du cluster augmente la stabilité de votre domaine. Comme pour tous les autres types de nœuds, un tarif horaire s'applique à chaque nœud principal dédié.

Les nœuds principaux dédiés effectuent les tâches de gestion du cluster suivantes :

  • Suivre tous les nœuds dans le cluster.

  • Suivre le nombre d'index dans le cluster.

  • Suivre le nombre de partitions appartenant à chaque index.

  • Gérer les informations de routage pour les nœuds dans le cluster.

  • Mettre à jour l'état du cluster après les changements d'état, tels que la création d'un index et l'ajout ou la suppression de nœuds dans le cluster.

  • Répliquer les changements d'état du cluster sur tous les nœuds dans le cluster.

  • Surveiller l'état de santé de tous les nœuds du cluster en envoyant des signaux de pulsation, des signaux périodiques qui contrôlent la disponibilité des nœuds de données dans le cluster.

L'illustration suivante montre un domaine OpenSearch de service avec 10 instances. Sept des instances sont des nœuds de données et trois sont des nœuds principaux dédiés. Un seul des nœuds principaux dédiés est actif. Les deux nœuds principaux dédiés gris patientent comme sauvegarde en cas de défaillance du nœud principal dédié actif. Toutes les demandes de chargement de données sont correctement traitées par les sept nœuds de données et toutes les tâches de gestion du cluster sont déchargées sur le nœud principal dédié actif.

Choix du nombre de nœuds principaux dédiés

Nous vous recommandons d'utiliser Multi-AZ with Standby, qui ajoute trois nœuds maîtres dédiés à chaque domaine de OpenSearch service de production. Si vous déployez en mode multi-AZ sans mode veille ou mono-AZ, nous recommandons tout de même trois nœuds maîtres dédiés. Ne choisissez jamais un nombre pair de nœuds principaux dédiés. Tenez compte des éléments suivants lors du choix du nombre de nœuds principaux dédiés :

  • Un nœud maître dédié est explicitement interdit par le OpenSearch Service car vous ne disposez d'aucune sauvegarde en cas de panne. Si vous essayez de créer un domaine avec un seul nœud principal dédié, vous recevrez une exception de validation.

  • Si vous avez deux nœuds principaux dédiés, votre cluster ne dispose pas du quorum de nœuds nécessaire pour choisir un nouveau nœud principal en cas de défaillance.

    Un quorum est le nombre de nœuds principaux dédiés / 2 + 1 (arrondi au nombre entier le plus proche). Dans ce cas, 2/2 + 1 = 2. Comme un nœud principal dédié a échoué et qu'il n'existe qu'une seule sauvegarde, le cluster n'a pas de quorum et ne peut pas choisir un nouveau nœud principal.

  • Trois nœuds principaux dédiés, le nombre recommandé, fournissent deux nœuds de secours en cas de défaillance d'un nœud principal et le quorum nécessaire (2) pour choisir un nouveau nœud principal.

  • Quatre nœuds principaux dédiés ne valent pas mieux que trois. Cela peut entraîner des problèmes si vous utilisez des zones de disponibilité multiples.

    • Si un nœud principal échoue, vous disposez du quorum (3) pour choisir un nouveau nœud principal. Si deux nœuds échouent, vous perdez ce quorum, comme vous le feriez avec trois nœuds principaux dédiés.

    • Dans une configuration à trois zones de disponibilité, deux zones ont un nœud principal dédié et une zone en a deux. Si cette zone subit une perturbation, les deux autres n'ont pas le quorum nécessaire (3) pour élire un nouveau nœud principal.

  • Cinq nœuds maîtres dédiés fonctionne aussi bien que trois et vous permet de perdre deux nœuds tout en conservant un quorum. Mais comme un seul nœud maître dédié est actif à un moment donné, cette configuration signifie que vous payez quatre nœuds inactifs. De nombreux utilisateurs jugent ce niveau de protection par basculement excessif.

Si un cluster possède un nombre pair de nœuds éligibles au master, OpenSearch et Elasticsearch version 7. x et plus tard, ignorez un nœud afin que la configuration de vote soit toujours un nombre impair. Dans ce cas, quatre nœuds principaux dédiés équivalent à trois (et deux à un).

Note

Si votre cluster ne dispose pas du quorum nécessaire pour choisir un nouveau nœud principal, les demandes en écriture et en lecture sur le cluster échouent. Ce comportement est différent de celui OpenSearch par défaut.

Choix des types d'instance pour les nœuds principaux dédiés

Bien que les nœuds maîtres dédiés ne traitent pas les demandes de recherche et de requête, leur taille est étroitement liée à la taille de l'instance et au nombre d'instances, d'index et de partitions qu'ils peuvent gérer. Pour les clusters de production, nous recommandons, au minimum, les types d'instances suivants pour les nœuds maîtres dédiés.

Ces recommandations reposent sur les charges de travail classiques et peuvent varier en fonction de vos besoins. Les clusters avec plusieurs partitions ou mappages de champ peuvent bénéficier de types d'instance plus large. Surveillez les mesures du nœud principal dédié pour voir si vous avez besoin d'utiliser un type d'instance plus large.

Nombre d'instances

Taille de mémoire RAM du nœud principal Nombre maximal de partitions prises en charge

Type d'instance principale dédiée minimum recommandé

1-10

8 GiO 10 000

m5.large.search ou m6g.large.search

11-30

16 GiO 30 000

c5.2xlarge.search ou c6g.2xlarge.search

31-75 32 GiO 40 000

r5.xlarge.search ou r6g.xlarge.search

76 – 125 64 Go 75 000

r5.2xlarge.search ou r6g.2xlarge.search

126 – 200

128 Gio 75 000

r5.4xlarge.search ou r6g.4xlarge.search