Ganeti2
De Xen-BR wiki
Ganeti
O projeto Ganeti desenvolvido pelo Google é uma aplicação para cuidar da parte de gerenciamento do Hypervidor Xen, até então apenas o mesmo era disponível, agora com a versão 2 já é possível configurarmos outro Hypervisor o KVM. Além desse processo de gerenciamento ele trabalha em conjunto com outra ferramenta bastante interessante e Open Source chamada DRBD.
DRBD - é uma aplicação Open Source que aplica o conceito Raid-1 pela rede ou seja tenho por exemplo 2 partições LVM, uma em cada um servidor, então com o drbd consigo manter elas sincronizadas replicando cada mudança de uma para a outra, ou ambas simultanêamente replicando em ambos os lados.
Bom, no cenário montado foi utilizado a distribuição Ubuntu Hardy 8.04 64bits, Xen versão 3.3.0, DRBD8.02 e Ganeti versão2.
Prereqs:
1. Xen Compilado e instalado
2. Source do Kernel
Esse documento consiste em 3 etapas sendo elas:
1- Preparação do ambiente
2- Instalação e configuração do Ganeti
3- Gerenciamento do Ganeti
Obs: Os procedimentos devem ser feitos em todos os nodes em que deseja rodar o Ganeti.
Tabela de conteúdo |
Preparação do ambiente
Instalando e configurando o DRBD
Primeiramente vamos baixar o tarball do drbd executando o seguinte comando:
wget http://oss.linbit.com/drbd/8.0/drbd-8.0.2.tar.gz
Entre no diretório onde foi feito o download e extraia os arquivos:
tar xvzf drbd-8.0.2.tar.gz
Agora iremos executar o make e precisamos passar na opção KDIR o local do Kernel source para incluir os módulos do DRBD:
make KDIR=/usr/src/linux-headers-2.6.24-23-xen/ && make install
Adicione essas duas entradas para carregar automaticamente no boot e também conseguir instanciar até 32 máquinas virtuais por nodos:
echo "loop max_loop=64" >> /etc/modules echo "drbd minor_count=64" >> /etc/modules
Na configuração do arquivo /etc/drbd.conf precisamos fazer algumas modificações, pode ser feito de algumas maneiras como por exemplo renomear o arquivo de configuração para drbd.bkp e criar um novo arquivo /etc/drbd.conf em branco. Ou também adicionar a palavra skip em cada resource. Para fazer uma analogia de como funciona o arquivo de configuração do DRBD podemos comparar com o arquivo de configuração do Samba que é dividido pela seção global e compartilhamento, com o DRBD funciona da mesma forma temos a seção global onde é definido as opções para todos os resources e as opções dos resources.
Escolhi pela opção de deixar o arquivo drbd.conf em branco:
mv /etc/drbd.conf /etc/drbd.bkp touch /etc/drbd.conf
Configurando endereçamento e interfaces
Na configuração do arquivo /etc/hosts precisamos mudar o ip de loopback do node e colocar seu ip, conforme documentado pelo Ganeti e também vamos adicionar o ip do cluster que será usado mais adiante:
#/etc/hosts 127.0.0.1 localhost 192.168.1.65 node01.ganeti.lab node01 192.168.1.100 cluster00.ganeti.lab cluster00
Agora iremos fazer a configuração de nossa interface bridge, para isto precisamos seguir alguns passos o primeiro é editar o arquivo /etc/xen/xend-config.sxp e comentar a linha de network-script para desativar o script de configuração da bridge gerenciada pelo Xen:
Encontre:
#/etc/xen/xend-config.sxp (network-script network-bridge)
E substitua por:
#/etc/xen/xend-config.sxp #(network-script network-bridge)
Agora que foi desabilitado o network-script do Xen, vamos configurar nossa bridge manualmente, adicionando os seguintes parâmetros do arquivo /etc/network/interfaces:
#/etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback
# The primary network interface
auto xen-br0
iface xen-br0 inet static
address 192.168.1.66
netmask 255.255.255.0
gateway 192.168.1.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
Caso tenha alguma dúvida sobre as sintaxes, confira o man do utilitário bridge-utils para maiores informações.
(Opcional) Para seguir boas práticas, vamos limitar o [1]dom0 do xen para 512 de memória e apenas um core, pois ele apenas é utilizado para o gerenciamento de suas instancias e o mesmo apenas deve designar esta função:
#/boot/grub/menu.lst title Xen 3.3 / Ubuntu 8.04.1, kernel 2.6.24-23-xen root (hd0,0) kernel /boot/xen-3.3.gz dom0_mem=512 nosmp module /boot/vmlinuz-2.6.24-23-xen root=/dev/sda1 ro console=tty0 module /boot/initrd.img-2.6.24-23-xen quiet
O Ganeti por padrão procura um volume lógico com o nome xenvg, mais à frente explicarei caso deseja personalizar as configurações do Ganeti, vamos à configuração dos volumes lógicos:
Certifique-se que o lvm2 esteja instalado em seu Sistema, caso deseja conferir execute o comando dpkg --list | grep lvm2
pvcreate /dev/sdX - onde X é a sua device desejada, caso seja um disco IDE a nomenclatura será hdX vgcreate xenvg /dev/sdX
Para concluir vamos rebootar o Sistema e prosseguir para a próxima etapa.
Instalação e configuração do Ganeti
Antes de executar o processo de compilação e instalação do Ganeti precisamos resolver algumas dependências de aplicativos utilizado pelo Ganeti, vamos começar instalando o docbook-utils:
O link para o download do docbook-utils é http://ufpr.dl.sourceforge.net/sourceforge/docutils/docutils-0.5.tar.gz então vamos fazer o download e instalar o pacote:
wget http://ufpr.dl.sourceforge.net/sourceforge/docutils/docutils-0.5.tar.gz
No meu caso fiz o download em /opt então vamos entrar no diretório salvo e descompactar o tarball:
cd /opt tar xvzf docutils-0.5.tar.gz cd docutils-0.5 ./install.py
Após executar o script install.py o dockbook-utils já está devidamente instalado em seu Sistema, precisamos após a instalação exportar uma váriavel de ambiente apontando para o RST2HTML:
export RST2HTML=/usr/bin/rst2html.py
Para adicionar a variável automaticamente no início do sistema basta incluir esta sintaxe ao final do /etc/profile conforme o exemplo:
export RST2HTML=/usr/bin/rst2html.py >> /etc/profile
Precisamos também fazer a instalação de mais algumas dependências como dot2tex, openssl, python-openssl e python-simplejson, felizmente temos esses pacotes disponíveis no repositório para instalação bastando apenas passar o comando:
apt-get install dot2tex openssl python-openssl python-simplejson
Agora vamos preparar os diretórios que seram utilizados pelo Ganeti e vamos criar 4 diretórios:
mkdir /etc/ganeti mkdir /srv/ganeti mkdir /srv/ganeti/os mkdir /srv/ganeti/export
Agora estamos prontos para compilar e instalar o Ganeti, primeiramente vamos fazer o download do Ganeti. Utilizei neste documento a versão 2.0.0rc1 o link para o download pode ser encontrado através da página do Ganeti http://code.google.com/p/ganeti/ após fazer o download vamos começar o processo de instalação:
wget http://ganeti.googlecode.com/files/ganeti-2.0.0%7Erc1.tar.gz tar xvzf ganeti-2.0.0%7Erc1.tar.gz ./configure --localstatedir=/var --sysconfdir=/etc make && make install
Junto com o pacote de instalação temos um diretório examples que pode ser encontrado alguns scripts utéis como por exemplo o script de inicialização do Ganeti, então vamos copiá-lo e adicionar para iniciar junto com o Sistema:
cp ganeti_install/doc/examples/ganeti.initd /etc/init.d/ganeti chmod +x /etc/init.d/ganeti update-rc.d ganeti defaults
Agora vamos compilar e instalar o pacote para a criação de máquinas virtuais e a instalação do Sistema Operacional.
wget http://ganeti.googlecode.com/files/ganeti-instance-debootstrap-0.7.tar.gz tar xvzf ganeti-instance-debootstrap-0.7.tar.gz ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-os-dir=/srv/ganeti/os make && make install
Vamos copiar também o kernel e ramdisk para utilizá-los nas máquinas virtuais:
cp /boot/vmlinuz-2.6.18.8-xen /boot/vmlinuz-2.6-xenU cp /boot/initrd.img-2.6.18.8-xen /boot/initrd-2.6-xenU
Uffa! terminamos, agora iremos iniciar os cluster e o mesmo deve ser iniciado no servidor que deseja ser o "master" do seu cluster, nele terá todo o conhecimento das máquinas virtuais que estão no ar, desligadas e com problemas. Também toda a parte de gerenciamento só poderá ser feita através do master. Você deve estar imaginando e se eu tiver algum problema com o servidor master do cluster? É facil, apenas forçamos outra estação a se tornar o master e retomamos o controle da toda estrutura de servidores físicos/virtuais, Isso será abordado mais afrente na parte de gerenciamento.
Vamos agora iniciar o cluster:
gnt-cluster init -H xen-pvm:initrd_path=/boot/initrd-2.6-xenU cluster00
Primeiramente usamos o comando gnt-cluster que é voltada para configurações baseadas em nível de cluster a opção init informa que desejamos iniciar um novo cluster, o -H xen-pvm:initrd_path=/boot/initrd-2.6-xenU indica que o Hypervisor que será utilizando será o Xen em modo paravirtualizado, também aproveitamos e apontamos o ramdisk que será usado por default pelas máquinas virtuais que criaremos mais adiante. E por último o nome do cluster que setamos no ínicio do documento no arquivo /etc/hosts.
Antes de prosserguimos para a última etapa precisamos certificar-se que o cluster está ativo e o script debootstrap-instance sendo reconhecido pelo Ganeti.
Verificando o status do cluster:
root@node01:/# gnt-cluster info
Cluster name: cluster00.ganeti.lab
Master node: node01.ganeti.lab
Architecture (this node): 64bit (x86_64)
Default hypervisor: xen-pvm
Enabled hypervisors: xen-pvm
Hypervisor parameters:
- xen-pvm:
root_path: /dev/sda1
kernel_path: /boot/vmlinuz-2.6-xenU
initrd_path: /boot/initrd-2.6-xenU
kernel_args: ro
Cluster parameters:
- candidate pool size: 10
Default instance parameters:
- default:
auto_balance: True
vcpus: 1
memory: 128
Isso nos indica que o cluster está ativo e funcionando, agora precisamos verificar se o debootstrap-instance está sendo listado pelo Ganeti:
node1:~# gnt-os list Name debootstrap
Ótimo! se chegou até aqui sem problemas já podemos ir para a última etapa que é a parte de gerenciamento.
Gerenciamento do Ganeti
Antes de prosseguirmos precisamos entender alguns conceitos, o Ganeti funciona de forma hierarquica então todas as configurações feitas pelo gnt-cluster, todos os nodes irão herdar as configurações. Ao passarmos configurações com o gnt-node apenas o nodo será alterado. Para cada máquina virtual ou nodo adicionado no cluster é preciso uma entrada no /etc/hosts do cluster master conforme adicionamos no início do documento uma entrada para o cluster.
Então para iniciarmos vamos adicionar mais um nodo no nosso cluster
root@node01:/# gnt-node add node02 ( OBS: o node02 deve estar na entrada /etc/hosts )
Vamos confirmar se o mesmo foi adicionado sem problemas:
root@node01:/# gnt-node list Node DTotal DFree MTotal MNode MFree Pinst Sinst node01.ganeti.lab2 139.2G 133.1G 1.9G 512M 1.3G 1 1 node02.ganeti.lab2 139.7G 136.6G 3.9G 512M 3.2G 1 0
Ótimo, ambos no ar e como podemos ver já temos informações de ambos, vamos começar adicionando uma máquina virtual standalone com 256 de memória e com 2GB em disco. (Obs: adicionar uma entrada no /etc/hosts para a instance01)
gnt-instance add -t plain --disk 0:size=2g -B memory=256 -o debootstrap -n node01 instance01
O comando gnt-instance é destinado para gerenciamento de máquinas virtuais, conforme a sintaxe acima estamos usando em conjunto com o gnt-instance a opção add para adicionar uma máquina virtual e o tipo ( -t ) plain que no caso seria uma máquina normal criada em um volume lógico, podemos usar outros tipos de instances como drbd para alta disponibilidade conforme será abordado mais adiante e também no modo diskless. Com a opção --disk podemos criar quantas partições quisermos, por exemplo se deserjamos duas partições de 2GB passariamos as sintaxes --disk 0:size=2g --disk 1:size=2g e -B o backend padrão será usado. A opção memória como o próprio nome já diz é destinado a quantidade de memória, -o nos indica qual script para a criação da máquina virtual vamos utilizar que no caso é debootstrap conforme instalamos acima, a opção -n node01 indica onde será criada a máquina virtual e por último o nome da nova máquina virtual e nome deverá corresponder ao mesmo da entrada /etc/hosts.
Após a saída do script vamos verificar o status da máquina virtual com o comando:
root@node01:/# gnt-instance list Instance Hypervisor OS Primary_node Status Memory instance01.ganeti.lab2 xen-pvm debootstrap node01.ganeti.lab running 256M
Já é possível utilizar nossa nova máquina virtual e instalar oque desejar bastamos executar gnt-instance console instance01 e já caímos para o shell de logon da mesma. Porém ainda não temos redundância da máquina virtual caso ela ou o nodo ao qual ela foi instanciada tiver algum problema, e em ambientes que precisam ter seus sistemas sem pausas de serviço não programadas seria motivo de muitas dores de cabeça, por isso resolvi incluir a parte de failover e alta disponibilidade.
Para comerçarmos precisamos de pelo menos dois nodos no cluster, ter configurado devidamente o DRBD conforme no ínicio do documento e fazer uma pequena alteração no arquivo de configuração do Xen.
Primeiramente vamos incluir algumas configurações no arquivo de configuração do Xen adicionando ou apenas descomentando as seguintes linhas:
(xend-relocation-server yes) (xend-relocation-port 8002) (xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ ^192\\.168\\.1\\.65$')
Obs: Deve ser configurado em ambos nodos
A primeira habilita o relocation( migração), a segunda linha especifica a porta utilizada para o relocation e por último os hosts que podem alocar em seu dom0 suas máquinas virtuais, pode ser configurado por host,domínio ou range da rede.
Após a inclusão dessas linhas vamos reiniciar o serviço do Xen:
/etc/init.d/xend restart
Após reiniciar o serviço vamos criar nossa primeira instance do tipo DRBD:
gnt-instance add -t drbd --disk 0:size=2g -B memory=256 -o debootstrap -n node01:node02 instance02 (Obs: criar uma entrada no arquivo /etc/hosts )
Após confirmar o comando aparecerá uma sincronização entre os nodos criando a máquina virtual, se quiser acompanhar o processo de sincronização pelo DRBD utilize o comando watch -n1 cat /proc/drbd verá uma tela semelhante à essa:
[root@node01 ~]# cat /proc/drbd version: 8.3.0 (api:88/proto:86-89) GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@node01.labcloud.int, 2009-02-13 11:24:41 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r--- ns:4166540 nr:0 dw:0 dr:4174560 al:0 bm:254 lo:1 pe:5 ua:252 ap:0 ep:1 wo:b oos:1076284 [==============>.....] sync'ed: 79.6% (1051/5119)M finish: 0:01:22 speed: 25,932 (25,352) K/sec
Terminando a sincronização a máquina virtual terá seu status marcado como up, qual o comando para verificarmos? exatamente:
[root@node01 ~]#gnt-instance list Instance Hypervisor OS Primary_node Status Memory instance02.ganeti.lab xen-pvm debootstrap node01.ganeti.lab running 256M
E então poderemos testar a alta disponibilidade e o failover vamos executar no primary node o seguinte comando:
[root@node01 ~]#gnt-instance migrate instance02
É só acompanhar que você vera todo o processo de migração para outra estação sem a queda do serviço com isso já se deve perceber o tanto que se ganha com futuras manutenções ou implementações sem se preocupar com a disponibilidade do Sistema. Agora e se um nodo por ventura vir a ficar indisponível? Então teriamos de avisar para o Ganeti que precisamos de um failover para a instance em questão, vamos fazer uma pequena simulação.
A instance atual foi migrada para o node02 vamos puxar o cabo de rede do node02 e dizer ao node01 fazer um failover da instance:
[root@node01 ~]#gnt-instance failover instance02 node1:~# gnt-instance failover instance02.ganeti.lab Failover will happen to image inst1.example.com. This requires a shutdown of the instance. Continue? y/[n]/?: <-- y * checking disk consistency between source and target Node node2.ganeti.lab: Disk degraded, not found or node down Failure: command execution error: Disk sda is degraded on target node, aborting failover. [root@node1 ~]#
Como podemos ver ele reclamou da checagem de consistência de disco porque não conseguiu fazer a consulta ao outro nodo e então ativou a instance02 no nodo1, ao colocarmos novamente o cabo ao nodo2 você não vai mais conseguir fazer o migrate da instance02 pois será advertido de incosistência do disco então precisamos botar a "mão na massa" e avisar para o DRBD que o dispositivo está inválido e precisa de uma nova sincronização, então vamos lá...
No node02 o qual puxamos o cabo não está mais sincronizado com o dispositivo do node01 então vamos pegar o device e invalidar ele utilizado o comando: [root@node01 ~]#drbd primary /dev/drbd0 Vamos deixá-lo como primário para receber as devidas mudanças [root@node01 ~]#drbd invalidate /dev/drbd0 Deixando o dispositivo inválido
Após executar este comando você pode assistir pelo watch -n1 cat /proc/drbd que será feito uma nova sincronização de todo o disco novamente:
[root@node02 ~]# cat /proc/drbd version: 8.3.0 (api:88/proto:86-89) GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@node02.labcloud.int, 2009-02-13 11:24:41 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r--- ns:4166540 nr:0 dw:0 dr:4174560 al:0 bm:254 lo:1 pe:5 ua:252 ap:0 ep:1 wo:b oos:1076284 [========>............] sync'ed: 79.6% (1051/5119)M finish: 0:01:22 speed: 25,932 (25,352) K/sec
Ao finalizar a migração do sistema utilizando o gnt-instance migrate instance02 já estará disponível novamente, podemos também fazer outras mudanças como nodo primário da instância ou nodo secundário, como deve ter notado as máquinas virtuais do tipo DRBD trabalham em duplas pois é assim que o DRBD trabalha em pares toda a mudança feita em uma instancia é replicada pra segunda.
Para finalizar este documento vou explicar como se recuperar de uma falha do nodo master, ao obter algum problema ao nodo master do seu cluster você pode designar outro nodo para se tornar o master, neste caso vamos alterar o master para o node02:
[root@node02 ~]#gnt-cluster masterfailover
E então o novo cluster master passará a ser o node02 e continuar o gerenciamento até que o node01 volte.
Sérgio Pelissari Junior vulgo PrimeHaxor
