Gustavo Soares

Foi tudo decidido em cima da hora e cá estou eu para participar da primeira conferência voltada para o Puppet: PuppetConf. Para vocês terem idéia, eu fiquei sabendo que iria vir na sexta-feira, dia 16/09/2011 e depois disso foi aquela correria para fazer inscrição, arrumar as passagens, hospedagem e o adiantamento. Cheguei hoje (quarta-feira, dia 21/09/2011) em Portland e amanhã já começa. Ainda bem que costumo me adaptar rápido ao fuso horário, espero que dessa vez não seja diferente.

Comecei a usar o puppet em 2009, e hoje 2 anos depois, é com muito entusiasmo que fico em poder assistir uma série de palestras dessa tecnologia que mudou a forma com que os servidores são instalados, configurados e mantidos na empresa que trabalho atualmente. Realmente considero o puppet uma ferramenta fantástica e juntamente com o Chef, eles são os big players do mercado para sistemas de gerência de configuração. Já escrevi alguns artigos aqui no blog sobre puppet.

A programação das palestras você encontra aqui. Pela descrição de algumas, vai ter momento que vou querer me dividir em 2!!

Para finalizar este post uma coincidência que aconteceu… Meu aniversário é no dia 6/11, o número do quarto que fiquei é o 611. E eu com isso, certo!? Você deve estar pensando… ))))

Speaker Presentation Slides
http://en.oreilly.com/velocity2010/public/schedule/proceedings

Watch Velocity 2010 Video
http://www.youtube.com/view_play_list?p=D1D3B0B233F2AD66

View Velocity 2010 Photos
http://www.flickr.com/photos/oreillyconf/sets/72157624218154391

Velocity News and Coverage
http://en.oreilly.com/velocity2010/public/content/news-coverage

Acabou tem pouco tempo o keynote sobre a operação do Twitter aqui no Velocity. O keynote foi apresentado pelo Jonh Adams. Apesar dele não ter entrado no detalhe de muitas coisas, achei bem legal saber as tecnologias que eles vêm utilizando lá.

Algumas, inclusive já são adotadas na Globo.com, como por exemplo a utilização do puppet na gerência de configuração. E outras, em fases de teste piloto, como por exemplo o scribe, que testei mês passado como solução para agregar logs dos servidores. Só posso adiantar, que os testes foram bem promissores.

Alguns pontos chaves mencionados no keynote:

Utilize um sistema de gerência de configuração independente do tamanho da sua infraestrutura

A maior parte do acesso ao twitter hoje em dia vem da API, através de aplicativos de terceiros e não via web (novidade!!! )

A final da NBA (Lakers x Celtics) gerou um tráfego de 3085 TPS (Tweets por segundo )

Syslog não escala muito bem para um alto tráfeo de dados. Para a agregação de logs eles estão utilizando o Scribe do facebook.

Assim como o Facebook eles também utilizam uma solução com torrent para deploy nos servidores (ok… ambas empresas tem um número estúpido de servidores, imagino…)

Na média são escrito 750 tweets por segundo diariamente… faça as contas, e veja quanto isso dá em 1 dia

Utilizam apache atrás dos balanceadores de carga

Monitoração e extração de métricas forte dos dados para gerar gráficos e relatórios

Utilizam o Unicorn como engine de rails

Utilizam um banco de dados próprio para lidar com os grafos sociais (A segue B, que não segue B, mas que segue C e por aí vai…)

Utilizam uma solução com Hadoop para extrair informações relevantes dos logs

Tirei algumas fotos dos slides do Keynote do Twitter. Elas podem ser acessadas no meu flickr, no seguinte endereço: http://www.flickr.com/photos/gustavosoares/sets/72157624223796237/

Para mais infos, consultem também a página http://twitter.com/about/opensource

Fuiii!! vai começar uma palestra agora!!

Cheers!!

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

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.