6.3 Guide de taille pour le déploiement d'OpenText eDirectory sur AWS

Ce guide recommande l'instance AWS EC2 et le volume EBS les mieux adaptés au déploiement d'OpenText eDirectory sur AWS VPC. Pour vous aider à estimer vos besoins en matière de taille, nous avons fourni les facteurs d'estimation les plus utiles ainsi que divers scénarios de performances, qui sont testés dans un environnement de test contrôlé avec des paramètres de configuration spécifiques.

6.3.1 Commencer avec la sélection d'instance AWS EC2

Avant de déployer OpenText eDirectory sur AWS, vous devez déterminer les types d'instance EC2 et de volume EBS pour obtenir des performances optimales sur votre serveur OpenText eDirectory. Les performances d'OpenText eDirectory dépendent de plusieurs ressources relatives à la manière dont une entreprise envisage de l'utiliser. Voici quelques-unes des ressources à prendre en compte pour votre estimation :

  • Catégorie d'instance AWS EC2 : vous devez sélectionner la catégorie d'instance appropriée à votre environnement. Nous avons pris en compte les catégories d'instance suivantes pour les différents scénarios de performances de notre environnement de test :

    • Postes de travail génériques

    • Optimisé pour la mémoire

    • Optimisé pour le calcul

    Il est également recommandé d'utiliser des instances EC2 optimisées pour EBS afin de déployer OpenText eDirectory, en vue de bénéficier d'une bande passante dédiée entre l'instance EC2 et le volume EBS associé. Cela permet également une utilisation efficace de l'IOPS prévu sur un volume EBS. Dans certains cas, l'optimisation EBS n'est pas activée par défaut. Dans ce cas, vous devez l'activer manuellement.

  • Type d'instance AWS EC2 : après avoir sélectionné la catégorie d'instance appropriée pour votre environnement, un type d'instance doit être sélectionné en fonction des besoins commerciaux ou de la charge attendue. AWS propose une large sélection de types d'instance EC2 sous chaque catégorie d'instance. Il existe des sous-catégories sous chaque catégorie en fonction de divers paramètres, tels que le type de processeur ou le débit réseau. Le nombre de coeurs de processeur, le volume de RAM, la capacité réseau et le coût dépendent du type d'instance sélectionné. Pour plus d'informations sur les types d'instance, voir Types d'instance Amazon EC2.

  • Types de volume AWS EBS : étant donné que le volume racine ou le stockage local dans l'instance EC2 est périssable, vous devez attacher un volume EBS (Elastic Block Storage) AWS à votre instance EC2 pour stocker la DIB OpenText eDirectory et d'autres fichiers serveur qui doivent être conservés. Les volumes EBS vous permettent de conserver les données stockées même après la fin de l'instance AWS EC2, ce qui facilite les scénarios de récupération de données. Les données stockées dans le volume EBS sont répliquées par défaut dans la même zone de disponibilité. Pour plus d'informations, voir Types de volume EBS.

    OpenText eDirectory étant un service d'annuaire à lecture intensive, la sélection du type de volume EBS dépendra des E/S disque élevées. Pour cette raison, il est recommandé d'utiliser les types de volume SSD plutôt que les types de volume HDD, car les types de volume SSD gèrent les E/S disque petites ou aléatoires plus efficacement que les types de volume HDD, qui sont essentiellement utilisés pour la lecture en continu des E/S disque.

    Le type de volume SSD IOPS prévu (io1 et io2) vous permet de spécifier un taux d'IOPS cohérent lors de la création des types de volume par rapport au type de volume SSD générique (gp2) où les performances peuvent être instables. En outre, le SSD générique reliera la configuration d'IOPS à la taille du disque, ce qui n'existe pas avec les types de volume SSD IOPS prévus.

6.3.2 Détails des environnements de test des performances

Dans cette section, nous présentons les différents paramètres de configuration, catégories d'instance et types utilisés dans notre environnement de test contrôlé.

Types d'instance EC2 :

Les types d'instance suivants ont été utilisés lors des tests des performances :

Tableau 6-3 Type d'instance 4xLarge

Catégorie

Type

UC

Mémoire

Optimisé pour EBS

Bande passante EBS

Otimisé pour le calcul

c5a.4xlarge

16 processeurs, 3,3 GHz

32 Go

Oui

3 170 Mbit/s

Tableau 6-4 Type d'instance 2xLarge

Catégorie

Type

UC

Mémoire

Optimisé pour EBS

Bande passante EBS

Postes de travail génériques

m5a.2xlarge

8 processeurs, 2,5 GHz

32 Go

Oui

2 880 Mbit/s

Optimisé pour la mémoire

r5a.2xlarge

8 processeurs, 2,5 GHz

64 Go

Oui

2 880 Mbit/s

Otimisé pour le calcul

c5a.2xlarge

8 processeurs, 3,3 GHz

16 Go

Oui

3 170 Mbit/s

Tableau 6-5 Type d'instance xLarge

Catégorie

Type

UC

Mémoire

Optimisé pour EBS

Bande passante EBS

Postes de travail génériques

m5a.xlarge

4 processeurs, 2,5 GHz

16 Go

Oui

2 880 Mbit/s

Optimisé pour la mémoire

r5a.xlarge

4 processeurs, 2,5 GHz

64 Go

Oui

2 880 Mbit/s

Otimisé pour le calcul

c5a.xlarge

4 processeurs, 3,3 GHz

8 Go

Oui

3 170 Mbit/s

Paramètres courants

Tableau 6-6 Explication des paramètres courants

Paramètre

Description

Détails du VPC AWS

Un sous-réseau public et un sous-réseau privé. Client et OpenText eDirectory sont tous deux dans le sous-réseau privé VPC.

Détails de l'instance EC2 OpenText eDirectory

  • Système d'exploitation: serveur SUSE Enterprise Linux 15 SP2 (HVM), type de volume SSD

  • Build OpenText eDirectory : OpenText eDirectory 9.2

  • Elastic Block Storage : SSD IOPS prévu io2, 100 Go, IOPS – 1 000

  • Dib : 3 Go, plus de 2 millions d'utilisateurs

Opérations

  • Opération : opérations de recherche et de modification LDAPS (636)

  • Pourcentage :80 % d'opérations en lecture et 20 % en écriture.

  • Étendue de la recherche : recherche dans la sous-arborescence

  • Base de recherche : ou=users,o=novell

  • Filtre de recherche: utilisateur aléatoire sous Base de recherche

  • Attributs: sn;title

Optimisation d'OpenText eDirectory

Paramètre OpenText eDirectory Flaim DB :

preallocatecache=true

cache=4000000000cpinterval=360

Instance EC2 client LDAP

  • Système d'exploitation : RHEL8.0

  • Outil client LDAP : JMeter 5.1

  • Type d'instance EC2 : m5d.4xlarge, 16 processeurs, 64 Go de RAM

  • Plage de ports TCP : 1024-65534

6.3.3 Détermination des exigences de taille

Dans cette section, nous présentons nos recommandations sur la base des données de performances pour les scénarios couramment utilisés. Ces données vous aideront à déterminer l'instance AWS EC2 optimale pour votre environnement. Avant de commencer avec l'estimation de taille appropriée pour votre déploiement OpenText eDirectory, vous devez identifier la catégorie d'instance la mieux adaptée à votre déploiement.

Scénario n° 1 : identification de la catégorie d'instance AWS EC2

Dans ce scénario de performances, nous déterminerons la catégorie d'instance AWS EC2 appropriée pour le déploiement et les opérations d'OpenText eDirectory.

Les graphiques ci-dessous représentent respectivement le temps de réponse moyen (en millisecondes) et des opérations par seconde par rapport au nombre de threads. La mesure a été calculée à partir de trois catégories d'instances : Utilisation générique, Optimisé pour la mémoire et Optimisé pour le calcul, qui appartiennent au type d'instance 2xlarge.

Figure 6-2 Modification du temps de réponse moyen en fonction du nombre de threads exécutés simultanément pour m5a par rapport à r5a et à c5a

Figure 6-3 Modification du nombre d'opérations exécutées simultanément en fonction du nombre de threads

Les graphiques ci-dessous représentent respectivement le temps de réponse moyen (en millisecondes) et des opérations par seconde par rapport au nombre de threads. La mesure a été calculée à partir de trois catégories d'instances : Utilisation générique, Optimisé pour la mémoire et Optimisé pour le calcul, qui appartiennent au type xlarge.

Figure 6-4 Modification du temps de réponse moyen en fonction du nombre de threads exécutés simultanément pour m5a par rapport à r5a et à c5a

Figure 6-5 Modification du nombre d'opérations exécutées simultanément en fonction du nombre de threads

Recommandation

Comme dans le scénario de test ci-dessus, vous devez utiliser les instances optimisées pour le calcul avec le volume EBS pour obtenir les meilleures performances OpenText eDirectory lors d'un déploiement dans un environnement AWS. Le type d'instance doit être choisi initialement en fonction de la charge attendue. Vous pouvez toujours redimensionner le type d'instance s'il ne répond pas aux exigences de ressources. Vous devez également attacher le volume SSD IOPS prévu à l'instance EC2 pour optimiser l'E/S et les performances de débit.

Scénario n° 2 : identification de l'exigence de taille AWS EC2

Dans le scénario de performances précédent, nous avons déterminé que la catégorie d'instance AWS EC2 appropriée pour le déploiement et les opérations d'OpenText eDirectory était Optimisé pour le calcul.

Dans ce scénario de test des performances, les données ont été collectées à partir de trois types d'instances Optimisé pour le calcul différents, à savoir xlarge, 2xlarge et 4xlarge pour vous aider à trouver le guide de taille le mieux adapté.

Les graphiques ci-dessous représentent respectivement le temps de réponse moyen (en millisecondes) et des opérations par seconde par rapport au nombre de threads. Pour ce test, 500 millisecondes ont été considérées comme le temps de réponse moyen maximum acceptable.

Figure 6-6 Modification du temps de réponse moyen en fonction du nombre de threads exécutés simultanément pour xlarge par rapport à 2xlarge et à 4xlarge

Figure 6-7 Modification du nombre d'opérations exécutées simultanément en fonction du nombre de threads

Recommandation

Le tableau suivant indique le nombre maximal de threads mesuré et les opérations correspondantes par seconde possibles, afin de conserver le temps de réponse moyen dans la limite acceptable de 500 millisecondes pour chaque instance EC2 spécifiée.

Type d'instance

Threads

Opérations par seconde

c5a.xlarge

1200

2 300

c5a.2xlarge

1 500

2 900

c5a.4xlarge

1 750

3 500

Vous pouvez sélectionner la taille d'instance de calcul la mieux adaptée en fonction des valeurs de thread et de débit attendues, comme expliqué ci-dessus.