Lado Servidor

Hoje eu participei do evento Plataforma Java x Plataforma .Net (edição DF 2009) ministrando uma palestra no Tema 1. O tema de minha palestra foi o mesmo da ministrada no 6º FGSL. Eu escrevi este artigo como base para minha apresentação.

Escalabilidade pode ser definida como a habilidade de garantir a qualidade de serviço desejada à medida que a demanda de uso aumenta. Uma solução pode ser considerada escalável se continuar respondendo dentro de limites estabelecidos apesar de um aumento na sua carga.

Para compreender o que e escalabilidade, primeiro e preciso entender a capacidade de um sistema, que pode ser definido como a quantidade de processos, ou usuários, que o sistema consegue suportar e ainda assim manter a qualidade do serviço. Se um sistema esta no máximo de sua capacidade e não consegue responder dentro de um limite estabelecido, podemos afirmar que esse sistema ultrapassou o seu limite de escalabilidade. Para escalar um sistema que atingiu a sua capacidade máxima, será preciso adicionar mais hardware. Esse hardware adicional pode ser adicionado verticalmente ou horizontalmente.

E importante lembrar que, ao definir a arquitetura de uma solução, será preciso considerar como o sistema ira se comportar no caso do ambiente precisar ser escalado.

Escalabilidade Vertical

E alcançada ao aumentar a capacidade em um hardware, entende-se por capacidade a adição de mais processadores, memória ou discos a maquina atual.

Escalar de forma vertical dificilmente ira ter algum impacto na sua arquitetura.

Apesar disso, não e possível garantir a disponibilidade da aplicação, uma vez que um único hardware representa um ponto único de falha, conhecido como SPOF (Single Point of Failure).

Geralmente a escalabilidade vertical é mais barata e demanda um menor esforço de manutenção que a escalabilidade horizontal.

Escalabilidade  Horizontal

E possível alcançar a escalabilidade horizontal ao adicionar mais maquinas ao ambiente atual,
aumentando assim a c apacidade do sistema como um todo .
Para distribuir a carga de maneira otimizada para cada servidor , você devera usar as técnicas de
balanceamento de carga (Load Balancing) e de montagem de clusters.

A arquitetura definida para a aplicação deve ser projetada tendo em mente que ela devera funcionar sem problemas em um ambiente que pode escalar horizontalmente.

Ao escalar de forma horizontal você consegue garantir a flexibilidade, disponibilidade e confiabilidade para o ambiente e para a aplicação.

Em contra partida você aumenta a complexidade e o gerenciamento da estrutura física da aplicação, alem de ser uma solução mais cara que a escalabilidade vertical.

Escalabilidade Diagonal

Para implementar uma solução que seja confiável, resiliente, performática, escalável e de alta disponibilidade, que usa de forma inteligente todo o poder disponibilizado pelo hardware, se faz necessário aplicar em conjunto as técnicas de escalabilidade horizontal e vertical, conhecida como escalabilidade diagonal.

Conclusão

Escalabilidade significa adicionar hardware para manter e melhorar a performance de uma solução.

Entretanto, apenas adicionar mais hardware pode não representar ganho de performance por parte da aplicação.

Antes de escalar o ambiente, e importante validar se todos os gargalos da aplicação foram devidamente eliminados, se o código esta otimizado e o ambiente devidamente configurado e otimizado.

Caso estas boas práticas não sejam executadas, escalar o ambiente apenas vai empurrar o problema mais pra frente. Por outro lado, quando a solução está devidamente otimizada, então escalar o ambiente se torna o próximo passo lógico para uma maior capacidade e desempenho para a solução.

Um abraço a todos,

Marcelo Ancelmo

Escalabilidade Horizontal

E possível alcançar a escalabilidade horizontal ao adicionar mais maquinas ao ambiente atual, aumentando assim a capacidade do sistema como um todo.

Para distribuir a carga de maneira otimizada para cada servidor , você devera usar as técnicas de balanceamento de carga (Load Balancing) e de montagem de clusters.

A arquitetura definida para a aplicação deve ser projetada tendo em mente que ela devera funcionar sem problemas em um ambiente que pode escalar horizontalmente.

Ao escalar de forma horizontal você consegue garantir a flexibilidade, disponibilidade e confiabilidade para o ambiente e para a aplicação.

SLA Tempo de reposta: 5s

1 Processador 512 MB 30% de utilização

1 Processador 512 MB 30% de utilização

+ 30 usuários

180 usuários

150 usuários

1 Processador 512 MB 95% de utilização

+ 1 Máquina

Tempo de reposta: 6s

Tempo de reposta: 2s

Figura SEQ Figura \* ARABIC 2 : Escalabilidade Horizontal

Em contra partida você aumenta a complexidade e o gerenciamento da estrutura física da aplicação, alem de ser uma solução mais cara que a escalabilidade vertical.

Fazer a JConsole monitorar a JVM que esta rodando o WebSphere Application Server.

A principio parece uma tarefa fácil, num primeiro momento, seria apenas seguir a documentação da SUN e inserir as seguintes propriedades de sistema para a inicialização da JVM:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<porta>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Como bom usuário do WebSphere, você ira configurar essas propriedades como Custom Properties da JVM do WebSphere, nesse momento você descobre que não poderá informar por aqui a propriedade com.sun.management.jmxremote. Por aqui, tudo e inserido como pares de nome e valor.

Vamos ao Infocenter então, onde você ira encontrar, na documentação da IBM JDK, a seguinte informação:

A aplicação Java que você quer monitorar deve ser inicializada com, no mínimo os seguintes parâmetros

-Dcom.sun.management.jmxremote.port=<porta>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Beleza, então não preciso do com.sun.management.jmxremote

Configuradas as propriedades mínimas necessárias, basta reiniciar o WebSphere, para ver que ele não sobe de jeito nenhum, e apresenta a seguinte mensagem no log:

javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com
.ibm.ws.management.PlatformMBeanServerBuilder: java.lang.ClassNotFoundException:
com.ibm.ws.management.PlatformMBeanServerBuilder

Vamos ao Infocenter do WebSphere então, lá reside a informação de que o WebSphere não tem suporte para o JConsole. Desistimos então?

Vamos botar esse negocio para funcionar, e é agora!

1. Para recuperar o ambiente, caso você tenha seguido o procedimento acima, edite o arquivo [PROFILE_HOME]/config/cells/[CELL_NAME]/nodes/[NODE_NAME]/servers/[SERVER_NAME]/server.xml, no final desse arquivo, dentro do elemento <jvmEntries> você ira encontrar as propriedades configuradas definidas como <systemProperties>, basta removê-las para o WebSphere iniciar normalmente.
2. Aproveite que você esta com o arquivo aberto, e coloque o seguinte valor para o atributo genericJvmArguments do elemento <jvmEntries>: -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote, perceba que o valor da propriedade javax.management.builder.initial= e um valor em branco, seguido pela propriedade com.sun.management.jmxremote
3. Encontre o arquivo [WAS_HOME]/java/jre/lib/management/management.properties e retire os comentários das seguintes linhas:
   com.sun.management.jmxremote.port=<porta>(informe uma porta qualquer como 9001)
   com.sun.management.jmxremote.ssl=false
   com.sun.management.jmxremote.authenticate=false

Reinicie o WebSphere, e inicialize a JConsole com o seguinte comando:

jconsole <host:porta>

Feito isso, a JConsole será apresentada, monitorando a JVM IBM do WebSphere.

Um abraço a todos,

Marcelo Ancelmo