Everlinux’s Blog

Neste exemplo eu tenho um cluster em produção com a LUN compartilhada de 500 GB via GFS. Pretendo dobrar sua capacidade sem parada no sistema.

1-) Adicionar um “Mapped Raw LUN” no ESX, em Compatibility Mode “Physical”.
A “SCSI Controller” também precisa ser “Physical”, e o disco RAW precisa estar nesta controller dedicada

Ex:
Hard Disk 1 = SCSI Controller 0 = SCSI (0:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:1)

2-) Adicionar a LUN no Linux:

[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
 
[root@cluster-02 ~]# echo "scsi add-single-device 1 0 1 0" > /proc/scsi/scsi
 
[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05

Sendo: Host – Channel – ID – Lun
(um reboot também funcionaria )

3-) Configurar o Cluster de LVM

3a-) Criando um Logical Volume

# fdisk /dev/sdc (usar ID 8e = Linux LVM)
# partprobe (em todas as maquinas do cluster)
# lvmconf --enable-cluster
# pvcreate /dev/sdb1
# vgcreate -Ay -cy pre_homolog /dev/sdb1
# lvcreate -L 499G -n hotsites pre_homolog

ou

3b-) Aumentando um já existente

[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1              lvm2 --   499.99G  499.99G
 
[root@cluster-01 ~]# vgextend pre_homolog /dev/sdc1
  Volume group "pre_homolog" successfully extended
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree  
  pre_homolog   2   1   0 wz--nc 999.98G 500.98G
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1  pre_homolog lvm2 a-   499.99G  499.99G
 
[root@cluster-01 ~]# lvextend -Ay -l+128252 /dev/pre_homolog/hotsites
  Extending logical volume hotsites to 999.98 GB
  Logical volume hotsites successfully resized
 
[root@cluster-01 ~]# lvs
  LV       VG          Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  hotsites pre_homolog -wi-ao 999.98G
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree
  pre_homolog   2   1   0 wz--nc 999.98G    0
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G    0
  /dev/sdc1  pre_homolog lvm2 a-   499.99G    0

4-) Aumentar o GFS

Com o /gfs montado, usando o gfs_grow

[root@cluster-01 ~]# gfs_grow -v /gfs
FS: Mount Point: /gfs
FS: Device: /dev/mapper/pre_homolog-hotsites
FS: Options: rw,hostdata=jid=0:id=131073:first=0
FS: Size: 130809855
RGRP: Current Resource Group List:
RI: Addr 130744354, RgLen 5, Start 130744359, DataLen 65496, BmapLen 16374
RI: Addr 130678852, RgLen 5, Start 130678857, DataLen 65496, BmapLen 16374
RI: Addr 130613350, RgLen 5, Start 130613355, DataLen 65496, BmapLen 16374
...
...
RI: Addr 261895985, RgLen 15, Start 261896000, DataLen 243904, BmapLen 60976
RGRP: 539 Resource groups in total
Preparing to write new FS information...
Done.

Antes:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      493G   12G  482G   3% /gfs

Depois:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      994G   12G  983G   2% /gfs

Dia desses percebi que estava gastando todo meu tempo livre jogando um dos maiores games já feitos para PC, o Diablo 2 com expansão. Eu comprei ele no submarino por R$29,90. Apesar de já ter gasto horas e horas nesse jogo alucinante há alguns anos atrás, eu consegui reunir um pessoal e estamos jogando frequentemente.

Para ajudar, por trabalhar em uma empresa de tecnologia, frequentemente fico algumas horas até mais tarde, seja para concluir um projeto, resolver um problema ou mesmo esperar o trânsito dar uma aliviada. Nesse último item, rola jogar um game e ir treinando para fazer uma aventura legal com o pessoal. Como no meu trabalho uso linux e em casa eu rodava ele num windão véio que só servia para isso, resolvi dar uma navegada no site da blizzard e ver as novidades.

Lá no site, você consegue baixar os arquivos que permitem a você instalar o game de qualquer computador, desde que você tenha o serial original do jogo. Primeiro, você precisa se cadastrar no site da blizzard para conseguir o serial que vai permitir a instalação.

Sussa, feito isso, baixei os 1.9GB de arquivos do site da blizzard.com. Você autentica no site e baixa um executável de uns 100kB. Esse arquivo quando executado baixa os arquivos do jogo direto do site. Na sequência já abri uma aba no site do wine.

O lance do Wine é o seguinte: antigamente até conseguia instalar o jogo, mas sempre ficava muito instável e a jogabilidade usando os recursos de rede não era muito legal, mesmo compilando. Mas a equipe de desenvolvimento dos caras não fica parada. Já tem uma versão do Wine que permite que você instale e jogue o D2LoD sem problemas. Inclusive troca de janelas sem trava o game, sem zoar a imagem ou perder o cursor do mouse.

Instalando o Wine:

Essas 3 linhas são o que você precisa para poder executar o .exe do instalador do Diablão.

$ wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -
$ sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/intrepid.list -O /etc/apt/sources.list.d/winehq.list
$ sudo apt-get update

No Ubuntu 8.10, o comando “apt-get install wine” traria a versão 1.0.1. Porém, com estas linhas acima a versão 1.1.12 será baixada e instalada.

Daí para frente é só instalar o D2Lod normalmente. Abaixo tem umas screenshoots para você ver como acontece a mágica.

$ wine /dados/games/D2LOD/D2-1.12A-enUS/Installer.exe
$ wine /dados/games/D2LOD/D2LOD-1.12A-enUS/Installer.exe

Caso queira rodar o wine em uma janela 800×600 e não em Fullscreen, edite o atalho criado em seu desktop e adicione no final da linha -w.

Olhando as screenshoot’s você percebe que fiz toda a malandragem usando o Ubuntu 8.10! Não tive tempo de testar em outros sabores linux. Se você gostou, instale e deixe seu comentário.

Pronto, depois de todo o trabalho, agora é pegar sua espada, vestir sua armadura e sair em busca de batalhas!!

8p

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 ($$$).

Participei hoje do evento “VMware Virtualization Forum 2008“, patrocinado pela VmWare e suas patrocinadoras como a Intel, HP, CA, EMC… Embora o evento maior da VmWare se passe “lá fora”, o evento aqui no Brasil foi bem interessante e tiveram suas inscrições esgotadas.

O evento foi gratuíto, contando com café da manhã, Coffee Break, Almoço e Coquetel de encerramento com o sorteio de alguns prêmios, como dois Ipod Touch e dois Nintendos WII, no qual eu tive a puta sorte de ganhar!!! Nunca ganha nada em sorteio algum, porém dessa vez eu realmente preciso agradecer a Deus pelo presentão de aniversário que eu não teria condições de comprar!!! Alias, agradeço de algum usuário desta maravilhosa tecnologia pudesse deixar alguns dicas para mim a respeito do console

Bom, voltando ao evento em si, com tanta coisa “de graça” bancada pelos patrocinadores, era de se esperar que os mesmos tentassem vender seus produtos durante as palestras. Não gostei de ver apresentações com slides “shareados” dando aquela sensação estranha Deja’vu…

Portando, com as palestras mais voltadas ao publico gerencial e não técnico, o evento deve ter agradado as pessoas que não precisam saber como o motor funciona, querem apenas ligar a chave e esperam que o carro saiam andando — e seus técnicos que se virem para aprender como a coisa funciona

Na parte da manhã tivemos palestras muito interessantes como:

- a Polícia Federal, mostrando sua solução de Virtualização usando Blades (edizendo que os dados ainda não estão todos centralizados, portanto, teoricamente você ainda pode cometer um delito em cada cidade do brasil )

- um estudo da IDC, muito bem apresentado com conteúdo técnico e gerencial bem dosado falando sobre as próximas tendências do mercado, e ainda sugerindo métodos para você virtualizar seu ambiente com a maior segurança possível;

- Tecnologia Quad-Core da Intel, mostrando os aspectos voltados à virtualização e prometendo novidades enormes ainda este ano;

- Case da PRODAM, mostrando os desafios de migrar um Data Center de local, arruma-lo e ainda Virtualizar para abstrair o Hardware. Não posso deixar de citar a quantidade de equipamentos velhos e obsoletos que faziam parte do DC deles, e também as duas toneladas de cabos de rede desnecessários que foram removidos durante a migração, pois os comentários que se escutava era: “está vendo o que é feito com o seu dinheiro dos impostos?”

Acho ainda interessante dizer que na parte da tarde, a cada palestra de 1 hora o pessoal da vmware abriu um espaço de 15 minutos para algum parceiro deles falaram um pouco sobre a empresa, e por incrível que pareça, esses 15 minutos foram extremamente técnicos (NetApp, EMC e Sun com o Rafael Tinoco, que mandou muito bem no FISL 9.0) alegrando eu e mais o restante de público Nerd não-gerente ali presente.

Claro que eu já esperava que o evento seria mais voltado à executivos de Terno e Gravata do que para Nerds de Jeans e Camiseta, portanto não posso dizer que estou decepcionado pois eu sabia que isso não era nenhum FISL. Muito pelo contrário, o lugar foi muito bem escolhido, a organização foi ótima e o evento bastante proveitoso.

Também serviu para encontrar velhos amigos (ex-professores do meu colégio, colegas de classe da faculdade, amigos de outras empresas e figuras que eu só encontro no FISL), além de perder um pouco o medo do inglês tentando fazer uns gringos entender que na maior parte das vezes, nós não usamos Linux porque é “de graça” ou é mais barato do que a solução X ou Y — muito pelo contrário, na maior parte das vezes nós pagamos pelo Linux (SuSE, Red Hat) mas usamos devido a suas características serem superiores do que as dos concorrentes, como por exemplo Desempenho, Estabilidade e Segurança.

E foi bom saber também que as empresas estão correndo atrás em adaptar seus produtos/ soluções para Linux nos próximos meses (o VConverter da VizionCore me parece muito promissor). Além do mais, as empresas que já tem solução para Red Hat ainda não expandiram a mesma para SuSE ou Ubuntu devido a problemas gerenciais, como o treinamento do pessoal de suporte e etc, e não por problemas técnicos.

Muito interessante também o pessoal da NetAPP elogiando o iSCSI que geralmente não é bem vindo por ser uma alternativa barata às caríssimas soluções com FC/HBA…

E para fechar, uma feature do VmWare que eu gostei muito e sinto falta no Xen é o chamado “VmWare LifeCycle Manager” que irá cuidar que as suas máquinas virtuais não se proliferem e espalhem em seu ambiente que nem coelhos, pois como é muito fácil provisionar a mesma é também muito fácil você perder o controle e não ter mais certeza se a VM está ou não sendo utilizada ainda…

Bom, vou parando por aqui e peço desculpas se o texto ficou muito grande ou com as idéias desordenadas… agora preciso descansar pois amanhã terei mais uma migração grande para fazer de madrugada, portanto, um dia desses eu arrumo melhor este texto

Boa noite para vocês
Diga “WI!!!!!!!”
PS: O console só chega semana que vem…

O script anterior foi atualizado contando com algumas melhorias sugeridas pelos seus usuários, como:

- Agora ele é escrito em Inglês, para maior portabilidade com outros usuários do xen ao redor do mundo;

- Você pode fazer backup de somente uma máquina específica, não é mais necessário esperar todo o laço terminar para ver o resultado do mesmo;

- Script parametrizado e funcões sub-divididas e

- Pequenos problemas corrigidos.

#!/bin/bash
# Backup of Xen VM's
# Tiago Cruz - tiagocruz@everlinux.com
# v 1.0	Mar/2008 - Initial version, just backup all VM's
# v 1.1 May/2008 - Now we have functions and parameters
 
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
BACK="_snap"
LOG=/var/log/backup.`date +%Y%m%d`
# root partition to backup ("/")
# usually the second it's swap
ROOT="1"
 
[ ! -d "/mnt/back" ] &&  mkdir -p /mnt/back
[ ! -d "/data/backup" ] &&  mkdir -p /data/backup
 
function showHelp() {
        echo " "        
        echo "Use the following parameters: "
        echo "          help   = Show this help"
        echo "          all    = Backup of all VM's"
        echo "          list   = List all VM's from this domain"
        echo "          <vm>   = Backup one specific VM"
        echo " "
	echo "ex: back_xen.sh tomcat_shop"
        echo " "
	exit 1
}
 
function listVM() {
	echo "List of VM's avaliables:"
	/usr/sbin/xm list | awk '{print $1}' | egrep -v '(Name|Domain-0)'
	echo " "
}
 
function backXen () {
	echo "Backuping machine $i..."
	echo "Please, look the progress on $LOG"
	listVM | grep $i >/dev/null
	if [ $? -ne 0 ]; then
		echo "Machine $i does not exist, aborting!"
		exit 2
	fi	
	backup
	if [ $? -eq 0 ]; then
                echo "Backup of $i completed successfully!!!"
		echo "Backup finalized on `date` with load `cat /proc/loadavg | cut -c 1-14`" >> $LOG
		echo "==============================================" >> $LOG
		echo "==============================================" >> $LOG
        fi
}
 
function backAll () {
	VMS=`xm list | awk '{print $1}' | egrep -v '(Name|Domain-0)'`
	for i in $VMS; do
		backup
	done
	echo "Backup finalized on `date` with load `cat /proc/loadavg | cut -c 1-14`" >> $LOG
	echo "==============================================" >> $LOG
	echo "==============================================" >> $LOG
}
 
function backup () {
	echo "==============================================" >> $LOG
	echo "Backup $i started on `date` with load `cat /proc/loadavg | cut -c 1-14`" >> $LOG
	DEVICE=`grep ^disk /etc/xen/$i | awk -F "Vol_LVM" '{print $2}' | cut -d / -f 2 | cut -d , -f 1`
	echo "Virtual Machine $i uses $DEVICE as storage device" >> $LOG
 
	lvcreate --snapshot -L 15G -n $i$BACK /dev/Vol_LVM/$DEVICE >> $LOG 2>&1
	[ $? -ne 0 ] && echo "Error $i: creating LVM $i$BACK" >> $LOG 
 
	kpartx -a /dev/mapper/Vol_LVM-$i$BACK >> $LOG 2>&1
	mount /dev/mapper/Vol_LVM-$i$BACK$ROOT /mnt/back/ >> $LOG 2>&1
	[ $? -ne 0 ] && echo "Error $i: mounting $i$BACK$ROOT" >> $LOG 
 
	SIZE1=`df -hP /mnt/back/ | awk '{print $3}' | grep -v Used`
	SIZE2=`df -hP /mnt/back/ | awk '{print $2}' | grep -v Size`
	echo "Backup of /dev/mapper/Vol_LVM-$i$BACK$ROOT - $SIZE1 of $SIZE2 used" >> $LOG
	tar zcf /data/backup/$i-xen.tar.gz /mnt/back >> $LOG
	[ $? -ne 0 ] && echo "Error $i: creating /LVM/backup/$i.tar.gz" >> $LOG 
 
	SIZE3=`ls -lh /LVM/backup/$i-xen.tar.gz  | awk '{print $5}'`
	echo "Created /LVM/backup/$i-xen.tar.gz with $SIZE3" >> $LOG
 
	sleep 1
	umount /mnt/back/ >> $LOG 2>&1
	[ $? -ne 0 ] && echo "Error $i: umounting $i$BACK" >> $LOG 
	kpartx -d /dev/mapper/Vol_LVM-$i$BACK >> $LOG 2>&1
	[ $? -ne 0 ] && echo "Error $i: deleting partition mappings $i$BACK" >> $LOG 
 
	echo "Removing snapshot already backuped $i$BACK" >> $LOG
	lvremove /dev/Vol_LVM/$i$BACK -f >> $LOG 2>&1
}
 
if [ "$#" -eq 0 ]; then
	showHelp
 
fi
 
case "$1" in 
	list)	listVM	;;
	all )	backAll	;;
	help)	showHelp ;;
	 *  )  	i=$1; backXen ;;
esac

Caso tenha problemas com o copy-past, você pode pegar o mesmo aqui: back_xen.sh.txt.

Se você usa o Xen, usa Storage Devices sob LVM, e acha importante ter um backup das mesmas, você pode utilizar/ adaptar este pequeno script que tira um snapshot e em seguida faz um “tar.gz” de todo o “/” da sua VM, e a guarda em um local para que você possa restaura-lo caso necessário.

#!/bin/bash
# Backup das VM's do Xen
# Tiago Cruz - tiagocruz@everlinux.com
# Mar/2008
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
VMS=`xm list | awk '{print $1}' | egrep -v '(Name|Domain-0)'`
BACK="_snap"
LOG=/var/log/backup
# Particao root, geralmente a segunda eh swap
ROOT="1"
 
[ ! -d "/mnt/back" ] &&  mkdir -p /mnt/back
[ ! -d "/dados/backup" ] &&  mkdir -p /dados/backup
 
for i in $VMS; do
        echo "=================================================================" >> $LOG
        echo "Backup $i iniciado em `date` com load de `cat /proc/loadavg`" >> $LOG
        DEVICE=`grep disk /etc/xen/$i | awk -F "Vol_LVM" '{print $2}' | cut -d / -f 2 | cut -d , -f 1`
        echo "Maquina Virtual $i usa $DEVICE como storage device" >> $LOG
 
        lvcreate --snapshot -L 15G -n $i$BACK /dev/Vol_LVM/$DEVICE >> $LOG
        [ $? -ne 0 ] && echo "Erro $i: criando LVM $i$BACK" >> $LOG
 
        kpartx -a /dev/mapper/Vol_LVM-$i$BACK >> $LOG
        mount /dev/mapper/Vol_LVM-$i$BACK$ROOT /mnt/back/ >> $LOG
        [ $? -ne 0 ] && echo "Erro $i: montando $i$BACK$ROOT" >> $LOG
 
        SIZE1=`df -hP /mnt/back/ | awk '{print $3}' | grep -v Used`
        SIZE2=`df -hP /mnt/back/ | awk '{print $2}' | grep -v Size`
        echo "Backup de /dev/mapper/Vol_LVM-$i$BACK$ROOT - $SIZE1 de $SIZE2 usados" >> $LOG
        tar zcf /dados/backup/$i-xen.tar.gz /mnt/back >> $LOG
        [ $? -ne 0 ] && echo "Erro $i: criando /dados/backup/$i.tar.gz" >> $LOG
 
        SIZE3=`ls -lh /dados/backup/$i-xen.tar.gz  | awk '{print $5}'`
        echo "Criado /dados/backup/$i-xen.tar.gz com $SIZE3" >> $LOG
 
        umount /mnt/back/ >> $LOG
        [ $? -ne 0 ] && echo "Erro $i: desmontando $i$BACK" >> $LOG
        kpartx -d /dev/mapper/Vol_LVM-$i$BACK >> $LOG
        [ $? -ne 0 ] && echo "Erro $i: desmapeando $i$BACK" >> $LOG
 
        echo "Removendo snapshot ja backupeado $i$BACK" >> $LOG
        lvremove /dev/Vol_LVM/$i$BACK -f >> $LOG
done
 
echo "Backup finalizado em `date` com load de `cat /proc/loadavg`" >> $LOG
echo "=================================================================" >> $LOG
echo "=================================================================" >> $LOG

Trecho do log:

Backup ora_busca iniciado em Fri Mar 28 05:02:53 BRT 2008 com load de 1.31 1.33 1.21
Maquina Virtual ora_busca usa ora_busca como storage device
Logical volume “ora_busca_snap” created
Backup de /dev/mapper/Vol_LVM-ora_busca_snap1 – 16G de 95G usados
Criado /dados/backup/ora_busca-xen.tar.gz com 4.9G
Removendo snapshot ja backupeado ora_busca_snap
Logical volume “ora_busca_snap” successfully removed

1-) Estou armazenando as VMs no LVM:

# lvcreate -Ay -L 60G -n vm00 Vol_LVM
# lvcreate -Ay -L 60G -n vm01 Vol_LVM
# lvcreate -Ay -L 60G -n vm02 Vol_LVM

2-) Estou usando o “partimage-0.6.7_beta2.tar.bz2″, pois a versão stable não funciona bem em 64 bits:

3-) A primeira VM deve ser instalada/ configurada manualmente/normalmente. Depois você pode tirar uma cópia dela:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# partimage -z1 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg.gz
ou
# partimage -z0 -c -d -f0 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg
# kpartx -d /dev/mapper/Vol_LVM-vm01

PS: Note que se você usar compressão (-z1) a geração da imagem vai demorar mais para ser criado, porém com o tamanho bem menor (515M vs 3.7GB) . A restauração da mesma também será mais lenta.

4-) Com base na primeira VM:

# fdisk -l /dev/mapper/Vol_LVM-vm00
Disk /dev/mapper/Vol_LVM-vm00: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/mapper/Vol_LVM-vm00p1 * 2 7395 59392305 83 Linux
/dev/mapper/Vol_LVM-vm00p2 7396 7832 3510202+ 82 Linux swap / Solaris


Você poderá preparar um arquivo, por exemplo, /tmp/parttable, com as especificações das demais partições.
1,7394,83,*
7395,,82,-

Estou usando uma partição primária para o raiz “/” (tipo 83) com ~ 60 GB e o restante para swap (tipo 82).

Você poderá usar o sfdisk e especificar os dados em: sectors, blocks, cylinders ou megabytes.

5-) Crie as partições para a segunda VM:

# dd if=/dev/zero of=/dev/mapper/Vol_LVM-vm01 count=1 bs=512
# sfdisk -uC /dev/mapper/Vol_LVM-vm01 < /tmp/parttable

Se preferir, simplesmente faça o processo manualmente:
# fdisk /dev/mapper/Vol_LVM-vm01

6-) Crie a SWAP para o segundo device:

Será necessário usar o "kpartx" para "mapear" as partições que existem dentro do device LVM:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# ll /dev/mapper/Vol_LVM-vm01*
# mkswap /dev/mapper/Vol_LVM-vm01p2

7-) Restaure a imagem da primeira VM:

- Restauração com GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm02p1 /LVM/vm01p1.partimg.gz
Time elapsed: 10m:59sec
Speed: 5.16 GiB/min
Data copied: 56.64 GiB

- Restauração sem GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm03p1 /LVM/vm01p1.partimg.000
Time elapsed: 1m:15sec
Speed: 2.90 GiB/min
Data copied: 3.62 GiB

Monte a VM e troque endereços de IP, hostname e MAC Address:
# mount /dev/mapper/Vol_LVM-vm01p1 /mnt/xen/
# vi /mnt/xen/etc/sysconfig/network-scripts/ifcfg-eth0
# vi /mnt/xen/etc/sysconfig/network
# vi /mnt/xen/etc/hosts

PS: Use o macgen.py para alterar o MAC address:

$ cat macgen.py
#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
print ':'.join(map(lambda x: "%02x" % x, mac))

9-) Desmonte a partição, e arrume seu /etc/xen/vm02:

# umount /mnt/xen
# kpartx -d /dev/mapper/Vol_LVM-vm02


Utilize o "uuidgen" para gerar um novo UUID para sua VM.
Não esqueça de trocar também o MAC no campo "vif" e o device LVM, ex:

name = "vm02"
uuid = "82f89076-487e-4de5-ab4a-99ce07c586eb"
maxmem = 1000
memory = 800
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ "type=vnc,vncunused=1,keymap=en-us" ]
disk = [ "phy:/dev/Vol_LVM/vm01,xvda,w" ]
vif = [ "mac=00:16:3e:5a:02:a6,bridge=xenbr0" ]

10-) Inicie a VM e corra para o abraço:

# xm create vm02 -c

Em caso de problemas, consulte este artigo: Xen: Dicas rápidas e problemas resolvidos

1-) Problemas com o reconhecimento do disco durante o boot:

“Booting from Hard Disk
Boot from Hard Disk failed: coud not read the boot disk
FATAL: No bootable device”

Verifique qual é o device utilizado em seu arquivo de configuração. Máquinas Para-Virtualizadas geralmente utilizam ‘xvda’:

disk = [ 'phy:/dev/Vol_LVM/xen_01,xvda,w', ]

Máquinas Full-Virtualizadas (HVM) geralmente utilizam-se de ‘hda’ ou ‘sda’.

disk = [ 'phy:/dev/Vol_LVM/xen_01,hda,w', ]

Para saber mais sobre os tipos de virtualizações existentes, consulte este post: Falando um pouco sobre Virtualização

2-) Se a sua placa de rede não é reconhecida depois do boot:

Experimente alterar o config da VM de
vif = [ 'mac=00:xx:xx:xx:xx:bc, bridge=xenbr0', ]

Para:
vif = [ 'type=ioemu, mac=00:xx:xx:xx:xx:bc, bridge=xenbr0', ]

Utilizando uma virtualização de um Red Hat 7.2, deu certo e apareceu a tal da Realtek

3-) Se o ‘xm console’ não funcionar…

- Altere o /etc/inittab (do guest) da seguinte forma:
...
# Console do Xen
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
...

- Dê um reload no inittab:
# /sbin/init q

- Altere o /etc/securetty para permitir o login de root via console:
...
tty11
xvc0

- Se o device não existir, crie-o:
# mknod /dev/xvc0 c 250 187

4-) Para gerar um UUID para uma nova máquina virtual:

# uuidgen

5-) Para gerar um MAC-ADDRESS para outra máquina virtual:

#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
print ':'.join(map(lambda x: "%02x" % x, mac))

Acredite: Seu roteador não vai gostar de encontrar duas máquinas com IP’s diferentes e MAC-ADDRESS iguais…

Este é um trabalho acadêmico realizado pelos meus alunos do 3 Semestre do curso de Tecnologia em Redes de Computadores, da FAENAC em São Caetano do Sul.

Os alunos fizeram algo muito interessante: Em um notebook P4 com 512 MB de RAM rodando Windows XP, instalaram o Ubuntu Feisty 7.04 dentro de um Vmware, e dentro desta máquina virtual configuraram um Xen para rodar uma para-virtualização do Ubuntu Edgy 6.10.

Uma pena que eles esqueceram de colocar as fontes das consultas, mas eu sei que uma delas foi retirada do Wiki do Ubuntu, a qual eu mesmo escrevi. E antes que eu esqueça, sim eles serão penalizados por esquecerem de citar a fonte!

A apresentação deles está bem recheada de ScreenShoots das configurações, mas você pode usar o Wiki se quiser fazer algo parecido (está mais legível).

Alunos:
Cezimar Nascimento / Diego Carvalho / Jose Wilter Frazão / Josiel Borges e Rodolfo Domingues

Link para download: Apresentação Acadêmica sobre o XEN

Abraços a todos

Uma dica rápida, colaboração do meu amigo Deny C. Luchetti:

Um problema de usar o virt-manager da Red Hat (também presente no Mandriva 2007.1!) para criar e administrar máquinas virtuais é o fato de que você simplesmente não consegue trocar de CD durante a instalação do guest OS, conforme eu havia comentado no artigo anterior sobre o Xen no Red Hat ES 5

O que acontece é uma pequena salada: O Xen não faz a instalação, ele executa uma versão modificada do qemu para faze-lo. E para trocar os CD’s pelo qemu existe um pequeno truque, bem documentado por sinal. O que não bem estava documentado era que o Xen da Red Hat chama o VNC por padrão quando você pede o console da máquina, e infelizmente, as teclas de atalho do qemu não funcionam dentro do VNC. Entendeu? Se não, leia de novo :-p

Para resolver isso, basta desabilitar o VNC no arquivo de configuração gerado pelo virt-manager (nota: o console gráfico continua funcionando, e até mais rápido!), mais ou menos assim:

name = “suse93″
builder = “hvm”
memory = “500″
disk = [ 'phy:/dev/lvm/xen_suse93,hda,w', 'file:/home/dluchetti/suse93.iso,hdc:cdrom,r',]
vif = [ 'type=ioemu, mac=00:16:3e:36:5b:9b, bridge=xenbr1',]
uuid = “e4e85bc7-b244-9d85-ec7a-b06728e6c70c”
device_model = “/usr/lib64/xen/bin/qemu-dm”
kernel = “/usr/lib/xen/boot/hvmloader”
vnc=0
vncunused=0
apic=0
acpi=0
pae=1
vcpus=1
boot=”d”
ne2000=1
serial = “pty”
on_reboot = ‘restart’
on_crash = ‘restart’

E, finalmente, para trocar a ISO do qemu e continuar a instalação, basta fazer assim:

Teclar “CRTL+ALT+2″ (atenção, não é F2!) e digitar:

(qemu) eject cdrom
(qemu) change cdrom /caminho/para/a/segunda/iso/arquivo.iso

Facinho né?
Abraços e boas virtualizações para vocês