Ejecución de JMeter distribuido (red pública)

Este articulo sería una ramificación de la publicación anterior en la que hablamos de JMeter distribuido, solo que en está ocasión lo haremos por medio de una red pública. En concreto me apoyaré de los sevicios web de Amazon (AWS) para este ejemplo. Así mismo el controlador será un equipo Linux Ubuntu en lugar de Windows como la versión anterior, además estaremos utilizando la seguridad para el RMI con la finalidad de evitar conexiones indeseadas.

¿ Cuando sería prudente realizar el esfuerzo ? #

De igual forma que la anterior publicación, si tienes la necesidad de realizar una prueba de carga o estrés de entre 2,000 a 8,000 hilos o usuarios virtuales, te aconsejo utilizar este esquema. La diferencia radicaría en que el esquema anterior pudiera quedar instalado indefinidamente en nuesto ambiente local, pero este esfuerzo probablemente no sería prudente dejarlo funcionar más allá de una par de iteraciones o pruebas, porque tendríamos que estar alquilando las direcciones IP públicas necesarias para hechar a andar este modelo. En pocas palabras es un ambiente que se construye y se destruye bajo demanda, que pudiera no ser lo óptimo pero es una rama que merece ser mencionada.

¿ Cómo funciona ? #

Funciona en la modalidad maestro - nodo, esto significa que requerimos de un nodo o servidor para fungir como controlador u orquestador y los servidores restantes serían nodos o injectores de carga ( generadores de carga). Este esquema funciona en equipos conectados a la red pública por medio de una interfaz de red homologada, esto significa que los equipos tienen una IP homologada o subneteada pero expuestas sobre una dirección IP pública (como la mayoría de los proveedores de Cloud SaaS lo hacen).

• Maestro aka Controlador aka Orquestador (Linux Ubuntu) x 1
  • Java 1.8+
  • JMeter 5.2.1
• Nodo aka Generador de carga** aka Injector de carga (Linux Ubuntu) x 4
  • Java 1.8+
  • JMeter 5.2.1

En esta ocasión tendremos la misma versión de JMeter 5.2.1 y la misma versión de Java 1.8.252 en todos los equipos, lo cual es siempre lo más recomendable. Si tienes dudas de como instalar JMeter puedes ver la publicación anterior o también aquí.

Receta de cocina #

1.- Generar el Keystore RMI - Controlador #

En el controlador, debemos generar el archivo rmi_keystore.jks. Este archivo es necesario para llevar acabo la comunicación segura entre el maestro y los nodos, motivo por el cual deberemos crearlo en el maestro y copiarlo manualmente a los nodos. Lo más recomendable es utilizar comunicación segura debido a que estamos trabajando en la red pública.

Puedes introducir información ficticia o real para crear el archivo, para ello requerimos ejecutar el shell scripting create-rmi-keystore.sh en caso de que tu controlador fuera Windows tendrías que utilizar el archivo por lotes create-rmi-keystore.bat. Estos ficheros se encuentran alojados en la carpeta BIN de JMeter.

Es muy importante que la contraseña las tengas a la mano, pues serán requiras a la hora de lanzar los servicios y la prueba. Para este ejercicio se utilizó la contraseña por defecto: changeit. Si todo salio correctamente JMeter te habrá generado el archivo: rmi_keystore.jks en la carpeta BIN.

2.- Copiar el Keystore - Nodos #

Copiar este fichero rmi_keystore.jks a todos los nodos, se puede utilizar el comando scp, en mi caso como utilizo las llaves de AWS por medio de un archivo PEM, el cual me permite firmarme a los equipos sin necesidad de teclear la contraseña, para darte una idea más concreta les compartiré las direcciones IP públicas que utilizaremos para el ejercicio.

3.80.12.127   <-- Maestro o controlador
 3.226.240.4   <--\
 3.227.17.255  <--|\
 3.227.19.225  <--|/ Nodos 
 35.175.127.72 <--/

En mi caso generé el archivo RMI Keystore en el controlador, lo copie a la carpeta temporal del mismo servidor, y luego lo copie localmente a mi equipo para ahí distribuirlo a todas las carpetas temporales de los nodos. Ya localmente firmado en cada nodo se debe colocar el archivo rmi_keystore.jks en cada carpeta BIN de JMeter.

3.- Servicio RMI - Controlador #

Vamos a iniciar el servicio de JMeter RMI para que los nodos puedan escuchar al maestro, en esta ocasión no editaremos el archivo jmeter-service como en el paso #9 de la publicación anterior, en esta ocasión aprovecharemos el “parameter override” o anulación de parametros que es soportado por Java. Pero primero debemos posicionarnos en cualquiera de los nodos i.e. 3.226.240.4, no podemos utilizar esta dirección IP para levantar el servicio, porque no está homologada, motivo por el cual no podemos hacer el BIND o ligar está IP púlica al servicio. Tendremos que utilizar la IP homologada de la interfáz de red que nos proporciona el servicio de Amazon. Nuevamente con el comando ifconfig obtendremos dicha dirección IP.

Entonces la IP homologada del nodo es 172.31.2.210, antes de iniciar el servicio recuerda finalizar el paso anterior y copiar el archivo rmi_keystore.jks en la carpeta BIN de JMeter.

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 &

Si todo salió bien, obtendrás algo como esto:

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 no utilizaste la contraseña por definición en la creación del archivo el paso #1, tendrás que actualizar esos valores en el archivo jmeter.properties, i.e. server.rmi.ssl.keystore.password y server.rmi.ssl.truststore.password.

4.- Conectividad - Nodo - Controlador #

Una vez que los generadores de carga o nodos están listos, cada uno de ellos deberá estar escuchando en el puerto 1099, antes de lanzar la prueba sería bueno comprobar la comunicación entre el maestro y los nodos, para ello utilizaremos el comando telnet, desde el maestro vamos a realizar una prueba de conexión ejecutando 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

Intenta con los demás nodos, espero todos te funcionen correctamente.

Si no sabes bien como generarla, intentar crear una regla para admitir todo el tráfico que pudiera ser más sencillo.

5.- Ejecucion - Controlador #

Ahora ejecutaremos la prueba por medio de CLI desde el controlador o servidor maestro:

./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

Conclusión #

Este mecanismo es muy parecido al anterior y funciona bien sobre Azure y AWS que son de los más grandes proveedores de Cloud IaaS en la nube, tampoco lo he probado en Google pero también me imagino que debe funcionar bien. De igual forma como podrán observar aquí seguimos haciendo tareas manuales que deben ser evaluadas en costo-beneficio sobre todo para ser especializarnos en el modelo. El siguiente y última publicación de JMeter distribuido, publicaremos el modelo distribuido basado en contenedores y utilizando de igual forma los servicios en la nube.