Trabalhos realizados

O meu estágio supervisionado, realizado ao longo de 2003 se deu no Laboratório de Sistemas Integráveis, da Escola Politécnica da USP (LSI).

O LSI é um laboratório que além de desenvolvimento de pesquisas dentro da Universidade, mantém projetos com empresas. O LSI atua em uma grande diversidade de áreas de tecnologia, tais como computação gráfica, realidade virtual e desenvolvimento de circuitos.

O projeto no qual trabalhei é em conjunto com a Itautec. A Itautec é uma empresa que faz parte do grupo Itaúsa--Investimentos Itaú S.A. A Itaúsa é uma das primeiras holdings puras de capital aberto do Brasil e é composta de uma série de empresas que atuam nos mais diversos mercados, tais como os setores financeiro, imobiliário, eletrônicos, louças, metais sanitários ou química.

Minha posição no LSI foi de estagiário na equipe que desenvolve o sistema de Cluster da Itautec. A equipe, entre outras atividades, desenvolve uma distribuição GNU/Linux baseada no sistema Red Hat para ser usada com clusters Itautec.

Logo que entrei na equipe, em fevereiro de 2004, fui incumbido de desenvolver a parte de Alta Disponibilidade junto com outro membro da equipe, Sandro Pedro Giusti. Não me foi passado um prazo ou uma data limite para o trabalho, contudo tinhámos reuniões semanais para decidir sobre o andamento do projeto.

A equipe na qual estava inserido era formada por Silvio Marangon que desenvolve a ferramenta de configuração do cluster, Jefferson Maximo da Silva que junto com o estagiário Jonatas Carneiro desenvolvem a parte de SCSI, por mim e Sandro P. Giusti que cuidamos da parte de alta disponiblidade, Volnys Borges Bernal é o coordenador do projeto. Além disso, tem mais algumas pessoas que trabalhavam fora do nosso espaço com outras atividades do cluster, assim como Edson Massao e Roberto Kenji.

As primeiras semanas passei procurando e avaliando textos e sites sobre alta disponibilidade, conceitos e colocando-me à par do que ocorria no cenário da alta disponibilidade para saber procurar, avaliar e selecionar características no software que empregaríamos.

Foi assim que entrei em contato com [2][4][5]. Particularmente, [2] mostra a experiência de Sulamita Garcia em montar um cluster de alta disponibilidade, este guia me serviu como base para os primeiros testes no nosso cluster.

Logo, os membros da equipe ficaram responsáveis pela elaboração de palestras sobre as áreas em que estávamos trabalhando. Em particular, eu devia ministrar uma palestra sobre alta disponibilidade, enquanto meu colega, Sandro P. Giusti, fora incumbido da palestra de alta disponibilidade em Linux, o que basicamente seria explicar a solução em que estavamos trabalhando. Minha abordagem deveria ser basicamente conceitual.

Para realizar essa palestra, me utilizei fortemente de [6], que me foi gentilmente indicado e cedido pelo meu chefe, Volnys Borges Bernal, para me servir de apoio.

Ao longo do semestre implementamos, nesta ordem, o sistema de redundância de máquinas, controlado pelo heartbeat (para maiores detalhes sobre o funcionamento das tecnologias mencionadas referir-se à seção ), a redundância de discos remotos e o monitoramento de recursos.

A nossa configuração era genérica e poderia servir para diversos tipos de serviços. Particularmente, para servidores de arquivos, web, ftp, etc.

Neste momento fiquei sabendo que o real objetivo para o qual estavamos desenvolvendo alta disponibilide era para um servidor de NAT (ver seção ).

De certo modo, a alta disponibilidade de um gateway é mais simples do que a que estávamos desenvolvendo porque não envolve monitoramento de serviços e até a replicação de discos, em princípio pode ser omitida, pois a única utilização de discos em um gateway é para logs e configuraçãoes.

Como as configurações são estáticas não há necessidade de se aumentar a complexidade de solução quando podem simplesmente ser sincronizadas e mantidas idênticas em todos os nós-membros do cluster. O problema de sincronização das informações é de solução trivial, e não requer altos tempos de ressincronização a cada failover como descrito em , na página .

Pode ser, no entanto, conveniente manter os logs em disco remotamente compartilhado para preservar a sua seqüência indepententemente do nó que está em estado primário. No momento da escrita deste texto ainda não foi decidido se vamos usar uma solução baseada em DRBD ou não. Talvez seja conveniente comprar um disco compartilhado.

Mesmo sendo mais simples nos aspectos citados, um cluster de NAT em alta disponibilidade apesenta um problema altamente não trivial que é a manutenção das conexões ativas após um failover.

A priori, a solução disto parece similar ao DRBD (ver seção  na página ), manter os estados da tabela de NAT replicados entre as máquinas. A situação é deveras análoga, com a diferença apenas de que ao invés de manter estados de disco, mantêm-se estados de memória.

A complexidade do problema surge porque um servidor de NAT pode trabalhar com uma enorme carga de dados, o que pode levar a um overhead proibitivo.

Uma das propostas foi de que eu, em conjunto com meu chefe, Volnys B. Bernal, alterássemos o kernel para produzir as mudanças desejadas. Ao longo de julho achamos uma proposta de uma solução mediante LVS (ver seção ) e começamos a implementar um cluster LVS sobre o cluster HA.

No meio do processo o meu colega, Sandro P. Giusti foi desligado da equipe e, por motivos que não cabem aqui, ele eliminou todos os dados da nossa pesquisa e eu fui obrigado a retomar a pesquisa desde o zero para produzir novamente a documentação do nosso trabalho até aquele momento.

Tive que gastar algum tempo procurando a bibliografia (linkografia) e refazendo procedimentos, preparando arquivos de configuração do kernel, etc.

No momento atual, estou projetando o sistema de interfaces de configuração, para automatizar o processo que foi desenvolvido.

Em nenhum momento do trabalho houve datas limite explicitas, houve, porém, como já foi dito, reuniões periódicas para decidir semanalmente sobre o andamento das atividades. Tive um bom tempo para pesquisar e testar, portanto pouca coisa ficou para trás.

Uma das coisas que eu gostaria de ter feito é a mudança no kernel do Linux, que foi iniciada, porém não foi concluída porque o trabalho de interfaces de configuração ganhou prioridade.

Eu nao participei de nenhum treinamento durante o ano de 2003.