Dimensionnement

Le dimensionnement vous aide à déterminer le type d'instance, le nombre de nœuds de données et les besoins en stockage adaptés à votre environnement cible. Nous vous recommandons de dimensionner d'abord en fonction du rangement, puis en fonction de CPUs. Si vous utilisez déjà Elasticsearch OpenSearch, le dimensionnement restera généralement le même. Cependant, vous devez identifier le type d'instance équivalent à votre environnement actuel. Pour vous aider à déterminer la bonne taille, nous vous recommandons de suivre les directives suivantes.

Stockage

Le dimensionnement de votre cluster commence par la définition des besoins de stockage. Identifiez le stockage brut dont vous avez besoin pour votre cluster. Ceci est déterminé en évaluant les données générées par votre système source (par exemple, les serveurs générant des journaux ou la taille brute du catalogue de produits). Après avoir identifié la quantité de données brutes dont vous disposez, utilisez la formule suivante pour calculer les besoins en stockage. Vous pouvez ensuite utiliser le résultat comme point de départ pour votre PoC.

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

La formule prend en compte les éléments suivants :

• La taille sur disque d'un index varie, mais elle est souvent 10 % supérieure à celle des données source.

• La surcharge du système d'exploitation de 5 % est réservée par Linux à la restauration du système et à la prévention des problèmes de défragmentation du disque.

• OpenSearch réserve 20 % de l'espace de stockage de chaque instance aux fusions de segments, aux journaux et à d'autres opérations internes.

• Nous recommandons de conserver 10 % de stockage supplémentaire afin de minimiser l'impact des défaillances des nœuds et des interruptions de la zone de disponibilité.

Combinés, ces frais généraux et ces réservations nécessitent 45 % d'espace supplémentaire sur la base des données brutes réelles de la source. C'est pourquoi vous multipliez les données sources par 1,45. Multipliez ensuite ce nombre par le nombre de copies de données (par exemple, un primaire plus le nombre de répliques que vous utiliserez). Le nombre de répliques dépend de vos exigences en matière de résilience et de débit. Pour un cas d'utilisation moyen, vous commencez par un appareil principal et un réplica. Enfin, multipliez par le nombre de jours pendant lesquels vous souhaitez conserver les données dans un niveau de stockage à chaud.

Amazon OpenSearch Service propose des niveaux de stockage à chaud, chaud et froid. Le niveau de stockage à chaud utilise UltraWarm le stockage. UltraWarm constitue un moyen rentable de stocker de grandes quantités de données en lecture seule sur Amazon OpenSearch Service. Les nœuds de données standard utilisent le stockage à chaud, qui prend la forme de magasins d'instances ou de volumes Amazon Elastic Block Store (Amazon EBS) attachés à chaque nœud. Le stockage à chaud fournit les performances les plus rapides possibles pour l'indexation et la recherche de nouvelles données. UltraWarm les nœuds utilisent Amazon Simple Storage Service (Amazon S3) comme solution de stockage et une solution de mise en cache sophistiquée pour améliorer les performances. Pour les index sur lesquels vous n'écrivez pas activement, ou que vous n'interrogez pas fréquemment, et qui ne présentent pas les mêmes exigences de performance, cela UltraWarm permet de réduire considérablement les coûts par GiB de données. Pour plus d'informations UltraWarm, consultez la documentation AWS.

Lorsque vous créez un domaine OpenSearch de service et que vous utilisez le stockage à chaud, vous devrez peut-être définir la taille du volume EBS. Cela dépend du type d'instance que vous avez choisi pour les nœuds de données. Vous pouvez utiliser la même formule d'exigence de stockage pour déterminer la taille du volume des instances soutenues par Amazon EBS. Nous recommandons d'utiliser des volumes gp3 pour les familles d'instances T3, R5, R6G, M5, m5G, C5 et C6g de dernière génération. À l'aide des volumes Amazon EBS gp3, vous pouvez fournir des performances indépendamment de la capacité de stockage. Les volumes Amazon EBS gp3 offrent également de meilleures performances de base, à un coût par Go inférieur de 9,6 % à celui des volumes gp2 existants sur Service. OpenSearch Avec gp3, vous bénéficiez également d'un stockage plus dense sur les familles d'instances R5, R6g, M5 et m6g, ce qui peut vous aider à optimiser davantage vos coûts. Vous pouvez créer des volumes EBS jusqu'au quota pris en charge. Pour plus d'informations sur les quotas, consultez la section Quotas Amazon OpenSearch Service.

Pour les nœuds de données dotés de lecteurs NVM Express (NVMe), tels que les instances i3 et r6gd, la taille du volume est fixe, les volumes EBS ne sont donc pas une option.

Nombre de nœuds et types d'instances

Le nombre de nœuds est basé sur le nombre de nœuds CPUs nécessaires au fonctionnement de votre charge de travail. Le nombre de CPUs est basé sur le nombre de partitions. Un index in OpenSearch est composé de plusieurs partitions. Lorsque vous créez un index, vous spécifiez le nombre de partitions pour l'index. Par conséquent, vous devez effectuer les opérations suivantes :

1. Calculez le nombre total de partitions que vous souhaitez stocker dans le domaine.

2. Déterminez le processeur.

3. Trouvez le type de nœud le plus rentable et le nombre de nœuds qui vous permettent d'obtenir le nombre CPUs et le stockage requis.

Il s'agit généralement d'un point de départ. Exécutez des tests pour déterminer si le montant de l'estimation répond à vos exigences fonctionnelles et non fonctionnelles.

Déterminer la stratégie d'indexation et le nombre de partitions

Une fois que vous connaissez les exigences de stockage, vous pouvez décider du nombre d'index dont vous avez besoin et identifier le nombre de partitions pour chacun d'eux. En général, les cas d'utilisation de la recherche comportent un ou plusieurs index, chacun représentant une entité consultable ou un catalogue. Pour les cas d'utilisation de l'analyse des journaux, un index peut représenter un fichier journal quotidien ou hebdomadaire. Après avoir déterminé le nombre d'index, commencez par suivre les instructions d'échelle suivantes et déterminez le nombre de partitions approprié :

• Cas d'utilisation de la recherche : 10 à 30 Go/partition

• Cas d'utilisation de l'analyse des journaux : 50 Go/partition

Vous pouvez diviser le volume total de données d'un seul index par la taille de partition que vous visez dans votre cas d'utilisation. Cela vous donnera le nombre de partitions pour l'index. L'identification du nombre total de partitions vous aidera à trouver les types d'instances adaptés à votre charge de travail. Les fragments ne doivent être ni trop grands ni trop nombreux. Les partitions volumineuses peuvent OpenSearch compliquer le rétablissement après une panne, mais comme chaque partition utilise une certaine quantité de processeur et de mémoire, le fait d'avoir trop de petites partitions peut entraîner des problèmes de performances et des erreurs. out-of-memory En outre, un déséquilibre dans l'allocation des partitions aux nœuds de données peut entraîner une distorsion. Lorsque vous avez des index avec plusieurs partitions, essayez de faire en sorte que le nombre de partitions soit un multiple pair du nombre de nœuds de données. Cela permet de garantir que les partitions sont réparties de manière uniforme entre les nœuds de données et d'éviter les nœuds chauds. Par exemple, si vous avez 12 partitions principales, votre nombre de nœuds de données devrait être de 2, 3, 4, 6 ou 12. Toutefois, le nombre de partitions est secondaire par rapport à la taille des partitions – si vous avez 5 Gio de données, vous devez toujours utiliser une seule partition. L'équilibrage uniforme du nombre de fragments de répliques dans la zone de disponibilité contribue également à améliorer la résilience.

Utilisation de l’UC

L'étape suivante consiste à déterminer le nombre dont CPUs vous avez besoin pour votre charge de travail. Nous vous recommandons de commencer avec un nombre de processeurs 1,5 fois supérieur à celui de vos partitions actives. Une partition active est une partition d'un index qui reçoit des écritures importantes. Utilisez le nombre de partitions principales pour déterminer les partitions actives pour les index qui reçoivent des demandes de lecture ou d'écriture importantes. Pour l'analyse des journaux, seul l'index actuel est généralement actif. Dans les cas d'utilisation de la recherche, toutes les partitions principales seront considérées comme des partitions actives. Bien que nous recommandions 1,5 processeur par partition active, cela dépend fortement de la charge de travail. Assurez-vous de tester et de surveiller l'utilisation du processeur et de l'adapter en conséquence.

Une bonne pratique pour maintenir l'utilisation de votre processeur consiste à vous assurer que le domaine de OpenSearch service dispose de suffisamment de ressources pour effectuer ses tâches. Un cluster dont l'utilisation du processeur est constamment élevée peut dégrader la stabilité du cluster. Lorsque votre cluster est surchargé, le OpenSearch service bloque les demandes entrantes, ce qui entraîne le rejet des demandes. Cela permet de protéger le domaine contre toute défaillance. Les directives générales concernant l'utilisation du processeur seront d'environ 60 % en moyenne et 80 % d'utilisation maximale du processeur. Des pics occasionnels de 100 % sont toujours acceptables et peuvent ne pas nécessiter de dimensionnement ou de reconfiguration.

Types d’instances

Amazon OpenSearch Service vous offre le choix entre plusieurs types d'instances. Vous pouvez choisir les types d'instances les mieux adaptés à votre cas d'utilisation. Amazon OpenSearch Service prend en charge les familles d'instances R, C, M, T et I. Vous choisissez une famille d'instances en fonction de la charge de travail : optimisée pour la mémoire, optimisée pour le calcul ou mixte. Après avoir identifié une famille d'instances, choisissez le type d'instance de dernière génération. En général, nous recommandons Graviton et les générations ultérieures, car elles sont conçues pour fournir des performances améliorées à moindre coût par rapport aux instances de génération précédente.

Sur la base de différents tests effectués pour l'analyse des journaux et les cas d'utilisation de la recherche, nous recommandons ce qui suit :

• Pour les cas d'utilisation de l'analyse des logs, une directive générale consiste à commencer par la famille R d'instances Graviton pour les nœuds de données. Nous vous recommandons d'exécuter des tests, d'établir des points de référence adaptés à vos besoins et d'identifier la taille d'instance adaptée à votre charge de travail.

• Pour les cas d'utilisation de la recherche, nous recommandons d'utiliser des instances Graviton de la famille R et C pour les nœuds de données, car les cas d'utilisation de la recherche nécessitent plus de processeur que les cas d'utilisation de l'analyse des journaux. Pour les petites charges de travail, vous pouvez utiliser les instances Graviton de la famille M pour les recherches et les journaux. Les instances de la famille I proposent des NVMe disques durs et sont utilisées par les clients ayant des exigences d'indexation rapide et de recherche à faible latence.

Le cluster est composé de nœuds de données et de nœuds de gestion de clusters. 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. La documentation AWS fournit une matrice qui recommande le type d'instance minimum de gestionnaire de cluster dédié.

AWS propose des solutions à usage général (m6g), optimisées pour le calcul (C6g) et pour la mémoire (R6g et R6gd) pour Amazon Service OpenSearch version 7.9 ou ultérieure, alimentées par des processeurs AWS Graviton2. Ces instances sont créées à l'aide de silicium personnalisé conçu par Amazon. Il s'agit d'innovations matérielles et logicielles conçues par Amazon qui permettent de fournir des services cloud efficaces, flexibles et sécurisés avec un hébergement mutualisé isolé, un réseau privé et un stockage local rapide.

La famille d'instances Graviton2 réduit la latence d'indexation jusqu'à 50 % et améliore les performances des requêtes jusqu'à 30 % par rapport aux instances Intel de génération précédente disponibles dans OpenSearch Service (M5, C5, R5).