Cette article est une branche de l’article précédent sur le JMeter distribué, mais cette fois-ci nous travaillons sur un réseau public. En particulier, je vais utiliser Amazon Web Services (AWS) pour cet exemple. Le contrôleleur sera un ordinateur Linux Ubuntu au lieu d’un ordinateur Windows comme dans la version précédente. Nous utiliserons également le RMI pour prévenir les connexions inopportunes.

Quand il serait judicieux de faire ce travail? #

Similaire à la précédente postérité, si vous devez effectuer une charge ou un essai sous pression sur entre 2.000 et 8.000 threads ou utilisateurs virtuels, je recommande d’utiliser cette méthode. La différence serait que l’approche précédente pourrait rester installée indéfiniment dans notre environnement local, mais il est probable qu’il ne serait pas judicieux de laisser ce travail s’exécuter au-delà de quelques itérations ou essais car nous aurions à louer les adresses IP publiques nécessaires pour mettre en place cette modèle. En bref, c’est un environnement qui est construit et détruit sur demande, ce qui pourrait ne pas être optimal, mais il s’agit d’une branche qu’il faut mentionner.

Comment cela fonctionne ? #

Il fonctionne en mode serveur-maître, ce qui signifie que nous avons besoin d’un node ou d’une machine à controller/orchestrateur, et les autres seront des nodes ou injecteurs de charge. Ce schéma fonctionne sur les ordinateurs connectés au réseau public via une interface réseau homologée. Cela signifie que les ordinateurs ont une adresse IP homologée ou sous-ensemble mais sont exposées à une adresse IP publique (comme la plupart des fournisseurs de services SaaS Cloud).

• Master, aussi connu comme Controller ou Orchestrator (Ubuntu Linux) x 1
  • Java 1.8+
  • JMeter 5.2.1
• Node, également appelé Load Generator ou Load Injector (Linux Ubuntu) x 4
  • Java 1.8+
  • JMeter 5.2.1

Cette fois, nous utiliserons la même version de JMeter 5.2.1 et la même version de Java 1.8.252 sur tous les ordinateurs, ce qui est toujours recommandé. Si vous avez des questions concernant l’installation de JMeter, vous pouvez voir le post précédent ou également welcome.

Recette #

1.- Générer le fichier keystore RMI - Controleur #

Sur le controleur, nous devons générer le fichier rmi_keystore.jks. Ce fichier est nécessaire pour effectuer des communications sécurisées entre le maître et les nœuds, c’est pourquoi il faut créer-le sur le maître et copier-le manuellement vers les nœuds. Il est préférable de utiliser une communication sécurisée car nous travaillons sur la réseau public.

Vous pouvez entrer des informations fictives ou réelles pour créer le fichier. Pour cela, nous devons exécuter le script shell create-rmi-keystore.sh. Si votre contrôleur est Windows, vous auriez besoin de utiliser le fichier batch create-rmi-keystore.bat. Ces fichiers se trouvent dans le dossier JMeter BIN.

C’est très important que vous ayez la clé de connexion à portée de main, car elle sera requise lors du lancement des services et de la réalisation du test. Pour cette exercice, la clé par défaut était changeit. Si tout s’est bien passé, JMeter aura généré le fichier : rmi_keystore.jks dans le dossier BIN.

2.- Copie le Keystore - Nœuds #

Copiez ce fichier rmi_keystore.jks sur tous les nœuds. Vous pouvez utiliser la commande scp. Dans mon cas, étant donné que je utilise des clés AWS via un fichier PEM, cela permet de m’identifier aux ordinateurs sans avoir à taper le mot de passe. Pour vous donner une idée plus concrète, je partagerai les adresses IP publiques que nous utiliserons pour l’exercice.

3.80.12.127   <-- Master or Controller
 3.226.240.4   <--\
 3.227.17.255  <--|\
 3.227.19.225  <--|/ Nodes 
 35.175.127.72 <--/

Dans mon cas, j’ai généré le fichier de clé RMI sur le conteneur, je l’ai copié dans la même machine que celui-ci, puis j’ai copié ce fichier locallement à ma machine pour distribuer-le aux autres machines temporelles. Une fois signé localement sur chaque machine, le fichier rmi_keystore.jks doit être placé dans chaque dossier JMeter BIN de chaque machine temporelle.

3.- Service RMI - Controleur #

Commencez la démarration du service JMeter RMI afin que les nœuds puissent écouter le maître. Cette fois-ci, nous ne modifierons pas le fichier jmeter-service car il s’agit de l’étape #9 de la précédente postérité. Cette fois-ci, nous tirerons parti de la fonctionnalité “paramétrage” supportée par Java. Avant cela, nous devrons être positionnés sur n’importe quel des nœuds, c’est-à-dire 3.226.240.4, car cette adresse IP ne sera pas approuvée et donc que nous ne pourrions pas effectuer BIND ou établir ce public IP comme service. Nous devrons utiliser l’adresse IP approvée de la carte réseau fournie par le service Amazon. Encore une fois, nous obtenons cette adresse IP en utilisant la commande ifconfig.

Le nom de l’hôte approbataire est 172.31.2.210, avant d’exécuter le service, n’oubliez pas de compléter la étape précédente et de copier le fichier rmi_keystore.jks dans le dossier JMeter BIN.

nohup ./jmeter-server -Djava.rmi.server.hostname=172.31.2.210 &

3.226.240.4   <-- nohup ./jmeter-server -Djava.rmi.server.hostname=172.31.2.210 &
3.227.17.255  <-- nohup ./jmeter-server -Djava.rmi.server.hostname=172.31.12.246 &
3.227.19.225  <-- nohup ./jmeter-server -Djava.rmi.server.hostname=172.31.15.71 &
35.175.127.72 <-- nohup ./jmeter-server -Djava.rmi.server.hostname=172.31.6.59 &

ubuntu@ip-172-31-2-210:~/apache-jmeter-5.2.1/bin$ tail -f nohup.out

Created remote object: UnicastServerRef2 [liveRef: [endpoint:[172.31.2.210:37567,SSLRMIServerSocketFactory(host=/172.31.2.210, keyStoreLocation=rmi_keystore.jks, type=JKS, trustStoreLocation=rmi_keystore.jks, type=JKS, alias=rmi),SSLRMIClientSocketFactory(keyStoreLocation=rmi_keystore.jks, type=JKS, trustStoreLocation=rmi_keystore.jks, type=JKS, alias=rmi)](local),objID:[3a50eccc:171c7f240a3:-7fff, 5307420091797206182]]]

Si vous n’avez pas utilisé le mot de passe par défaut lors de la création du fichier dans le pas #1, vous devrez mettre à jour ces valeurs dans le fichier jmeter.properties, c’est-à-dire server.rmi.ssl.keystore.password et server.rmi.ssl.truststore.password.

4.- Connexions - Nœud - Contrôleur #

Une fois que les générateurs de charge ou les nœuds sont prêts, chaque d’entre eux doit écouter sur le port 1099. Avant de lancer la test, il serait bon de vérifier la communication entre le maître et les nœuds. Pour cela, nous utiliserons la commande telnet. De la part du maître, nous effectuerons une connexion test en exécutant telnet 3.226.240.4 1099 :

ubuntu@ip-172-31-12-156:~/apache-jmeter-5.2.1/bin$ telnet 3.226.240.4 1099
Trying 3.226.240.4...
Connected to 3.226.240.4.
Escape character is '^]'.  <--- es importante que salga este simbolo, lo que significa que se estabelció la comunicación

5.- Exécution - Controleur #

Maintenant, nous exécuterons le test à partir du controleur ou du serveur maître :

./jmeter.sh -n -t Script.jmx -l Script.jtl -R 3.226.240.4,3.227.17.255,3.227.19.225,35.175.127.72

Conclusion #

Cette méthode est très similaire à la précédente et fonctionne bien sur Azure et AWS, les deux des plus grands fournisseurs de Cloud IaaS. Je n’ai pas testé cela sur Google, mais je l’imaginais travailler bien aussi. De même, comme vous pouvez le voir, nous sommes toujours en train d’exécuter des tâches manuelles qui doivent être évaluées selon leur coût-bénéfice, surtout pour les spécialistes du modèle. Dans la prochaine et dernière version distribuée de JMeter, nous publierons également le modèle distribué basé sur les conteneurs, en utilisant les services cloud.