2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 005

Vou tentar segui uma sugestão anônima para criação de frases mais curtas de agora em diante. Quem sabe assim, meus textos possam ser melhores compreendidos. Bom, mas se nem eu mesmo, às vezes, me entendo, como fazer meus leitores compreenderem-me plenamente? (Adorei a expressão "meus leitores"). ;-)
Até que enfim eu tinha conseguido superar o problemão de "adormecimento" esporádico do cluster e agora ele funcionava "a mil". Ainda havia um detalhe que não consegui resolver até o final do trabalho e vou relatá-lo resumidamente (a minha moda) para que, quem sabe, alguém possa me dizer o que estava havendo.
Um computador cliente, em uma sessão de testes, fazendo requisições por, digamos 10 minutos, nunca conseguia fazer com que o cluster (nos primeiros testes somente um computador, o primário), chegasse próximo a 100% de uso da CPU. E não era porque o cliente era fraco, pois normalmente não exigia mais de 30% de CPU do cliente neste tipo de teste, enquanto que o cluster não chegava a 80%. Cheguei até a tentar virtualização com Xen para fazer com que um computador rodasse várias instâncias servidoras tentando obter o máximo de sua performance, mas não adiantou em nada. Para ilustrar mais um pouco e tentarem compreender o problema, se eu utilizasse 2 computadores clientes, cada um ocuparia no máximo 20% de sua CPU (média) durante 10 minutos de teste e o cluster, então, passava de 80%. Se no teste fosse utilizado 3 computadores clientes, cada um também usava em média 20% da CPU, mas então o cluster já era carregado a mais de 90%. Nunca entendi isto, procurei razões, gargalos de rede ou de entrada/saída, mas não encontrei.
Estava na responsabilidade de conseguir computadores clientes, para meu cluster de 3 nós, que fossem capazes de "sugar" o máximo de sua capacidade e graças a Deus consegui isto para praticamente todos os meus teste, só um, entre diversas configurações de teste é que não consegui obter, com 3 computadores clientes, 100% de uso da CPU do cluster na configuração de 3 nós.
Até agora ainda Java parece algo pouco irrelevante para o Trabalho de Conclusão, mas lá por maio ele tornou-se peça fundamental. Como nesta época eu já tinha o cluster funcionando (até tive que refazê-lo logo após usar xen, pois consegui destruir com todos os arquivos de configuração do primário), e estava sobrando tempo para algo a mais.
Foi aí que meu orientador de TCC, Alexandre Timm, fez-me aceitar que o mais importante do meu TCC não era o cluster e sim as ferramentas para medição de performance que eu tinha iniciado como um instrumento simples para poder comparar os resultados em diversos tipos de configuração do cluster: 1 nós, 2 nós, 3 nós, entre outros detalhes, para apurar se realmente um cluster obteria alguma vantagem em relação a um computador só.
Que ótimo que este modelo de cluster trazia bons resultados, imagina se eu tivesse perdido meses pesquisando e iniciado o projeto, comprado computadores para verificar que não servia pra melhorar a performance, no máximo para alta disponibilidade, eu teria ficado muito decepcionado.
Era incrível, pois o cluster já tinha failover e failback funcionando. Era desligar o primário "na marra" que o secundário assumia suas funcões, a base de dados postgresql não ficava comprometida e somente a performance é que ficava diminuída. Colocava o primário no ar e este reassumia suas funções, atualizando em disco tudo aquilo que estava desatualizado (somente a partição da base de dados, que era a única coisa realmente mutante do cluster) era automagicamente atualizada e o cluster retomava sua capacidade máxima. Inclusive se um nó parasse de funcionar, o cluster reconhecia e se regulava.
Voltando ao Java, passei então a aprimorar todos os componentes que estava utilizando, separando-os e melhorando a troca de informações entre eles. Eu tinha então:

• uma aplicação web rodando em cada nós do cluster;
• uma aplicação cliente rodando em cada computador cliente
• uma aplicação console que coordenava todos os computadores clientes, iniciando uma sessão de teste simultaneamente e obtendo e armezanando os resultados verificados pelos clientes
• uma aplicação que chamei de gráficos para comparar resultados de testes

É tão extensa as possibilidade de configuração de "peso" por nó para um determinado tipo de processamento, que obtive resultados extraordinários entre um teste e outro, simplesmente mudando estes "pesos" (se realmente alguém estiver interessado posso disponibilizar meu TCC para isto, mas acredito que valha a pena somente para quem esta trabalhando com clusters mesmo).
Aprendi muito sobre Java, tive que usar extensivamente Thread (algo que era totalmente obscuro pra mim), e confirmei que Java é uma ótima plataforma, mesmo em intensa carga jamais "arriou", no máximo apresentou problemas que eu custei muito a saber o que era, hehehe, mas por causa de um módulo de memória que pifou e fazia a aplicação web (na verdade o tomcat), simplesmente sumir da memória.
Estava na transição entre Java 5 e Java 6, e mesmo sendo beta, utilizei Java 6 em praticamente todo o trabalho.
Algo muito engraçado que ocorria era que em testes, distante do meu laboratório, um Athlon 64 3000+ com Debian Sarge, podia processar algo como 30% a mais de requisições que um Athlon 64 3500+ com Windows XP. Este Athlon 64 3000+ era o servidor (ainda é), de banco de dados da prefeitura e o Athlon 64 3500+ era o notebook do meu colega que jamais teve intenção de se ligar ao mundo livre e simplesmente ignorava-o por não lhe fornecer as ferramentas que ele precisava. Então, por causa disto, muitas e muitas vezes "arriava-me" nele por um "simples" Athlon 64 3000+ sem bem mais poderoso, com Linux, que seu ínfimo Athlon 3500+ com ruindous.
Chegou o dia da apresentação do TCC para a banca e era, basicamente, demonstrar como fôra todo o planejamento e construção do cluster, bem como das ferramentas para medição de performance que tinham se tornado tão ou mais importante que o próprio cluster para o escopo do trabalho. Sempre tive muita dificuldade para falar em público, imagina na defesa do TCC!
Minha namorada (na época, hoje noiva. TE AMO), levou uma filmadora para o local da apresentação, mas pedia a ela para não filmar, pois saberia que dificultaria mais ainda meu rendimento. Antes da demanda, a todo momento verificava se ela não estava tentando me enrolar, mas para minha surpresa, quando iniciei a apresentação foi como se minhas vistas se fechassem a tudo, só vinha a minha cabeça parcelas do meu trabalho ancoradas por tópicos de uma apresentação do OpenOffice.org Impress preparada para isto. Consegui consumir mais que 45 minutos e eu achava que poderia falar tudo em menos de 15. Aliás, seriam somente 15 minutos de apresentação por TCC se mais do que somente eu, formando, estivesse terminando a graduação naquele semestre.
Ah! A Katy, sem que eu percebesse, fez toda a filmagem da apresentação e foi um sarro só rever minha performance. Como eu sou ruim de apresentação!
Acredito que este relato sobre meu TCC, Gnu/Linux e Java termine por aqui, a não ser que me venha a cabeças mais algumas coisas interessantes que ocorreram neste período.