Cluster com VMware ESX + GFS
Posted by: Tiago Cruz in Cluster, Dicas, ESX, High Availability, Linux, Scripts, Storage, VMware, Virtualização
Já escrevemos bastante sobre Virtualização usando Xen e Cluster aqui no Blog.
Desta vez, para começar bem 2009 eu irei apenas citar alguns testes que fiz usando VMware ESX com GFS, em um Storage compartilhado, usando tecnologia Red Hat 5.2 x86_64 com um Fence_VMWare Tech Preview do RHEL 5.3 beta.
O Problema
Eu já o utilizava o GFS com Xen ou até mesmo com DRBD em Muti-Master, porém o grande problema é que não existia um fence para vmware que funcionasse a contento.
O fence_vmware, escrito em perl parou no tempo em Agosto de 2007 e fora que a VMware Perl API necessária não compila em 64 bits.
A Red Hat pretende lançar agora no RHEL 5.3 um fence_vmware re-escrito em Python, porém ele ainda não trabalha com Cluster, pois conecta-se direto na máquina física, e não no VMCenter.
A Solução
A solução é utilizar o vmware_fence_vi, também da Red Hat que está em fase de desenvolvimento atualmente, que conecta no Virtual Center e não na máquina física que pode estar morta 
Segue o /etc/cluster/cluster.conf utilizado nos testes:
Configuração do Cluster
<cluster alias="Cluster_GFS" config_version="10" name="Cluster_GFS"> <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> <cman> <multicast addr="224.0.0.1" interface="eth1"/> </cman> <clusternodes> <clusternode name="cluster-01-node-01" nodeid="1" votes="1"> <multicast addr="224.0.0.1" interface="eth1"/> <fence> <method name="single"> <device name="node-01"/> </method> </fence> </clusternode> <clusternode name="cluster-01-node-02" nodeid="2" votes="1"> <multicast addr="224.0.0.1" interface="eth1"/> <fence> <method name="single"> <device name="node-02"/> </method> </fence> </clusternode> <clusternode name="cluster-01-node-03" nodeid="3" votes="1"> <multicast addr="224.0.0.1" interface="eth1"/> <fence> <method name="single"> <device name="node-03"/> </method> </fence> </clusternode> </clusternodes> <fencedevices> <fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-01" passwd="xxxxx" port="Cluster_01_Node_01"/> <fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-02" passwd="xxxxx" port="Cluster_01_Node_02"/> <fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-03" passwd="xxxxx" port="Cluster_01_Node_03"/> </fencedevices> </cluster>
Notas:
1-) Troque parênteses por sinal de maior/ menor (maldito wordpress!) 
2-) O IP 10.107.113.2 é o IP do Virtual Center. Ele sempre sabe onde a máquina virtual se encontra, mesmo que ela for migrada para outro host físico.
3-) Forçamos o MultiCast pela eth1, que é uma interface dedicada para o heartbeat do Cluster. Algumas vezes o multicast tentava sair pela interface de loopback e cada máquina achava que estava sozinha no cluster
/etc/hosts dos servidores:
10.0.0.1 cluster-01-node-01
10.0.0.2 cluster-01-node-02
10.0.0.3 cluster-01-node-03
10.0.1.1 node-01
10.0.1.2 node-02
10.0.1.3 node-03
Script de escrita
Foi utilizado um script para escrever no storage compartilhado a cada segundo com o nome da máquina e a hora exata (minuto, segundo) da escrita.
# for i in `seq 1 1000`; do a=`echo $RANDOM | cut -c1-2`; dd if=/dev/zero of=/teste/`hostname -s`-`date +%H_%M_%S` bs=512k count=$a; sleep 1; done
Nós do Cluster
[root@cluster-01-node-02 ~]# cman_tool nodes
Node Sts Inc Joined Name
1 M 60 2009-01-06 19:46:11 cluster-01-node-01
2 M 56 2009-01-06 19:46:11 cluster-01-node-02
3 M 68 2009-01-06 19:56:35 cluster-01-node-03
Fence Device
/sbin/fence_vmware_vi - DEVEL.1229423489 # The Following agent has been tested on: # VI Perl API 1.6 against: # VMware ESX 3.5 # VMware ESXi 3.5 update 2 # VMware Virtual Center 2.5 #</code>
Com a seguinte modificação na linha 13:
#sys.path.append("@FENCEAGENTSLIBDIR@") sys.path.append("/usr/lib/fence")
Desligar máquina VIRTUAL
Teste: Desligar máquina VIRTUAL cluster-01-node-03
Resultado: GFS congelado por ~1 minuto
O que ocorreu: O fence_vmware_vi conectou no vmcenter e tirou a máquina do Cluster, liberando assim o I/O.
Desligar máquina FISICA normalmente
Teste: Desligar com reboot máquina FISICA 01 (que tinha a cluster-01-node-03)
Resultado: GFS congelado por ~2 minutos
O que ocorreu: Máquinas física iniciou o processo de reboot, a máquina virtual cluster-01-node-03 morreu e foi migrada e reiniciada em outro host físico.
PS: A máquina virtual não retornou ao seu host de origem quando a máquina física voltou
-rw-r--r-- 1 root root 44040192 Jan 6 2009 cluster-01-node-01-19_50_52
-rw-r--r-- 1 root root 15204352 Jan 6 2009 cluster-01-node-01-19_50_53
-rw-r--r-- 1 root root 10485760 Jan 6 2009 cluster-01-node-01-19_50_54
-rw-r--r-- 1 root root 41418752 Jan 6 2009 cluster-01-node-01-19_52_57
-rw-r--r-- 1 root root 17825792 Jan 6 2009 cluster-01-node-01-19_52_58
-rw-r--r-- 1 root root 23068672 Jan 6 2009 cluster-01-node-01-19_52_59
-rw-r--r-- 1 root root 6815744 Jan 6 2009 cluster-01-node-01-19_53_00
-rw-r--r-- 1 root root 49807360 Jan 6 2009 cluster-01-node-01-19_53_01
-rw-r--r-- 1 root root 10485760 Jan 6 2009 cluster-01-node-01-19_53_03
Desligar máquina FISICA brutalmente
Desligar com RESET (via RSA) máquina FISICA 02 (que tinha a cluster-01-node-03)
Resultado: GFS congelado por ~3 minutos
O que ocorreu: Máquinas física foi brutalmente desligada, a máquina virtual cluster-01-node-03 morreu e foi migrada e reiniciada em outro host físico.
O fence_vmware_vi tentou várias vezes tirar a máquina do cluster com falhas consecutivas pois a máquina não mais existia e o ESX demorou um pouco para entender o que estava acontecendo.
PS: A máquina virtual não retornou ao seu host de origem quando a máquina física voltou
-rw-r--r-- 1 root root 12058624 Jan 6 20:17 cluster-01-node-01-20_17_57
-rw-r--r-- 1 root root 11534336 Jan 6 20:17 cluster-01-node-01-20_17_58
-rw-r--r-- 1 root root 10485760 Jan 6 20:17 cluster-01-node-01-20_17_59
-rw-r--r-- 1 root root 5242880 Jan 6 20:18 cluster-01-node-01-20_18_00
-rw-r--r-- 1 root root 5767168 Jan 6 20:20 cluster-01-node-01-20_18_01
-rw-r--r-- 1 root root 6291456 Jan 6 20:21 cluster-01-node-01-20_21_00
-rw-r--r-- 1 root root 37748736 Jan 6 20:21 cluster-01-node-01-20_21_02
-rw-r--r-- 1 root root 17825792 Jan 6 20:21 cluster-01-node-01-20_21_03
-rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_04
-rw-r--r-- 1 root root 34603008 Jan 6 20:21 cluster-01-node-01-20_21_05
-rw-r--r-- 1 root root 5242880 Jan 6 20:21 cluster-01-node-01-20_21_06
-rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_07
-rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_08
Trechos de logs
Jan 6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] The token was lost in the OPERATIONAL state. Jan 6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] Receive multicast socket recv buffer size (288000 bytes). Jan 6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] Transmit multicast socket send buffer size (262142 bytes). Jan 6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] entering GATHER state from 2. Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] CLM CONFIGURATION CHANGE Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] New Configuration: Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] r(0) ip(10.0.0.1) Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] r(0) ip(10.0.0.2) Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] Members Left: Jan 6 20:18:15 cluster-01-node-01 fenced[2666]: cluster-01-node-03 not a cluster member after 0 sec post_fail_delay Jan 6 20:18:15 cluster-01-node-01 openais[2646]: [CLM ] r(0) ip(10.0.0.3) Jan 6 20:18:15 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03" Please use '-h' for usagcation=HASH(0x1df33bd0)ing with the remote host.eports: vmware_helper returned Cannot power off vm Cluster_01_Node_03! Jan 6 20:18:47 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: e Jan 6 20:18:47 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (44880). Jan 6 20:18:47 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor Jan 6 20:18:47 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed Jan 6 20:18:52 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node" Jan 6 20:19:28 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: Connection timed out Jan 6 20:19:28 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (45600). Jan 6 20:19:28 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor Jan 6 20:19:28 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed Jan 6 20:19:33 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03" Please use '-h' tNotConnected=HASH(0x19bb0090)mote host, since it is disconnected.ware_helper returned Cannot power on vm Cluster_01_Node_03! Jan 6 20:19:46 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: for usage Jan 6 20:19:46 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed Jan 6 20:19:51 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03" Jan 6 20:20:59 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (46710). Jan 6 20:20:59 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor Jan 6 20:20:59 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03.ig.com.br" success Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Trying to acquire journal lock... Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Looking at journal... Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Acquiring the transaction lock... Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Replaying journal... Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Replayed 79 of 93 blocks Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: replays = 79, skips = 13, sames = 1 Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Journal replayed in 1s Jan 6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Done
Conclusão
Estes testes foram realizados buscando alternativas que reduzam o downtime dos serviços e/ou aplicações contidos em um servidor, chegando a manter sua disponibilidade próxima dos 99,999%.
Como você pôde perceber, esta estrutura permite chegarmos a este número, mas até o momento em que está sendo escrito este post, a versão usada ainda não está homologada, usando pacotes ainda em desenvolvimento (cman+fence_vmware).
Num futuro próximo, já devemos ter algum retorno das empresas desenvolvedoras, pois focam em uma fatia do merdado muito forte e competitiva ($$$).
Entries (RSS)
January 8th, 2009 at 5:00 am
[...] Conseguimos uma solução para todos estes problemas.” [...]
January 8th, 2009 at 5:51 pm
Porque não usa o plugin WP-Syntax (http://wordpress.org/extend/plugins/wp-syntax/) ele permite que você escreva códigos nos posts. Vai ser ver pra digitar arquivos de configuração.
January 9th, 2009 at 1:45 pm
Vinícius,
Muito obrigado pela dica! O post ficou bem melhor agora!
Aproveitei e dei uma atualizada geral no wordpress… ficou bem melhor agora
Muito legal o seu blog também, não me admira que tenha conseguido comprar um Wii só com a renda dele… o meu aqui anda meio parado, nem as contas anuais da DreamHost eu não consigo pagar…. hahahahha
Um grande abraço!