Este artigo é uma ramificação do anterior sobre JMeter distribuído, mas desta vez trabalharemos em um ambiente público. Especificamente, eu usarei Amazon Web Services (AWS) para este exemplo. O controle será um computador Linux Ubuntu ao invés de um Windows como na versão anterior. Também usaremos segurança para RMI para prevenir conexões indesejadas.

Quando seria prudente fazer essa tentativa? #

Similaramente ao post anterior, se você precisar realizar uma carga ou teste de estresse entre 2.000 e 8.000 threads ou usuários virtuais, recomendo usar este método. A diferença seria que o método anterior poderia permanecer instalado indefinidamente em nosso ambiente local, mas provavelmente não seria prudente permitir que essa tentativa sejam executadas além de algumas iterações ou testes, porque teríamos que alugar as IPs públicas necessárias para colocar este modelo em funcionamento. Em resumo, é um ambiente construído e destruído a pedido, o que não poderia ser ótimo, mas merece mencionar.

Como funciona? #

Funciona em modo controlador/nó, o que significa que precisamos de um nó ou servidor para atuar como controller ou orchestrador, e os servidores restantes serão nós ou injetores de carga. Este esquema funciona em computadores conectados à rede pública através de uma interface de rede homologada. Isso significa que os computadores têm uma IP homologada ou subendereço, mas estão expostos a uma IP pública (como muitas das provedoras de serviços SaaS fazem).

• Master aka Controller aka Orchestrator (Linux Ubuntu) x 1
  • Java 1.8+
  • JMeter 5.2.1
• Node aka Load Generator aka Load Injector (Linux Ubuntu) x 4
  • Java 1.8+
  • JMeter 5.2.1

Esta vez, usaremos a mesma versão de JMeter 5.2.1 e a mesma versão de Java 1.8.252 em todos os computadores, que é sempre recomendada. Se você tiver alguma dúvida sobre como instalar JMeter, pode ver o post anterior ou também bem-vindo.

Receita #

1.- Gerar o Keystore RMI - Controller #

No controle, precisamos gerar o arquivo rmi_keystore.jks. Este arquivo é necessário para realizar comunicação segura entre a master e os nós, por isso devemos criar-o na master e copiar manualmente para os nós. É melhor usar comunicação segura porque estamos trabalhando em rede pública.

Você pode inserir informações fictícias ou reais para criar o arquivo. Para isso, precisamos executar o script de shell create-rmi-keystore.sh. Se seu controle é Windows, você precisaria usar o arquivo batch create-rmi-keystore.bat. Estes arquivos estão localizados na pasta JMeter BIN.

É muito importante que você tenha o senha à mão, pois será necessário quando iniciar os serviços e realizar a testagem. Para este exercício, a senha padrão foi changeit. Se tudo ocorrer conforme previsto, JMeter gerará o arquivo: rmi_keystore.jks no diretório BIN.

2.- Copie o Keystore - Nodos #

Copie este arquivo rmi_keystore.jks para todos os nós. Você pode usar a scp comando. No meu caso, já que uso chaves AWS através de um PEM, permite-me entrar nos computadores sem precisar digitar a senha. Para dar uma ideia mais concreta, compartilhar as IPs públicas que usaremos para o exercício.

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

no meu caso, gerenciei o arquivo Keystore RMI no controle, copiei-o para a pasta temporária na mesma máquina e depois copiei-o localmente para minha máquina para distribuir-o em todas as pastas temporárias nos nós. Após ser assinado localmente em cada nó, o rmi_keystore.jks deve ser colocado em cada diretório BIN do JMeter.

3.- Serviço RMI - Controller #

Vamos iniciar o serviço JMeter RMI para que os nós possam escutar do mestre. Esta vez, não editaremos o arquivo jmeter-service como no post anterior em #9. Nesta vez, aproveitaremos a “operação de override de parâmetros” suportada por Java. Mas primeiro, precisamos nos posicionar em qualquer um dos nós, isto é, 3.226.240.4, pois não podemos usar este endereço IP para iniciar o serviço porque ele está desaprovado, então não conseguimos realizar BIND ou vincular este endereço público ao serviço. Precisaremos usar o endereço IP aprovado da interface de rede fornecida pela Amazon service. Novamente, obtém-se este endereço IP usando o comando ifconfig.

O endereço IP aprovado do nó é 172.31.2.210, antes de iniciar o serviço, lembre-se de completar o passo anterior e copiar o arquivo rmi_keystore.jks para a pasta 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 &

Se tudo der certo, você receberá algo como isso:

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]]]

Se você não usou a senha padrão ao criar o arquivo no passo #1, precisará atualizar essas valores na jmeter.properties, isto é, server.rmi.ssl.keystore.password e server.rmi.ssl.truststore.password.

4.- Conexão - Nós - Controle #

Quando os geradores de carga ou nós estão prontos, cada um deve escutar na porta 1099. Antes de iniciar o teste, é bom verificar a comunicação entre o mestre e os nós. Para isso, usaremos a comandos telnet. Do mestre, faremos uma conexão test por executar 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.- Execução - Controlador #

Agora executaremos o teste via CLI a partir do controlador ou servidor mestre:

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

Conclusão #

Este mecanismo é muito semelhante ao anterior e funciona bem em Azure e AWS, que são entre os maiores provedores de IaaS na nuvem. Não testei ele no Google, mas imagino que funcione bem também. Como você pode ver, ainda estamos realizando tarefas manuais aqui que devem ser avaliadas em termos de custo-benefício, especialmente para especialização na modelagem. No próximo e final JMeter distribuído release, publicaremos o modelo distribuído baseado em contêineres, utilizando serviços da nuvem.