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.

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

Que beleza, o cluster estava sendo construído, mas eu precisa poder testar sua capacidade de processamento e minha primeira ação neste sentido foi criar uma aplicação web para instalar no cluster. Esta aplicação web deveria ter que acessar uma base de dados para que simulasse uma aplicação real, que fizesse transações na base de dados, como consultas e gravações.
Eu já tinha resolvido iniciar estudos em Java e na época estava brincando com Mentawai (http://www.mentaframework.org) para desenvolvimentos de aplicações J2EE (este seria meu framework MVC). Antes dele estava penando estudando Struts e depois Webwork2, mas não era nada fácil produzir algo em Java e ter que declarar um monte de coisas em XML. Com Mentawai era tudo muito mais "natural" para mim, logo consegui desenvolver a aplicação web para rodar em Tomcat no cluster (já havia desistido de usar apache, porque para meu projeto, o Tomcat iria servir bem).
Beleza, a aplicação web rodando no cluster, eu acessava com Firefox, mas e como medir os tempos de processamento? Quantas requisições por segundo o cluster era capaz de processar. E se eu tivesse um cluster com 2 nós, 3 nós, ou mesmo um só computador, como eu iria obter resultados para comparação?
Antes mesmo de procurar por uma ferramenta para medição de performance, atraquei-me no desenvolvimento de uma aplicação desktop (com swing, nesta época o matisse estava me salvando, por isto optei por desenvolvê-la em Java) para disparar requisições contra o cluster e obter os tempos de cada resposta. Estava bem legal, mas para minha surpresa, o computador cliente, que estava disparando as requisições ao cluster, retornava praticamente os mesmos valores, independente de utilizar 1, 2 ou 3 computadores no cluster (certos estamos de que 1 nós não seria um cluster). Rapidamente tive a idéia de monitorar o uso de CPU de cada nó durante uma sessão de processamento e foi aí que descobri que meu notebook com processador pentium IV de 2.8GHz não seria capaz de elevar o uso de CPU, nem mesmo o nó primário (um athlon 3000+) de cluster a 100%, ou seja, o cluster estava com folga, mesmo que eu utilizasse um só nó, eu deveria ter que utilizar mais computadores clientes e aí estava um grande problema. A muito custo consegui comprar mais dois "jogos" de gabinete, placa-mae, memoria, disco rígido e processador para, juntamente com meu PC (o primário) formar o cluster. Eita projetinho mal elaborado!

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

Para que eu pudesse ter balanceamento de carga e cada nós rodando um servidor web, eu precisava da base de dados disponível para cada nó o mais imediato possível. Minha idéia era de que cada nós teria uma cópia da base de dados, até mesmo para auxiliar na tarefa de alta disponibilidade. O problema era sincronizar estes dados todos. Isto levou-me a pesquisar sobre sistemas de arquivo replicados em rede, como OCFS2 e GFS, pensando que nisto meu problemas de replicação de dados estariam resolvidos, mas não foi nem perto, depois de muito pelear com GFS, passei a utilizar OCFS2 com o auxílio de um de seus desenvolvedores e consegui colocá-lo em funcionamento, mas não havia forma de conseguir fazer o mysql de um nó enxergar os dados gravados pelo mysql de outro nó, deveria ser algo relacionado a cache que o mysql faz. Voltei para o GFS, já entendendo um pouquinho de replicação de dados em rede e consegui fazâ-lo funcionar. Ah! Esqueci de dizer que eu usava Debian e faria tudo em Debian.
De tanto fuçar até que consegui fazer o mysql, às vezes, um nó enxergar os dados gravados por outro, mas tive que desabilitar tudo quanto é cache, não poderia usar transação (InnoDB) e até mesmo uns negócios de flush do disco rígido tive que configurar. Tentei até mesmo postgresql, mas depois de muito procurar, fiquei sabendo que um diretório que armazena uma base de dados não pode ser acessado por mais de um processo servidor postgresql ao mesmo tempo, ele usa umas travas e o servidor postgresql do segundo nós já não podia abrir a base.
Estava tudo errado, eu queria uma solução de balanceamento de carga que não precisasse ser vinculada a um único fornecedor de banco de dados. Em conversa com o desenvolvedor do OCFS2, este até recomendou-me utilizar uma versão do banco de dados da Oracle com suporte nativo a replicação. Mas se fosse o caso usaria o mecanismo de replicação nativo do Mysql e não era minha intenção.
Passaram-se quase dois meses de pesquisa intensa, até que resolvi que não replicaria a base de dados, todos acessariam do nó principal, o redirecionador, e por minha sorte, ao estudar sobre balanceamento de carga com LVS, "achei" o DRDB e meu problema de replicação de dados estava em partes resolvido. Embora eu pudesse somente ter uma cópia dos dados replicada em outro servidor, este era o modelo do meu cluster para alta disponibilidade, em caso de falha do redirecionador, um outro nó, previamente configurado, assumiria o papel daquele, usando os dados replicados, mas um pouco antes disto até tentei fazer com que o DRDB permitisse gravação em ambos nós, o primário e o secundário, mas não teve jeito, a versão de uso ainda não permitia que o secundário montasse a partição para escrita, somente, leitura, então abandonei de vez a idéia de a base sendo gravada por diversos nós, somente o redirecionador ou primário o faria.
A partir disto, acredito que já era março, passei a implementar LVS e DRDB, para, por fim, Heatbeat e Keepalived. Não que eu tenha terminado em março, mas sim acredito que eu já havia conseguido descobrir todos os componentes de software livre eu precisaria para poder implementar o cluster e realmente as pesquisas feitas nestes dois primeiros meses (janeiro e fevereiro/2006), foram as responsáveis pelo êxito do projeto. Estas pesquisas deveriam ter sido feitas lá em 2004, mas na época eu não estava muito a fim de passar trabalho.

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

Finalmente, no final de 2004 eu havia pensando em algo para o Trabalho de Conclusão de Curso que não fosse desenvolver um sistema. Resolvi que iria enfrentar a tarefa de desenvolver um cluster, afinal, não tinha conhecimento de que alguém no campus da Ulbra tivesse elaborado trabalho parecido e eu julgava-me competente para abraçar esta tarefa utilizando somente software livre.
No início de 2005 apresentei o projeto à banca e a orientaçao do curso veio com a boa notícia de que estava aceito. A princípio, no projeto, especifiquei uma meia dúzia de requisitos para construir o cluster, acredito que eu tenha trabalhado 2 dias neste projeto, o que me fez ter certeza de que em um ou dois meses, utilizando open-mosix eu teria um cluster para rodar aplicações web rodando a milhão. Este foi meu maior erro durante o TCC.
Resolvi que não cursaria o segundo semestre de 2005 e daria início ao TCC somente em 2006, o que efetivamente ocorreu. Chegou então Janeiro de 2006 e tirei para começar a estudar, novamente, open-mosix e algumas coisas a mais que seriam necessárias para construi este cluster, ainda nem estava pesando onde arranjaria os computadores para montar este cluster.
Lia Pitanga falando dos tipos de cluster e foi então que caiu a ficha. Um cluster open-mosix não serviria para aplicações web com apache! Ele era voltado para cálculos paralelizados, utilizando bibliotecas em C para criação do programa a ser paralelizado, era um cluster do tipo de alta performance. Eu definitivamente não queria aceitar que não daria para rodar apache, bem mais rápido, com open-mosix, mas tudo que eu lia era afirmando que não trazia vantagens e que no máximo eu teria que usar um esquema de cache de memória sei lá das quantas... Bom, tive que abandonar open-mosix, o que não poderia ser diferente.
Passei então a estudar o domínio do problema, o que deveria ter feito lá em 2004 com mais vontade. Cheguei então ao tipo de cluster para balanceamento de carga e alta disponibilidade. Em termos de resultado, o de balanceamento de carga daria para mostrar em gráficos as diferenças no número de requisições concluídas pelo cluster em um terminado tempo. Mas ao mesmo tempo achei muito interessante uma solução de alta disponibilidade para um ambiente como o da Prefeitura. Pronto, estava resolvido, modifiquei um pouco a proposta e reapresentei, agora citando cluster para balanceamento de carga e alta disponibilidade. Mas isto não era nada do que eu eu iria passar ainda.