Académique Documents
Professionnel Documents
Culture Documents
So Paulo
2011
So Paulo
2011
So Paulo
2011
DEDICATRIA
AGRADECIMENTOS
Aos meus filhos Renan e Nicolly, minha av Wilma, aos meus irmos Alberto,
Paulo Tiago e Matheus, que me suportaram durante o mestrado.
Ao meu saudoso pai, Yoshisuke Ogura, que me incentivou a ingressar na vida
acadmica, assim como minha me, Mary Ogura, que tambm me ajudou
incondicionalmente.
Ao professor orientador Edson Toshimi Midorikawa pelos trs anos de
convivncia e ensinamentos, e pela amizade e pacincia nas horas boas e nas
difceis.
professora Lria Matsumoto Sato pelas diversas ajudas, diretas e indiretas.
A todos os professores da Escola Politcnica da Universidade de So Paulo
pelas matrias ministradas durante meu curso de mestrado.
Aos professores Edson Midorikawa, Lria Sato e Pedro Corra pelos comentrios
e sugestes efetuadas na qualificao dessa dissertao.
Aos meus amigos Artur, Charles, Kakugawa e Piantola, que me ajudaram em
diversas situaes.
A todos os meus amigos do laboratrio LAHPC.
s empresas HP e IBM, que viabilizaram minha participao no processo de
mestrado.
RESUMO
Computao nas nuvens um novo termo criado para expressar uma tendncia
tecnolgica recente que virtualiza o data center. Esse conceito busca um melhor
aproveitamento
dos
recursos
computacionais
dos
aplicativos
corporativos,
ABSTRACT
Cloud computing represents a new age, raised to express a new technology trending
that virtualizes the data center. This concept advanced to make a better use of the
computational resources and corporate application, virtualizing through the programs of
operating systems virtualization, platform, infrastructure, software, etc.
This virtualization occurs through the virtual machine (VM) to execute virtualized
applications in this environment. However, a VM may be configured in such a way that
the performance delays on processing, due to overhead or other hardware allocation
itself.
In order to maximize the hardware allocation on MV creation, it was developed a
methodology of application characterization to collect performance data and achieve the
best VM configuration. After this study, based on workload metric, it is possible to
identify the classification of the application type and present the best configuration, the
recommended environment and the not recommended. This way, the trend to achieve a
satisfactory performance in virtualized environment may be discovered through the
program characterization, which possibly evaluate the behavior of each scenario and
identify important conditions for its proper operation. In order to prove this argument,
mono and multi core applications under monitors of virtual machines were executed.
The collected results were satisfactory and are aligned with each previously known
application characteristic. However, it may occur exceptions in this method, mainly when
the monitor of the virtual machine monitor is submitted with high volume of processing.
Keywords: Cloud Computing, cloud applications, system characterization, virtual
machines, virtual machine monitors, virtual machines.
SUMRIO
1. INTRODUO..............................................................................................................17
1.1 OBJETIVO................................................................................................................20
1.2 METODOLOGIA.......................................................................................................20
1.3 CONTRIBUIO DESTE TRABALHO....................................................................21
1.4 ESTRUTURA DOS CAPTULOS.............................................................................22
2. CONCEITOS BSICOS...............................................................................................23
2.1 COMPUTAO NAS NUVENS...............................................................................23
2.1.1 Tipos de nuvens....................................................................................................28
2.1.1.1 Nuvem pblica....................................................................................................28
2.1.1.2 Nuvem privada...................................................................................................29
2.1.1.3 Nuvem hbrida....................................................................................................29
2.1.2 Desafios da computao nas nuvens...................................................................30
2.1.2.1 Disponibilidade de um servio............................................................................31
2.1.2.2 Dados em lock-in................................................................................................31
2.1.2.3 Confidencialidade e auditabilidade....................................................................31
2.1.2.4 Gargalos na transferncia de arquivos..............................................................32
2.1.2.5 Imprevisibilidade no desempenho......................................................................32
2.1.2.6 Armazenamento escalvel.................................................................................32
2.1.2.7 Bugs em larga escala em sistemas distribudos................................................33
2.1.2.8 Escalonando rapidamente..................................................................................33
2.1.2.9 Lista de reputao..............................................................................................34
2.1.2.10 Licena de software.........................................................................................34
2.2 VIRTUALIZAO.....................................................................................................35
2.2.1 Tipos de monitores de mquinas virtuais..............................................................35
2.2.1.1 MMV - tipo I........................................................................................................36
2.2.1.2 MMV - tipo II.......................................................................................................36
2.2.1.3 MMV - Hbrido....................................................................................................37
2.2.2 Monitores de mquinas virtuais.............................................................................39
8
2.2.2.1 Xen.....................................................................................................................39
2.2.2.2 VMware...............................................................................................................41
2.2.2.3 Kernel virtual machine (KVM).............................................................................42
2.2.3 Computao nas nuvens privada..........................................................................43
2.3 INSTRUMENTAO DE APLICAES..................................................................45
2.4 Lgica Fuzzy............................................................................................................50
2.5 CONCLUSO DO CAPTULO.................................................................................50
3. METODOLOGIA DE CARACTERIZAO DE APLICAES....................................51
3.1 APLICAES EXPERIMENTADAS.........................................................................51
3.1.1 Pacote sysstat: comandos de instrumentao.....................................................51
3.1.2 Aplicativo iostat......................................................................................................52
3.1.2.1 Relatrio de utilizao de CPU..........................................................................52
3.1.2.2 Relatrio de utilizao de dispositivos...............................................................53
3.1.3 pmap: instrumentao de memria por processo.................................................56
3.2 CARACTERIZAO DE APLICAES PARA COMPUTAO EM NUVENS......58
3.2.1 Aplicaes do estudo inicial..................................................................................58
3.2.1.1 Aplicaes distribudas.......................................................................................58
3.2.1.2 Aplicaes transacionais....................................................................................61
3.2.2 Primeiros estudos sobre a caracterizao de aplicaes.....................................63
3.2.3 Ambiente computacional.......................................................................................67
3.2.4 Tipos de aplicaes...............................................................................................68
3.2.4.1 CPU bound.........................................................................................................68
3.2.4.2 I/O de disco e memria......................................................................................69
3.2.4.3 I/O de rede..........................................................................................................70
3.2.5 Resultados do estudo inicial..................................................................................71
3.2.5.1 Resultados de CPU bound abordagem de multiprocessadores.....................71
3.2.5.2 Resultados de CPU bound aplicao em ambiente distribudo......................73
3.2.5.3 Resultados de I/O de disco aplicao transacional........................................74
3.2.5.4 Comparativo entre cenrios com a mesma quantidade de vcpus.....................76
3.2.6 Concluso do estudo inicial...................................................................................77
9
11
LISTA DE ILUSTRAES
Figura 1: Computao utilitria........................................................................................24
Figura 2: Computao nas nuvens..................................................................................24
Figura 3: Arquitetura de computao nas nuvens (ZHANG, 2010).................................28
Figura 4: Os 10 maiores obstculos e oportunidades de melhorias na computao nas
nuvens (ARMBRUST, 2009).............................................................................................30
Figura 5: Monitores de mquina virtual do tipo I (LAUREANO, 2006)............................36
Figura 6: Monitores de mquinas virtuais tipo II (LAUREANO, 2006).............................37
Figura 7: Monitores de mquinas virtuais hbridas tipo I (LAUREANO, 2006)................38
Figura 8: Monitores de mquinas virtuais hbridas tipo II (LAUREANO, 2006)...............39
Figura 9: Arquitetura atual de I/O no XEN (CHERKASOVA, 2007).................................40
Figura 10: Arquitetura VMware (VMWARE, 1999)...........................................................41
Figura 11: Arquitetura KVM (BARUCHI, 2010)................................................................43
Figura 12: As trs possibilidades de uma requisio de servio (JAIN, 1991)................47
Figura 13: Abordagem de aplicaes transacionais........................................................74
Figura 14: metodologia completa.....................................................................................78
Figura 15: DER do banco de dados.................................................................................82
Figura 16: pbzip2 tempo de execuo..........................................................................94
Figura 17: pbzip2 tempo iowait do dom0......................................................................95
Figura 18: pbzip2 I/O de gravao................................................................................96
Figura 19: pbzip2 I/O de leitura.....................................................................................97
Figura 20: lame - tempo de execuo..............................................................................98
12
LISTA DE TABELAS
Tabela 1: Recursos do OpenNebula................................................................................44
Tabela 2: Sada do comando iostat..................................................................................52
Tabela 3: exemplo de iostat - utilizao de CPU..............................................................53
Tabela 4: exemplo de iostat - utilizao de dispositivo....................................................53
Tabela 5: exemplo de iostat - parmetros........................................................................55
Tabela 6: Exemplo de sada do comando pmap..............................................................57
Tabela 7: comando pmap - parmetros............................................................................58
Tabela 8: NPB benchmarks (EL-GHAZAWI, 2002) .........................................................60
Tabela 9: Principais parmetros do dbgen.......................................................................62
Tabela 10: Cenrios dos experimentos iniciais da dissertao.......................................64
Tabela 11: Exemplo de execuo do mpiexec com NPB.................................................64
Tabela 12: Cenrios do TPC-H.........................................................................................65
Tabela 13: Consulta table scan........................................................................................66
Tabela 14: Consulta complexa.........................................................................................66
Tabela 15: Configurao das mquinas reais e virtuais..................................................67
Tabela 16: Resultados de CPU bound abordagem de multiprocessador (unidade em
segundos).........................................................................................................................72
Tabela 17: Resultados de CPU bound abordagem de aplicao distribuda (unidade
em segundos)...................................................................................................................73
Tabela 18: Aplicaes transacionais FS utilizados........................................................75
Tabela 19: Comparao dos cenrios com 4 vcpus (unidade em segundos)................76
Tabela 20: Comparao dos cenrios com 3 vcpus (unidade em segundos).................77
Tabela 21: Classificao Fuzzy vs recurso ideal/recomendado......................................81
Tabela 22: Opes do pbzip2...........................................................................................87
Tabela 23: Exemplo de compactao do pbzip2..............................................................88
Tabela 24: Parmetros do lame.......................................................................................90
Tabela 25: Exemplo de sada (stdout) do lame ...............................................................90
13
14
GLOSSRIO
API
Benchmark
BPS
BT
Block Tridiagonal
CAPEX
Capital Expenses
CG
Conjugate Gradient
CPU
DOM0
Domnio 0
EP
Embarrassingly Parallel
ERP
FS
File System
FT
Fourier Transform
HD
Hard Disk
HPC
IaaS
Infrastrucuture As A Service
IO
IS
Integer Sort
ISP
KVM
LU
MFLOPS
MG
Multigrid calculation
MIPS
MPI
MTBE
MTBF
MTTF
MTTR
MV
Mquina Virtual
NFS
15
NFS
NPB
OPEX
Operating Expenses
PaaS
Platform As A Service
QOS
Quality of Services
RTT
SaaS
Software As A Service
SGBD
SLA
SO
Sistemas Operacionais
SP
SQL
SSD
TI
Tecnologia da Informao
TPC
TPS
VCPU
VMM
VPN
16
1.
INTRODUO
Atualmente, o conceito de computao nas nuvens tem sido alvo de muitas discusses,
pois cada provedor de servio implementa computao nas nuvens de acordo com sua
prpria poltica, e tambm pelo fato de no existir um padro.
Mesmo no havendo um padro, a computao nas nuvens descrita
basicamente em trs arquiteturas: infrastrucutre as a service (IaaS), plataform as a
service (PaaS), software as a service (SaaS). Com essas estruturas bsicas, o provedor
organiza o ambiente computacional provendo para o cliente uma mquina virtual (MV)
simples, uma interface com uma plataforma (Google App Engine, Microsoft Windows
Azure, Amazon S3, Force.com, Morph, Bungee Connect) ou o produto ser
disponibilizado diretamente para o cliente.
Na perspectiva do provedor de infraestrutura na nuvem, vantajosa a mistura de
diferentes equipamentos ou arquiteturas de computadores para a execuo de um
determinado programa. Para isso, se a aplicao possuir suporte a processamento
distribudo e paralelo, as vantagens aumentaro de acordo com a possibilidade de se
utilizar mais de uma mquina ou um multiprocessador para um aplicativo. Com isso, o
provedor de nuvem tem a possibilidade de criar solues de escalabilidade e
flexibilidade no gerenciamento de mquinas virtuais (MV) de uma forma simples,
conforme a necessidade do cliente da nuvem.
Ao fazer uso desta flexibilidade de alocao dos recursos computacionais conforme a
demanda, o provedor aproveita ao mximo os equipamentos disponveis em seu data
center para o processamento das aplicaes na nuvem.
A tecnologia de computao nas nuvens ainda tem algumas dificuldades,
principalmente em termos de desempenho, confidencialidade de dados, escalabilidade,
segurana e armazenamento de dados (ARMBRUST, 2009). O provedor da nuvem
precisa modificar os mecanismos de provisionamento de custos, desempenho e
segurana de dados. Alm disso, deve fornecer recursos ou meios para garantir
integridade de dados, confidencialidade e auditoria nos ambientes de mquinas virtuais.
Esses requisitos no funcionais so importantes para o controle e a garantia de
execuo de uma aplicao comercial. Alm do mais, importante que haja um
17
contrato de prestao de servio (Service Level Agreement - SLA) (PATEL, 2009) com
as regras e polticas que regem o funcionamento das atividades desse provedor de
nuvem. O SLA garante, para ambas as partes, qualidade e disponibilidade do ambiente
e inclui o que est ou no no escopo do ambiente virtual, entre outros aspectos. Caso o
provedor de nuvem necessite utilizar ambientes computacionais de empresas terceiras,
preciso que seja includo no contrato, para que o cliente tenha o conhecimento dessa
possibilidade de transferncia da mquina virtual para outra infraestrutura. Uma vez
firmado esse contrato, os clientes podem usufruir da mquina virtual conforme suas
necessidades, e utilizar desse ambiente o tempo que for necessrio. Pode-se, apenas,
ter mtodos para monitorao de desempenho, algoritmo de tolerncia falha no
monitor de mquinas virtuais, entre outros mtodos para a administrao do ambiente
computacional.
Na perspectiva do cliente da nuvem, ocorre uma mudana de cultura empresarial
em termos de projeto e arquitetura das solues computacionais. O cliente pode
configurar os aplicativos corporativos em formato de MVs em sua infraestrutura privada,
e, na falta de recurso para o processamento, transferir essa MV para a nuvem,
flexibilizando a arquitetura das aplicaes, com a possibilidade de escalar diferentes
infraestruturas e combinar ambientes privados e pblicos. Outra soluo interessante
da nuvem a possibilidade de criar um ambiente redundante; caso o sistema falhe na
infraestrutura privada, ativada a MV de contingncia na nuvem pblica, contendo os
mesmos aplicativos, bibliotecas, framework, e todos os recursos para executar os
servios necessrios.
Com relao ao provedor da nuvem, tambm se est passando por uma
mudana empresarial, pois ele precisa contabilizar a utilizao das MVs do cliente da
nuvem por hora, que convertida em tarifas para o cliente. Conceitualmente,
denomina-se pay-as-you-go (paga-se pelas horas utilizadas) (PATEL, 2009) ou
operating expenses (Opex despesas operacionais) (ARMBRUST, 2009).
O modelo Opex consiste na forma como uma empresa investe em infraestrutura,
contratando servios em infraestrutura de terceiros para operar aplicativos sem a
aquisio de recursos, equipamentos, programas etc. Um outro modelo o capital
18
1.1 OBJETIVO
O objetivo desta dissertao definir uma metodologia para a caracterizao de
aplicaes em ambientes de computao nas nuvens. A partir deste mtodo, possvel
identificar caractersticas da aplicao que possam ser classificadas por taxonomia de
programas, sendo que cada categoria tem uma soluo de arquitetura indicada ou
recomendada. Esta metodologia prope uma alternativa para que os provedores da
nuvem possam controlar, configurar e escalar os ambientes computacionais conforme a
necessidade do cliente ou conforme a necessidade de negcio que o provedor da
nuvem possa vir a ter.
1.2 METODOLOGIA
Esta dissertao foi desenvolvida em duas etapas. Na primeira, foi feito um estudo
inicial com o intuito de identificar caractersticas de consumo de CPU, disco e a
influncia do monitor de mquinas virtuais em aplicaes distribudas, paralelas e
transacionais. Na segunda parte, foi desenvolvida uma metodologia para caracterizao
de aplicao, e nela foram definidas trs fases. Na primeira fase, foi criada uma MV
contendo todos os aplicativos do experimento e os comandos de instrumentao, para
que estes ltimos possam ser executados paralelamente, coletando os dados de
20
2.
CONCEITOS BSICOS
23
24
27
2.1.1
Tipos de nuvens
2.1.1.1
Nuvem pblica
28
ambientes virtualizados a qualquer momento. Sendo assim, para uma empresa que
acaba de nascer, no necessrio adquirir equipamentos e servidores para iniciar sua
operao. Tendo um provedor de servio que possibilite um SaaS ou IaaS (Opex),
pode-se obter um ambiente pronto para executar aps alguns minutos. Por outro lado,
se a empresa recente e precisa comprar um servidor, faz-se necessrio investir na
aquisio (Capex) de um equipamento robusto e com capacidade para suportar a
demanda dos usurios. Alm disso, necessita-se da aquisio de licena de programas
para a operacionalizao do produto no ambiente de produo. Muitas vezes, essa
licena pode ser utilizada por um usurio desse sistema ou por outra modalidade que
faa o produto ficar caro e o investimento inicial, maior. Para finalizar os aspectos
negativos do Capex, h um prazo de entrega dos equipamentos, softwares e da
infraestrutura que adiar o funcionamento completo da nova empresa.
2.1.1.2
Nuvem privada
os
equipamentos
disponveis
na
infraestrutura
permite
que
esse
2.1.1.3
Nuvem hbrida
2.1.2
2.1.2.1
Disponibilidade de um servio
2.1.2.2
Dados em lock-in
2.1.2.3
Confidencialidade e auditabilidade
Esse desafio talvez seja o mais complexo e custoso para ser tratado em uma nuvem
31
2.1.2.4
As aplicaes corporativas tendem a ter grandes massas de dados que podem, chegar
a nveis bastante elevados. Para que o aplicativo seja transferido para a infraestrutura
do provedor de nuvem pblica, pode haver um gargalo de envio das informaes
(dados) necessrias para o funcionamento deste aplicativo. Estes dados podem levar
algumas horas para serem carregados na infraestrutura do provedor. Esse um
obstculo e as corporaes precisam lidar com esse limitao tcnica. Existem algumas
propostas para resolver esse problema (ARMBRUST, 2009), mas elas ainda no saram
do plano terico.
2.1.2.5
Imprevisibilidade no desempenho
pode
ocorrer
overhead
na
utilizao
de
um
desses
recursos,
e,
2.1.2.6
Armazenamento escalvel
32
(storage), este um assunto que precisa ser explorado pelos provedores da nuvem
para que nenhuma das requisies falhe ou faltem recursos para o armazenamento que
o cliente da nuvem estiver solicitando. Caso uma demanda por mais espao no seja
atendida, provavelmente a empresa cliente migrar o aplicativo para outro provedor
com estabilidade. No caso de demanda por aumento de espao em disco o que
acontece com grande frequncia , o provedor precisar de mecanismos para escalar o
storage, o que muitas vezes no uma tarefa trivial. O grande desafio definir e
implementar polticas de fornecimento de recursos de armazenamento de dados para
os clientes da nuvem. Essa dificuldade permanece como um tpico em aberto em todos
os provedores de servio, porque atualmente eles alocam e desalocam os espaos de
acordo com a demanda solicitada pelos clientes.
2.1.2.7
2.1.2.8
Escalonando rapidamente
2.1.2.9
Lista de reputao
Um dos artigos estudados (ARMBRUST, 2009) trata esse tema como Reputation Fate
Sharing (compartilhamento de reputao), nada mais do que uma lista de reputao por
cliente. Uma vez que a nuvem tem o propsito de alocar uma MV na infraestrutura do
provedor, pode-se utilizar essa MV para assuntos ilegais, invases, spamming, entre
outros comportamentos inadequados. Para evitar esse tipo de problema, o provedor
precisa de mecanismos para evitar que aplicativos dessa natureza possam afetar seu
ambiente como um todo, alm de meios de identificao e isolamento da comunicao,
para evitar que os IPs desse provedor entrem em blacklists (lista de IPs que tem o
intuito de bloquear acessos suspeitos de IPs utilizados para invaso ou ato ilcito na
internet). Outra forma de resguardar a integridade do provedor consiste em criar
documentos de transferncia de responsabilidade, nos quais o usurio responder por
qualquer processo por prticas ilcitas, que no condizem com a poltica de segurana
do provedor de servio.
2.1.2.10
Licena de software
Com relao s licenas de softwares, ainda h o que ser explorado pelas empresas de
desenvolvimento de programas, uma vez que h compatibilidade do mtodo pay-asyou-go com o modelo de negcios de vendas por quartil, que o modelo de negcios
empresariais norte americano. Portanto, as empresas teriam de readequar o modelo de
34
2.2 VIRTUALIZAO
A virtualizao uma tecnologia que foi aplicada em diversos programas
computacionais nos quais se objetivava simular o comportamento de uma mquina ou
programa por meio de uma mquina real. Apesar dessa mquina ou programa virtual
no se encontrar implementada diretamente na mquina real, isso no significava que
ela estivesse inacessvel. Muitas vezes, para o usurio era transparente a utilizao
desse ambiente virtual, pois ele aparentava estar disponvel mesmo sem existir
fisicamente (LAUREANO, 2006). Mas, por intermdio desta virtualizao, pode-se criar
aplicativos que executam instrues especificas de uma linguagem de programao ou
plataforma em diferentes sistemas operacionais (SO) de uma mquina real; por
exemplo: Java Virtual Machine (ORLANDO, 2006). Alm desta soluo, pode-se
virtualizar sistemas operacionais, transformando-os em processos do sistema
operacional gerenciado por meio de um monitor (VMM) ou hypervisor. Esta abstrao
das mquinas virtuais permite que diferentes SOs possam ser criados sobre uma
mesma mquina fsica, virtualizando os recursos computacionais e dividindo-os entre
cada MV.
2.2.1
35
2.2.1.1
MMV - tipo I
2.2.1.2
MMV - tipo II
impossibilitando
otimizaes.
Obrigatoriamente
as
comunicaes
2.2.1.3
MMV - Hbrido
37
38
2.2.2
Esta seo apresenta trs aplicaes de monitores de mquinas virtuais difundidos nos
ambientes corporativos e acadmicos. O objetivo desta apresentao dos MMVs
caracterizar cada aplicao dentro dos conceitos e tipos de MMVs vistos na seo
anterior (seo 2.2.1) e introduzir o Xen como parte do experimento aplicado nesta
dissertao.
2.2.2.1
Xen
drivers, kernel, API etc. Essa estrutura pode ter trocas de contextos e traps, o que
aumenta a complexidade e pode diminuir o desempenho por conta do overhead dessa
tarefa.
Por outro lado, a paravirtualization utiliza um kernel modificado para fazer
comunicao com o hypervisor no intuito de interagir diretamente com o hardware, no
havendo interveno do kernel do sistema operacional da mquina hospedeira. Desse
modo, uma imagem em paravirtualization tem um desempenho elevado por conta de
no ter um intermedirio interpretando e enviando mensagens para o sistema
operacional real. Alm disso, ter um kernel paravirtualization modificado faz com que
uma imagem paravirtualizada seja independente do sistema operacional da mquina
hospedeira.
rede. Usar MVs na mesma mquina hospedeira faz com que a comunicao entre as
MVs tenha um desempenho maior. Se forem executadas em mquinas diferentes,
ocorrer comunicao com a rede fsica e, portanto, haver atraso no processamento
de uma MV com outra.
2.2.2.2
VMware
2.2.2.3
O KVM um MMV nativo do sistema operacional Linux que suporta as arquiteturas x86.
Conforme a Figura 11, o KVM apresentado como MMV do tipo I, sendo que criado
um device driver (/dev/kvm) no qual, para cada MV, gerado um processo no sistema
operacional hospedeiro e alocados os recursos de memria e disco. Contudo, o
escalonamento de CPU permanece gerenciado pelo SO da mquina real. As operaes
do /dev/kvm incluem: criao de uma nova mquina virtual, alocao de memria
para a MV, leitura e gravao virtual dos registradores de CPU, interrupo da CPU
virtual e execuo do processamento na CPU virtual.
42
2.2.3
43
Descrio
Escalonador
rgido)
para
executar
MV.
Caso
no
haja
Contextualizador
gerenciador
servio
da
MV,
podendo,
assim,
padronizar
as
Tolerncia a falhas
que, aps analise individual, no obteve base suficiente para levar a alguma concluso.
Porm, preciso haver um cuidado a mais para que no haja concluses indevidas,
pois as mtricas precisam ser complementares e terem um significado coerente.
Informaes desconexas e no conclusivas devem ser avaliadas separadamente para
no afetar o resultado da anlise.
Aps as mtricas serem definidas, preciso configurar os parmetros dos limites
para que as medidas possam ser caracterizadas e classificadas. Posteriormente, a
totalizao dessas medidas pode indicar se uma dada informao oriunda dessas
mtricas foi satisfatria ou no. Estes limites devem ser criteriosos para alcanar uma
base analtica justificvel.
Por fim, preciso fazer a coleta das informaes das mtricas no ambiente real
ou simulado. Os aplicativos que possuem infraestrutura e meios para executar em
ambientes reais podem ser instalados e executados diretamente em um computador ou
MV. Caso a aplicao tenha caractersticas especficas e houver inviabilidade para
execuo em uma mquina real ou sistema operacional suportados, buscam-se
alternativas em ambientes de simulao. Para essa situao, criado um ambiente
compatvel com os requisitos da aplicao, reproduzindo os resultados com base nesta
simulao. Muitas vezes, os resultados podem comportar diferenas significativas se
aplicados no ambiente real, por haver variveis que no foram consideradas na
definio do experimento simulado. Como resultado, possvel utilizar dados
quantitativos coletados e gerar grficos, tabelas e relatrios.
A Figura 12 (JAIN, 1991), apresentada uma proposta com as trs
possibilidades de resposta de uma requisio de servio. Sendo que o servio pode ser
processado corretamente (esperado), incorretamente ou recusado (inesperado). A
requisio que finalizar o processamento corretamente categorizada como mtricas
de velocidades (response time), vazo (throughput) e alocao de um recurso
(utilization).
46
operations
per
second
(MFLOPS).
Para
redes
de
Outra forma de mtrica (2) calcular o tempo mean time to Fail (MTTF), um valor
mdio calculado com base no tempo de vida de um hardware. Conforme o equipamento
48
vai envelhecendo, o valor de MTTF diminui. Um MTTF de 50 horas significa que a cada
50 horas esperado uma falha no componente. Outra forma de avaliar por meio da
mtrica mean time to repair (MTTR), segundo a qual, na ocorrncia da falha, preciso
haver um tempo para a resoluo do problema. Portanto, o tempo em que houve a
falha e a recuperao a medida do mean time between error (MTBE).
MTBE= MTTF MTTR (AGARWAL, 2008)
Uma vez calculado o MTFB, pode-se aplicar a frmula abaixo para descobrir a
disponibilidade do ambiente em que foram submetidas as mtricas de disponibilidade.
Esse percentual refere-se ao tempo em que o sistema ou ambiente esteve em operao
por um determinado perodo. Essa mtrica importante para determinar se um
ambiente esta estvel ou instvel, alm de apresentar dados para os clientes deste
sistema.
Avaliability=
MTTF
100 (AGARWAL, 2008)
MTBF
49
50
3.
METODOLOGIA DE CARACTERIZAO DE
APLICAES
Uma metodologia tem o objetivo de conceituar e estudar diferentes mtodos para o
processamento um determinado processo de uma aplicao. Para ser vivel a
aplicao de uma metodologia, preciso ter regras e processos. A metodologia tem um
papel importante na definio e conceituao do experimento, ou avaliao, pois
permite criar as regras de cada situao que identifica os limites, as variveis
comparativas, e at concluir se o mtodo adequados ou no. A seguir, sero
apresentados os componentes da metodologia proposta para caracterizar aplicaes
em ambiente de computao em nuvens.
3.1.1
3.1.2
Aplicativo iostat
Descrio
Mostra o percentual de utilizao de CPU que ocorreu durante a
execuo da aplicao no nvel de usurio.
%nice
%system
%iowait
%idle
Descrio
Device
tps
dispositivo.
Mltiplas
requisies
lgicas
podem
ser
Blk_wrtn
rrqm/s
wrqm/s
r/s
w/s
rsec/s
wsec/s
avgrq-sz
avgqu-sz
await
r_await
w_await
%util
Descrio
-c
-d
-h
-k
-N
-n
-x
3.1.3
O aplicativo pmap monitora o consumo de memria por processo. Com esse recurso,
possvel fazer a leitura do consumo/utilizao da memria por um determinado
processo e seus respectivos subprocessos. O pmap basicamente coleta informaes do
/proc (/proc/pid/maps e /proc/pid/smaps), separando as mtricas: endereo
inicial do processo, tamanho, RSS (tamanho do mapeamento da memria fsica,
incluindo a memria compartilhada resident set size), PSS (tamanho dos processos
utilizados na memria compartilhada proportional set size), total de pginas dirty, as
permisses do processo e o nome do processo em si.
56
SIZE
380K
4K
4K
340K
1340K
2048K
16K
4K
20K
340K
2044K
4K
4K
120K
288K
16K
4K
4K
1168K
4K
4K
8156K
RSS
260K
4K
4K
200K
372K
0K
16K
4K
16K
84K
0K
4K
4K
100K
144K
16K
4K
4K
900K
4K
0K
2140K
PSS
260K
4K
4K
200K
10K
0K
16K
4K
16K
38K
0K
4K
4K
1K
144K
16K
4K
4K
900K
0K
0K
1629K
DIRTY
0K
4K
4K
200K
0K
0K
16K
4K
16K
0K
0K
4K
4K
0K
144K
16K
4K
4K
900K
0K
0K
1320K
SWAP
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
0K
PERM
r-xp
r--p
rw-p
rw-p
r-xp
---p
r--p
rw-p
rw-p
r-xp
---p
r--p
rw-p
r-xp
rw-p
rw-p
r--p
rw-p
rw-p
r-xp
r-xp
MAPPING
/usr/local/bin/lame
/usr/local/bin/lame
/usr/local/bin/lame
[heap]
/lib64/libc-2.9.so
/lib64/libc-2.9.so
/lib64/libc-2.9.so
/lib64/libc-2.9.so
[anon]
/lib64/libm-2.9.so
/lib64/libm-2.9.so
/lib64/libm-2.9.so
/lib64/libm-2.9.so
/lib64/ld-2.9.so
[anon]
[anon]
/lib64/ld-2.9.so
/lib64/ld-2.9.so
[stack]
[vdso]
[vsyscall]
57
Descrio
-d, --device
-q, --quiet
-h, --help
3.2.1
Aplicaes distribudas
58
possvel
desenvolver
diferentes
algoritmos
para
analisar
executar
cenrios
de
avaliaes
em
supercomputadores,
clusters
ou
(com o suporte ao MPI). Nessa verso, havia oito benchmarks possveis para executar
e coletar informaes de aplicaes distribudas: embarrassingly parallel (EP), multigrid
calculation (MG), conjugate gradient (CG), fourier transform (FT), integer sort (IS), lower
and upper (LU), scalar and pentadiagonal (SP) e block tridiagonal (BT). A Tabela 8
apresenta as descries de cada benchmark e suas caractersticas.
Tabela 8: NPB benchmarks (EL-GHAZAWI, 2002)
Benchmark
BT
Descrio
Block tridiagonal benchmark uma aplicao de simulao CFD que
usa um algoritmo implcito para resolver em 3D equaes de Navier
Stokes. A soluo de diferenas finitas para o problema baseada
em uma ADI (Alternating Direction Implicit), que fatora a aproximao
de blocos 5x5, que, por sua vez, so resolvidos sequencialmente ao
longo de cada dimenso.
SP
LU
EP
CG
FT
IS
3.2.1.2
Aplicaes transacionais
As aplicaes transacionais, por sua vez, utilizam bancos de dados relacionais para
publicar e executar consultas em um sistema gerenciador de banco de dados (SGBD).
Todos os recursos disponveis em um SGBD relacional devem ser avaliados e
considerados na definio dos cenrios a serem executados e analisados. Recursos
como transaes tm como objetivo manter a integridade dos dados, gravando os
registros nas tabelas somente no caso de sucesso da incluso nas tabelas principais e
auxiliares. Com isso, as informaes ficam todas relacionadas por meio de chaves
estrangeiras ou relacionamentos (join) nas consultas da linguagem SQL. As aplicaes
transacionais tm uma utilizao intensa de HD, tanto para leitura como para gravao,
porque ao inserir um registro no banco de dados, ocorre um processamento de
61
insero de registro por meio da linguagem SQL, que, de uma estrutura lgica, faz o
depsito em dispositivos de armazenamento de dados: storage, HD, SSD, entre outros.
Cada dispositivo possui uma caracterstica peculiar para o tratamento de leitura ou
leitura e gravao. Para todos os perifricos, pode-se utilizar diferentes tipos de
sistemas de arquivos, com alguma otimizao na gravao do registro.
Para avaliar aplicaes transacionais, foi utilizado o TPC-H, que permite coletar e
analisar desempenho. A TPC uma organizao sem fins lucrativos criada para definir
benchmarks de processamentos de transaes em bancos de dados transacionais cujo
intuito consiste em divulgar dados de desempenho obtidos, providenciar um
comparativo entre outros concorrentes e ter um parmetro. Na metodologia TPC-H,
possvel fazer o download do aplicativo DBGEN, sendo permitido, portanto, utiliz-lo
para gerar o banco de dados e a quantidade de registros para a execuo das
consultas criadas pelo QGEN. A princpio, o DBGEN gera um arquivo de texto com a
quantidade de registros necessria para o tamanho do banco de dados solicitado na
execuo do DBGEN, cujo parmetro o prprio tamanho do banco de dados.
A Tabela 9 apresenta os principais parmetros do comando dbgen depois de
compilado:
Tabela 9: Principais parmetros do dbgen
Parmetros
Descrio
do dbgen
-h
-f
-F
-D
-s
-T
p part e partsupp
c customer
s supplier
o orders/lineitem
n nation
r region
l code ( o mesmo que n e r)
O orders
L lineitem
P part
S partsupp
3.2.2
10).
Outra
anlise
experimentada
foi
utilizar
configurao
63
Nome do
Descrio
cenrio
Configurao
1 proc 4 MV
2 MVs em cada n
1 proc 3 MV
2 MV no n principal e 1
MV no n secundrio
1 MV em cada n
1 MV no n principal
1 MV no n principal
1 MV no n principal
cada nmero de processo (4, 8, 16 e 32), bem como passou-se o arquivo compilado do
NPB IS de acordo com a quantidade de processos do MPI. Aps o trmino da execuo
do script bash do primeiro cenrio, foi reconfigurado (reiniciada a MV, para garantir que
a memria fosse limpa e desligada, caso no fosse parte do cenrio) o ambiente para o
segundo cenrio, deixando ligadas apenas as MVs que fariam parte do ambiente, e
reexecutado o script com as mesmas quantidades de processos com vinte iteraes
cada. Sucessivamente, executou-se cada cenrio da Tabela 10.
J no experimento transacional, o objetivo foi avaliar a influncia de uma
aplicao com alta utilizao de disco rgido (HD) no tratamento de leitura de disco por
intermdio do benchmark TPC-H e SGBD IBM DB2. Primeiramente, compilou-se o
TPC-H (dbgen) para a gerao de dados, utilizando-se as opes: dbgen -s 2 -f. O
comando aplicou a escala de 2, efetuando a reescrita, caso o arquivo de sada j
existisse. Portanto, foram gerados ~2 Gb (~7 milhes de registros) de dados
distribudos nas 8 tabelas do TPC-H. O valor de escala 2 foi um nmero aleatrio (o
dobro do valor padro do comando), e como os resultados de desempenho foram
satisfatrios, no foi necessrio fazer o incremento dos nmeros de registros. Com os
dados gerados e importados para o banco de dados relacional DB2, chamado de
TPCH2, iniciaram-se os experimentos desse teste:
Tabela 12: Cenrios do TPC-H
Cenrio
Nome do cenrio
Local
Ext3
Hardware
Software
Principal
operacional
Opensuse
11.1
64
bits
Memria
4 Gb
Kernel
2.6.27.56
-0.1-xen
Disco
1 Tb
Rede
Xen
3.3
interface
Full-duplex
100
(rede
MbE
do
laboratrio LAHPC)
Secundrio Processador AMD Phenon 9650 quad- Sistema
core 2.3 GHz
operacional
Opensuse
11.1
64
bits
Memria
4 Gb
Kernel
2.6.27.56
-0.1-xen
Disco
1 Tb
Rede
Xen
3.3
interface
100
MbE
67
Full-duplex
(rede
do
laboratrio LAHPC)
MVs
Sistema
Opensuse
operacional
11.1
64
bits
Memria
[Depende do cenrio]
2.6.27.56
Kernel
-0.1-xen
Disco
60 Gb
2.12.0
Rede
TPC-H
3.3
DB2 9.7
Express-C
3.2.4
PBZIP2
1.1.3
LAME
3.98.4
Systat
8.1.5
Pmap
3.2.7
Tipos de aplicaes
3.2.4.1
CPU bound
3.2.4.2
Com relao a aplicativos com utilizao de disco elevada, o I/O uma forma de
analisar o quanto de workload est sendo requisitado para ler ou gravar dados. Essa
mtrica de I/O pode indicar uma srie de estatsticas de trfego de dados, espera
(delay), quantidade de blocos processados, consumo de CPU, etc. Alm disso,
possvel separar as mtricas de I/O de leitura e gravao; elas possibilitam uma anlise
detalhada independentemente. O principal motivo de se analisar separadamente que
alguns perifricos possuem um tratamento mais eficiente para situaes de leitura de
dados (Solid State Drive SSD).
Portanto, para aplicaes com consumo elevado de leitura em disco, e para as
quais h pouca ou moderada gravao, pode-se indicar a utilizao de dispositivos
SSDs ou perifricos locais na MV. Se a aplicao possuir consumo mediano de leitura e
gravao no dispositivo, recomenda-se utilizar um Network File System (NFS) ou
qualquer outro tipo de sistema de arquivo que utilize a rede para sincronizar dados com
o equipamento hospedeiro (dom0), pois o Xen possui a otimizao que sincroniza os
dados por intermdio da memria compartilhada do dom0. Todavia, no caso de baixa
leitura e baixa gravao, pode-se utilizar o NFS com outras mquinas fsicas, pois a
necessidade de desempenho baixa, o que possibilita o uso de mecanismos de NFS.
69
3.2.4.3
I/O de rede
Aplicativos que possuem uma intensa utilizao de rede necessitam de banda de rede
para enviar e receber uma quantidade de dados elevada. Para os aplicativos que esto
nessas taxonomias, pode-se utilizar uma tecnologia de 10 Giga bit Ethernet (GbE),
padro IEEE 802.3ab, para transmitir dados entre os ns do cluster. Essa tecnologia de
10 GbE inicialmente foi desenvolvida em cabos de fibra tica, porm h informaes de
que cabos de cobre e equipamentos de rede suportam 10 GbE com algumas limitaes,
o que no ocorre com a fibra tica. Contudo, o custo de implementao ainda um
obstculo, pelos altos preos dos equipamentos de redes e cabeamentos para a
tecnologia de fibra tica.
Com relao aos programas que utilizam a rede moderadamente, pode-se
configurar uma rede de 1 GbE, praticamente um padro de mercado, pois a maioria dos
equipamentos de rede suporta essa tecnologia. Alm disso, pelo fato de a utilizao ser
mediana, pode-se utilizar a otimizao do Xen para transmitir uma informao pela rede
das MVs por meio do dom0 (memria compartilhada). No entanto, quando a
comunicao externa MV, o dom0 no utiliza esses algoritmos de otimizao;
efetivamente, usam-se as camadas TCP/IP.
Para aplicaes com baixa utilizao de rede pode-se utilizar a comunicao
70
tradicional, sem qualquer otimizao. Uma rede de 100 MbE o suficiente para
suportar a demanda das solicitaes de envio e recebimento de informaes de um n
para outro.
3.2.5
Para a fase inicial do estudo, foram coletadas informaes dos cenrios de CPU
BOUND e I/O de disco, com os cenrios de aplicaes paralelas Tabela 10
Nesta subseo, sero analisados os resultados de uma MV com mais de uma vcpu
atribuda
para
processamento
da
aplicao
MPI.
Esta
abordagem
de
71
2 proc 1 VM
Cenrio 5
3 proc 1 VM
Cenrio 6
4 proc 1 VM
4
Avg
Std Dev
Avg
Std Dev
16
32
26,6
0,11 0,11
0,37
0,1
0,2
0,91 0,36
Avg
18,9
Std Dev
0,45
3.2.5.2
distribudo
Esta anlise, por sua vez, tem a inteno de avaliar o comportamento da aplicao MPI
por meio de aplicaes distribudas, ou seja, a aplicao MPI foi implementada em
duas, trs e quatro MVs na mesma mquina hospedeira. Com isso, o mtodo de
comunicao entre as MVs se deu por intermdio da memria compartilhada, pois o
Xen possui um mtodo de otimizao que utiliza o dom0 (CHERKASOVA, 2005) para
encapsular a rede na memria compartilhada do dom0, obtendo uma comunicao
mais eficiente.
Tabela 17: Resultados de CPU bound abordagem de aplicao distribuda (unidade
em segundos)
Nmero de processos
Cenrio 1 1 proc 4 VM
Cenrio 2 1 proc 3 VM
Cenrio 3 2 proc 2 VM
16
32
Avg
32,2
Std Dev
2,05
Avg
40,3
46,7
Std Dev
4,66
Avg
14,5
Std Dev
0,51
52
82,1
3.2.5.3
0
1,2
17
140,00
s
e
c
o
n
d
s
120,00
100,00
80,00
,63
90
60,00
40,00
20,00
0,00
47
6,
C HD
25
8,
C NFS G
4
,6
32
C NFS T
,90
63
TS HD
TS NFS
G
TS NFS T
experimento, foi executado em cada cenrio, conforme a Tabela 18, vinte iteraes para
cada consulta (table scan e complexa). Com isso, pode-se avaliar o comportamento de
cada consulta (leitura) em execuo nos FS local, NFS com o dom0 e NFS remoto.
Tabela 18: Aplicaes transacionais FS utilizados
Legenda
Descrio
C HD
C NFS G
C NFS T
TS HD
75
3.2.5.4
vcpus
Esta subseo tem o objetivo de apresentar um comparativo entre os cenrios que
possuem a mesma quantidade de processadores alocados, independentemente da
forma como foram implementados. Pode-se analisar os resultados de cada cenrio
contendo 3 e 4 vcpus atribuda nas MVs. Com isso, caractersticas sobre
processamento paralelo e distribudo podem fornecer informaes relevantes sobre a
adoo da configurao em uma MV.
Tabela 19: Comparao dos cenrios com 4 vcpus (unidade em segundos)
Nmero de processos
Cenrio 1
1 proc 4 VM
Cenrio 3
2 proc 2 VM
Cenrio 6
4 proc 1 VM
4
Avg
16
32
75.7
2.27
Avg
29.9
0.72
Avg
18.9
0.45
1 proc 3 VM
Cenrio 5
3 proc 1 VM
4
Avg
40.3 46.7
16
32
52
82.1
0.2
0.91
5.27
21.2
0.36
3.2.6
aplicaes com uso da lgica Fuzzy. A partir desses recursos, pode-se coletar mtricas
de I/O, tempo e workload para identificar caractersticas ou particularidades de um
programa ou aplicativo. As subsees a seguir apresentam o conceito de classificao
Fuzzy e a definio de trs tipos de aplicaes.
78
3.4.1
Etapas da metodologia
3.4.1.1
Primeira etapa
3.4.1.2
Segunda etapa
etapa. Sendo assim, para esta dissertao foi definido avaliaes de recursos
computacionais de CPU, memria, HD leitura e HD gravao. Para cada grupo, foi
dividido em trs categorias: utilizao intensa (+), mdia e baixa (-). Uma vez
categorizado, pode-se inserir as leituras no banco de dados que contm as
instrumentaes anteriores para enfim dividir entre todas as leituras, nos trs grupos
sugeridos nesta dissertao. Para este processo de diviso, utilizou-se a metodologia
Crisp (Fuzzy) para dividir todos os registros de cada recurso computacional em trs
grupos conforme descritos na Tabela 21. Quanto maior a quantidade de registros
instrumentados, melhor vai ser o mtodo classificatrio para indicar a configurao ideal
para o processamento desta aplicao. Para esta etapa, foi desenvolvido um script
(APNDICE A) e executado em todos os programas instrumentados e avaliados nesta
dissertao, para que os bancos de dados pudessem ter histrico para as distribuies
dos trs tipos de aplicaes (taxonomias). Por meio das tabelas instrumentacao e
metrica, possvel obter informaes referentes aos valores de CPU, memria, HDR
e HDW. Nesta dissertao, no sero apresentadas mtricas de rede, pelo fato de as
mtricas de CPU, memria e HD serem suficientes para justificar a metodologia de
caracterizao de aplicaes.
Aps completar a transao no banco de dados, pode-se executar a view
(APNDICE D) vw_metrica pelo comando SQL (select * from vw_metrica)
para apresentar o resultado atual das medidas, indicando qual taxonomia adequada
para cada registro da tabela instrumentao, relacionada com metrica. Os campos
que sero apresentados na consulta sero: avgmetrica (mdia do valor da mtrica),
desviopad (desvio padro dos valores da mtrica), dscmetrica (descries da
mtrica), codexecucao (cdigo da execuo da aplicao, atribudo na primeira etapa)
e grupo (execuo da funo F_CATEG_FUZZY, (APNDICE C) que comporta a
categoria em que o valor da mtrica se encontra.
80
Descrio
CPU+
Utilizao alta
de CPU
Multiprocessador Processamento
Distribudo com
multiprocessador
iostat %user
CPU
Utilizao
mdia de CPU
Multiprocessador Processamento
Distribudo
iostat %user
CPU-
Utilizao
baixa de CPU
Processamento
Distribudo
Memria local
Memria local
Configurao
ideal
Configurao
recomendada
Mtrica
MEM
Utilizao
mdia de
memria
Memria local
Memria
distribuda
MEM-
Utilizao
baixa de
memria
Memria
distribuda
Memria
distribuda
Local
SSD
iostat r/s
HDR
Utilizao
mdia de
leitura a HD
NFS com o
DOM0
NFS com o
DOM0
iostat r/s
HDR-
Utilizao
NFS remoto
baixa de leitura
a HD
NFS remoto
iostat r/s
Local
Local
iostat w/s
Utilizao
mdia de
gravao em
HD
NFS com o
DOM0
NFS com o
DOM0
iostat w/s
HDW-
Utilizao
baixa de
gravao em
HD
NFS remoto
NFS remoto
iostat w/s
%user /n
writable-private readonly-private /n
r/s /n
w/s /n
81
do registro previamente. Porm, essa informao ser apenas para utilizao futura,
pois o usurio dessa metodologia possivelmente precisar saber os dados do
equipamento de instrumentao que foi executado, incluindo configurao e
especificao do sistema operacional.
3.4.1.3
Terceira etapa
82
84
banda de rede. Contudo, com o LB no nvel do IaaS, esta uma abordagem que
possibilitou escalar os recursos de modo interessante, mas que ainda requer alguns
estudos para se tornar uma soluo de escalabilidade eficiente em ambiente de nuvem
de infraestrutura.
Outras pesquisas (TICKOO, 2010) apresentam uma anlise sobre os desafios na
modelagem de desempenho de mquinas virtuais em um data center. Basicamente,
nas estruturas de servidores multiprocessadores e na ferramenta de benchmark de VM
vConsolidate, identificaram-se trs problemas: modelagem da conteno dos
dispositivos visveis (CPU, capacidade de memria, dispositivos de I/O etc.), de
recursos invisveis (recursos de microarquitetura compartilhada, cache compartilhado,
memria compartilhada etc.), e o overhead do VMM (ou hypervisor). Os autores
chegam a concluses relevantes, segundo as quais modelar as interferncias, os
recursos visveis e invisveis pode influenciar significativamente no desempenho da MV.
85
4.
APLICAO PBZIP2
O pbzip2 (PBZIP, 2011) uma implementao do bzip2, mas para
Descrio
-b#
-c ou --stdout
-d
--decompress
-f ou --force
-h ou --help
-k ou --keep
-l
--loadavg
-m#
-p#
-q ou --quiet
-r ou --read
-S#
-v
para o stdout.
--verbose
-V
--version
pbzip2.
ou Compacta o arquivo (o padro do pbzip2 compactar caso
-z
--compress
-1
ou
--best
--ignore-
trailing-
garbage=#
APLICAO LAME
89
Descrio
-b #
-h
-f
-V #
--preset
type
--preset
help
--
longhelp
--license Apresenta informaes sobre a licena.
A seguir, um exemplo de sada (stdout) do lame, sendo que foi convertido um
arquivo wav para mp3 usando apenas a opo: lame -h.
Tabela 25: Exemplo de sada (stdout) do lame
LAME 3.98.4 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding /personal/local/music/Adagio_molto_e_cantabile.wav
to /personal/local/music/Adagio_molto_e_cantabile.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
Frame
| CPU time/estim | REAL time/estim | play/CPU | ETA
39273/39273 (100%)| 1:41/ 1:41| 1:41/ 1:41| 10.117x| 0:00
------------------------------------------------------------------------------kbps
LR MS % long switch short %
128.0
13.3 86.7
100.0 0.0 0.0
Writing LAME Tag...done
ReplayGain: +7.3dB
90
Quantidade de memria
1024 Mb
1024 Mb
1024 Mb
1024 Mb
512 Mb
512 Mb
512 Mb
512 Mb
91
Na Tabela 26, cada cenrio foi implementado por intermdio de um script bash
que executou, na ordem da tabela, duas iteraes em um lao de repetio ( for),
modificando os parmetros -p e -m para variar o valor de threads e memria,
respectivamente. Esse algoritmo foi executado quatro vezes em cada cenrio,
coletando oito amostras para anlise. Pelo fato de os cenrios no terem tido diferena
significativa, no houve necessidade de coletar outras amostras. Com oito execues
de 20 iteraes cada, o planejado foi o suficiente para obter dados do comportamento
da aplicao pbzip2
abordagem local (na prpria MV), depois o cenrio com o dom0 (NFS dom0) e,
finalmente, NFS com uma mquina remota (NFS remoto).
Com relao ao programa de converso lame, este foi processado de modo
diferente em relao ao experimento anterior; principalmente pelo fato de no possuir
suporte a multiprocessador, a MV foi reconfigurada para single core. Alm disso, o
comando no possua opo de modificao de memria mxima alocada para a
aplicao, o que dificulta a utilizao de um script bash para processar todos os
cenrios de uma vez. Portanto, conforme a Tabela 27, foram definidos os seguintes
cenrios para o lame:
Tabela 27: Cenrios do experimento da aplicao lame
Cenrio
Quantidade de memria
Local
512 Mb
1024 Mb
NFS dom0
512 Mb
1024 Mb
NFS remoto
512 Mb
1024 Mb
Para a converso dos arquivos de wav para mp3, foi escolhida a 9 sinfonia do
compositor Ludwig van Beethoven, com quatro msicas no lbum em formato wav. A
primeira msica Allegro ma non troppo, un poco maestoso (175 Mb), a segunda
92
Adagio molto e cantabile (173 Mb), a terceira Molto vivace (145 Mb), e a ltima,
Presto (242 Mb).
Primeiramente, foi executado um script bash que implementou dez iteraes de
cada cenrio, alternando as execues entre local, dom0 e remoto com a configurao
de 1024 Mb de memria na MV. Pelo fato de a converso dos arquivos ser rpida,
possvel experimentar mais iteraes para identificar desvios que possam caracterizar
algum possvel problema que precisaria de anlise. Posteriormente, a MV foi desligada
e a alocao de memria reconfigurada para 512 Mb. Sendo assim, o experimento foi
reiniciado com a nova quantidade de memria. Ao se variar a memria, objetivou-se
verificar se ela influencia na execuo da aplicao.
93
2.500,00
2.000,00
1.500,00
1.000,00
500,00
p1
_lo
ca
l
p1
_d
om
0
p1
_r
em
ot
o
p2
_lo
ca
l
p2
_d
om
0
p2
_r
em
ot
o
p3
_lo
ca
l
p3
_d
om
0
p3
_r
em
ot
o
p4
_lo
ca
l
p4
_d
om
0
p4
_r
em
ot
o
0,00
512_mem
1024_mem
O comando iostat fornece duas medidas que podem justificar o motivo do atraso para
o processamento, tanto para a abordagem local quanto para o NFS com dom0: o I/O
efetivo do FS e o I/O wait, que a aplicao necessitou efetuar, incluindo as interrupes
ou gargalos no processamento no dom0 ou no prprio FS.
DOM0
20,00
18,00
16,00
14,00
iowait
12,00
10,00
8,00
6,00
4,00
2,00
0,00
local_dom0
P1_512
P3_512
nfs_dom0_dom0
P1_1024
P3_1024
P2_512
P4_512
nfs_remoto_dom0
P2_1024
P4_1024
95
HD write - PBZIP2
3.000,00
2.500,00
blocks / sec
2.000,00
1.500,00
1.000,00
500,00
0,00
P1_512
P2_512
P3_512
hdw_local
P4_512
hdw_nfs_dom0
P1_1024
P2_1024
P3_1024
P4_1024
hdw_nfs_remoto
96
HD read - PBZIP2
3.500,00
3.000,00
blocks / sec
2.500,00
2.000,00
1.500,00
1.000,00
500,00
0,00
P1_512
P2_512
P3_512
hdr_local
P4_512
hdr_nfs_dom0
P1_1024
P2_1024
P3_1024
P4_1024
hdr_nfs_remoto
4.4.2
Resultados do lame
97
140
130
120
seconds
110
100
90
80
70
Music 2
Music 3
2
o_
ot
0_
nf
s_
re
m
do
nf
s_
nf
Music 1
51
2
51
12
re
s_
ot
m
al
_5
o_
10
0_
m
do
nf
s_
lo
c
24
4
02
al
_1
lo
c
10
24
60
Music 4
98
5.
este precisou processar o algoritmo de compactao, gerou I/O para ler o arquivo de
origem e I/O para gravar efetivamente o arquivo no diretrio NFS com o dom0.
Portanto, o dom0 ficou sobrecarregado. Porm, essa mesma situao no ocorreu na
abordagem de NFS com uma mquina remota, pelo fato de este ter distribudo o I/O de
disco em equipamentos diferentes, portanto, o dom0 no teve gargalo significativo para
atrasar o processamento. Uma MV alocada com abordagem distribuda com o mesmo
dom0, a princpio, aparenta ser uma boa implementao, desde que a aplicao no
exija processamento do dom0. Portanto, este mtodo possibilita definir a melhor
configurao de MVs de acordo com as caractersticas das aplicaes, alm de
identificar gargalos de processamento ou consumo elevado de recurso computacional.
Uma vez coletadas as informaes da instrumentao, pode-se fazer uma abordagem
analtica e encontrar alternativas para implementar um ambiente adequado para a
aplicao, alterando a sada de configurao recomendada para o grupo em que a
aplicao analisada se encontra. Com isso, o mtodo torna-se flexvel e incremental,
possibilitando que o provedor da nuvem controle a alocao dos equipamentos de uma
forma organizada e controlada.
5.1 CONTRIBUIES
A seguir, so expostas as contribuies alcanadas nesta dissertao:
I. Definida a estratgia das medies dos benchmarks e mtricas para
avaliao dos desempenhos das aplicaes.
II. OpenNebula no OpenSuse 64 bits implementado e configurado. Solues
de
bugs
melhorias
na
documentao
do
OpenNebula
foram
Foram
encontradas
situaes
caracterizando
diferentes
5.2 PUBLICAES
Neste Capitulo apresentado as apresentaes e publicaes de artigos alcanados
durante o curso de ps-graduao:
101
102
REFERNCIAS BIBLIOGRFICAS
AGARWAL, B.; Tayal, P.; Gupta, M.; Software Engineering & testing, Jones and
Bartlett Publishers, 2008 , p. 110 112.
ARMBRUST, M. et al. Above the Clouds: A Berkeley View of Cloud computing,
Technical Report No. UCB/EECS-2009-28. University of California at Berkley, 2009.
BAILEY, D.; BARSZCZ, E. The NAS Parallel Benchmarks. NASA TM 103863, Moffett
Field. California: NASA Ames Research Center, 1993.
BARHAM, P.; et. al. Xen and the Art of Virtualization. Proceedings of the 19th ACM
SOSP, 2003, p. 164-177.
BARUCHI, A.; MIDORIKAWA, E. Memory Dispatcher: Uma Contribuio para a
Gerncia de Recursos em Ambientes Virtualizados. 2010. Dissertao (Mestrado) Escola Politcnica, Universidade de So Paulo, So Paulo, 2010.
BOSC. P.; PIVERT O. SQLf: A relational database language for fuzzy querying.
IEEE Trans. on Fuzzy Systems. v. 3, n. 1, p. 1-17, 1995.
CHERKASOVA, L.; GARDNER, R. Measuring CPU overhead for I/O processing in
the Xen virtual machine monitor, Proceedings of USENIX Annual Technical Conf, Apr
2005.
CHERKASOVA, L.; GUPTA, D.; Vahdat, A. Comparison of the Three CPU Schedulers
in Xen, SIGMETRICS Perf. Eval. Rev. v. 35, n. 2, p.42-51, 2007.
DUDA, R.; HART, P. Pattern Classification and Scene Analysis, J. Wiley, 1973.
EL-GHAZAWI, T.; CANTONNET, F. UPC performance and potential: A NPB
experimental study, Supercomputing2002 (SC2002), 2002.
EVERITT, B. Cluster Analysis. New York: Wiley ,1974.
FOSTER, I.; ZHAO, Y.; RAICU I.; LU, S. Cloud computing and grid computing 360103
in
Message-passing
Applications,
Proceedings
of
International
105
106
"CREATE
TABLE
Metrica
(CodMetrica
INTEGER
NOT
NULL
primary
key,
dscMetrica
VARCHAR(20)
NOT
NULL,
"CREATE
TABLE
Execucao
(CodExecucao
INTEGER
NOT
NULL
primary
key,
dscExecucao
VARCHAR(50)
NOT
NULL,
"CREATE
TABLE
Maquina
(CodMaquina
INTEGER
NOT
NULL
primary
key,
Hostname
VARCHAR(30)
NOT
NULL,
IP
107
"Estatisticas"
iostat_exp.out
|awk
$1}'`
#connecting to appl_db db2 database
db2 connect to appl_db
db2
"insert
into
execucao
(dscExecucao,
CodMaquina,
dscExecucao = '$dirname'"`
for mem in `echo $output`
do
db2 "insert into instrumentacao values ($count, $mem, 0,
'$codexec')"
count=$((count+1))
done
108
"insert
into
instrumentacao
values
($count,
((wp+rp)), 1, $codexec)"
wrprivate=1
count=$((count+1))
fi;
done
##### Importing iostat #####
output=`cat iostat_blk.out |egrep "xvda4" |awk '{print $3 " "
$4}'`
count=1
wrprivate=1
for number in `echo $output`
do
if [ $wrprivate = 1 ]; then
db2 "insert into instrumentacao values ($count, $number,
2, $codexec)"
109
wrprivate=$((wrprivate+1))
else
db2 "insert into instrumentacao values ($count, $number,
3, $codexec)"
wrprivate=1
count=$((count+1))
fi;
done
110
PROCEDURE
P_CATEG_FUZZY
(OUT
cat
VARCHAR(4),
IN
(a_maior_max) =
Instrumentacao
OVER(ORDER
BY
(SELECT MIN(NUM_LINHA.avgVlrMetrica)
INNER
AVG(vlrMetrica)
DECIMAL(AVG(vlrMetrica),10,2)
Instrumentacao
WHERE
JOIN
ASC)
(SELECT
AS
AS
CodMetrica
IDNUM,
ROW_NUMBER()
CodExecucao,
avgVlrMetrica
=
codMetr
GROUP
FROM
BY
111
CodExecucao)
AS
NUM_LINHA
ON
NUM_LINHA.CodExecucao
v_qtde_reg_min AND
v_qtde_reg_max);
IF ( v_qtde_real > 1 AND v_qtde_real <=3 ) THEN
SET v_qtde_reg_max = v_qtde_real - 1;
SET v_qtde_reg_min = v_qtde_real - 1;
ELSE
SET v_qtde_reg_max = v_qtde_reg_min - 1;
SET v_qtde_reg_min = v_qtde_reg_max - v_qtde_reg;
END IF;
SET
FROM
(a_medio_max) =
Instrumentacao
OVER(ORDER
BY
(SELECT MIN(NUM_LINHA.avgVlrMetrica)
INNER
AVG(vlrMetrica)
DECIMAL(AVG(vlrMetrica),10,2)
Instrumentacao
CodExecucao)
WHERE
AS
JOIN
ASC)
AS
AS
ON
IDNUM,
ROW_NUMBER()
CodExecucao,
avgVlrMetrica
CodMetrica
NUM_LINHA
(SELECT
codMetr
GROUP
NUM_LINHA.CodExecucao
FROM
BY
=
v_qtde_reg_min AND
v_qtde_reg_max);
IF ( v_qtde_real =
3 ) THEN
SET v_qtde_reg_max = 1;
SET v_qtde_reg_min = 1;
ELSE
SET v_qtde_reg_max = v_qtde_reg_min - 1;
SET v_qtde_reg_min = 1;
END IF;
SET
FROM
(a_menor_max) =
Instrumentacao
(SELECT MIN(NUM_LINHA.avgVlrMetrica)
INNER
JOIN
(SELECT
ROW_NUMBER()
112
OVER(ORDER
BY
AVG(vlrMetrica)
DECIMAL(AVG(vlrMetrica),10,2)
Instrumentacao
CodExecucao)
WHERE
AS
ASC)
AS
CodMetrica
NUM_LINHA
AS
ON
IDNUM,
CodExecucao,
avgVlrMetrica
=
codMetr
GROUP
NUM_LINHA.CodExecucao
FROM
BY
=
v_qtde_reg_min AND
v_qtde_reg_max);
SET (dscMetr) = (SELECT dscTaxonomia FROM Metrica where
codMetrica = codMetr);
IF ( v_qtde_real = 1 ) THEN
IF ( vlrMetrica >= a_maior_max ) THEN
SET cat=dscMetr || '+';
ELSE
SET cat=dscMetr || '-';
END IF;
ELSE
IF ( v_qtde_real >= 2 ) THEN
IF ( vlrMetrica >= a_maior_max ) THEN
SET cat=dscMetr || '+';
ELSE
IF ( vlrMetrica >= a_medio_max AND vlrMetrica <=
a_maior_max ) THEN
SET cat = dscMetr;
ELSE
SET cat=dscMetr || '-';
END IF;
END IF;
END IF;
END IF;
END @
113
114
as
desviopad,m.dscmetrica,
i.codexecucao,F_CATEG_FUZZY(decimal(avg(vlrmetrica),10,2),
m.codmetrica) AS GRUPO from instrumentacao
i inner join metrica m ON i.codmetrica = m.codmetrica
where idInstr > 1 group by m.dscmetrica,
i.codexecucao, m.codmetrica"
115
$NETSTAT
$iostat
$VMSTAT
$pmap
$iostat_BLK
#$1
#$2
#$3
#$4
echo
echo
echo
echo
echo
is
is
is
is
$4
$4
$4
$4
$4
the
the
the
the
"
"
"
"
"
process name
device name
iteration number
data time stamp for
Estatisticas
Estatisticas
Estatisticas
Estatisticas
Estatisticas
de
de
de
de
de
117
$NETSTAT
$iostat
$VMSTAT
$pmap
$iostat_BLK
echo
echo
echo
echo
echo
$4
$4
$4
$4
$4
"
"
"
"
"
Estatisticas
Estatisticas
Estatisticas
Estatisticas
Estatisticas
de
de
de
de
de
118
$NETSTAT
$iostat
$VMSTAT
$pmap
$iostat_BLK
echo
echo
echo
echo
echo
$4
$4
$4
$4
$4
"
"
"
"
"
Estatisticas
Estatisticas
Estatisticas
Estatisticas
Estatisticas
de
de
de
de
de
120
121
122
123
124