Adicionando mais nós

Uma vez instalado, diversas abordagens podem ser feitas de acordo com o contexto e as necessidades específicas atribuídas ao cluster. Em um laboratório público, por exemplo, onde os computadores devem estar disponíveis para diversos fins, pode-se usar o cluster descentralizado, onde cada um dos nós será instalado seguindo os mesmos passos acima expostos e garantindo, assim, a independência de cada nó. Desta forma, uma vez iniciado o cluster (krgadm cluster start), os processos executados em qualquer dos nós serão distribuídos aos demais, sendo abstraído aos usuários o processo de migração. Cada um dos computadores se comportará como uma grande maquina SMP, dispondo da soma de todos os recursos distribuídos.

Apesar da cansativa instalação dos nós, o modelo descentralizado pode ser facilmente alcançado usufruindo de métodos que visam acelerar o processo. Um exemplo é a utilização de um fast install, que possibilita replicar, sem muito esforço, toda configuração de uma maquina para todas as demais em uma rede, semelhante a uma clonagem de disco, porém mais bem elaborada.

Concluído o processo de fast install, os nós só precisam ser ajustados quanto a configurações específicas, como IP e node_id, a fim de se integrarem corretamente ao cluster, que já estará disponível.

Nós sem disco rígido

Outra abordagem geralmente adotada quando não há necessidade de que os nós, exceto o central, estejam disponíveis para usuários, é a utilização destes sem um disco rígido. Este tipo de cluster normalmente é preferível, porém ressalta-se mais uma vez que o método escolhido deve levar em consideração as necessidades do laboratório.

Para este método, pode ser usada uma instalação mínima do sistema no nó central, a qual será utilizada pelos demais nós, compartilhada via TFTP; que disponibilizará a imagem do kernel e configurações de boot, NFS; que exportará o sistema de arquivos, possibilitando que este seja montado remotamente e um servidor DHCP; que fará a configuração automática dos nós, elevando, desta forma, a escalabilidade do cluster.

O quadro 4 demonstra a configuração para uso através de um sistema mínimo de arquivos. Caso se deseje aproveitar a instalação realizada na seção 1, pode-se seguir adiante e pular este quadro.

Quadro 4: Instalando um sistema mínimo de arquivos (chroot)

O compartilhamento do sistema de arquivos pode ser configurado de acordo com os passos abaixo.

Iniciar o computador escolhendo, no grub, o kernel do kerrighed e instalar os serviços:

#apt-get install dhcp3-server nfs-kernel-server nfs-common tftpd-hpa syslinux

Configurando TFTP

Copiar a imagem do kernel para o diretório do tftp:

#cp /boot/vmlinuz-2.6.20-krg /var/lib/tftpboot

Copiar arquivo pxelinux.0 para o diretório do tftp, necessário para o boot via rede:

#cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot

Criar diretório que disponibilizará os arquivos com as configurações necessárias para que os nós iniciem corretamente:

#mkdir pxelinux.cfg

A documentação do kerrighed instrui a criação de um arquivo default, no diretório criado acima, que conterá as configurações de boot para os nós, semelhante a um grub, porém via rede. O conteúdo deste arquivo de configuração pode ser visto abaixo:

### /var/lib/tftpboot/pxelinux.cfg/default ###

default cluster

label cluster

kernel /vmlinuz-2.6.20-krg

append console=tty1 root=/dev/nfs initrd=/initrd.img-2.6.20-krg nfsroot=<IP_DO_NÓ_CENTRAL>:/ ro ip=dhcp pci=nommconf session_id=1

######

Porém, esta abordagem reduz a escalabilidade do cluster, visto que um só arquivo será utilizado por todos os nós durante o boot, não sendo possível, assim, configurar-se o node_id específico de cada um dos nós automaticamente. Repare que no nó central, esta configuração é feita no arquivo menu.list do grub, após session_id.

Uma solução para esse problema é disponibilizar um arquivo de configuração para cada um dos nós, o qual irá atribuir o node_id durante o boot, a fim de que o nó se integre ao cluster sem a necessidade de posterior configuração. O TFTP pode atribuir, automaticamente, um arquivo de configuração para cada nó de acordo com o IP, porém para que este “casamento” entre arquivo e nó seja bem sucedido, é necessário, também, que os nomes dos arquivos sejam iguais aos respectivos IPs dos nós, em hexa-decimal. O exemplo abaixo pode esclarecer melhor a situação:

Nó 2 recebe IP: 192.168.0.4 ßà TFTP envia arquivo de configuração: C0A80004 (o IP em hexa)

Nó 3 recebe IP: 192.168.0.132 ßà TFTP envia arquivo de configuração: C0A80089 (o IP em hexa)

E assim por diante.

Isto significa que o TFTP terá que ter um arquivo para cada possível IP atribuído pelo DHCP. Essa tarefa pode ser facilmente auxiliada por um script/programa que os gere, cada qual com um node_id diferente. Foi escrito um programa em java com esse objetivo, que pode ser obtido no link: www.joaomatosf.com/files/ConvIpHexa.jar e seu código segue no quadro 5.

Quadro 5: Programa em Java para gerar os arquivos de configuração do TFTP automaticamente:

Para gerar os arquivos de configuração com o programa, é necessário informar apenas o diretório raiz do sistema (que será exportado mais adiante pelo NFS), a faixa de IPs que será usada pelo cluster e o IP do nó central. Os passos abaixo demonstram essa configuração:

#java –jar ConvIpHexa.jar

Diretório NFS compartilhado[ex: /NFSROOT/kerrighed]: / [ENTER]

Faixa de IPs para os nós[ex: 192.168.0]: 192.168.0 [ENTER]

IP do servidor NFS[ex: 192.168.0.1]: 192.168.0.1 [ENTER]

O programa irá gerar um arquivo para cada IP da faixa informada, os quais deverão ser movidos para o diretório /var/lib/tftpboot/pxelinux.cfg.

Configurando NFS

O NFS é responsável por permitir a montagem remota dos diretórios como se fossem diretórios locais. Sua configuração é simples e feita no arquivo /etc/exports.

Abre-se o arquivo de configuração e adiciona-se as linhas abaixo:

#pico /etc/expots

### /etc/exports ###

/ *(rw,no_root_squash,no_subtree_check,async,fsid=1)

/tmp *(rw,sync,no_root_squash,no_subtree_check)

/var *(rw,sync,no_root_squash,no_subtree_check)

/root *(rw,sync,no_root_squash,no_subtree_check)

/etc *(rw,sync,no_root_squash,no_subtree_check)

######

Caso se deseje limitar a faixa de IPs que poderá montar os diretórios remotos, pode-se substituir os “asteriscos” pela faixa pretendida, de acordo com o exemplo abaixo:

/ 192.168.0.0/255.255.255.0(rw,no_root_squash,no_subtree_check,async,fsid=1)

Após alterar o arquivo exportfs, o seguinte comando deve ser usado para pôr as modificações em vigor:

#exportfs –avr

Configurando fstab e initrd

O arquivo /etc/fstab deverá refletir os diretórios exportados pelo NFS, a fim de que estes sejam montados durante o boot dos nós remotos. Deve-se criar um backup do arquivo original e um novo com o seguinte conteúdo:

#mv /etc/fstab /etc/fstab.old

#vi /etc/fstab

none /proc proc defaults 0 0

none /sys sysfs defaults 0 0

none /var/run tmpfs defaults 0 0

/var /var nfs rw,soft,nolock 0 0

/tmp /tmp nfs rw,soft,nolock 0 0

/root /root nfs rw,soft,nolock 0 0

#we need this as rw to setup ssh (refer to our ramdisk.sh script)

/etc /etc nfs rw,soft,nolock 0 0

/dev/nfs / nfs defaults 0 0

Após a alteração acima, deve-se gerar um novo initrd que seja capaz de montar os diretórios remotos durante o boot.

No arquivo:

#vi /etc/initramfs-tools/initramfs.conf

Substitui-se a linha:

BOOT=local

Pela linha:

BOOT=nfs

Em seguida, deve-se gerar o novo initrd:

#mkinitramfs –o /var/lib/tftpboot/initrd.img-2.6.20-krg 2.6.20-krg

Este initrd carrega os módulos necessários para o computador iniciar e montar os diretórios do fstab. Porém, além dos módulos necessários para iniciar o PC, deve-se também garantir que o modulo kerrighed, necessário para funcionamento do cluster, seja carregado automaticamente durante o boot, de acordo com os passos abaixo:

No arquivo /etc/modules, adiciona-se a linha dos módulos que se deseja carregar:

#vi /etc/modules

# /etc/modules: kernel modules to load at boot time.

#

# This file contains the names of kernel modules that should be loaded

# at boot time, one per line. Lines beginning with "#" are ignored.

Kerrighed

Configurando DHCPD

O servidor DHCP é o serviço responsável por informar aos nós o arquivo pxe de configuração, além de lhes atribuir os IPs. Existem diversas configurações possíveis para um servidor dhcp, onde, normalmente, pode-se “amarrar” IPs aos MACs, informar configurações específicas para cada nó, entre outras. A configuração julgada mais viável para este tipo de aplicação é feita em poucas linhas, que seguem abaixo:

Cria-se um backup do arquivo de configurações original:

#mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.old

Gera-se o novo arquivo com o seguinte conteúdo:

#vi /etc/dhcp3/dhcpd.conf

allow booting;

allow bootp;

# What IP range to serve:

subnet 192.168.0.0 netmask 255.255.255.0 {

range 192.168.0.2 192.168.0.250;

option broadcast-address 192.168.0.255;

# MTU (possibly lower than 1500 to walk through NATs):

option interface-mtu 1500;

# IP do servidor

next-server 192.168.0.1;

# Eventual section for the server (disconnected mode):

# TFTP image:

filename "pxelinux.0";

}

Devendo-se alterar as faixas de IPs, bem como o IP do servidor, de acordo com as configurações da rede local.

Considerações e Testes Finais

Para testar o cluster, é necessário reiniciar os serviços instalados anteriormente no nó central:

#/etc/init.d/dhcp3-server restart

#/etc/init.d/nfs-kernel-server restart

#inetd

É importante frisar que para o servidor dhcp ser executado normalmente, é necessário que o IP do servidor seja o mesmo informado no arquivo de configuração do dhcp. Também é aconselhável desativar o ambiente gráfico, caso este não vá ser utilizado:

#update-rc.d –f gdm remove

Para reativar, use:

#update-rc.d gdm defaults

Iniciado os serviços, basta ligar os computadores, configurados para realizarem o boot pela rede, e aguardar que sejam iniciados. A figura 5, a seguir, ilustra o funcionamento do cluster.

Figura 5 – Iniciando o cluster e exibindo processadores disponíveis

Ao rodar o comando top e pressionar a tecla 1, apresenta-se o resumo dos processadores disponíveis e a carga utilizada. Talvez seja necessário informar, pelo arquivo /etc/kerrighed_nodes, os nomes dos hosts com seus respectivos node_ids, de acordo com o exemplo abaixo:

No1:1:eth0

No2:2:eth0

E assim por diante.

Conclusão

Clusters SSI são boas alternativas de baixo custo, que possibilitam atingir excelentes níveis de disponibilidade, performance e escalabilidade para aplicações de risco. Com a descontinuidade do OpenMosix, o kerrighed tem se mostrado uma excelente alternativa e que vem evoluindo a um nível rápido, dado os esforços da equipe de desenvolvimento.

Por conta da complexidade desse tipo de projeto, raramente se tem versões que conseguem acompanhar a velocidade de desenvolvimento do kernel linux, daí a necessidade de se usar suas versões anteriores, o que pode reduzir a compatibilidade e quantidade recursos disponíveis se comparado ao oferecido pelas versões mais nova do kernel linux.

Outra modalidade de cluster que vem crescendo são os baseados na biblioteca MPI, que permitem aos programadores escreverem programas específicos para este tipo de sistema distribuído, que trabalha com a troca de mensagens, embora esse tipo de cluster, diferente dos SSIs, necessitem de aplicações específicas para ele.

O kerrighed mostrou-se estável e confiável, sendo satisfatório os resultados dos testes realizados no Departamento de Informática – DI/UFPB, tendo sido considerado um bom modelo para atender às necessidades de processamento “pesado” e disponibilidade dos servidores.

Referencias

Kerrighed on NFSROOT. Disponível em http://www.kerrighed.org/wiki/index.php/Kerrighed_on_NFSROOT_(contrib)

Booting On PXE ... Partimage. Disponível em http://www.howtoforge.com/forums/archive/index.php/t-20887.html

Tutorial: Kerrighed. Disponível em http://bioinformatics.rri.sari.ac.uk/drupal/?q=wiki/tutorial_kerrighed

Ubuntu Forums. Disponível em http://ubuntuforums.org/showthread.php?p=6979803