Mergulhamos fundo em virtualização na empresa e eu ando varando as madrugadas migrando a infra-estrutura. Algumas coisas interessantes para dizer sobre isso…

A primeira observação é que a geração anterior de sysadmins a qual eu substituo até começou o processo – mas infelizmente por falta de fundos ou de apoio ou de conhecimento ou, mais provavelmente, de uma combinação dos três – fez uma melança horrível. E acertar esse meio-ambiente previamente virtualizado para o nosso novo vSphere tem sido mais complexo do que o previsto.

Com versões diferentes de vmware, número limitado de licenças de vCenter e vSphere (sim… no momento tenho os dois), uso de diferentes tecnologias e servidores como storage e péssimos posicionamentos dentro do rack migrar uma máquina virtual de um servidor ESX 3.5 para o vSphere pode ser uma tarefa bem ingrata. Principalmente quando você tem uma janela de manutenção limitada.

Imaginem a seguinte situação: Meu vCenter tinha 4 servidores ESX 3.5 sendo gerenciados. 2 numa subnet, 1 em outra subnet e outro numa terceira subnet. Não houve a preocupação de criar uma interface de gerenciamento na subnet de administração. Pior: subnets de níveis de segurança diferente. Então todo o tráfego do VMware passava pelo firewall.

Nem preciso dizer que vmotion não funcionava, né? Mas também não ia adiantar… No storage criaram um volume para cada ESX, de forma que um não via as VMs do outro. Então o vmotion tinha que ser full. Ah, sim… E cada ESX tinha apenas máquinas virtuais da subnet a qual a interface de administração pertencia. Trunk é para os fracos. Já falei que vmotion não funcionava?

Resumindo, eram apenas contâineres isolados com uma interface de administração centralizada. Horrível.

O que eu fiz agora, que compramos 4 Power Edges R710 top de linha e um storage EqualLogic foi sapecar placas de rede nos bichos. Cada servidor tem: 1 NIC pro iDrac, 1 NIC pra gerenciamento do vmware (incluindo vmotion), 1 NIC para cada subnet nas quais terei máquina virtual, 1 NIC para a rede de backup, 1 NIC para o storage e ainda 1 NIC disponível no momento (provavelmente utilizarei para fault-tolerance).

Para migrar as máquinas da antiga infra (!??) virtual para essa nova a forma mais fácil tem sido, acredite se quiser, usar o VMware Converter. Em alguns casos consegui fazer uma gambiarra e conectar com um ESXi novo num storage antigo e importar a VM para dentro do meu inventário e depois fazer um vmotion para o EqualLogic, mas foram poucos os casos que consegui.

E a cereja no bolo: No total já devo ter migrado – entre máquinas virtuais e P2V – uns 20 servidores. Desses todos, menos 2, eram Linux. Dos dois Windows que migrei um deles deu merda. Só 50% de aproveitamento. Como pode uma coisa dessa? Ainda bem que só servidor de uso interno é Windows, viu? Todos os servidores de serviços aos clientes são Linux. Senão a essa hora eu já tinha pedido para sair.

De qualquer forma tem sido uma tarefa longa e tediosa. Minhas madrugadas basicamente tem sido 2 horas de sono seguidas de 1 hora acordado em ciclos eternos até que acabe de migrar as máquinas do dia ou acabe a janela de manutenção e eu tenho simplesmente que destruir a VM nova e bootar a VM antiga.

Em compensação – exceto por ontem à noite – P2V tem sido uma baba. Conecto no servidor, desabilito todos os serviços e o crond, faço o P2V, dou shut na interface do switch onde a máquina físca está, subo a máquina virtual, instalo vmware-tools e corro pro abraço. No dia seguinte – quando chego no escritório – vou até o console do servidor e dou shutdown nele. Uns dois dias depois tiro a máquina do data-center e já era.

E aqui entre nós: Quando tenho a oportunidade de dormir eu até descanço mais tranquilo, pois alguns servidores muito críticos que fiz P2V estavam rodando em hardware com mais de três anos e o tempo médio para restaurar os backups é de 5 a 8 horas. Nem tava afins de enfrentar uma merda dessas.

Kudos para quem inventou o conceito de snapshot de file system direto no storage viu?

Os planos são de reduzir nossos 6 racks cheios de servidores hoje para 1 ou 1,5 rack com toda a infra virtualizada. E a ferramenta escolhida foi o VMware, que apesar de eu gostar, anda me dando uns nelvoso. E hoje foi outro desses dias.

Pra quem tem ESXi 3.5 com Virtual Center 2.5, atenção… Eu tive os seguintes problemas:

1-) Hardware incompatível: Dois dos cinco servidores – PowerEdges 2600 e 2650 – não são compatíveis com ESXi 4.0

2-) Ferramenta de upgrade: Eu escolhi o vSphere Host Update Utility, que é até fácil de usar, mas eu ACHO que está bugado. Além de ESXi tenho também um ESX na parada e ele deveria pedir um .iso pra fazer upgrade, de acordo com o knowledge base da vmware, mas na prática a ferramenta tá me pedindo um .zip que não tenho nem idéia de onde achar. Alias, achar o .zip pra fazer upgrade do ESXi também não foi nada fácil, então aqui a dica: Vai na parte de downloads do site e faz como se fosse baixar um demo. Na mesma tela onde tem o .iso tem também um .zip. É dele que você precisa.

3-) Site escroto, mal-feito, porco: Mesmo com a minha sessão logada, quando clicava em um link de download ou algo do tipo ele me pedia DE NOVO pra logar. E nas 3 vezes que fiz download hoje, já logado com meu usuário, tive que preencher quantos funcionários tem a empresa, qual tipo de storage uso, se eu tenho projeto em andamento e o cacete… de novo e de novo e de novo…

4-) Documentação mal-elaborada e cheia de recursividade: Um dos documentos que cheguei a consultar falava um monte de coisa inútil e referenciava outro documento. Esse outro documento enchia mais lingüiça e referenciava o primeiro de volta! Isso sem contar que todos os documentos do knowledge base tem frases do tipo “baixe o arquivo xpto”. E não tem link pra m* do arquivo.

Bom… tinha até mais coisa pra falar, mas tá pra começar NCIS e sou mais assitir TV que passar nervoso de novo lembrando a encheção de saco que foi o dia. Qualquer dúvida ou sugestão, os comentários são bem-vindos. Ou não.

Mas ai me envolvi no projeto de virtualização de servidores e começou minha dor de cabeça. Vale dizer que não uso Windows pessoalmente desde 1998, mas em 2001 fiz todos os cursos da certificação MCSE, sem nunca ter feito as provas. Afinal tenho até vergonha de admitir que fiz os cursos. uhauhauhauh

Mas o que importa é que depois de 2001 eu nunca mais mexi em Window Server e mesmo nas empresas onde passei e era obrigado a usar Windows no desktop eu mesmo nunca instalei o SO e praticamente usava o XP como uma ponte para abrir o putty e conectar nos Linux ou Cisco da vida.

Voltando ao projeto atual, estamos usando VMware de ponta a ponta. Inclusive fiquei sabendo que conseguimos ser um canal oficial da VMware. (Tchurrru!).  Então basicamente tenho uns 50 servidores Linux para virtualizar. Nosso objetivo é passar de 6 racks cheios de máquinas para 1 ou 1,5 rack.

O Hypervisor da VMware, como sabem é um Linux, certo? Então tenho meus servers Linux rodando num Hypervisor Linux. Simples. Mas ai o que eu preciso para gerenciar isso tudo? Um servidor Windows. Porquê o cocô do vCenter só roda em Windows. E não só o vCenter, mas o vCenter Client também.

Caracas… Quem foi o imbecil que não pensou em fazer um client para Linux ou pelo menos alguma coisa multi-plataforma?

E não só Windows Server é necessário, mas também Microsoft SQL Server!!! Só eu acho que as equipes internas da VMware não conversam entre si? O core do sistema inteiro em cima de Linux, mas administrar isso tudo precisa de Windows?

Então para minha felicidade estou tendo que rodar um Windows XP virtualizado (usando VirtualBox) no meu Linux e estou nesse momento instalando o Windows 2003 para colocar o vCenter.

Mas lógico que instalar Windows só é fácil nas mentes criativas de certas pessoas. Além de um horrível instalador em modo texto, numa tela azul assustoradora, ainda tem a maldita licença – que parece mais uma pegadinha pra ver se você sabe digitar – e ainda uma pergunta capciosa: Você vai licenciar esse server per seat ou per server. Hãããããnnn?? WTF? E seu sei lá que isso? Foram mais de 20 minutos perdidos até descobrir o que clicar nesse botão.

E depois ainda precisei fazer um windows update (tipo um apt-get upgrade de pobre, via web) que travou no meio e precisei rebootar. Vamos ver se a instalação vai até o final…

Então, apenas para constar, odeio Windows e a VMware, por me fazer usar Windows.

Mas a questão é uns dois meses atrás numa palestra técnica da HP sobre as novas linhas de servidores x86 e storages deles o engenheiro comentou, por alto, que ele havia – naquela semana – trabalhado em um cliente que tinha colocado em produção 16 blade servers em cima de um EVA 4400 onde os ESXi tinham disco local, mas as imagens da VMs eram compatilhadas na rede via NFS,  à partir de um blade server, mas esse com fiber channel ligado no storage.

Isso ficou na minha cabeça – porquê diacho alguém usaria NFS ao invés de iSCSI (que o EVA suporta nativamente)?

Ontem pesquisando achei algumas coisas interessantes, como esse post de um funcionário da NetApp, falando das vantagens de NFS sobre iSCSI num ambiente virtualizado.

Se você pensar bem, faz todo o sentido. Ao utilizar iSCSI você vai, inevitavelmente encapsular um sistema de arquivos em cima do outro (vmfs em cima de zfs, ext3, ou o que seja) e depois um sistema de arquivos dentro de um arquivo (os tal .vmdk)  e além disso vai colocar em cima do VMware a responsabilidade de gerenciar lock control, acesso aos blocos, etc. Sem contar que você está encapsulando comandos SCSI dentro do TCP/IP (algumas NICs já tem off-load disso no hardware).

E enquanto isso o NFS tá lá, bonitão. Fazendo aquilo que ele sabe fazer: Fornecendo arquivos via rede, controlando acesso e deixando na mão do sistema operacional a responsabilidade de cuidar de block device. Fica mais leve para o VMware não precisar cuidar disso.

Eu lancei a idéia para o meu chefe e a resposta dele foi: “Equallogic suporta NFS?  Porquê é isso que quero comprar”. Respondi que não, já desanimado pois estava acostumado com meu antigo gerente. Mas ai volta o email dele: “Então pesquisa isso a fundo e me apresenta quais os motivos pelos quais NFS vai ser uma solução melhor que o iSCSI. Se for o caso a gente muda pra NetApp.”

Amanhã devo preparar algo mais extenso para mandar para ele. Se sobrar tempo/disposição/paciência eu posto aqui também.

Mas fica ai a idéia… Quem tiver pra fazer deployment de ESXi, vale a pena pesquisar NFS como opção.

Estive recentemente num fórum promovido por eles aqui em Halifax e vi muito produto bacana, mas o vídeo abaixo acaba de mostrar que eles realmente não sabem brincar. Partiram pra ignorância muito forte agora.

E mais um ponto pro N810 na minha lista de prós e contras.

Quanto ao assunto principal, eu sou fã de virtualização faz um bocado de tempo e lembro de ter testado as primeiras versões do VMware lá pelos idos de 2001. Era um bocado lerdo e não muito estável.

Com o tempo eles foram melhorando o produto, mas infelizmente nossos caminhos não se cruzaram mais até 2006, quando um dos projetos da empresa onde eu trabalhava adotou VMware para migrar mais de 60 servidores legados para 4 servidores ponta de linha.

Minha atuação na época limitou-se a configurar os equipamentos de rede atendendo os servidores e fazer um eventual surfe de ombro no pessoal que estava configurando os ESXis.

Fiquei com isso na cabeça um tempo e assim que tive a oportunidade aqui no novo serviço coloquei um ESXi pra rodar, visto que agora ele é grátis. Sem contar o VMware server que rodo na minha workstation e também no micro de casa.

Como devem saber, existem diversos produtos de virtualização no mercado, incluindo vários opensource, mas eu nutro uma simpatia especial pelo VMware a um bom tempo e o que vi ontem só melhorou a imagem que eles tem na minha concepção.

Eu e o outro colega que me acompanhou no evento temos inúmeras idéias de como podemos utilizar o VMware aqui (e vou dizer que consigo ver uma enorme economia de dinheiro se fizemos isso), mas acho pouco provável que consigamos implementar… Sabe como é… Gerente velho não aprende truque novo.

Eu queria ter saído ileso de NY, sem comprar nada, conforme havia dito antes, mas não teve jeito. Sou um fraco.

O N810 é sensacional, mas caro demais pro orçamento no momento. E um PVR montado ia sair mais caro que a AppleTV, que depois de devidamente hackeada faz quase a mesma coisa.

Já fazia tempo que eu estava querendo alguma coisa da Apple, mas como sou mão-de-vaca até umas horas acabei ficando na linha PC tradicional mesmo, lógico que estirpando o Windows e rodando Linux e a AppleTV me pareceu um bom começo.

Antes de comprar fiz uma pesquisa no papai Google e achei este site, que serviu de ponte pra outros e ai minha felicidade estava completa.

Apesar de ser uma caixa pequena, fanless e sem interfaces comuns (aka teclado, mouse e monitor) a AppleTV nada mais é que um x86 rodando uma versão do Darwin:

Darwin appletv.home.lan 8.8.2 Darwin Kernel Version 8.8.2: Mon Jan 29 18:57:29 PST 2007; root:xnu-792.94.18~1/RELEASE_I386 i386 i386

Ai já viu, né? x86 com Unix é convite pra festa. Não vou entrar em detalhes dos hacks disponíveis, já que quem se interessar pode pesquisar, mas particularmente o que mais gostei foi suporte para codecs divx .

A segunda coisa que mais gostei nem sequer é hack: Suporte NFS, que é nativo no Darwin. Isso significa que minha AppleTV de 40GB tem agora 280GB de espaço:


Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s3 900M 456M 435M 51% /
devfs 95K 95K 0B 100% /dev
fdesc 1.0K 1.0K 0B 100% /dev
<volfs> 512K 512K 0B 100% /.vol
/dev/disk0s4 36G 870M 35G 2% /mnt
192.168.1.104:/home/arquivos/Movies 240G 86G 155G 36% /mnt/Scratch/Users/frontrow/remote

No começo eu estava apanhando um pouco porquê apesar de vir com bash (e não com o quebra-galho busybox) não tinha editor de texto. Mas alguma alma abençoada disponibilizou o VIM na internet. Ai fechou, né?

Por enquanto assistir DVD ainda dá um pouco de trabalho, pois preciso ripar e colocar no share manualmente, mas assim que entender melhor os programas que to usando pra fazer isso (todos CLI) vou fazer um scriptzin e ai acabou.

A pior parte foi a integração com o iTunes (software e loja), já que o dito cujo só roda em MacOS X e Windows. Mas nada que uma máquina virtual rodando Windows XP no VMWare não tenha resolvido. Aliás, fica a dica do seamlessrdp pra quem interessar. O nome é auto-explicativo, né?

Então vocês me dão licença que eu to indo ver TV, tá?

Até pouco tempo eu não conhecia essa “distribuição do Solaris”.

Os mais informados sabem que a Sun liberou o Solaris como software opensource há um certo tempo e pelo menos duas vertentes do SO são bem conhecidas: O Solaris propriamente dito e o OpenSolaris.

A idéia dos criadores do Nexenta foi juntar o Kernel do Solaris com o sistema de empacotamento do Debian. Jogada de mestre.

Colocar as ferramentas GNU em cima de um Kernel é a mesma coisa que o Linus fez em 1991, mas o pobre coitado na época contava apenas com o básico.

O Nexenta, por sua vez, ainda na sua versão alpha já conta com um sistema de gerenciamento de pacote “state of the art”, Gnome, Firefox, OpenOffice…

E como não se mexe em time que está ganhando, até o tema do Gnome tem as cores muito parecidas com as utilizas no Ubuntu.

As impressões como usuário final são boas, pois eu jamais poderia dizer que estou num Solaris e não no Linux.

Agora, se você já é rato velho de Linux, aqui começam as pequenas, mas irritantes diferenças:

1-) BSD vs System V

Voltando um pouco no tempo, podemos ver algumas pequenas diferenças entre as escolas BSD e System V. São poucas e são contornáveis, mas são extramente chatas para quem tem a mão mais rápida que a cabeça.

É frustante quando acontece isso:

root@myhost:~# ps aux
usage: ps [ -aAdefHlcjLPyZ ] [ -o format ] [ -t termlist ]
[ -u userlist ] [ -U userlist ] [ -G grouplist ]
[ -p proclist ] [ -g pgrplist ] [ -s sidlist ] [ -z zonelist ] [-h lgrplist]
'format' is one or more of:
user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid ctid
pri opri pcpu pmem vsz rss osz nice class time etime stime zone zoneid
f s c lwp nlwp psr tty addr wchan fname comm args projid project pset lgrp


Mas pode ser resolvido com:

root@myhost:~# /usr/ucb/ps aux|head -5
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 284 17.0 14.47664473952 ? S 18:55:10 5:44 /usr/lib/hal/hald
root 353 7.9 0.3 2196 1340 ? R 18:55:16 0:43 /usr/lib/hal/hald-
root 285 3.0 0.4 4096 1660 ? S 18:55:10 0:50 hald-runner
root 409 2.5 6.25091231988 ? R 18:55:18 1:25 /usr/bin/X :0 -br


2-) Diferenças nos comandos:

root@myhost:~# route -n
usage: route [ -fnpqv ] [ -R ] cmd [[ - ] args ]
root@myhost:~# man route
No manual entry for route
See 'man 7 undocumented' for help when manual pages are not available.

Tudo bem, vai… netstat -nr também resolve a questão.

3-) Voltar ao manual

Responda rápido: Como impedir que um host acesse sua máquina com iptables?

E com o ipf?


root@myhost:~# ipf --help
ipf: illegal option -- help
usage: ipf [-6AdDEInoPrRsvVyzZ] [-l block|pass|nomatch|state|nat] [-cc] [-F i|o|a|s|S|u] [-f filename] [-T ]
root@myhost:~# man ipf
No manual entry for ipf
See 'man 7 undocumented' for help when manual pages are not available.

Nada que 10 minutos no Google não resolva, mas o comodismo começa a falar mais alto. Aprender um boca de coisa de novo pode não ser interessante se o sistema não for muito superior.

4-) Out of the Box
Apesar de estar usando a versão disponível no site em formato imagem do VMWare, creio que a instalação padrão segue estes moldes e não gostei da quantidade de portas e serviços abertos na máquina.
Sou a favor das implementações “tudo fechado e você abre o que quiser”, mas o pessoal da Nexenta adotou o “deixamos isso aberto e você fecha se quiser (ou conseguir)”:

TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -----------
*.* *.* 0 0 49152 0 IDLE
127.0.0.1.4999 *.* 0 0 49152 0 LISTEN
*.111 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.54099 *.* 0 0 49152 0 LISTEN
*.62323 *.* 0 0 49152 0 LISTEN
*.4045 *.* 0 0 49152 0 LISTEN
*.445 *.* 0 0 49152 0 LISTEN
*.139 *.* 0 0 49152 0 LISTEN
*.35681 *.* 0 0 49152 0 LISTEN
*.62383 *.* 0 0 49152 0 LISTEN
*.33415 *.* 0 0 49152 0 LISTEN
*.36726 *.* 0 0 49152 0 LISTEN
*.22 *.* 0 0 49152 0 LISTEN
*.25 *.* 0 0 49152 0 LISTEN
*.25 *.* 0 0 49152 0 LISTEN
*.587 *.* 0 0 49152 0 LISTEN
127.0.0.1.631 *.* 0 0 49152 0 LISTEN


5-) Habemos BASH!
Pelo menos ninguém teve a idéia de colocar o famigerado KSH como shell e o Bash está aqui.

6-) Bom desempenho
Mesmo em uma máquina virtual, o Nexenta apresenta uma performance melhor do que a máquina Virtual com o Feisty que rodei há pouco tempo. Com 512MB de RAM está fazendo um bom trabalho.
Seria interessante trabalhar mais pesado com ele, numa máquina física e com mais variáveis envolvidas do que o Gnome, Mozilla, Shell e gerenciador de arquivos, mas parece que dá boa conta do recado

7-) ZFS
Pelo que tenho lido ZFS é o sistema de arquivos que todos os outros sistemas de arquivos gostariam de ser. No Linux ele está disponível só através de uma gambiarra meio pesada, devido às licenças do ZFS e a GPL serem incompatíveis, impossibilitando colocar o suporte a ele diretamente no Kernel. No Nexenta, isso não é problema. Faça bom proveito de tudo que esse FS pode te oferecer

Apesar deste post ter mais pontos negativos do que positivos, leve em consideração que ainda está em Alfa e que comodismo não é uma coisa boa!
Pessoalmente torço para o Nexenta dar certo e já tenho planos para ele, no meu futuro storage para uso pessoal.

Vou continuar acompanhando de perto o desenvolvimento dele.

Nexenta: http://www.gnusolaris.org/