quarta-feira, 9 de janeiro de 2008

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.

2 comentários:

Anônimo disse...

Ola Amigo uma duvida nao e possivel usa o DRDB para transporta dados de ambas as maquinas ? tanto primaria quanto secundaria replicariam uma para outro pq ai poderia fazer balaceamento de carga com dns.
vou começa implementa com xen
se pode me da umas dicas
meu email e msn eh brunowcs@gmail.com
Abraços

biande disse...

Buenas amigo! Bom, nunca utilizei dns pra balanceamento de carga, utilizei o LVS (Linux Virtual Server), não é tão complicado assim e ele dispôe de inúmeros algoritmos de escalonamento que podem fazer uma grande diferença no resultado final, permitindo atribuição de pesos às máquinas que compôem o cluster, permitindo dar mais trabalho àquelas que são mais "fortes". Na época que estava utilizando DRBD até já estava sendo permitido montar dois computadores como master e acho que com algo como "autoreplicação", mas preferi utilizar o clássico master e slave, gravando tudo no nó primário do LVS que sempre será o responsável pelo IP virtual, se o primário cai, então ao secundário assumir ele passará a responder pelo IP Virtual e passará seu DRBD slave a atuar como master, até que o verdadeiro primário seja posto em operação e se o auto failback estiver habilitado, o verdadeiro primário assume novamente a condição de primário e o secundário transformado em primário volta a secundário, sendo que antes disto o verdadeiro primário atualiza tudo que foi gravado no secundário para sua partição a fim de ter os dados sincronizados. É um pouco confuso, se quiseres te envio o TCC que acredito está bem esmiuçado e ficará mais fácil entender.

Abraços