Produção

Apesar do JBossWorld ter acabado, vou falar de mais um assunto ligado ao que rolou por lá. Assisti uma session intitulada “Introduction to JBoss Application Server 5.0” apresentada pelo Dimitris Andreadis e achei valeria apena eu falar um pouco do que vi nela, sobre as novidades do JBoss 5.

O Dimitris começou a session contando um pouco sobre a história dos realeases do JBoss lá por volta de 2001/02 (começei a trabalhar com JBoss no ano de 2003). Atualmente o JBoss 5 está na versão beta 4 e segundo o apresentador eles não tem mais intenção de lançar mais muito beta, talvez mais um apenas e só. O objetivo da JBoss é lançar um application server certificado com o Java EE5. Vou listar algumas novidades/melhorias mencionadas na session, lembrando é claro, que todas as features do JBoss 5 não se resumem a que vou listar aqui.

Vamos lá…

1. Melhorias no mecanismo de clustering, que teve a sua arquitetura revista para melhor utilização dos recursos do servidor (memória por exemplo). O JBossClustering irá permitir definir a granularidade do que irá ser replicado e o que podemos chamar de BuddyReplication, que resumidamente consiste de que cada nó do cluster tenha um par com quem irá replicar os dados, evitando que uma informação seja replicado para todos os nós do cluster e consequentemente diminuindo o tráfego na rede. Aqui vale uma observação, acredio que essa feature possa ser utilizada no JBoss 4.0.x ou 4.2.x, bastando atualiazar o JGroups e o JbossCache.
2. Melhorias no serviço de mensagens (JBoss Messaging v. 1.4.1) que passará a usar a implementação do JMS 1.1, de performance melhor, permitindo cluster das filas (queues) e tópicos (topics) e redistribuições inteligentes de mensagens.
3. Failover transparente (essa eu quero ver funcionar mesmo! )
4. JBoss Web 2.1.0 como container web, que nada mais é do que um tomcat 6 turbinado, o pessoal da JBoss costumar dizer “Tomcat on stereoids“. Eles pegaram a api APR da apache e portaram para o tomcat, criando o JBoss Web com uma performance superior ao Tomcat.
5. Houveram mudanças na arquitetura de deploy.
6. API de configuração. Essa é a uma feature nova e segundo eu entendi ela irá facilitar a replicação de configurações do JBoss

Bem isso foi tudo que anotei e que me lembro da session.

Ahh! outra coisa que falaram é que eles não pretendem mais lançar mais nenhuma versão da família do JBoss 4.0.x (a versão 4.0.5 é a última) e que a família 4.2.x é uma versão intermediária entre as versões do JBoss 4.0.x e o JBoss 5 que está para ser lançado.

Esse link aqui também tem umas informações adicionais: http://www.theserverside.com/news/thread.tss?thread_id=43175

Hoje de manhã assisti um hands on alucinante sobre o JON, também conhecido como JBoss Operation Network. No hands on foi uma prática sobre os procedimetos básicos para a instalação e operação do JON. Recebemos um DVD com os arquivos a serem instalados durante o laboratório.

Já havia falado do JON, porém não sabia muito bem o que ele podia fazer e se ele realmente iria agregar algum valor na área de Produção. Vamos lá, com o JON podemos…

Inventário

Automatically discover

Cria grupos lógicos de JBoss instalados para facilitar a administração. Ex.: um grupo para o aplicativo A, outro grupo para o aplicativo B e por aí vai

Monitoração (Utilizacao de CPU, FileSystem, utilizacao da rede, metricas especificas para o Jboss AS, tomcat, hibernate, apache, postresql)

Operação (Start/stop/restart e etc)

Configuration (cria/atualiza servicos, i.e, datasources)

Deploy de application archives

Aplica patchs quando necessário

Fica claro na lista que o JON é uma ferramenta de monitoração e adminstração de Jboss, facilitando e muito a vida de quem precisa lida com o JBoss no dia a dia. Além disso, ele pode ser utilizado para relatórios, plano de capacidade/ocupação, uma vez que os dados coletados pelo JON são guardados num banco de dados (Oracle, Mysql ou Postgresql), havendo portanto um histórico. Basicamente o JON é composto de 2 componentes: o jon server que deve ser instalado em um servidor central qualquer e os agentes que ficam espalhados pelo parque de servidores que rodam JBoss. Como já mencionei antes, só é necessário um agente, mesmo que tivemos mais de uma instância de JBoss instalado. Outra feature interessante, é o que o JON permite a geração de alertas baseadas em thresholds pre-definidos, enviado a notificação por email.

Ele também pode exportar traps SNMP para serem coletados por algum outro serviço, o que em tese permitiria uma integração com o cacti apesar de no fim das contas termos 2 ferramentas para fazer a mesma coisa.

Vamos ao HandsOn!!!

Para instalar o JON precisamos instalar o JON (óbvio!!), o agente do JON, ter o jdk 5 (que eu felizmente já tinha no meu macbook) e um banco de dados. No laboratório acabamos usando o postgresql. O postgresql acabou fazendo com que que eu perdesse um pouco tempo, pois tive que instalá-lo (felizmente o macports me ajudou aí ) e configurá-lo. Tive que chamar um dos monitores para dar uma mão, pois eu nao tenho muita experiência com ele e tive que criar um usuário e database para o jon usar na munheca.

Os passos feitos estão na foto acima. Por fim, foi preciso carregar a liçenca fornecida, a qual é válida por 1 mês. Ahhh sim! O JON não é free, e apesar de ser pago, me parece que vale o investimento.

Instalando agente

Na versão 2.0, que ainda é beta, mas que será liberada ainda este ano, não é preciso passar o parâmetro de start. No fim, basta acessar o endereço no qual foi instalado para entrar no JON novamente. Infelizmente, fui nao pude avançar muito no laboratório pois havia perdido um certo tempo no início e quando eu ia começar a brincar com o JON instalado o tempo acabaou!

Minha opinião é que o JON é uma ferramenta que iria agregar muito valor na administração e operação dos Jboss, principalemente quando se fala de dezenas de instâncias rodando.

Orlando, Florida. Hoje começou o JBossWorld. Agora estou no meio de um brake e aproveitei para escrever um pouco desse primeiro dia. Assisti 3 palestras hoje, 1 muito boa, outra boa e outra ruim.

A palestra muito boa foi a primeira que assisti foi apresentada pelo Bela Ban e era sobre JBoss Clustering. Para quem sabe o Bela Ban é o “pai” do jboss cache. Já havia assistido algumas palestras sobre cluster em outros eventos que participei, mas mesmo assim resolvi ir lá conferir. A palestra começou com o Bela Ban falando um pouco do conceito de jboss clustering para sessões http dentro do JBoss.

Algumas coisas que ele falou já são bastantes conhecidas para quem já configurou um tomcat em cluster, ou seja, colocar a cláusula <distributble/> dentro do web.xml. Ao contrário do que algumas pessoas pensam, não precisamos replicar todos os dados da sessão http a torto e a direita e sim apenas algumas partes da sessão, a partir do que chamamos de granularidade da sessão. No Jbossweb isto deve ser feito no arquivo jbossweb.xml. Outro ponto importante é que se temos um cluster com 8 nós por exemplo e um dos nós tem sua sessão alterada, o dado alterado será replicado para todos os nós do cluster. Isto é ruim, a medida que o cluster se torna maior, devido ao grande número de dados sendo gerados na rede. Como exemplo, tome uma sessão com 2,5kb. No cenário sugerido, teremos a geração de 25kb de tráfego a mais rede, num sistema que na maioria das vezes já está “under pression“. Para tenuar o volume de dados na rede, podemos configurar cada nó do cluster para replicar um dado apenas para um par, o que seria seu backup, no que chamamos de “buddy replication“. Voltando ao papo de granularidade da sessão, podemos configurar o cluster para replicar apenas um atributo da sessão e nao todos os dados da sessão. E ainda, podemos e devemos configura o cluster para replicar uma sessão apenas quando o método SET é invocado, indicando que algum atributo foi alterado. A segunda parte da palestra foi marcada pela apresentação de um benchmark que foi feito com diferentes tipos de configurações. Ficou evidente que o attribute replication foi mais perfomático em conjunto com o buddy replication. Uma observação deve ser feita, o buddy replication gera stress no sistema quando um dos nós cai, pois o cluster precisa ser reorganizado, quem vai replicar para quem, quais são os membros do cluster e etc… Na terceira parte da apresentação foi apresentado algumas dicas para melhorar a performance de um cluster jboss que irei procurar resumir aqui.

1. MaxClients (Apache) = maxThreads (Jbossweb)
2. Usar a biblioteca native da APR desenvolvida para o jbossweb
3. Usar JBoss EAP (JBoss Enterprise Application), dependendo da natureza e criticidade da aplicação
4. Utilizar a console JMX para obter informações de utilização de cpu e thread dump (kill -3)
5. Setar timetou para a sessão http
6. Dar um call invalidate quando terminar de mexer na sessão
7. Tune logging
8. Remover do jboss serviços que não serão utilizados
9. Ter uma rede para as requisições de clientes http, outra para o AJP e outra para o tráfego sendo replicado
10. Utilizar a feature de domains do mod_jk para criar sub clusters dentro de um cluster

Ufa! Isso foi tudo sobre a primeira palestra, desculpem por ter me estendido tanto.

 

A segunda palestra que assisti foi sobre EJB3. Não gostei da didática do palestrante e ficou tudo muito confuso. A terceira palestra achei muito boa, sobre um produto chamado JON, ou JBoss Operation Networks. Não sei quão estável está esta ferramenta, mas sei que seria muito útil num ambiente de produção, pois ela permite gerenciar instâncias de JBoss instaladas ao longo do parque de servidores de uma empresa, permitindo verificar versão do jboss (fazer um inventário), se a vm está de pé, atualizar a versão do software, entre outras coisas. Sexta-feira, dia 15/02/2008 , haverá um Hands-On sobre esta ferramenta. Basicamente, ela consiste de um agente que é instalado no servidor, responsável pela monitoração da vm do jboss e uma interface web onde são visualizados os dados gerados e/ou obtidos.

Vale ressaltar, que mesmo que tenhamos mais de um jboss instalado só é necessário um único agente rodando, e em tese, eu disse em tese :), ele iria detectar automaticamente qualquer novo jboss que fosse instalado.