Virtualização nos servidores mais simples da IBM e Sun
ANÁLISE
A seu serviço
Os principais personagens do cenário
de servidores Unix incluem suporte
a virtualização em seus sistemas
operacionais. Nós comparamos dois
candidatos da IBM e da Sun.
por Jens-Christoph Brendel
C
rawford Del Prete, Vice-Presidente
Sênior da empresa de pesquisa de mercado IDC, crê que cada década tem
sua própria revolução na TI. Os anos sessenta
foram marcados pela ascensão dos mainframes,
superados dez anos depois pelos minicomputadores. A revolução cliente-servidor se iniciou
em 1985, e os anos noventa viram o nascimento
e a explosão da Internet. Atualmente, o tópico
número um é a computação como utilidade,
ou seja, os recursos computacionais orientados à demanda, fornecidos como utilidades,
exatamente como eletricidade ou água. A virtualização, que é um forte pré-requisito para
a computação como utilidade, é o campo de
maior crescimento, segundo o IDC. Os analistas prevêem um volume de mercado de US$
2,2 bilhões em 2007 [1].
As histórias de sucesso de grandes vendedores de software parecem confirmar essa
previsão: O VMware alega ser a empresa de
maior crescimento em toda a indústria do
software, e a SWSoft, cujos sistemas virtuais
Virtuozzo estão disponíveis para todas as principais plataformas de 32 e 64 bits, reportou um
crescimento de 160% e dobrou seu quadro de
funcionários no ano passado. O derivado li-
52
vre, OpenVZ [2], não é o único concorrente
no setor do código aberto; o Xen [3] também
visa à inclusão no kernel Linux. E há várias
alternativas a esses produtos.
Não é de se surpreender que os fornecedores tradicionais de servidores Unix, como IBM,
Sun e HP, estejam tentando garantir que não
sejam deixados para trás, apresentando soluções
mais baratas para assegurar sua fatia do bolo.
A Linux Magazine investigou dois candidatos.
IBM P5-505
A primeira máquina a chegar em nosso escritório foi um sistema IBM P5-505. A máquina
veio com o sistema operacional AIX 5L 5.3
pré-instalado e o chamado Virtual I/O Server
(VIOS), a entidade central que circunda e
gerencia todos os recursos de E/S do sistema.
O VIOS mapeia discos físicos, interfaces de
rede e dispositivos ópticos em recursos para as
máquinas virtuais, que são conhecidas como
partições lógicas, ou LPARs. Além disso, obviamente as LPARs precisam de memória e,
ou uma CPU dedicada, ou uma garantia de
uma cota mínima de ciclos de CPU de um
grupo de processadores compartilhados, que
http://www.linuxmagazine.com.br
IBM x Sun | ANÁLISE
externo foi configurado para bombardear
cada servidor com requisições. Utilizamos
para isso a ferramenta de teste de regressão
HTTP Siege. A idéia era usar instâncias
paralelas dos benchmarks para pedir um
número máximo de páginas de um, dois,
três, quatro e, finalmente, todos os cinco
servidores virtuais (figura 3).
Isso torna necessário alocar recursos
para os consumidores, baseado em pesagens (a configuração original era 0.2
CPUs por LPAR). Como esperado, os
tempos de resposta dos servidores virtuais individuais aumentam junto com
o número de servidores virtuais respondendo a requisitos, enquanto a taxa de
transações cai de forma mais ou menos
inversamente proporcional (figura 2).
Acrescentar a taxa de transação ou os resultados do processamento total de todos
os servidores retorna números semelhantes aos valores para uma única instância,
levando-nos a concluir que o trabalho
adicional para realizar a virtualização é
mais ou menos desprezível.
Sem competição
Figura 1 O LPARMon visualiza a carga nas várias partições virtuais. Nesse cenário, a primeira
instância, que está sujeita a uma maior carga, demonstrou melhor desempenho da CPU.
os administradores podem alocar em
décimos de CPU. Todas essas alocações são estáticas. Em outras palavras,
os recursos conferidos a uma LPAR não
ficam disponíveis para outras partições,
e mudanças dinâmicas não são suportadas. Dito isso, para alterar alocações,
os administradores só precisam desabilitar temporariamente a partição em
questão, sem necessidade de reiniciar
o servidor todo.
O VIOS também oferece a interface
de usuário na forma do Integrated Virtualization Manager (IVM) [4]. Nesse caso,
o IVM substitui o Hardware Management
Console (HMC) normalmente instalado
pela IBM, que normalmente exigiria uma
máquina adicional. Além de uma interface
de linha de comando, o IVM ainda traz
uma interface web intuitiva que permite
que os administradores instalem e configurem as partições virtuais. Um assistente
está disponível para auxiliar na maioria
das tarefas, e os valores padrão também
fazem sentido, eliminando a necessidade
de habilidades de expert.
Linux Magazine #24 | Outubro de 2006
Quinteto virtual
Em nosso primeiro teste, configuramos
cinco partições lógicas e instalamos o
Suse Linux Enterprise Server (SLES) 9 [5]
em cada. Um servidor web foi instalado
em cada máquina virtual, e um cliente
Em outro teste, o benchmark esperava um
espaço aleatório de tempo, menor que um
segundo, antes de pedir cada página. Isso
significou menor sobreposição no acesso
aos recursos do sistema em cada servidor
virtual, e, portanto, uma distribuição de
carga mais realista do que o teste de carga
total. Nesse cenário, o número de servidores web paralelos não tinha praticamente
nenhuma influência sobre a taxa de transação. A carga da CPU medida na máquina
AIX hospedeira simplesmente mostra que
o tempo ocioso da CPU cai quando mais
servidores web são ativados (figura 3). Isso
Figura 2 O desempenho das máquinas virtuais dos servidores de categoria de entrada da IBM
e da Sun foi semelhante, e os tempos de resposta aumentaram proporcionalmente
ao número de instâncias concorrentes sob carga total.
53
ANÁLISE | IBM x Sun
Sun Fire 4100
Nome: Sun Fire 4100
CPU: Uma ou duas CPUs 64 bits Athlon64 ou Opteron (núcleo simples ou duplo: dois Opteron 280s de núcleo duplo, 2,4 GHz, na máquina testada)
Cache: 1MB Cache L2 por núcleo
RAM: máx. 16 GB (8 GB na máquina testada)
Discos: máx. 4x SAS 2,5” internamente, com hotplug
Slots: 2x PCI (perfil pequeno, 1x100 MHz, 1x133 MHz)
Interfaces: 4x Ethernet (10/100/1000), 3x USB 1.1
Conectores de sistema: Processador de serviço (Ethernet)
Sistemas operacionais: Solaris, Linux (RHEL3/4, SLES9), Windows Server 2003
Fonte: 2 redundantes, 550 W, com suporte a hotplug
Dimensões: 19” (48,26 cm), 1U
demonstra que múltiplas LPARs podem
mobilizar reservas de força inutilizadas sem
atrapalharem umas às outras – supondo
uma tarefa que imponha carga máxima
nas LPARs simultaneamente.
Sun Fire 4100
O segundo candidato foi um modelo
de categoria de entrada da Sun. O Sun
Fire 4100 também tem 2 CPUs (2x Opteron 280 dual core, no caso) e 8 GB de
RAM. O Solaris 10, com sua tecnologia
de virtualização baseada em zonas, veio
pré-instalado. À primeira vista, esse conceito não é muito diferente das partições
lógicas da IBM: nos dois casos, aplicações específicas podem ser completamente isoladas, conferidas a ambientes
de execução independentes, e receber
uma quantidade pré-definida de recursos do sistema.
À segunda vista, algumas diferenças
óbvias se tornam visíveis. A mais gritante
delas é que as zonas do Solaris automaticamente usam a instância do Solaris
que está rodando no hospedeiro como
seu próprio sistema operacional. Outras
versões e outros sistemas operacionais não
são suportados – pelo menos, não quando escrevemos esta matéria –, mas uma
extensão na forma do framework BrandZ
já foi liberada para o Open Solaris.
Além disso, o conjunto de recursos, que
agrupa os recursos operacionais de uma
54
zona e os isola das outras, só suporta um
tipo de recurso: a CPU. Diferentemente
da solução da IBM, não há como alocar
RAM para uma zona. Dito isso, pode-se
especificar um limite para o consumo de
memória de um aplicativo específico dentro de uma zona, embora de uma forma
um tanto obtusa. Para isso, devem-se definir projetos para impulsionar o recurso
de gerenciamento de recursos do Solaris,
pois projetos podem ser alocados em zonas.
Uma solução semelhante permite que se
defina o desempenho mínimo aceitável
de CPU para uma zona. Essa definição
pode ser modificada dinamicamente a
qualquer momento.
Menos quebras,
mais trabalho
Os administradores precisam usar a linha
de comando para configurar e iniciar as
zonas no Solaris. Essa é uma tarefa bem
simples, apesar da falta de uma interface
gráfica ou de um assistente. Exatamente
como em nosso teste anterior, configuramos
cinco zonas e ativamos um servidor web em
cada. Depois disso, rodamos os benchmarks
descritos anteriormente.
É claro que os valores absolutos do benchmark não permitem um julgamento aprofundado do desempenho do sistema – nem
era esse o propósito do teste. O que podemos
Figura 3 Em um cenário menos competitivo, o desempenho de cada servidor virtual não
depende minimamente do número de servidores concorrentes – o que diminui é o
tempo ocioso da CPU.
http://www.linuxmagazine.com.br
IBM x Sun | ANÁLISE
IBM P5-505
Nome: IBM System P5-505
CPU: Uma ou duas CPUs POWER5 de 64 bits (duas no sistema testado)
Cache: 1,9 MB Cache L2, e 36 MB Cache L3
RAM: máx. 32 GB (8 GB na máquina testada)
Discos: 2x Ultra320 SCSI, máx. 600 GB internamente
Slots: 2x PCI (1x longo, 1x perfil pequeno)
Interfaces: 2x Ethernet (10/100/1000), 2x USB, opcional: Fibre Channel, 10 Gigabit Ethernet, Infiniband
Conectores de sistema: 2x HMC
Sistemas operacionais: AIX 5L ou Linux (RHEL AS 4, ou SLES 9)
Fonte: 2 redundantes com suporte a hotplug
Dimensões: 19” (48,26 cm), 1U
dizer é que os resultados do benchmark fo- da CPU caiu somente 10%, mas tenha em
ram semelhantes nos dois sistemas.
mente que mais servidores virtuais não só
No cenário da virtualização, os resultados consumiriam mais tempo de CPU, mas
da máquina Sun foram como o esperado: a também precisariam de mais memória,
carga máxima força a distribuição dos recur- espaço em disco, e interfaces.
sos pelos candidatos do benchmark. A soma
dos resultados de desempenho individuais
permanece mais ou menos constante, novamente demonstrando que a virtualização Enquanto a virtualização no Linux ou no
não causa um excesso perceptível de traba- Windows® significa a adição de software de
lho (figura 4). Se relevarmos os problemas terceiros, muitas tecnologias tradicionais do
de concorrência – o que seria um reflexo Unix integram essa capacidade. A virtualizamais verídico de um cenário de produção ção traz um mínimo acréscimo de trabalho
– veremos que a máquina é capaz de suportar nesse cenário, e integra-se transparentemente
muito mais do que somente uns poucos ser- com a administração já familiar do sistema.
vidores virtuais. No Solaris, o tempo ocioso Em combinação com hardwares de alto de-
Conclusões
sempenho, onde sistemas de categoria de
entrada não são muito mais caros que um
PC bem equipado, a virtualização oferece
uma alternativa convincente.
As diferenças ficam escondidas nos
detalhes. Em nosso teste comparativo, o
sistema IBM conseguiu alguns pontos
extras graças a seu suporte a um uso mais
flexível das máquinas virtuais e um gerenciamento mais simples dos recursos. Mas
para administradores experientes de Solaris, que conseguem lidar com todas as
exigências de seus usuários numa única
plataforma, a virtualização sem perda e
sem ferramentas de terceiros, baseada na
abordagem de zonas, definitivamente tem
algumas vantagens. ■
Mais Informações
[1] Relatório especial IDC sobre
virtualização:
http://www.sinaimedia.com/
board/file/IDG Special Report
DC Virtualization.pdf
[2] OpenVZ: http://openvz.org
[3] Xen: http://www.cl.cam.ac.uk/
Research/SRG/netos/
xen/index.html
[4] IVM: http://www.redbooks.ibm.com/
abstracts/redp4061.html?Open
Figura 4 A soma dos resultados do benchmark de todos os candidatos permaneceu constante: adicionar mais zonas ao Solaris obviamente afeta muito pouco o desempenho do
sistema.
Linux Magazine #24 | Outubro de 2006
[5] SLES9: http://www.novell.com/
products/linuxenterpriseserver
55