RELATÓRIO DE VALIDAÇÃO VALIDAÇÃO ESG Lab. - IBM

RELATÓRIO DE 

VALIDAÇÃO 

ESG Lab. 

Série IBM DS5000 

Desempenho Real para Sistemas Virtualizados 

Por Brian Garrett 

Com Claude Bouffard 

Setembro, 2008

VALIDAÇÃO ESG LAB 

IBM DS5300 – Análise de Desempenho Mista 

Índice 

Índice Geral.................................................................................................................................................. 2 

Introdução.................................................................................................................................................... 3 

Histórico............................................................................................................................................ 3 

Série IBM DS5000............................................................................................................................4 

Validação ESG Lab...................................................................................................................................... 5 

Metodologia Benchmark Variada e Realista............................................................................................. 5 

Cargas de Trabalho de Aplicações........................................................................................................... 6 

Configurações do Laboratório de Teste (Test Bed).................................................................................. 7 

Layout do Drive ........................................................................................................................................ 7 

Configurando Máquinas Virtuais............................................................................................................... 8 

Os Resultados........................................................................................................................................... 9 

Throughput Bruto Agregado ....................................................................................................................................... 9 

Utilização da Maquina Virtual...................................................................................................................................... 11 

Escalabilidade IOPS Heterogênea Realista ............................................................................................................... 11 

Lidando facilmente com Picos Curtos de Throughput............................................................................................... 13 

Escalabilidade do Desempenho em nível de Aplicações Heterogêneas................................................................... 14 

Destaques da Validação ESG Lab............................................................................................................. 18 

Pontos a Serem Considerados.................................................................................................................. 18 

Ponto de Vista do ESG Lab........................................................................................................................ 19 

Apêndice...................................................................................................................................................... 20 

Relatórios ESG Lab. 

O objetivo dos Relatórios ESG Lab é instruir profissionais do campo da Tecnologia da Informação a respeito de 

tecnologias emergentes e produtos da indústria de armazenamento, administração de dados e segurança de 

informação. Os relatórios ESG Lab não visam substituir qualquer processo de avaliação que deva ser conduzido 

previamente à opção pela compra de qualquer destas tecnologias emergentes, mas sim auxiliar no discernimento 

das mesmas. Nosso propósito é avaliar algumas das características/ funções mais valiosas destes produtos, 

demonstrar como elas poderiam ser utilizadas para solucionar problemas de clientes reais e identificar quaisquer 

áreas carentes de melhorias. A perspectiva de perícia da ESG como mediadora baseia-se em nossa própria 

experiência testando tais produtos assim como em entrevistas com clientes que fazem uso destes produtos em 

ambiente de produção. Este relatório ESG foi patrocinado pela LSI Corporation. 

Todos os nomes de marca registrada são de propriedade de suas respectivas empresas. Informações contidas nesta publicação foram obtidas por 

fontes consideradas confiáveis pelo Enterprise Strategy Group (ESG), porém tais informações não são garantidas pelo ESG. Esta publicação pode 

conter opiniões do ESG, que estão sujeitas a mudanças eventuais. Esta publicação está protegida pelas leis de direitos autorais, em nome de The 

Enterprise Strategy Group, Inc. Qualquer reprodução ou distribuição, total ou parcial, seja em forma impressa, eletrônica ou de qualquer outra 

forma a pessoas não autorizadas a recebê-la, sem o expresso consentimento de Enterprise Strategy Group, Inc., será considerada violação dos 

direitos autorais americanos e estará sujeita a ação contra danos civis e, se aplicável, processo penal. Caso haja dúvidas, favor contatar o 

Atendimento ao Cliente ESG através do telefone (508) 482.0188. 

- 2 - 

Copyright © 2008, The Enterprise Strategy Group, Inc. Direitos Reservados

Introdução 



Um número cada vez maior de organizações vem implementando o armazenamento em rede juntamente com a 

virtualização do servidor de forma a consolidar, reduzir custos e melhorar a flexibilidade e disponibilidade de 

aplicações críticas, como bases de dados e e-mails. As pesquisas do ESG indicam que Profissionais de TI 

procurando obter mais benefícios da consolidação entre servidor e armazenamento estão preocupados com 

desempenho. Este relatório ESG Lab apresenta os resultados de um novo Benchmark de desempenho, desenvolvido 

para avaliar as aptidões realistas de um sistema de armazenamento IBM DS5300, associado ao SAN (Storage Area 

Network), implementado em datacenter altamente consolidado e virtualizado. 

Histórico 

O uso da tecnologia de virtualização de servidores tem aumentado entre organizações de todos os tamanhos, 

em todos os ramos do mercado, em todo o mundo. Em pesquisa recente do ESG sobre usuários atuais e futuros 

da virtualização de servidores, 52% das organizações entrevistadas já fazem uso desta tecnologia, enquanto 

48% planejam utilizá-la. ¹ Considerando os grandes benefícios econômicos da virtualização de servidor, a 

abundância de capacidade de processamento acessível e a dificuldade cada vez maior em solucionar questões 

relacionadas ao consumo de eletricidade e refrigeração dos Datacenters, o ESG prevê que a adoção da 

virtualização de servidores continuará intensa no futuro próximo. 

A pesquisa do ESG indica que a vasta maioria das organizações (87%) que já utiliza servidores virtualizados fez 

a transição em conjunto com a implementação do armazenamento em rede. Fazendo uma comparação, se 

tivermos discos rígidos interligados como ilhas, um grande aumento na utilização ocorrerá quando as aplicações 

compartilharem uma 'piscina' de armazenamento em rede. Aplicações implementadas em máquinas virtuais 

compartilhando uma 'piscina de armazenamento' são mais ágeis e acessíveis do que aquelas implementadas 

em discos rígidos ligados diretamente. 

FIGURA 1. DESAFIOS DA VIRTUALIZAÇÃO DO SERVIDOR E DO ARMAZENAMENTO EM REDE 

1 

Relatório de Pesquisa ESG, O Impacto da Virtualização do Servidor no Armazenamento, Dezembro, 2007. 

- 3 - 




Enquanto os benefícios da virtualização do servidor e armazenamento em rede são claramente persuasivos, 

profissionais de TI se deparam com um número de desafios em seu dia-a-dia enquanto tentam administrar um misto 

consolidado de aplicações sendo executadas em infra-estrutura virtualizada. Como mostrado na Figura 1, as duas 

maiores preocupações são o desempenho e a falta generalizada de informação e de melhores práticas. Isto se 

comprova em organizações de todos os tamanhos, independente do número de servidores virtuais utilizados. Faz 

sentido que haja tanta preocupação com o desempenho das infra-estruturas, considerando que 46% dos usuários de 

virtualização relatam que atualmente executam aplicações “Tier-1” em máquinas virtuais enquanto outros 33% 

planejam fazê-lo no futuro. 

A Série IBM DS5000 

A IBM recentemente anunciou o DS5300 Storage System — um sistema de armazenamento turbo-charged 

associado ao SAN, com até quatro vezes mais desempenho do que seu antecessor, o DS4800, e oito vezes o 

desempenho do DS4700. O DS5300 foi desenvolvido para atender os exigentes requisitos de desempenho real para 

ambientes de armazenamento de uso empresarial. Com alto desempenho otimizado para cargas de trabalho 

heterogêneas, o DS5300 foi projetado para escalabilidade modular (capacidade e/ou desempenho), alta disponibilidade 

e funcionalidade avançada, incluindo serviço de cópia e replicação remota. Como mostrado na Figura 2, o 

DS5300 é um sistema dual controller, suportando 16 interfaces host Fibre Channel de 4 Gbps, até 256 drives (FC ou 

SATA), até 16 GB de cache e 16 GB/seg. de banda interna. 

FIGURA 2. DESTAQUES DO DS5300 

Este relatório examina as capacidades de desempenho do DS5300 turbo-charged em nível de uso empresarial, e 

avalia a afirmação da IBM de que ele é ideal para atender os exigentes requisitos de desempenho de aplicações 

heterogêneas reais utilizadas em ambiente de servidor virtual. Especificamente, este relatório demonstra como um 

único DS5300 suporta: 

• Impressionantes 6.2 GB/seg. de throughput seqüencial agregado. 

• Diversas aplicações de uso crítico em empresas, executadas em dezesseis máquinas virtuais 

implementadas em dois servidores físicos. 

• Até 17, 512 usuários de e-mail utilizando Microsoft Exchange JetStress; 9,164 I/Os por segundo em base de 

dados pequena utilizando Oracle Orion; 4,551 IOPs em web servers simulados e 425 MB/seg. de throughput para 

leituras extensas utilizando Iometer. 

• Consolidação e crescimento otimizados com tempo de resposta rápido e excelente escalabilidade de 

desempenho. 

- 4 - 


Validação ESG Lab 



As capacidades de desempenho reais do IBM DS5300 foram avaliadas pelo ESG Lab através de testes práticos 

nas instalações da IBM localizadas em Gaithersburg, Maryland. A metodologia apresentada neste relatório foi 

desenvolvida para avaliar as capacidades de desempenho de um único IBM DS5300 Storage System 

compartilhado com múltiplos servidores virtuais executando uma carga heterogênea de aplicações. A cooperação 

das empresas VMware, IBM e LSI foi a chave para o sucesso deste projeto. Este projeto se beneficiou 

particularmente da perícia da VMware em auxiliar clientes a planejar a implementação de aplicações críticas em 

ambientes virtualizados, e da longa tradição de sucesso da IBM no mercado de sistemas de armazenamento 

modular, em parceria com a LSI. 

Metodologia Benchmark Variada e Realista 

Benchmarks convencionais para servidores foram criados para medir o desempenho de uma única aplicação 

sendo executada em um único sistema operacional instalado em um único computador. As ferramentas CPU2000 

e CPU2006, do SPEC (Standard Performance Evaluation Council) são exemplos conhecidos neste tipo de 

Benchmark para servidores. Muito similar aos benchmarks dos servidores tradicionais, os parâmetros para 

sistemas de armazenamento convencionais foram desenvolvidos para medir o desempenho de um único sistema 

de armazenamento executando uma única carga de trabalho. O benchmark SPC-1, desenvolvido e administrado 

pelo Storage Performance Council, citando a IBM como um elemento chave, é um ótimo exemplo. O SPC-1 foi 

desenvolvido para avaliar as capacidades de desempenho de um único sistema de armazenamento, enquanto ele 

serve uma aplicação em base de dados interativa on-line. 

Benchmarks tradicionais, executando uma única carga de trabalho de aplicações não podem demonstrar o que 

ocorre quando várias aplicações são utilizadas em conjunto num ambiente de servidor virtual. Para superar tais 

limitações, a VMware criou uma ferramenta para avaliar o desempenho de cargas heterogêneas, chamada VMmark. 

O VMmark utiliza esquema tile-based para medir o desempenho de aplicações e fornece metodologia consistente 

que captura tanto a escalabilidade geral quanto o desempenho individual das aplicações de uma solução em servidor 

virtual. O conceito VMmark é simples, porém elegante. Cada tile é definido de acordo com benchmarks padrões do 

mercado, emulando aplicações comuns de negócios (ex.: e-mail, base de dados, web server). O número de tiles 

sendo executados em uma única máquina é aumentado até que o servidor esgote seu desempenho. Uma pontuação 

é atribuída para que Profissionais de TI possam comparar os servidores com foco em suas capacidades de 

desempenho quando aplicações virtualizadas são executadas. Como um exemplo, os servidores high-end IBM x3850 

utilizados durante esta validação ESG Lab Validation possuem a excelente pontuação VMmark publicada de 13.5 

tiles. 

- 5 - 




Embora o VMmark auxilie na compreensão do desempenho de aplicações heterogêneas sendo executadas em um 

único servidor, ele não foi desenhado para avaliar o que ocorre quando um grupo heterogêneo de aplicações é 

executado em servidores múltiplos compartilhando um único sistema de armazenamento. O VMmark tende a 

exercer mais pressão interna no servidor do que no sistema de armazenamento. A metodologia apresentada neste 

relatório foi desenvolvida para exercer mais pressão no sistema de armazenamento do que nos servidores. Usando 

como base a metodologia VMmark, um conceito baseado em tiles foi utilizado durante esta Validação do ESG Lab. 

Como mostrado na Figura 3, cada tile é composto de quatro cargas de aplicações heterogêneas. Dois servidores 

físicos, cada um configurado com oito máquinas virtuais, foram usados para medir o desempenho enquanto o 

número de tiles ativos foi aumentando de um até quatro. 

As Cargas de Trabalho da Aplicação 

Os benchmarks padrões da indústria foram utilizados para emular a atividade de I/O (Input/Output) da carga de 

trabalho de quatro aplicações comumente utilizadas em empresas: 

• E-mail: O utilitário Microsoft JetStress foi utilizado para gerar tráfego de e-mail. Similar ao utilitário Microsoft 

LoadSimm usado nos testes do VMmark, o JetStress simula a atividade de usuários típicos do Microsoft Exchange 

quando enviam e recebem e-mails, agendam reuniões e criam listas de tarefas. O utilitário JetStress é, entretanto, 

um utilitário mais leve que o LoadSimm. Utilizando em conjunto a base de dados Jet Engine, o JetStress foi 

desenvolvido para o foco em desempenho de armazenamento. ² 

• Base de Dados: O utilitário Orion (Oracle) foi usado para gerar tráfego na base de dados. Assim como o 

Jetstress, o Orion é uma ferramenta leve com uso ideal para a medição do desempenho de armazenamento. O Orion 

foi desenvolvido para auxiliar administradores a compreender a capacidade de desempenho de um sistema de 

armazenamento, seja para identificar problemas com o desempenho ou para organizar a instalação de uma nova 

base de dados sem ter de criar e executar uma Base de Dados Oracle. O Orion é tipicamente usado para medir dois 

tipos de atividade em base de dados: processamento de transação on-line sensível ao tempo de resposta (OLTP) e 

processamento analítico on-line sensível a banda (OLAP). ³ 

• Web Server: O utilitário Iometer, padrão da indústria, foi utilizado para gerar tráfego no web server. A 

definição I/O era composta de leituras aleatórias de vários tamanhos de blocos, como documentado no Apêndice. O 

perfil do web server para Iometer usado neste teste foi originalmente distribuído pela Intel, autora do Iometer. 

Atualmente, o Iometer é um projeto open source. 

4 

Testes com o Iometer foram executados em drives físicos do 

Windows. 

• Scan/read: O utilitário Iometer foi usado para gerar um único fluxo de tráfego read. Operações que tendem a 

gerar este tipo de blocos seqüenciais grandes de tráfego incluem operações de indexação e scan, longas consultas 

em bases de dados ativas, operações de backup, uploads e cópias de dados em massa. Uma carga de trabalho 

seqüencial lida de 256 KB foi incluída em cada tile para adicionar um componente intensivo de throughput ao perfil 

I/O predominantemente aleatório de base de dados interativa e aplicações de e-mails. Como os mais experientes 

administradores de base de dados sabem, uma intensificação massiva de throughput no tráfego I/O pode diminuir o 

desempenho de aplicações interativas, fazendo com que usuários finais reclamem do desempenho. Adicionando 

alguns fluxos de throughput, tráfego intenso de scan/read foi utilizado para determinar se o desempenho interativo 

continuaria previsivelmente receptivo enquanto a quantidade na utilização de I/O mista aumentava. 5 

Cada uma das quatro cargas de trabalho foi executada em paralelo com o teste de e-mail JetStress levando o tempo 

mais longo possível para ser completada. (aproximadamente três horas). As cargas do Iometer foram paradas 

manualmente após a finalização por parte do utilitário JetStress. 

___________________________ 

2 

Os parâmetros JetStress, incluindo 32 threads por grupo de armazenamento, estão inclusos no output de JetStress mostrado no Apêndice como Figura 11. 

3 

Os parâmetros Orion, incluindo I/O pequeno de 8 KB e I/O grande de 1 MB estão inclusos no output de Orion, mostrado na Figura 12. 

4 

Definições da carga do Web server Iometer (www.sourceforge.net/projects/iometer) estão inclusas em trechos do arquivo de resultados como Figura 13. 

5 

A definição da carga de scan/read está inclusa em trechos do arquivo de resultados como Figura 14. 

- 6 - 




Configurações do Laboratório de Testes (Test Bed) 

O software VMware ESX Server 3.5 foi instalado em um par de servidores IBM xSeries 3850, cada um com quatro 

processadores quad-core de 3 GHz e 128 GB de RAM. Cada servidor possuía quatro adaptadores host bus com dual 

ports de 4 Gbps FC, conectados a um switch FC SAN Cisco MDS-9513. Um DS5300 com 256 drives FC de 15K 

RPM foi conectado aos servidores através de 16 portas FC de 4 Gbps como mostrado na Figura 4. 

FIGURA 4. TEST BED DO ESG LAB 

Layout do Drive 

A configuração do drive do DS5300 está resumida na Tabela 1. Dois grupos de armazenamento Microsoft Exchange e duas base 

de dados Oracle foram testadas com cada tile. Os volumes Exchange foram configurados em oito grupos de drives RAID-10. 

Simulando um par de aplicações de base de dados com desempenhos e requisitos de custos diferentes, uma das bases de dados 

Oracle foi configurada utilizando RAID-10 e a segunda foi configurada com RAID-5. O web server e os volumes scan/read foram 

configurados utilizando layout 7+1 RAID-5. O domínio de Volume foi balanceado com os dual controllers através do DS5300 e 

distribuídos igualmente entre as 16 interfaces Host. 

6 

6 

Para mais detalhes, favor consultar as Figuras 15 e 16 no Apêndice. O balanço dos 256 drives não foi configurado (8) ou definido como hot 

spares (8). 

- 7 - 




Configurando Máquinas Virtuais 

A configuração de uma das dezesseis máquinas virtuais é mostrada na Figura 5. Cada uma das dezesseis máquinas 

virtuais foi mapeada a um CPU quad-core, 16 GB de RAM, disco virtual em VMFS para o sistema operacional e outro 

mapeado em LUNs. A capacidade de disco do DS5300 foi utilizada para toda capacidade de armazenamento, 

incluindo os arquivos de disco virtual VMDK do VMware, imagens do sistema operacional Windows 2003, 

executáveis de aplicações e dados de aplicações. Todos os volumes de dados de aplicações em teste foram 

configurados com raw LUNs mapeados (também conhecidos como volumes RDM - Raw Device Mapped). A 

configuração de uma das máquinas virtuais utilizada no teste de e-mail JetStress é mostrada na Figura 5. Note como 

quatro raw LUNs mapeados foram configurados: dois como volume de base de dados Exchange e dois para os 

volumes de log do Exchange. 

FIGURA 5. CONFIGURAÇÃO DO SERVIDOR VIRTUAL 

Porque Isto é Importante 

Pesquisas do ESG indicam que a maior preocupação relacionada à implantação de armazenamento em rede para suportar a 

virtualização do servidor é com o desempenho. De 51% dos respondentes que já haviam implementado a virtualização do servidor 

e o armazenamento em rede, o desempenho foi, de longe, a maior preocupação entre os clientes. 

Os benchmarks para Armazenamento eram historicamente focados em um tipo de carga de trabalho (ex: base de dados ou e- 

mail) e uma métrica chave de desempenho (tempo de resposta ou throughput). Tipicamente, somente um servidor executando 

carga de trabalho intensiva em um CPU, sem sobrecarregar o armazenamento, era testado. Então, para que clientes da IBM 

pudessem compreender como o DS5300 se desempenha em um ambiente de servidor virtual, os testes aqui aplicados foram 

desenvolvidos para avaliar como aplicações reais se comportam quando executadas em servidores virtualizados múltiplos, 

compartilhando um único sistema de armazenamento. 

- 8 - 




Os Resultados 

De certa forma, benchmarks de sistemas de armazenamento são como uma análise do desempenho de um carro. As 

especificações, incluindo a potência do motor e aceleração de 0’ a 60’, são bons indicadores iniciais do desempenho 

de um carro. Enquanto as especificações fornecem um bom ponto de partida, existem vários outros fatores que 

devem ser levados em conta, incluindo as condições da estrada, as habilidades do motorista e as estimativas de uso 

de combustível. Assim como quando compramos um carro, um teste drive com tráfego real de aplicações é a melhor 

maneira de determinar como um sistema de armazenamento irá se desempenhar em situações cotidianas. 

Throughput Bruto Agregado 

A análise de desempenho começou com um exame das capacidades do throughput agregado de baixo nível no 

equipamento de testes. Este teste foi executado usando o utilitário Iometer, rodando em dez servidores físicos IBM 

x335 em nível de entrada, executando os sistemas operacionais Microsoft Windows. Metade dos drives utilizados 

depois nos testes heterogêneos de aplicativos reais foi exercitado (128 drives de disco). 

Um total de dez servidores com vinte portas FC de 4 GB foram conectados ao DS5300 através de um switch Cisco 

MDS 9513 com dezesseis portas host ativas de 4 Gbps. Um total de 16 LUNs foi exercido. Cada um dos LUNs foi 

configurado em um grupo RAID-5 de drives de 15K RPM configurados com esquema de paridade 4+1. Cada um 

dos servidores do Windows exerceu dois LUNs distribuídos nos dois controllers do DS5300. 

Um perfil Iometer de reads/writes seqüenciais de 1 MB foi utilizado para esta primeira análise de aprovação das 

aptidões de throughput bruto agregado do DS5300. Uma rodada similar de testes executada contra o mesmo test 

bed utilizando um servidor IBM p595 executando o sistema operacional AIX produziu resultados similares. De 

forma similar à classificação de um dinamômetro quanto à potência de um carro, o throughput máximo registrado 

pelo console DS5000 foi utilizado para quantificar o poder de um DS5300 Storage System turbo-charged. 

FIGURA 6. RESULTADOS DE TESTES AUDITADOS 

- 9 - 


O Que Significam os Números 



• Semelhantemente à avaliação da potência do motor de um carro, a avaliação do throughput de um sistema 

de armazenamento é um bom indicador do poder do motor de um sistema de armazenamento. 

• O throughput de armazenamento é a medida de banda disponível da qual o sistema pode tirar vantagem. O 

throughput pode ser medido em base de fluxo ou agregados. Um fluxo é representado por uma aplicação ou usuário 

se comunicando através de uma interface I/O para um dispositivo. O throughput agregado é a medida de quantos 

dados o sistema de armazenamento pode mover de uma só vez por todas as aplicações e usuários. 

• O ESG Lab confirmou que o DS5300 possui uma avaliação impressionante de throughput agregado de 6.2 

GB/seg para reads e 5.85 MB/seg para writes. Estes resultados são aproximadamente quatro vezes melhores do que 

as avaliações da geração antecessora, IBM DS4800. 


Um sistema de armazenamento precisa de um motor forte e arquitetura modular bem desenhada para se desempenhar 

previsivelmente em ambiente heterogêneo real. Uma medida de força de um motor do controller de armazenamento é seu 

throughput agregado máximo. O ESG Lab confirmou que um sistema DS5300 com metade dos drives utilizados durante os 

testes de carga de trabalho heterogênea, apresentados depois neste relatório, pode sustentar um excelente throughput 

agregado de 6.2 Mb/seg. (read) seqüenciais em grandes blocos. 

De acordo com a experiência do ESG Lab, este resultado é extremamente impressivo para um sistema de armazenamento com 

dual controller. De fato, este resultado indica que o DS5000 é bastante recomendado para consolidação de servidores virtuais e 

aplicações heterogêneas reais, e definitivamente recomendado para computação intensiva, edição de vídeos e aplicações 

científicas com requisitos extremos de banda. 

- 10 - 




Utilização da Máquina Virtual 

Uma vez terminados os testes de throughput de baixo nível, utilizando dez servidores físicos em nível de entrada, o 

DS5300 foi reconfigurado para testes realistas heterogêneos, utilizando um par de servidores high end IBM x3850, 

como documentado previamente neste relatório. O teste com aplicações heterogêneas começou com uma análise 

rápida da memória do servidor e da utilização do CPU para garantir que não houvesse congestionamentos entre 

aplicações virtualizadas e o DS5300. O uso da memória e do CPU, como registrados pelo administrador de infraestrutura 

VMware, é mostrado na Figura 7. 

FIGURA 7. COMPONENTES DO SISTEMA (DASHBOARD) 

Estes screenshots foram feitos durante a fase de pico de atividade do teste de quatro tiles. Com utilização da 

memória abaixo de 50% e utilização do CPU abaixo de 25%, não houve nenhum congestionamento óbvio entre 

as aplicações virtualizadas e o IBM DS500. 

Escalabilidade IOPS Heterogênea Realista 

Input /Output por segundo, ou IOPS, é a medida do número de operações que um sistema de armazenamento 

pode desempenhar em paralelo. Quando um sistema é capaz de mover muito IOPS, originando-se em um disco 

ou saindo do cachê, ele tenderá a ser capaz de servir mais aplicações e usuários paralelamente. Similar ao poder 

de torque do motor de um carro, a avaliação do IOPS para um controller de armazenamento pode ser utilizada 

como indicador da potência do motor de um sistema de armazenamento. 

Enquanto o IOPS saindo de um cachê é tipicamente um número grande e pode fornecer indicação da velocidade no 

front end do controller de armazenamento, o IOPS de disco é uma métrica mais útil para determinar o desempenho 

real de um sistema de armazenamento servindo aplicações heterogêneas comumente utilizadas em empresas. Por 

exemplo, e-mails e aplicações interativas de base de dados tendem a ser aleatórios por natureza e, portanto, se 

beneficiam de bom IOPS do disco. Com isto dito, um conjunto heterogêneo de aplicações tende a ter padrões de 

tráfego I/O aleatórios e seqüenciais que podem ser utilizados a partir de cachê ou de disco. 

- 11 - 




O ESG Lab mediu o desempenho do IOPS como relatado pelo DS5300 enquanto o número de máquinas virtuais 

executando cargas de aplicações heterogêneas foi aumentado de quatro para dezesseis. Com uma mistura de I/O 

aleatórios e seqüenciais em centenas de drives de disco, o objetivo não era registrar um número grande de IOPS. O 

objetivo com este exercício era avaliar a escalabilidade do DS5300 enquanto um número de aplicações em constante 

aumento eram consolidadas em uma única plataforma virtualizada. A escalabilidade do IOPS durante este período 

de pico de carga de atividade heterogênea é demonstrada na Figura 8 a seguir. 

FIGURA 8. CONSOLIDAÇÃO DE CARGA DE TRABALHO HETEROGÊNEA COM PICO ATIVO 


• As taxas de IOPS variaram no teste de Ambientes Heterogêneos com picos ocorrendo durante o teste “Orion 

Small IOPS” e próximo ao fim, quando utilitário JetStress executou uma checagem de consistência nas bases de 

dados. 

• Um pico de 34, 438 IOPS e uma média de 24, 714 IOPS foram gravados durante a execução dos quatro 

tiles. 

O IOPS se dimensionou de forma quase-linear enquanto o tráfego de aplicações heterogêneas aumentou de 

um até dezesseis servidores virtuais. 


Escalabilidade de desempenho previsível é um ponto crítico quando aplicações heterogêneas estão compartilhando um sistema 

de armazenamento. Uma intensificação na atividade de I/O em uma aplicação (ex: uma verificação de consistência em uma base 

de dados) pode causar lentidão no tempo de resposta, perda em produtividade e, no pior dos casos, perda de receita. 

O ESG Lab confirmou que a taxa de I/O processada pelo DS5000 escala extremamente bem enquanto várias aplicações 

heterogêneas são executadas em paralelo. 

- 12 - 


Lidando facilmente com Picos Curtos de Throughput 



Como percebido durante o monitoramento do IOPS, houve picos de atividade de throughput que poderiam ser 

correlacionados ao comportamento periódico de aplicações reais. Duas intensificações de throughput agregado 

foram observadas: a primeira durante o teste de alto volume de MBPS com o Oracle, que simula throughput intensivo 

em aplicações OLAP, enquanto o segundo ocorreu durante o teste de consistência de base de dados do JetStress. 

O pico registrado logo após a fase OLAP do Orion é mostrado na Figura 9. 

FIGURA 9. PICO DE THROUGHPUT (UM SERVIDOR, QUATRO TILES ATIVOS, VISTA SOBREPOSTA DO VM VIEW) 


• Um nível de throughput agregado de 1.6 GB/seg. foi registrado enquanto aplicações heterogêneas reais 

foram executadas em 16 máquinas virtuais compartilhando um único DS5300 Storage System (800 MB/seg. de um 

dos dois servidores físicos, como mostrado na Figura 9). 

• Enquanto o throughput se intensificou durante a fase de testes OLAP do Orion, a utilização de banda para 

outras cargas heterogêneas operando em paralelo permaneceram estáveis. 


Análises de desempenho geralmente se focam em cargas de trabalho com tempo de resposta sensível ou cargas de trabalho com 

throughput seqüencial intensivo, mas ainda assim aplicações heterogêneas reais em ambientes virtualizados são geralmente uma 

mistura de ambas. Intensificações da atividade devido a operações de pesquisa e indexação, consultas a base de dados, 

trabalhos de backup ou fluxo de vídeo podem ser extremamente intensivas no throughput. Implementar mais sistemas de 

armazenamento, ou mais hardware em cada sistema de armazenamento, pode ser uma maneira de evitar um possível impacto no 

desempenho causado por throughput intensivo em carga de trabalho de ambiente heterogêneo. Ainda assim, isso aumenta os 

custos e a complexidade de administração do sistema, além de anular os objetivos da consolidação de armazenamento. 

O ESG Lab observou pico de 1.6 GB/seg. de throughput agregado intensivo enquanto um teste de throughput com o Oracle Orion 

OLAP era executado — mesmo enquanto houve tráfego de e-mail do Exchange o sistema fluiu com ótimo tempo de resposta. 

- 13 - 


Escalabilidade do Desempenho em nível de Aplicações Heterogêneas 



Após analisar as avaliações de IOPS e throughput do motor turbo-charged do DS5300, aqui examinaremos o 

desempenho em nível de aplicações. O output esperado por cada ramo da indústria foi analisado para 

determinar a escalabilidade do desempenho e a receptividade de aplicações reais sendo executadas em um 

ambiente virtual consolidado. 

Microsoft Exchange 

A ferramenta de teste JetStress, da Microsoft, foi utilizada para estabelecer quantos usuários simulados de e-mail 

são suportados pelos recursos do DS5300 alocados para o Exchange. O número de IOPS e tempo de resposta 

para cada base de dados, juntamente com o log de volume, foram gravados após cada execução do JetStress. 

Uma meta de 20 milissegundos ou menos para reads de DB foi estabelecida como parâmetro de aprovação no 

teste. Este valor é definido pela Microsoft como o limite além do qual os usuários finais sentirão que seu sistema de 

e-mail está se comportando de forma lenta. 

O ESG utilizou as orientações a seguir - retiradas de um relatório da IBM descrevendo os resultados de um sistema 

de armazenamento IBM DS4800 (Relatório de Análise JetStress) - para interpretar os resultados: 

Em ambiente Exchange 2007, o desempenho é geralmente calculado considerando perfil de usuário com 0.5 IOPS, o 

que equivale a um usuário de peso do Exchange. Como o desempenho de disco varia, seus cálculos devem ser 

baseados na métrica de cem IOPS por disco, um ponto de início bem conservador, e a partir daí ajustados a seu 

ambiente específico. 

7 

Logs do Microsoft JetStress foram utilizados para determinar o número de IOPS e tempo de resposta, enquanto o 

número de máquinas virtuais era aumentado de quatro até dezesseis. Considerando um perfil de usuário de 0.5 

IOPS, o número de IOPS foi utilizado para calcular o numero suportado de usuário do Exchange. A escalabilidade 

dos usuários do Exchange, enquanto o número de tiles era aumentado de um até quatro, é mostrada na Figura 10 

e na Tabela 2. 

8 

7 

"IBM System Storage DS4800 Exchange Server 2007 15, 000 Mailbox JetStress Analysis", David Hartman e David West, Novembro de 2007, 

8 

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101123 Uma amostra de log do JetStress está inclusa no Apêndice -Figura 

11. 

- 14 - 





• O teste de aplicações heterogêneas com tile único suportou 7, 713 usuários do Exchange com 14.5 milissegundos de 

tempo de resposta médio do disco da DB. 

• O desempenho foi escalado de forma quase linear para 17, 512 usuários enquanto o DS5300 estava ocupado 

processando e servindo outras aplicações simultaneamente. 

• Todos os testes aprovaram com média de tempo de resposta de leitura da DB abaixo das recomendações da Microsoft 

de 20 milissegundos. 

• O teste de quatro tiles produziu 8, 756 usuários em 64 drives da base de dados, e desenvolveu 137 IOPS por drive, 

muito acima da recomendação conservadora da IBM de 100 IOPS por drive. 

Este teste utilizou dois servidores e se focou somente no desempenho de armazenamento e dimensionamento. Um único array de 

armazenamento do IBM DS5300 manteve recursos significantes disponíveis e seus recursos foram subutilizados em todas as 

rodadas de testes. Com 8, 752 usuários por servidor físico (17, 512 usuários distribuídos em dois servidores físicos) este resultado 

ficou perto de exceder os 10, 000 usuários recomendados pela Microsoft. A Microsoft não recomenda mais de 10, 000 usuários 

por servidor devido ao impacto que tal quantidade de usuários poderia causar no tempo de recuperação do servidor, de acordo 

com os SLAs. Em um ambiente de produção é recomendado manter o número de usuários dentro das recomendações da 

Microsoft, para fins de suporte e recuperação. 

Oracle Orion 

O utilitário Oracle Orion foi utilizado para medir o IOPS de transferências pequenas (8 KB) e o tempo de resposta e throughput 

para transferências grandes (1 MB). Os resultados 'pequenos' foram utilizados para prever o desempenho e escalabilidade de 

aplicações interativas sensíveis ao tempo de resposta da base de dados (Ex.: OLTP). Os resultados 'grandes' foram utilizados 

para prever o desempenho do throughput com aplicações de pesquisa intensa da base de dados (Ex.: DSS) 

O ESG utilizou as seguintes recomendações, fornecidas pela Oracle no Oracle OpenWorld em Novembro de 2007, para 

interpretação dos resultados: 

Tenha tempo de resposta de 5-10 milissegundos para discos com desempenho do tempo de resposta de IO crítico. Comece 

supondo 30 IOPS por disco para OLTP e 20 MB/seg por disco em DSS. Estes valores estão bem abaixo do valor teórico, mas 

permitem reparação de mídia e etc. 9 

Para aplicações novas ou inexistentes utilize fluxos de regras de negócios ou de perfis de transações de dados para entender 

“o que é uma transação”, e então estenda para transações por segundo ou por hora. Opcionalmente o números vistos em 

nossas apresentações de consultoria podem ser utilizados. Note que estes são somente valores de referência. Utilize os 

valores a seguir como referências básicas para OLTP: 

Sistema de transações baixas – 1 000 IOPS ou 200MBytes/s 

Sistema de transações médias – 5, 000 IOPS ou 600 Mbytes/s 

Sistema de transações high-end – 10, 000 IOPS ou 1Gbytes/s




• Duas aplicações de base de dados Oracle foram testadas dentro de cada tile. A primeira rodou em 

capacidade RAID-10 e a segunda em capacidade RAID-5. 

• O teste de quatro tiles alcançou um total de 9, 164 IOPS pequenos e 883 MBPS grandes enquanto o sistema 

rodava simultaneamente um grupo cargas de aplicações heterogêneas. 

• Utilizando o guia de referências do Oracle "Back of the envelope sizing guidelines", este nível de atividade 

I/O é significantemente maior do que um “sistema de transações médias” típico e quase representa um “sistema de 

transações high-end” o que é “raramente possível”. 

• O número total de IOPS pequenos processados durante o teste com quatro tiles mostrou excelentes 176 

IOPS small por drive, diminuindo a recomendação extremamente conservativa de 30 IOPS por drive fornecida pelo 

Oracle. 

• Os volumes de base de dados RAID-10 com média de latência pequena a 4.6 milissegundos foram 

levemente mais rápidos do que os volumes RAID-5 a 5.6 milissegundos. Considerando a recomendação de 5 a 10 

milissegs. do Oracle, o ESG Lab acredita que estes são resultados excelentes – especialmente quando consideradas 

as cargas heterogêneas intensivas de I/O que estavam sendo atendidas pelo DS5300 em paralelo. 

- 16 - 




Web Server e Scan/Read 

Os resultados de desempenho como relatados pelo utilitário Iometer para cargas de trabalho do web server e 

scan/read executadas em máquinas virtuais durante o teste de quatro tiles são listados na Tabela 4. 


• Considerando a natureza read-only (somente leitura), cache-friendly, do tráfego I/O do web server, o ESG 

Lab acredita que estes resultados indicam que o DS5300 possui a potência requerida para servir dezenas de 

milhares de solicitações simultâneas de página. 

• O ESG Lab acredita que uma carga de sistema de arquivos produziria resultados que seriam 

aproximadamente similares a carga do web server utilizada para este teste. 

• Cada um dos quatro fluxos scan/read manteve ao menos 100 MB/seg. de throughput por todo o período de 

duração do teste de cargas de trabalho heterogêneas. Um fluxo dessa magnitude pode suprir as necessidades de 

diversos fluxos simultâneos de backup, trabalhos de scan e indexação ou um table scan da base de dados com 

throughput intensivo – sem impactos perceptíveis no desempenho das aplicações sendo executadas em paralelo. 

Assim como no sistema elétrico de sua casa, compreender quantas aplicações podem ser executadas em paralelo 

antes de se explodir um fusível não é função dos fios atrás das paredes. O que faz a diferença é o design utilizado 

pelos circuitos para distribuir a quantidade correta de eletricidade para cada aplicação. Os testes de throughput bruto 

forneceram indicação precoce de que o motor do DS5000 foi desenvolvido para fornecer a quantia certa de força 

para cada aplicação virtualizada quando necessário. Os testes de aplicações heterogêneas em servidores virtuais 

provaram isso. O DS5000 é ideal para suportar diversas aplicações e usuários em um datacenter virtual consolidado. 


Tempo de inatividade excessivo e tempo de resposta lento pode resultar em perda nas vendas, perda de afeição dos 

clientes, perda de produtividade, perda de competitividade e aumento nas despesas. Com cada vez mais empresas 

executando conjuntos de aplicações de negócios em soluções de virtualização como o VMware, a escalabilidade das 

cargas de trabalho heterogêneas com desempenho previsível se faz necessária. 

O e-mail é geralmente considerado a aplicação de negócios mais significante hoje em dia e, dentro do mundo do e- 

mail, o Microsoft Exchange é líder. Os testes do ESG Lab confirmaram que o DS5000 pode manipular de forma 

satisfatória um grande número de usuários do Exchange — mesmo enquanto trabalha com outras aplicações e 

milhares de outros usuários, com tempo de resposta previsível rápido. 

- 17 - 


Destaques da Validação do ESG Lab 



Impressionantes 6.2 GB/seg de throughput agregado foram mantidos durante os testes simulando o uso de 

servidores físicos e 128 drives. 

Cargas de aplicações heterogêneas reais sendo executadas simultaneamente em dezesseis máquinas 

virtuais preparadas em dois servidores IBM x3850 forneceram o desempenho necessário para suportar 

simultaneamente: 

17, 512 usuários de e-mail JetStress (perfil 0.5). 

9, 164 I/Os por segundo de base de dados pequena do Orion e 883 MBPS grandes. 

4, 551 IOPs simulados do web server. 

425 MB/seg. fluxo de tráfego de leitura (read) 

Excelente quantidade de IOP por drive (ex.: 167 no teste OLTP Oracle). 

Enquanto o número de máquinas virtuais compartilhando um único DS5300 foi aumentando, o desempenho 

se escalou de maneira quase-linear com tempos de resposta previsivelmente rápidos (16 ms para leituras de 

base de dados do JetStress, 4.6 a 5.8 ms para IOPS pequeno do Oracle Orion). 

O DS5300 teve potência sobressalente para uso em rebuilds e funções avançadas, incluindo serviços de 

cópia e replicação remota. 

Pontos a serem considerados 

As melhores práticas geralmente aceitas e configurações predominantemente padrão do VMware e do 

DS5300 foram utilizadas durante o desenvolvimento deste teste. Como é esperado após qualquer 

benchmark desta magnitude, a análise profunda dos resultados indica que mais ajustes provavelmente 

forneceriam resultados ligeiramente acima dos resultados aqui obtidos. Considerando que o objetivo deste 

teste não era gerar grandes números, o ESG Lab está confiante de que os resultados apresentados neste 

relatório satisfarão o objetivo de estimar a escalabilidade e receptividade do desempenho, enquanto um 

crescente de máquinas virtuais compartilha um grupo de armazenamento consolidado do DS5300. 

Comparado com a geração anterior de controllers, a Série DS4000, o DS5300 duplica o número máximo de 

interfaces host suportadas de 4 Gbps FC para 16 e aumenta o número de máximo de drives suportados de 

244 para 256. Considerando a potência turbinada dos motores da Série DS5000, como mostrado neste 

relatório, suporte futuro a mais drives e interfaces host (ex.: 8 Gbps FC) permitiriam aos clientes da IBM 

consolidar o número cada vez maior de máquinas virtuais em um único grupo de armazenamento. A IBM 

informou ao ESG que lançamentos futuros do DS5300 irão suportar 8 Gbps FC e até 448 drives. 

No caso de aplicações que requerem desempenho extremo além do fornecido pelos drives FC e SATA, o 

ESG Lab acredita que o DS5000 seria uma arquitetura ideal para a adição de drives SSD. Drives SSD 

podem ser utilizados particularmente para melhorar o desempenho de indexação de bases de dados 

altamente referenciadas e arquivos temporários. A IBM informou o ESG que lançamentos futuros do DS5300 

irão suportar a tecnologia de drives SSD. 

Os resultados do testes e os dados apresentados neste documento estão baseados em conceitos de 

benchmark com padrão industrial, implementados simultaneamente em ambiente controlado. Devido a 

diversas variáveis em cada ambiente de produção de datacenter, é importante que seja feito um 

planejamento de capacitação e testes em seu próprio ambiente para que as configurações de um sistema de 

armazenamento possam ser validadas. 

- 18 - 


Ponto de Vista do ESG Lab 



A virtualização do servidor tem sido implementada por um número crescente de organizações de forma a diminuir gastos, 

aumentar a disponibilidade e melhorar o uso de recursos e fornecer atualizações ao sistema sem perturbar a rotina dos usuários. 

Cada um destes benefícios é fundamentalmente habilitado ao se desacoplar servidores, aplicações e dados de bens físicos 

específicos. A virtualização do servidor permite que o mesmo seja feito, estendendo estes benefícios dos servidores ao domínio 

de armazenamento subjacente — fazendo com que as organizações de TI fiquem um passo mais próximas do ideal de uma 

infra-estrutura completamente virtualizada. 

Porém, enquanto os benefícios de uma infra-estrutura completamente virtualizada são óbvios aos profissionais de TI, o 

desempenho ainda é uma preocupação real. Administradores de servidor, armazenamento e rede andam procurando respostas 

para diversas perguntas: 

• Podemos alcançar o desempenho prometido no SLA com aplicações heterogêneas críticas para empresas? 

• O sistema de armazenamento possui a potência necessária para atender aplicações heterogêneas reais? 

• O sistema de armazenamento pode ser escalado para acomodar crescimento e consolidação futura? 

A IBM, a LSI e a VMware abordaram o ESG Lab em 2008 com o ambicioso objetivo de responder a estas perguntas. Parâmetros 

para uma avaliação foram então desenvolvidos, para medir as capacidades de desempenho de um sistema de armazenamento 

sujeito a I/O intensivo de um misto de aplicações de negócios virtualizadas. Ao invés de desenvolver parâmetros baseados em 

uma única carga de aplicações com o objetivo de produzir um algarismo grande, os parâmetros foram desenvolvidos para simular 

um misto de carga de aplicações, incluindo e-mail e aplicações on-line ligadas à base de dados. Ao invés de desenvolver um teste 

para determinar a escalabilidade de um único servidor, os parâmetros foram utilizados para forças um sistema de armazenamento 

compartilhado por servidores múltiplos. Em outras palavras, os parâmetros foram desenvolvidos para que pudéssemos ver o que 

acontece quando várias aplicações heterogêneas virtualizadas são implementadas em servidores múltiplos compartilhando uma 

plataforma de armazenamento consolidada. 

Usando a deixa dos parâmetros VMmark da VMware, um conceito de “tile” foi utilizado durante o desenvolvimento deste teste. 

Cada “tile” era composto de quatro aplicações, cada uma executando sua própria máquina virtual. A potência de um par de 

servidores IBM x3850, com a ótima nota VMmark de 13.5 tiles, foi utilizada para elevar a pressão até quatro tiles e dezesseis 

aplicações virtuais em paralelo. O ESG acredita que os resultados desta avaliação focada em armazenamento complementam 

os excelentes resultados da avaliação focada no servidor previamente feita pelo VMmark no servidor IBM x3850. 

A IBM e a LSI Logic possuem mais de uma década de experiência no desenvolvimento de sistemas de armazenamento 

modulares FC-attached, desenvolvidos para alcançar a demanda de desempenho otimizado no que concerne custos, abrangendo 

organizações de médio porte, aplicações mid-tier, departamentos remotos e aplicações near-line. Este relatório ESG Lab se focou 

no mais recente produto proveniente da parceria entre a LSI e a IBM — o IBM DS5300. A série IBM DS5000 se baseia na herança 

de sua antecessora, a série DS000 com sistema de disco, com mais de 87, 000 sistemas e 511 petabytes enviados até hoje. Os 

motores sob os capôs do DS5100 e do DS5300 foram turbinados (turbo-charged) para atender a demanda de desempenho 

realista de aplicações virtualizadas. Com duas vezes mais conectividade de host e até quatro vezes mais desempenho que o 

DS4800, o DS5000 foi desenvolvido para entregar alto desempenho, baixa latência e a escalabilidade balanceada necessária 

para suprir as exigentes necessidades de desempenho de aplicações heterogêneas reais compartilhando uma infra-estrutura 

consolidada. 

Os testes do ESG Lab se iniciaram com a confirmação de que o test bed do DS5300 pode entregar até 6.2 GB/seg. de 

throughput bruto agregado — com somente metade dos drives FC disponíveis. Este resultado impressionante foi um indicador 

antecipado de que o IBM DS5300 possui a banda interna e o poder de processamento necessários para lidar com cargas de 

trabalho heterogêneas reais. Os resultados dos testes com cargas de trabalho heterogêneas foram ainda mais impressionantes. 

Um único DS5300 suportou simultaneamente 17, 512 usuários simulados do Exchange; 9, 164 I/O de base de dados pequena; 

4,551 IOPs de web server simulado e 425 MB/Seg. de throughput para banda de fluxos intenso de tráfego lido (read). Tempos 

de resposta previsivelmente rápidos foram mantidos enquanto o número de servidores virtuais era aumentado. 

Com potência de sobra para funções extra de armazenamento, incluindo serviços de cópia e replicação remota, o ESG Lab 

tem o prazer de reportar que o DS5000 entrega o desempenho real necessário para um misto de I/O intensivo de aplicações 

sendo executadas em máquinas virtuais compartilhando um grupo de armazenamento consolidado. 

- 19 - 


Apêndice 



- 20 - 




Exemplo do output criado pelo utilitário JetStress. Este exemplo mostra o desempenho de um dos quatro 

testes JetStress sendo executados em paralelo. Este relatório, especificamente, foi criado pelo utilitário 

JetStress rodando em máquina virtual dentro do 4° tile do teste de quatro tiles. 

- 21 - 


Desempenho do Sistema Host 



Test Log 

8/15/2008 10:09:51 AM -- Jetstress testing begins ... 

8/15/2008 10:09:51 AM -- Prepare testing begins ... 

8/15/2008 10:09:55 AM -- Attaching databases ... 

8/15/2008 10:09:55 AM --Dispatching transactions begins ... 

8/15/2008 10:09:55 AM --Database cache settings: (minimum: 64.0 MB, maximum: 512.0 MB) 

8/15/2008 10:09:55 AM --Database flush thresholds: (start: 5.1 MB, stop: 10.2 MB) 

8/15/2008 10:09:58 AM --Database read latency thresholds: (avg: 0.02 sec/read, max: 0.05 sec/read). 

8/15/2008 10:09:58 AM -- Log write latency thresholds: (avg: 0.01 sec/write, max: 0.05 sec/write). 

8/15/2008 10:09:59 AM -- Operation mix: Sessions 32, Inserts 40%, Deletes 30%, Replaces 5%, Reads 25%, Lazy 

Commits 55%. 

8/15/2008 10:09:59 AM -- Performance logging begins (interval: 15000 ms). 

8/15/2008 10:09:59 AM -- Attaining prerequisites: 

8/15/2008 10:14:03 AM -- \MSExchange Database(JetstressWin)\Database Cache Size, Last: 483606500.0 (lower 

bound:483183800.0, upper bound: none) 

8/15/2008 12:14:05 PM -- Performance logging ends. 

8/15/2008 12:14:05 PM --JetInterop batch transaction stats: 100849, and 100734. 

8/15/2008 12:14:05 PM --Dispatching transactions ends. 8/15/2008 12:14:05 PM -- Shutting down databases ... 

8/15/2008 12:14:08 PM -- Instance2560.1 (complete), and Instance2560.2 (complete) 

8/15/2008 12:14:08 PM -- Performance logging begins (interval: 30000 ms). 

8/15/2008 12:14:08 PM -- Verifying database checksums ... 

8/15/2008 1:46:06 PM --E: (100% processed), and F: (100% processed) 

8/15/2008 1:46:09 PM -- Verifying log checksums ... 

8/15/2008 1:46:15 PM -- Volume E: has 0.0171 for Avg. Disk sec/Read. 

8/15/2008 1:46:15 PM -- Volume F: has 0.0159 for Avg. Disk sec/Read. 

8/15/2008 1:46:15 PM -- Volume G: has 0.0018 for Avg. Disk sec/Write. 

8/15/2008 1:46:15 PM -- Volume G: has 0.0010 for Avg. Disk sec/Read. 

8/15/2008 1:46:15 PM -- Volume H: has 0.0018 for Avg. Disk sec/Write. 

8/15/2008 1:46:15 PM -- Volume H: has 0.0010 for Avg. Disk sec/Read. 

8/15/2008 1:46:15 PM -- Test has 0 Maximum Database Page Fault Stalls/sec. 

8/15/2008 1:46:15 PM -- Test has 0 Database Page Fault Stalls/sec samples higher than 0. 

- 22 - 




Abaixo temos um exemplo do output criado pelo utilitário Oracle Orion. Este exemplo mostra o 

desempenho para um dos oito testes Orion executados em paralelo. Este relatório, especificamente, foi 

criado pelo utilitário Orion rodando em máquina virtual dentro do 4° tile do teste de quatro tiles. 

- 23 - 




Exemplo do output criado pelo utilitário Iometer após um test run do Web Server. Este exemplo mostra o 

desempenho para um dos quatro testes de Web Server executados paralelamente. Este relatório foi criado 

especificamente pelo teste Iometer Web Server rodando em maquina virtual dentro do 4° tile do teste de 

quatro tiles. 

- 24 - 




Exemplo do output criado pelo utilitário Iometer após uma rodada de teste scan/read. Este exemplo mostra 

o desempenho para um dos quatro testes Scan/Read executados em paralelo. Especificamente, este 

relatório foi criado pelo teste Scan/Read do Iometer quando foi executado em máquina virtual dentro do 4° 

tile do teste de quatro tiles. 

- 25 - 




- 26 - 




- 27 - 




Os trechos a seguir foram extraídos do Resumo de Perfil de um IBM DS5300 Storage System, após a 

última rodada de testes ter sido concluída. 

- 28 - 




- 29 - 




- 30 - 




- 31 -

RELATÓRIO DE VALIDAÇÃO VALIDAÇÃO ESG Lab. - IBM

Create successful ePaper yourself

Delete template?

Save as template?