T4 Leonardo Menezes

UNIVERSIDADE ESTADUAL DO CEAR
LEONARDO MENEZES DE SOUZA

UMA METODOLOGIA PARA ANLISE DE
DESEMPENHO EM SISTEMAS DE COMPUTAO EM
NUVENS
FORTALEZA - CEAR
2012
UMA METODOLOGIA PARA ANLISE DE DESEMPENHO EM SISTEMAS DE
COMPUTAO EM NUVENS
Dissertao apresentada no Curso de Mestrado
Acadmico emCincia da Computao do Cen-
tro de Cincias e Tecnologia da Universidade
Estadual do Cear, como requisito parcial para
obteno do grau de Mestre em Cincias da
Computao.
rea de Concentrao: Redes de Computado-
res.
Orientador: Prof. Dr. Jorge Luiz de Castro e
Silva
Co-Orientador: Marcial Porto Fernandez
FORTALEZA - CEAR
2012
C824p
Souza, Leonardo Menezes de
Uma metodologia para anlise de desempenho emsistemas de
Computao em Nuvens / Leonardo Menezes de Souza 2012.
77 f. : il. 30cm.
Orientador: Prof. Dr. Jorge Luiz de Castro e Silva
Coorientador: Prof. Dr. Marcial Porto Fernandez
Dissertao (Mestrado) - Universidade Estadual do Cear,
Centro de Cincias e Tecnologia, Curso de Mestrado Acadmico
em Cincia da Computao. rea de Concentrao: Redes de
Computadores. Fortaleza, 2011.
1. Computao em Nuvens 2. Benchmarks 3. Desempenho 4.
DEA 5.
I. Universidade Estadual do Cear, Centro de Cincias e Tecno-
logia.
CDD:001.6
UMA METODOLOGIA PARA ANLISE DE DESEMPENHO EM SISTEMAS DE
COMPUTAO EM NUVENS
Dissertao apresentada no Curso de Mestrado
Acadmico emCincia da Computao do Cen-
tro de Cincias e Tecnologia da Universidade
Estadual do Cear, como requisito parcial para
obteno do grau de Mestre.
Aprovada em: 06/09/2012
BANCA EXAMINADORA
Prof. Dr. Jorge Luiz de Castro e Silva
Universidade Estadual do Cear UECE
Orientador
Prof. Dr. Marcial Porto Fernandez
Prof. Dr. Cidcley Teixeira de Souza
Instituto Federal de Educao, Cincia e
Tecnologia do Cear - IFCE
Prof. Dr. Gerardo Valdisio Rodrigues Viana
AGRADECIMENTOS
minha famlia, por sempre acreditarem em mim. s mulheres da minha vida; minha me
Raimundinha, e minha irm Andreia. Ao meu pai Juarez, ao meu tio Jos Maria Melo (In
Memoriam). E minha prima Daila Melo. Sem vocs, os caminhos teriam sido bem mais
rduos.
Ao professores Jorge Luiz Castro e Sila e Marcial Fernandez, pelas orientaes e pela oportu-
nidade de executar esse trabalho.
Ao professores Jerfesson Teixeira, Ricardo Rodrigues, Cidcley Teixeira, Gustavo Campos, Cle-
cio Thomaz, Andr Santos e Joaquim Celestino, pelos ensinamentos, orientaes, fora, pron-
tido e serenidade, em momentos crticos, que foram essenciais para continuar seguindo em
frente.
Aos amigos do MACC/InSeRT, que contriburam para o meu crescimento intelectual, minha
formao e minha vida, seja emuma aula, ou tomando um caf durante os intervalos. Saudaes
especiais ao Walisson Pereira (guru-mestre-doutor), grande amigo e orientador. Aos amigos de
trabalho e estudo, Alandson Mendona, Pablo Nbrega, Luanna Falco, Silas Santiago, Renan
Henry, Luis Ribeiro, Alisson Barbosa, Sergio Vieira, Sergio Luis, Thiago Gomes, Heitor Barros,
Anderson, Luiz Gonzaga, Edgar Tarton, Rodrigo Magalhes, Incio, Saulo Hachem, Leandro
Jales, Davi Teles, Fred Freitas, Klecia Pitombeira e Davi di Cavalcante.
Aos amigos e parentes, que nunca estiveram ausentes durante este perodo, sempre me dando
fora: Lila Licario (nenem), Vilson Nunes, Aldo Bessa, Leticie Bastos, Breno Cmara, Daila
Bertulis & Ed, Jack Anderson, Iane Rocha, Manuela Sales, Raquel Costa, Diego Lucena, Pris-
cila Aranha, Flora Bezerra, Pedro Nogueira, Daniel Feitosa, Rafael Feitosa, Aline Honrio,
Ricardo Moreira, Davson Maia, Flora Bezerra, Pedro Nogueira, Fernando Pinheiro, Adriano
Menezes, Felipe Leito, Fabrcio Carvalho, Rinaldo Marx, e Vincius Zavam.
Aos parceiros de banda (A Trigger to Forget) por proporcionarem momentos de descontrao e
relaxamento: Lucas Nobre, Rafael Benevides, Leonardo Mamede, e Lucas Martins.
A todas as pessoas que passaram pela minha vida e contriburam para a construo de quem
sou hoje, e que no puderam estar nessa folha de papel, mas com certeza so sempre lembradas
pelo meu corao.
A cincia descreve as coisas como
so; a arte, como so sentidas, como
se sente que so.
Fernando Pessoa
RESUMO
Computao em nuvens um modelo de computao distribuda baseado em Internet, onde
poder computacional, infraestrutura, aplicaes, e at distribuio de contedo colaborativo so
providos aos usurios atravs da nuvem como um servio, em qualquer lugar e a qualquer mo-
mento. A adoo de sistemas de computao em nuvens nos ltimos anos notvel, e vem
ganhando mais visibilidade progressivamente. Com isso, anlises crticas inerentes s carac-
tersticas fsicas da nuvem devem ser executadas para garantir o funcionamento consistente do
sistema. Portanto, necessrio propor uma abordagem de medio de desempenho das plata-
formas de computao em nuvens levando em considerao o funcionamento ecaz dos pontos
crticos de hardware e rede, tais como: taxas processamento, taxa de atualizao do buffer de
memria, transferncia de armazenamento, e a latncia da rede. Para tal, utiliza-se a metodo-
logia DEA em testes provenientes de duas sutes de benchmarks: HPCC e PTS. Analisa-se os
resultados e transcreve-se uma formulao para anlise de desempenho dos recursos requeridos
em aplicaes padro de computao em nuvens, exprimindo a utilidade desta pesquisa para os
usurios e gestores deste tipo de sistema.
Palavras-Chave: Computao em Nuvens. Benchmarks. Desempenho. DEA.
.
ABSTRACT
Cloud Computing is a distributed computing model based on the Internet, where computational
power, infrastructure, applications, and even collaborative content distribution are provided to
users through the Cloud as a service, anywhere, anytime. The adoption of Cloud Computing
systems in recent years is remarkable, and it is gradually gaining more visibility. Thus, critical
analysis inherent to clouds physical characteristics must be performed to ensure consistent
system running. Therefore, it is necessary to propose an approach to performance measurement
of Cloud Computing platforms taking into account the effective functioning of critical Hardware
and Network matters, such as: Processing rate, Memory Buffer refresh rate, Disk I/O transfer
rate, and the Network Latency. For this purpose, it uses the DEA metodology in tests from
two benchmark suites: HPCC and PTS. The results are analyzed, and a formulation is tted
to analyze the required resources performance in cloud-standard applications, expressing the
usefulness of this research to Cloud Computing adopters.
Keywords: Cloud Computing. Benchmarks. Performance. DEA.
.
LISTA DE FIGURAS
Figura 1 Evoluo da Internet: 1995 a 2007 (LAM et al., 2010). . . . . . . . . . . . . . . . . . . . 21
Figura 2 Evoluo da Internet: 2009 em diante (LAM et al., 2010). . . . . . . . . . . . . . . . . 21
Figura 3 Comunicao Intra Data Center (LAM et al., 2010). . . . . . . . . . . . . . . . . . . . . . 22
Figura 4 Estrutura de Recursos em Computao em Nuvens. . . . . . . . . . . . . . . . . . . . . . . 23
Figura 5 Convergncia de Tecnologias e Servios (INFORMA, 2011). . . . . . . . . . . . . . 25
Figura 6 Modelo dos Multiplicadores Orientados a Input (Fracionrio) (CCR/M/I) (CHAR-
NES; COOPER; RHODES, 1978). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 7 CCR - Modelo dos Multiplicadores Orientados a Input (Linear) (CCR/M/I)
(CHARNES; COOPER; RHODES, 1978). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 8 Modelo do Envelope Orientado a Input (CCR/E/I) (CHARNES; COOPER;
RHODES, 1978). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 9 Modelo do Envelope Orientado a Output (CCR/E/O) (CHARNES; COOPER;
RHODES, 1978). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 10 Modelo dos Multiplicadores Orientado a Output (CCR/M/O) (CHARNES; CO-
OPER; RHODES, 1978). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 11 Modelo do Envelope Orientado a Input (BCC/E/I) (BANKER; CHARNES;
COOPER, 1984). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 12 Modelo do Envelope Orientado a Output (BCC/E/O) (BANKER; CHARNES;
COOPER, 1984). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 13 Modelo dos Multiplicadores Orientado a Input (BCC/M/I) (BANKER; CHAR-
NES; COOPER, 1984). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 14 Modelo dos Multiplicadores Orientado a Output (BCC/M/O) (BANKER; CHAR-
NES; COOPER, 1984). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 15 Fluxograma dos Processos da Metodologia Proposta. . . . . . . . . . . . . . . . . . . . . . 41
Figura 16 Modelo Matemtico da Metodologia DEA (BCC-O) (BANKER; CHARNES;
COOPER, 1984). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 17 Abordagem de Virtualizao Bare-Metal (VMWARE, 2012). . . . . . . . . . . . . . 52
Figura 18 Arquivo de Congurao do HPCC hpccinf.txt . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 19 HPCC Benchmark (CPU): HPL x DGEMM x FFT (GFLOPS) . . . . . . . . . . . . 56
Figura 20 HPCC Benchmark (CPU): PTRANS (GB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 21 HPCC Benchmark (Memria): STREAM (GB/s) . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 22 HPCC Benchmark (Memria): Random Access (GUPs) . . . . . . . . . . . . . . . . . 59
Figura 23 Phoronix Test Suite (Memria): RAM Speed SMP Integer x Float (MB/s) . 60
Figura 24 Phoronix Test Suite (Storage): PostMark (Transaes/s) . . . . . . . . . . . . . . . . . . 61
Figura 25 HPCC Benchmark (Rede): b
e f f
(s) x Loopback TCP (s). . . . . . . . . . . . . . . . . 62
Figura 26 Desempenho dos Benchmarks por Recurso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 27 Desempenho dos Benchmarks por Instncia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 28 Desempenho dos Recursos (IAD
G
R
). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
LISTA DE TABELAS
Tabela 1 MVs utilizadas na plataforma Amazon EC2 (AMAZON, 2008). . . . . . . . . . . . 25
Tabela 2 Benchmarks utilizados por Recurso, e suas respectivas Terminologias. . . . . . 46
Tabela 3 Overheads de Virtualizao (HUBER et al., 2011). . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 4 Conjuntos dos Parmetros da Formulao Proposta . . . . . . . . . . . . . . . . . . . . . . 50
Tabela 5 MVs utilizadas no Estudo de Caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Tabela 6 Resultados obtidos atravs dos Benchmarks para cada MV (X
iRj
). . . . . . . . . . 63
Tabela 7 Pesos atribudos aos Recursos para cada MV (U
iRj
). . . . . . . . . . . . . . . . . . . . . . . 64
Tabela 8 ndices de Avaliao de Desempenho dos Benchmarks por Recurso em cada
MVs (IAD
iR
j
). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
LISTA DE SIGLAS
b
e f f
Effective Bandwidth Benchmark
BLAS Basic Linear Algebra Subprograms
CDN Content Distribution Network
CRS Constant Returns to Scale
DDR3 Double-Data Rate
DEA Data Envelopment Analysis
DFT Discrete Fourier Transform
DGEMM Double-precision General Matrix Multiply
DMU Decision Making Units
EC2 Elastic Compute Cloud
ECUs Elastic Compute Units
FFT Fast Fourier Transform
GUPS Giga Updates Per Second
HPL High Performance Linpack
IaaS Infrastructure as a Service
InSeRT Information Security Research Team
ISP Internet Service Provider
MJMI Multiple-Job-Multiple-Instance
MPI Message Passing Interface
MTC Many-Task Computing
MV Mquina Virtual
PaaS Platform as a Service
PPI Parallel Production Infrastructures
QoS Quality of Service
RAM Random Acess Memory
RMW Read-Modify-Write
SaaS Software as a Service
SAS Serial Attached SCSI
SSH Secure Shell
TCP Transmission Control Protocol
TI Tecnologia da Informao
ToR Top-of-Rack
VRS Variable Returnsto Scale
SUMRIO
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Contextualizao e Problemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.1 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.2 Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Trabalho Realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 CONCEITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Fundamentao Terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Virtualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.4 Metodologia DEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.4.1 CCR - Modelo dos Multiplicadores (Orientado a Input) . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.4.2 CCR - Modelo do Envelope (Orientado a Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4.3 CCR - Modelo do Envelope (Orientado a Output) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.4.4 CCR - Modelo dos Multiplicadores (Orientado a Output) . . . . . . . . . . . . . . . . . . . . . 32
2.1.4.5 BCC - Modelo do Envelope (Orientado a Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.4.6 BCC - Modelo do Envelope (Orientado a Output) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.4.7 BCC - Modelo dos Multiplicadores (Orientado a Input) . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.4.8 BCC - Modelo dos Multiplicadores (Orientado a Output) . . . . . . . . . . . . . . . . . . . . . 35
2.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.1 Iosup e Ostermann . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.2 Cardoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.3 Huber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.4 Comentrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 PROPOSTADEMETODOLOGIAPARAANLISEDEDESEMPENHOEM
SISTEMAS DE COMPUTAO EM NUVENS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.1 Sutes de Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 HPCC - High Performance Computing Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.3 PTS - Phoronix Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.4 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.5 Aplicao do DEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.6 Formulao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 ESTUDO DE CASO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Execues dos Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Desempenho de CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2 Desempenho de Memria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Desempenho de Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.4 Desempenho de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 ndices dos Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 ndices do DEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 RESULTADOS E DISCUSSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 CONCLUSES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1 Contribuio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 Trabalhos futuros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
BIBLIOGRAFIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
APNDICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
14
1 INTRODUO
Os sistemas de Processamento Distribudo, tais como grids, clusters e PPI (Parallel
Production Infrastructures), tem sido alvo de estudos de anlise de desempenho, devido sua
importncia para o processamento em grande escala. Assim como estas plataformas de Compu-
tao Distribuda, um novo modelo de computao baseado em Internet, vem se popularizando
a cada dia. Trata-se da Internet com todos os padres e protocolos associados para prover um
conjunto de servios web. O que torna esta tecnologia atrativa a maneira como os clientes
(usurios) trocam informaes, acessam e compartilham contedo.
A ideia de computao em nuvens uma pretenso de longa data. No um modelo
novo, pois remete dcada de 60 (PARKHILL, 1966), mas nunca foi posta em prtica devido
precariedade da largura de banda oferecida pelos provedores. Atualmente, tornou-se uma reali-
dade comercial, pois os negcios de Tecnologia da Informao tem apresentado um crescimento
considervel, acompanhando a demanda dos usurios por poder computacional, impulsionados
pelo advento da popularizao da Internet banda larga, promovendo a evoluo da indstria de
TI (ARMBRUST et al., 2009).
Em Sosinsky (2011), foi denido que uma estrutura de computao em nuvens deve
possuir recursos agrupados e particionados de acordo com a necessidade de utilizao. Ao
desenharmos a Internet como uma nuvem, representa-se a primeira das caractersticas essenciais
desse modelo: a abstrao. A virtualizao o grande trunfo da computao em nuvens, pois
abstrai as caractersticas fsicas do hardware, emulando sistemas operacionais em uma nica
plataforma computacional, formando uma camada de abstrao dos recursos da plataforma.
Em funcionamento normal, essa infraestrutura atende a vrios workloads simultanea-
mente. Estes workloads so oriundos de MVs (mquinas virtuais) ou de qualquer outra requisi-
o externa, e so compostos de vrias instncias e/ou tarefas (workloads) MJMI (Multiple-Job-
Multiple-Instance). Em contrapartida, no h referncias a pesquisas de anlise de desempenho
atravs de benchmarks e/ou baselines de kernels para sistemas de Computao Distribuda com
infraestrutura compartilhada por vrias tarefas independentes, tal como a computao em nu-
vens (OSTERMANN et al., 2010).
Inicialmente, a Internet era uma espcie de rede de redes, com uma arquitetura re-
dundante que sobreviveria enormes perturbaes. Hoje em dia, os recursos conectados
Internet, alm de normalmente redundantes (por questes de segurana), tornaram-se bastante
escalveis, fato que denota a segunda caracterstica essencial da computao em nuvens: a es-
calabilidade. A escalabilidade permite que os ambientes virtuais sejam ampliados ou reduzidos
dinamicamente para atender solicitaes de usurios por recursos.
A infraestrutura do Google por exemplo, alm de desenvolver sua prpria demanda
15
de aplicativos baseados em nuvem, arrenda sua plataforma a desenvolvedores de aplicaes
baseadas na web. Em contrapartida, a maioria das empresas de pequeno ou mdio porte no
possui fundos sucientes para investir em estruturas fsicas de grande porte. Logo, a soluo
mais vivel e vantajosa fazer um outsourcing dos recursos requeridos. Este fato credencia a
enumerao da terceira caracterstica essencial da computao em nuvens: a possibilidade da
nuvem funcionar como uma utilidade, e os servios providos serem disponibilizados, utilizando
uma abordagem pay-as-you-go.
Cloud computing ou computao em nuvens representa um paradigma da computa-
o em grande escala como conhecemos hoje, pois traz tona questes referentes s funcionali-
dades que dispe. A avaliao abordada neste trabalho focada na criticidade e no desempenho
dos recursos virtualizados da estrutura de computao em nuvens.
Tal avaliao requerida devido o desempenho dos recursos virtualizados no ser
transparente para a gerncia de rede, demandando uma metodologia que permita quantiz-la
de acordo com a especicidade da plataforma. Utilizando esta metodologia para medies pe-
ridicas de desempenho, a disponibilidade prometida possuir maior garantia de conabilidade,
reduzindo riscos de mau funcionamento. Portanto, este o momento para expor ideias de solu-
es, para que possamos responder s hipteses levantadas, e explorar o potencial deste novo
modelo de tecnologia distribuda.
1.1 Contextualizao e Problemtica
De acordo com a Lei de Moore (MOORE et al., 1998), os processos evolutivos das
arquiteturas computacionais so muito mais frequentes que o consumo destas tecnologias, fato
que torna o hardware obsoleto cada vez mais rpido. A constante evoluo da indstria de TI,
requer investimento para renovao de hardware, o que pode trazer instabilidades ao sistema,
devido s reposies sazonais. Compreendemos, ento, a necessidade em tornar o hardware
rentvel o mais rpido possvel. As plataformas de computao em nuvens utilizam a virtu-
alizao para a abstrao do seu prprio hardware, aumentando sua base de usurios, porm
diminuindo potencialmente o desempenho alcanvel (IOSUP et al., 2011).
Outro fato para o qual devemos atentar que as reposies de equipamento, tendo
como objetivo a melhoria do desempenho, consequentemente levam a um maior consumo de
energia. Durante o tempo de vida de uma estrutura computacional, o gasto com recursos de
energia e refrigerao podem superar o valor do hardware. Os servios de computao em
nuvens foram projetados para substituir data centers empresariais de pequeno e mdio porte
subutilizados (10 a 20% de utilizao) (IOSUP et al., 2011).
16
A adoo de sistemas de computao em nuvens nos ltimos anos vem ganhando mais
visibilidade. A demanda crescente dos usurios por disponibilidade de recursos computacionais
aliada capacidade do sistema de entregar resultados em um tempo bastante razovel (tempo-
real), faz da infraestrutura deste modelo uma plataforma mais convel, mais barata, e mais
escalvel que grids, clusters e supercomputadores (OSTERMANN et al., 2010). Com isso,
anlises crticas inerentes s caractersticas fsicas da nuvem devem ser executadas para garantir
um desempenho eciente do sistema.
Acomputao emnuvens prov maior exibilidade, maior explorao do potencial dos
recursos, e elasticidade. Esta abordagem de marketing computacional transformou grande parte
da indstria de TI, provendo softwares ainda mais atrativos como servios. a implementao
da computao como uma utilidade, vista como um servio de utilidade pblica como energia
eltrica, gua, etc. Cada servio procura atender s necessidades de seus clientes, cobrando-os
de acordo com a utilizao do servio (ARMBRUST et al., 2009).
Com a evoluo computacional, os dispositivos portteis microprocessados, como
computadores cada vez menores, tablets, smartphones, entre outros dispositivos mveis, vm
se popularizando. Assim, a evoluo das telecomunicaes, disponibiliza o acesso Internet
mvel proporcionalmente demanda computacional. Os aplicativos desenvolvidos para estes
dispositivos mveis, e at mesmo para mquinas tradicionais, so hospedados em servidores na
nuvem, tal como servios a serem disponibilizados sem necessidade de instalao local prvia.
Desta maneira, observamos a formao de ambientes de processamento distribudos, proporci-
onando ao usurio exibilidade e disponibilidade no acesso ao contedo hospedado.
Toda esta facilidade sensvel aos usurios do sistema, que percebem quando a
entrega dos servios est degradada ou no. Por outro lado, os gestores e desenvolvedores
deste tipo de plataforma, necessitam entregar estes servios aos clientes de maneira convel,
disponvel, e escalvel. Tal desempenho no transparente para a gerncia, mesmo utilizando
um software de gerenciamento, demandando uma maneira eciente de quantiz-la, que ser
exposta mais adiante neste trabalho.
Tendo em vista o atendimento dos requisitos de disponibilidade, tais como zero down-
time, que extremamente crtico e a alta latncia de rede, que pode interromper a comunicao
do sistema; vericamos a necessidade de avaliar os pontos crticos de hardware e rede das MVs
pertencentes ao sistemas de computao em nuvens, a m de manter o sistema operante, ex-
cluindo riscos de mau funcionamento. Cada infraestrutura possui restries e diferenas entre
si, contudo possuem a mesma criticidade, a capacidade de entrega das requisies realizada
pelos recursos virtualizados na estrutura.
Por conta das criticidades de hardware e virtualizao, a operao eciente do sis-
tema depender do bom desempenho dos recursos da estrutura computacional. Caso contrrio,
permitir uma continuidade da subutilizao da estrutura computacional, como foi evidenciado
17
em Iosup et al. (2011). Assim, detectamos o potencial problema a ser resolvido atravs das
anlises de benchmarks e posterior formulao para a avaliao do desempenho de sistemas de
computao em nuvens, levando em considerao a ponderao dos resultados obtidos.
1.1.1 Objetivos Gerais
Neste trabalho prope-se uma metodologia genrica para a avaliao do desempenho
de uma estrutura de computao em nuvens; padronizando o mtodo e contemplando um vasto
contingente de sistemas. Tal metodologia atender qualquer estrutura de computao em nu-
vens, uma vez que orientada ao desempenho dos recursos da estrutura. A avaliao dever
considerar a inuncia de cada recurso sob o desempenho total do sistema. Determina-se ento,
qual destes recursos apresenta maior relevncia para o sistema, auxiliando na deciso de qual
modelo de infraestrutura proporcionar melhor ecincia de consumo aos usurios, desenvol-
vedores e administradores.
Traados os objetivos deste trabalho, percebe-se mais uma motivao para a proposi-
o de uma abordagem de avaliao do desempenho das plataformas de computao em nuvens,
destacando a utilizao dos recursos da infraestrutura. O tempo de resposta da nuvem para alo-
cao de recursos e a latncia da rede atrelados utilizao da metodologia DEA parametrizam
os resultados encontrados pelos testes realizados em cada instncia computacional, apresen-
tando a ecincia de cada experimento executado.
1.1.2 Objetivos Especcos
Prope-se uma abordagem de anlise de desempenho das plataformas de computao
em nuvem, levando em considerao o funcionamento ecaz dos pontos crticos de hardware e
rede. Os objetivos principais deste trabalho so relacionados a seguir:
Obter conhecimento sobre o hardware da estrutura de computao em nuvens.
Implementar as MVs na estrutura de computao em nuvens baseadas no padro Amazon
EC2 (AMAZON, 2008), apresentadas na Tabela 5.
Instalar e executar os benchmarks a m de simular a execuo de aplicaes e mensurar
o desempenho dos recursos envolvidos, atividades apresentadas na Seo 4.2.
Elaborar uma metodologia para avaliao do desempenho atravs de uma formulao
matemtica realizada na Seo 3.1.6.
Exprimir analiticamente a taxa de desempenho de cada recurso utilizado e seu grau de
importncia para o funcionamento ecaz no ambiente, apresentado na Seo 4.3.
18
Calcular os ndices propostos na formulao, a m de encontrar o desempenho inerente a
cada recurso proprietrio da estrutura de computao em nuvens.
1.2 Trabalho Realizado
Neste trabalho, foram realizados experimentos para avaliao de desempenho dos sis-
temas de computao em nuvens, utilizando benchmarks e a metodologia DEA. Desta maneira,
foi possvel a aplicao da formulao proposta, e o alcance dos nveis de desempenho de cada
recurso. Levamos em considerao o desempenho mdio dos pontos crticos de hardware e
rede, tais como: processamento, taxa de atualizao do buffer de memria, E/S de armazena-
mento e latncia da rede. Duas sutes de benchmarks foram utilizadas na avaliao dos pontos
crticos do sistema, apresentadas a seguir.
OHPCChallenge benchmark (HPCC) utiliza kernels computacionais reais, permitindo
dados de entrada e tempos de execuo de tamanhos variveis, de acordo com a capacidade do
sistema utilizado (DONGARRA; LUSZCZEK, 2010). O HPCC consiste em sete benchmarks
responsveis pela anlise individual de cada componente crtico do sistema de computao em
nuvens apresentados na Seo 3.1.2.
O outro conjunto de testes utilizado na avaliao dos pontos crticos o Phoronix
Test-Suite, ou PTS (LARABEL; TIPPETT, 2008b), que mais respaldado em termos comer-
ciais, sendo a ferramenta-base do site referncia para anlise de sistemas de nuvens pblicas
do mundo todo; o Cloud Harmony (READ, 2009). O PTS consiste em mais de 130 testes para
anlise de sistemas, porm apenas trs benchmarks sero utilizados nesta proposta. A escolha e
ltragem dos benchmarks para utilizao neste trabalho tomou como parmetro a manipulao
ecaz e compatibilidade do resultados obtidos. Os trs benchmarks selecionados apresentaram
maior estabilidade e verossimilhana quando comparado a benchmarks com o mesmo objetivo
(rede, memria, disco ou processamento), e sero apresentados na Seo 3.1.3.
A partir dos resultados obtidos em ambas as sutes de benchmark, analisamos os resul-
tados, atribuindo pesos de acordo com a relevncia de cada recurso da plataforma, e transcre-
vemos uma formulao considerando o desempenho mdio de cada recurso em cada instncia
implementada no experimento. A formulao tambm leva em considerao o overhead atre-
lado a cada recurso avaliado, culminando na representao do desempenho real destes recursos.
Mais informaes sobre a metodologia utilizada nesta dissertao estaro nos Captulos 3 e 4.
1.3 Resultados Obtidos
A tecnologia de computao em nuvens representa a abstrao dos recursos compu-
tacionais disponibilizando servios sob demanda, mesmo que a virtualizao imponha certas
19
limitaes de desempenho para os workloads processados. Aps a execuo dos benchmarks, a
aplicao da metodologia DEA, e a classicao dos recursos quanto ao seu desempenho, apli-
camos os resultados obtidos na formulao proposta na Seo 3.1.6. Tal formulao apresentou
resultados relativos ao desempenho de cada recurso hospedado em cada MV implementada
dentro da estrutura de computao em nuvens.
Enm, pudemos destacar o desempenho mdio atribudo a cada recurso utilizado, le-
vando em considerao seus respectivos overheads de funcionamento. Obtivemos o desem-
penho mdio de cada recurso da plataforma de computao em nuvens como resultado nal,
representado pelo ndice de avaliao de desempenho global por recurso, considerando todas
as MVs implementadas na plataforma. Desta maneira, ser possvel avaliar o desempenho dos
recursos de qualquer estrutura de computao em nuvens, considerando apenas a nfase do
sistema quanto aos recursos mais crticos, independentemente de quantas MVs sejam imple-
mentadas.
1.4 Organizao da Dissertao
Esta dissertao est dividida em seis captulos, onde o Captulo 2 expe os conceitos
fundamentais para a compreenso do problema abordado, o estado da arte da infraestrutura de
computao em nuvens, desde sua denio estrutural at as impresses do mercado com re-
lao a esta nova tecnologia. Neste captulo ainda so apresentados os benchmarks utilizados,
bem como a metodologia DEA que propicia anlises de ecincia comparativas em organi-
zaes complexas, retornando resultados dos sistemas com melhor desempenho. Ao nal do
captulo, contamos com a justicativa sobre as pesquisas tomadas como base para a realizao
deste trabalho.
O Captulo 3 refere-se proposta da metodologia de anlise de desempenho em siste-
mas de computao em nuvens, tomando como referncia as principais aplicaes deste tipo de
estrutura computacional, e a apresentao dos benchmarks. Avaliamos os principais requisitos
das aplicaes, a anlise especca dos benchmarks sobre cada mtrica, e ento propomos uma
formulao que contempla o desempenho ecaz das aplicaes de computao em nuvens.
No Captulo 4 apresentamos o cenrio utilizado para implementar a pesquisa, uma
descrio especca dos benchmarks para anlise de desempenho do sistema de computao
em nuvens, a justicativa de cada resultado obtido, e a abordagem experimental adotada para
analisar o desempenho em sistemas de computao em nuvens.
O Captulo 5 apresenta a anlise dos resultados obtidos a partir das simulaes, apli-
cando a formulao proposta. Finalmente no Captulo 6 exporemos as concluses alcanadas,
a contribuio da pesquisa e as propostas de trabalhos futuros.
20
2 CONCEITOS
Este captulo apresenta os conceitos fundamentais e os trabalhos pesquisados para a
compreenso aprofundada do assunto em questo, e para a concepo das contribuies da pre-
sente dissertao. A Seo 2.1 apresenta a denio de um sistema de computao em nuvens,
os conceitos bsicos, a representatividade do sistema, o estado da arte da arquitetura, a virtua-
lizao dos recursos, a utilizao dos benchmarks e da metodologia DEA. A seo 2.2 resume
os trabalhos relacionados, considerados como alicerce fundamental para o desenvolvimento da
presente pesquisa. Apresentaremos a ideia central dos trabalhos pesquisados, com o objetivo de
contextualiz-los no mbito da importncia da realizao deste trabalho.
2.1 Fundamentao Terica
Foster et al. (2008) deniu que computao em nuvens um paradigma da computao
de grande porte focado em proporcionar economia escalvel na qual um conjunto abstrato, vir-
tualizado, e dinamicamente escalvel de poder de processamento, armazenamento, plataformas
e servios so disponibilizados sob demanda para clientes atravs da Internet. A partir desta
denio veremos como a computao de Internet estruturada e como esta chegou no atual
patamar de evoluo.
Nesta Seo apresentaremos os conceitos mais importantes relacionados aos atribu-
tos de computao em nuvens. Na Subseo 2.1.1, apresenta-se o histrico, o estado da arte,
os servios atrelados, e dados estatsticos sobre a arquitetura fsica e lgica da infraestrutura
de computao em nuvens. Na Subseo 2.1.2, apresenta-se os conceitos, funcionalidades, e
melhores prticas relativos tecnologia de virtualizao. E por ltimo, nas Subsees 2.1.3
e 2.1.4, apresenta-se os conceitos e funcionalidades dos benchmarks e da metodologia DEA,
ambas aplicaes importantssimas para a realizao deste trabalho.
2.1.1 Arquitetura
Conforme Lam et al. (2010), a Internet dividida em dois momentos de topologias
distintas: A Internet 1995-2007, que representa a viso hierrquica da Internet inicial; contando
com poucos provedores de servios de core de grande porte (em um nvel mais alto), e provendo
interconexes de backbone para os ISPs, provedores de acesso regional e local (em um nvel
mais baixo), conforme a Figura 1.
21
Figura 1: Evoluo da Internet: 1995 a 2007 (LAM et al., 2010).
O segundo momento referente Internet de 2009 em diante, em que a topologia
foi transformada em um modelo de conectividade mais entrelaado, conforme mostra a Figura
2. O ncleo central - dominado pelos provedores tradicionais de backbone - conectado por
gigantes das comunicaes, oferecendo contedo rico, hospedagem, e uma rede de servios de
distribuio de contedo (CDN).
Figura 2: Evoluo da Internet: 2009 em diante (LAM et al., 2010).
Assim sendo, a computao em nuvens um modelo de sistema de computao de
Internet que tem como objetivo impulsionar a prxima gerao de data centers, arquitetando-
os como uma rede de servios virtuais (hardware, banco de dados, interface com o usurio,
etc.). Assim, seus usurios podem acessar e instalar aplicativos em qualquer lugar do mundo,
sob demanda, a custos competitivos, dependendo dos seus requerimentos de QoS. Deste modo,
essa evoluo representa benefcios s empresas de TI, que cam livres da responsabilidade de
congurao de uma infraestrutura de hardware e software (servidores), possibilitando um foco
maior na inovao e gerao de negcios de valor (WEISS, 2007).
22
Para melhor compreendermos a comunicao em nuvens, necessitamos entender como
funcionam as comunicaes entre data centers. Um data center uma estrutura computacional
massiva e paralela que consiste em clusters com milhares de servidores conectados em rede.
Servidores dentro do mesmo rack so interconectados por um switch ToR. Tais racks so co-
nectados a um switch de cluster, provendo interconectividade, como mostra a Figura 3.
Figura 3: Comunicao Intra Data Center (LAM et al., 2010).
Data centers distribudos no proveem somente redundncia, mas tambm so utili-
zados para balanceamento de carga de processamento, melhorando a experincia do usurio
e reduzindo a latncia no trfego. As redes pticas de longas distncias (long-haul) (OPTI-
COMM, 2008) se fazem necessrias para manter o trfego entre data centers, distribuindo-os
para os centros nos quais os usurios esto localizados, reduzindo assim os custos de interco-
nexo; transportando dados entre localidades remotas, e garantindo capacidade escalvel su-
ciente para suportar as operaes necessrias. O trfego entre data centers em sua maioria
gerado por mquinas que rodam aplicaes de computao em nuvens, com um grande volume
de trfego (LAM et al., 2010).
A tecnologia de computao em nuvens baseada nos conceitos da chamada utility
computing (WARDLEY, 2009). O termo utility faz meno aos servios de utilidade pblica,
tais como o fornecimento de energia eltrica, gua, etc. Os provedores procuram atender s
necessidades dos seus clientes disponibilizando recursos computacionais sob demanda, utili-
zando um modelo de tarifao do usurio de acordo com a utilizao do recurso, ao invs de
exigir o uso de licenas temporrias. Essa abordagem de marketing computacional conhecida
como pay-as-you-go, e tem potencial para transformar grande parte da indstria de TI, provendo
softwares mais atrativos como servios (ARMBRUST et al., 2009).
A expresso Everything-as-a-Service (EaaS) um conceito que mostra a capacidade
de acesso aos recursos computacionais atravs de um ambiente virtualizado. Todos esses re-
cursos esto associados a aplicaes (SaaS), equipamentos (IaaS) e plataformas (PaaS). SaaS
possibilita que uma instncia executvel de um software instalado em um servidor remoto seja
23
acessada e executada por vrios computadores-clientes sem necessidade de instalao local.
Similarmente, o IaaS compreende o provisionamento de infraestrutura baseado na virtualiza-
o de entidades tais como servidores, data centers ou equipamentos de rede. Por m, o PaaS
consiste em uma plataforma onde os recursos esto alocados (hardware e software) e sero
posteriormente executados (ARMBRUST et al., 2009). possvel vericar a estrutura de uma
plataforma de computao em nuvens a partir da Figura 4.
Figura 4: Estrutura de Recursos em Computao em Nuvens.
A topologia de computao em nuvens consiste em uma nuvem de Mega data centers
geogracamente distribudos, interconectados por uma rede de alta capacidade. Esta infraes-
trutura representa o principal montante de despesas operacionais (incluindo o fornecimento de
energia e o resfriamento do equipamento) s provedoras, responsvel por 75% do TCO (Total
Cost of Ownership). A principal motivao para manter um sistema de computao em nuvens,
para a maioria das empresas a agilidade, enquanto que o restante enfatiza mais a reduo do
TCO (NARASIMHAN; NICHOLS, 2011).
Em Narasimhan e Nichols (2011), uma pesquisa realizada com empresas adotantes da
tecnologia de computao em nuvens, mais de 60% armou que as solues hospedadas na
nuvem so melhores que as solues locais, e que pretendem rodar suas aplicaes em nuvens
pblicas em at trs anos. Mais de 80% das empresas armaram conseguir respostas mais
rpidas s necessidades dos negcios, tornando a tecnologia um paradigma em relao ao papel
da TI em seus negcios.
Os usurios tem seus dados residentes na rede, acessveis em qualquer lugar do mundo
e ainda contam com um backup automtico destes dados. Proporciona ainda a possibilidade
de compartilhamento, permite que mltiplos colaboradores modiquem os dados simultanea-
mente, e melhor utilizem os recursos computacionais atravs da virtualizao, pois os usurios
no precisam se preocupar em manter sua prpria mquina, gerando assim, uma considervel
reduo de despesas (ARMBRUST et al., 2009).
24
2.1.2 Virtualizao
Virtualizao capacidade de criar diversas mquinas lgicas (virtuais) em um nico
hardware. Origina-se do particionamento fsico, que divide um nico servidor fsico em mlti-
plos servidores lgicos. Desse modo, cada servidor pode rodar sistemas operacionais e aplica-
tivos de forma independente. Os componentes principais desta tcnica so as mquinas virtuais
(MVs), ambientes operacionais autossucientes, que implementam um hardware virtual inde-
pendente da plataforma; e o hypervisor, que o software que desvincula o sistema operacional
e os aplicativos de seus recursos fsicos. O hypervisor possui kernel prprio, e roda diretamente
no hardware da mquina, sendo inserido entre o hardware e o sistema operacional (GONCAL-
VES; JUNIOR, 2010).
Banerjee et al. (2011), determina que uma plataforma de computao em nuvens total-
mente otimizada quanto virtualizao deve prover as seguintes caractersticas:
Virtualizao computacional, onde cada servidor rode um hypervisor.
Alocao de recursos ecientemente e dinamicamente.
Isolamento entre as MVs, permitindo que dados e softwares sejam visualizveis como
cache em cada n do servidor.
Modelo scale-out, onde os ns possam ser adicionados rede, e seus estados possam ser
reconstrudos remotamente.
Automatizao relativa instalao, atualizao, gerncia e recuperao do sistema ope-
racional e aplicaes.
Plataforma rica em servios (monitoramento, log, medio e faturamento) acessveis atra-
vs de protocolos de rede.
Armazenamento com conabilidade e escalabilidade para uma base de dados comparti-
lhada.
Devido grande diculdade em comparar desempenhos de processamento em siste-
mas de computao em nuvens diferentes, as MVs implementadas neste trabalho so baseadas
nas instncias mais bsicas disponibilizadas pela Amazon EC2, que utiliza a terminologia ECU
(Elastic Compute Units), para tratar deste recurso fsico (OSTERMANN et al., 2010). Logo, as
capacidades da MVs implementadas so denidas por ECUs, onde 01 (um) ECU equivale ca-
pacidade de um processador 1.0-1.2GHz 2007 Opteron ou Xeon. As instncias so conguradas
tal como observamos na Tabela 1.
25
MVs ECUs (Cores) RAM [GB]) Archi [bit] Disk [GB]
m1.small 1 (1) 1,7 32 160
c1.medium 5 (2) 1,7 32 350
m1.large 4 (2) 15 64 850
m1.xlarge 8 (4) 15 64 1690
c1.xlarge 20 (8) 7 64 1690
Tabela 1: MVs utilizadas na plataforma Amazon EC2 (AMAZON, 2008).
A aquisio de novos softwares de aplicao ou de equipamentos especcos d lugar
utilizao de navegadores de Internet, possibilitando o acesso a vastos acervos de contedo
disponibilizados sob demanda na rede. Tudo isso possvel a partir da convergncia de tec-
nologias e servios (Figura 5), que formam o alicerce para a prxima gerao de dispositivos
conectados (BANERJEE et al., 2011). Tal convergncia prover um desempenho extremamente
alto a um custo relativamente baixo, enriquecendo a experincia do usurio, e simplicando as
interaes para acesso informaes e servios personalizados em qualquer lugar, a qualquer
momento.
Figura 5: Convergncia de Tecnologias e Servios (INFORMA, 2011).
A partir do momento em que as MVs encontram-se devidamente instaladas e operan-
tes dentro da estrutura de computao em nuvens, devemos rodar os experimentos de avaliao
de desempenho. H vrias possibilidades de se realizar aferies de desempenho em sistemas:
traces, benchmarks, simulaes (em vrios nveis) e mixes (combinao de mtodos). O prin-
cipal meio para anlise de dados utilizado por esta pesquisa a execuo de benchmarks, os
quais iro fornecer dados estatsticos indispensveis para a anlise de desempenho em qualquer
sistema.
2.1.3 Benchmarks
Benchmarks so softwares ou operaes, a m de avaliar o desempenho de um objeto
26
ou sistema em questo, realizando simulaes, testes e ensaios neste. A partir da evoluo
das arquiteturas dos computadores, torna-se cada vez mais difcil comparar o desempenho de
sistemas de computao diferentes. O benchmark realiza esta funo, imitando um determinado
tipo de comportamento de um componente ou sistema.
Os Benchmarks provem mtodos de comparao de desempenho de subsistemas de
diferentes arquiteturas e sistemas, sendo teis para o entendimento de como um sistema reage
sob a variao de condies, para testes de cenrios no tratamento de deadlocks, anlise de
desempenho de utilitrios, mtodos de carregamento de dados, caractersticas de transio e
ainda testa os efeitos da utilizao de uma nova verso de um produto.
OHPCChallenge benchmark (HPCC) utiliza kernels computacionais reais, permitindo
dados de entrada e tempos de execuo de tamanhos variveis, de acordo com a capacidade do
sistema utilizado (DONGARRA; LUSZCZEK, 2010). O HPCC consiste em sete benchmarks:
HPL, STREAM, DGEMM, PTRANS, Random Access, FFT e b
e f f
, responsveis pela anlise
individual de cada componente crtico do sistema de computao em nuvens apresentados na
Seo 3.1.2.
Alm do HPCC, utilizamos outra sute de benchmarks, o PTS. Esta sute de bench-
marks compreende mais de 130 testes para anlise de um sistema, abrangendo destaques a
vrios recursos e aplicaes-teste diferentes. Neste trabalho foram utilizados os benchmarks
RAM Speed SMP, PostMark, eLoopback TCP Network Performance.
2.1.4 Metodologia DEA
A histria da Anlise Envoltria de Dados tem incio com a publicao da tese de
Edwardo Rhodes (CHARNES; COOPER; RHODES, 1978), a qual continha uma metodologia
de comparao das ecincias de escolas pblicas. O principal objetivo era estimar a ecicia
tcnica de cada uma das escolas sem que os pesos de cada insumo (input) ou produto (output)
fossem informados arbitrariamente, e sem que houvesse a converso para uma medida nica
para comparao entre as variveis.
Para o clculo da medida de ecincia foi utilizada uma abordagem que rma que um
vetor input-output tecnicamente eciente, se e somente se:
Nenhum dos inputs pode ser reduzido sem que algum output seja reduzido ou algum outro
input seja aumentado.
Nenhum dos outputs pode ser aumentado sem que algum input seja aumentado ou algum
output seja reduzido.
Debreu (1951) props uma medida radial de ecincia tcnica, que o coeciente de
27
utilizao dos recursos, que busca a mxima reduo equiproporcional de todos os insumos, ou
seja, obter o menor valor possvel de cada input mediante restries mencionadas anteriormente.
Pode ainda buscar a mxima expanso equiproporcional de todos os produtos, ou seja, conseguir
o maior valor possvel de cada output.
Conforme (LINS; MEZA; ANTUNES, 2000), Von Neumann utilizou modelos de pro-
gramao matemtica para representar sua anlise de atividades e modelos de crescimento.
Outros autores no menos importantes tambm zeram referncia programao linear como
instrumento de anlise essencial para o modelo DEA, porm tais referncias s foram am-
plamente aceitas aps a publicao de Charnes e Cooper, com a utilizao do modelo CCR
(CHARNES; COOPER; RHODES, 1978).
As principais caractersticas da metodologia DEA so:
No h necessidade de converter todos os inputs e outputs nas mesmas unidades de me-
dida;
Os ndices de ecincia so baseados em dados reais, ou seja, nos valores de cada input e
output;
Tem como resultado un nico input virtual e um nico output virtual;
Considera que as observaes dspares dentro de uma srie no representam apenas gran-
des desvios em relao aos valores mdios das variveis, mas possveis benchmarks (mo-
delos de referncia para outras unidades avaliadas);
A metodologia DEA otimiza cada observao individualmente tendo como objetivo de-
terminar uma fronteira linear por partes, compreendendo o conjunto de unidades Pareto-
Eciente.
Tal metodologia propicia a anlise da ecincia comparativa de organizaes comple-
xas obtida pela revelao do desempenho de outras unidades, de modo que a referncia no
obtida apenas terica ou conceitualmente, mas atravs da observao das melhores prticas.
As organizaes que estiverem sob anlise DEA so denominadas DMUs (Decision Making
Units), e devero utilizar recursos em comum e produzir os mesmos produtos. Com isto, se-
ro denidas DMUs ecientes (mximo de outputs produzidos mediante os inputs utilizados) e
inecientes; as primeiras caro situadas na fronteira de ecincia, enquanto as ltimas, abaixo
da mesma fronteira.
Assim, DEA (Data Envelopment Analysis) uma tcnica matemtica de programa-
o linear que consiste em uma metodologia de apoio deciso de natureza multicritrio, que
analisa mltiplos insumos e produtos simultaneamente, sendo capaz de modelar problemas do
28
mundo real atendendo anlise de ecincias. Pode ser implementada por meio de programa-
o linear desenvolvida para converter medidas de mltiplos insumos e produtos em uma nica
medida de ecincia (FOCHEZATTO, 2010).
Conforme Meireles (2012), existem vrias maneiras de determinar uma fronteira de
ecincia, porm existem dois modelos da metodologia DEA amplamente aceitos: o BCC e
o CCR. Ambos apresentam variaes quanto a sua orientao, tal como ser apresentado em
seguida.
2.1.4.1 CCR - Modelo dos Multiplicadores (Orientado a Input)
O modelo CCR (CHARNES; COOPER; RHODES, 1978) constri uma superfcie li-
near por partes, a qual envolve os dados. Trabalha com retornos de escala constantes, ou seja,
crescimentos proporcionais de inputs produzindo crescimentos proporcionais de outputs. Exis-
tem dois modelos de programao matemtica para representar o modelo CCR: o dos multipli-
cadores e o do envelope.
Figura 6: Modelo dos Multiplicadores Orientados a Input (Fracionrio) (CCR/M/I) (CHAR-
NES; COOPER; RHODES, 1978).
Tem como objetivo encontrar os valores das variveis u
j
e v
j
, que so seus respectivos
pesos, maximizando a soma ponderada dos outputs dividida pela soma ponderada dos inputs da
29
DMU em questo, como apresentado em (5) na Figura 6. Tal maximizao tem restrio que
o quociente em questo deve ser menor ou igual a um para cada DMU (6).
Desta maneira, o modelo permite que os pesos para cada varivel (input e output)
sejam escolhidos para cada DMU da forma que lhe for mais conveniente. O ndice de ecincia
encontrado o ndice apenas da DMU em questo (O), portanto esse procedimento deve ser
repetido para cada uma das k DMUs.
Este modelo permite que sejam atribudos pesos (multiplicadores) a todas as DMUs. A
m de maximizar a ecncia, cada DMU dene o seu prprio conjunto de pesos, uma vez que
possuem um sistema de valores particular. Para tal, todas as DMUs devem ter uma ecincia
inferior ou igual a 1.
Figura 7: CCR - Modelo dos Multiplicadores Orientados a Input (Linear) (CCR/M/I) (CHAR-
NES; COOPER; RHODES, 1978).
O modelo apresentado um modelo de programao fracionria, e deve ser trans-
formado em um modelo de programao linear. Deve-se linearizar tambm as restries do
problema conforme a Figura 7. Para tal, xa-se o denominador da funo objetivo em um valor
constante (normalmente 1), como visto em (10). A partir deste modelo possvel calcular
alm da ecincia de cada DMU, os respectivos pesos de cada input e output.
30
O modelo CCR dos multiplicadores (M) orientado a input (I) tambm denominado
CRS/M/I por assumir retornos de escala constantes (CRS) (Constant Returns to Scale).
2.1.4.2 CCR - Modelo do Envelope (Orientado a Input)
Omodelo do envelope orientado a input temcomo objetivo calcular a ecincia de uma
DMU observando as formulaes apresentadas na Figura 8, e tem como variveis de deciso
h
o
e
k
. A priori, h
o
deve multiplicar todos os inputs tentando colocar a DMU na fronteira de
ecincia.
Figura 8: Modelo do Envelope Orientado a Input (CCR/E/I) (CHARNES; COOPER; RHODES,
1978).
Desta maneira, o primeiro conjunto de restries (15) faz com que a fronteira formada
pelas DMUs ecientes no seja ultrapassada pela reduo causada por h
o
em cada um dos
inputs. O segundo conjunto de restries (16), garante que a reduo provocada por h
o
no
altere os valores dos outputs da DMU.
Atravs da varivel
k
indicado quais DMUs ecientes serviro de referncia para
a DMU que est sendo analisada. Caso
k
seja igual a zero, considera-se que a DMU k no
referncia para a DMU O. Portanto, quanto maior for
k
, maior a importncia como DMU
referncia.
Similarmente classicao adotada para o modelo dos multiplicadores, o modelo
do envelope denominado CRS/E/I por assumir retornos de escala constantes (CRS), por ser
31
formulado a partir do modelo do envelope (E) e por ser orientado a input (I).
2.1.4.3 CCR - Modelo do Envelope (Orientado a Output)
Neste modelo os insumos so mantidos xos, os produtos so maximizados, e as va-
riveis de deciso so as mesmas do modelo orientado a input (h
o
e
k
). Neste caso, h
o
ser o
valor necessrio para multiplicar os produtos mantendo constantes os insumos, possibilitando
que a DMU atinja a fronteira de ecincia. Portanto, h
o
ser um valor maior que 1 de acordo
com as restries da Figura 9.
Figura 9: Modelo do Envelope Orientado a Output (CCR/E/O) (CHARNES; COOPER; RHO-
DES, 1978).
Similarmente s outras classicaes de modelos, sua denominao ser CRS/E/O por
assumir retornos de escala constantes (CRS), por ser formulado a partir do modelo do envelope
(E) e por ser orientado a output (O).
32
2.1.4.4 CCR - Modelo dos Multiplicadores (Orientado a Output)
Figura 10: Modelo dos Multiplicadores Orientado a Output (CCR/M/O) (CHARNES; COO-
PER; RHODES, 1978).
Similarmente s outras classicaes de modelos, sua denominao ser CRS/M/O
por assumir retornos de escala constantes (CRS), por ser formulado a partir do modelo dos
multiplicadores (M) e por ser orientado a output (O). Podemos visualizar na Figura 10 o modelo
dos multiplicadores orientados a output.
2.1.4.5 BCC - Modelo do Envelope (Orientado a Input)
O modelo BCC (BANKER; CHARNES; COOPER, 1984) difere do CCR quanto aos
retornos de escala; no BCC o retorno de escala varivel, enquanto que no CCR constante.
Com isso, o modelo tambm denominado VRS (Variable Returns to Scale). As DMUs que
trabalham com inputs de valores baixos tero retornos de escala crescentes, e as que trabalham
com inputs de valores altos tero retornos de escala descrescentes. Considera que um acrs-
cimo no input poder promover um acrscimo no output, no necessariamente proporcional.
Sendo assim, este modelo relevante para o estudo da ecincia por admitir retornos de escala
33
variveis.
O modelo BCC surgiu como uma forma de ecincia resultante da diviso do modelo
CCR em duas componentes: ecincia tcnica e ecincia de escala. A ecincia tcnica
identica a correta utilizao dos recursos escala de operao da DMU. A ecincia de escala
igual ao quociente da ecincia BCC com a ecincia CCR, e nos retorna a distncia da DMU
em anlise at uma DMU ctcia.
Na orientao a input, o modelo do envelope adiciona mais uma restrio s j exis-
tentes no modelo CCR. A nova restrio adicionada (30), garante que o somatrio dos
k
seja
igual a 1 tal como mostra a Figura 11.
Figura 11: Modelo do Envelope Orientado a Input (BCC/E/I) (BANKER; CHARNES; COO-
PER, 1984).
Tal como apresentado anteriormente, a denominao do modelo obedece o padro es-
tabelecido; VRS/E/I por assumir retornos de escala variveis (VRS), ser formulado a partir do
modelo do envelope (E) e ser orientado a input (I).
34
2.1.4.6 BCC - Modelo do Envelope (Orientado a Output)
Na orientao a output tambm h a adio de uma restrio do somatrio dos
k
(35)
tal como mostra a Figura 12.
Figura 12: Modelo do Envelope Orientado a Output (BCC/E/O) (BANKER; CHARNES; CO-
OPER, 1984).
modelo do envelope (E) e ser orientado a input (I).
2.1.4.7 BCC - Modelo dos Multiplicadores (Orientado a Input)
Atravs dos modelos do envelope orientados a input e output possvel gerar os mo-
delos dos multiplicadores orientados a input e output respectivamente. Em ambos, a restrio
do somatrio dos
k
transforma-se nas variveis duais u e v dos modelos dos multiplicadores
orientados a input e output respectivamente. Essas variveis so conhecidas como fatores de
escala, e podem ser variveis ou constantes.
35
Na orientao a input, os possveis valores de u:
u = 0, indica retornos de escala constantes;
u > 0, indica retornos de escala crescentes;
u < 0, indica retornos de escala decrescentes;
Figura 13: Modelo dos Multiplicadores Orientado a Input (BCC/M/I) (BANKER; CHARNES;
COOPER, 1984).
modelo dos multiplicadores (M) e ser orientado a input (I).
2.1.4.8 BCC - Modelo dos Multiplicadores (Orientado a Output)
modelo dos multiplicadores (M) e ser orientado a output (O).
36
Na orientao a output, os possveis valores de v:
v = 0, indica retornos de escala constantes;
v > 0, indica retornos de escala decrescentes;
v < 0, indica retornos de escala crescentes;
Figura 14: Modelo dos Multiplicadores Orientado a Output (BCC/M/O) (BANKER; CHAR-
NES; COOPER, 1984).
O modelo BCC/M/O (BANKER; CHARNES; COOPER, 1984) foi escolhido para este
trabalho por permitir retornos variveis de escala, podendo tais retornos crescerem, decrescerem
e permanecerem constantes medida em que a escala de produo aumentada ou reduzida.
A orientao a output foi escolhida por conta das variveis de input serem xas, no havendo
controle sobre as variveis de input (instncias de MVs). Como o objetivo a obteno do
melhor desempenho dos benchmarks (outputs) executados nas MVs pretendido portanto, obter
a maior quantidade de produtos mediante os insumos disponveis.
37
2.2 Trabalhos Relacionados
Para o desenvolvimento deste trabalho houve a necessidade de um aprofundamento em
diversas publicaes pesquisadas em nichos de literatura acadmica, providenciando o amadu-
recimento das ideias e embasamento terico. A seguir, evidenciaremos o princpio fundamental
de cada um dos trabalhos onde esta pesquisa est alicerada.
2.2.1 Iosup e Ostermann
Ostermann et al. (2010) e Iosup et al. (2011), primeiramente criaram uma plataforma
virtual a partir dos recursos da nuvem, utilizando a plataforma comercial Amazon EC2 (AMA-
ZON, 2008). Vrias instncias so criadas, especicando o tipo e a imagem da MV que vai ser
inicializada e instalada. No mximo 20 instncias podem ser utilizadas simultaneamente por
usurios normais, para no comprometer o desempenho do sistema. Assim, o recurso pode ser
utilizado como um n computacional via conexo SSH (LEHTINEN; LONVICK, 2006).
Um dos principais atrativos da computao em nuvens, a proviso de recursos sob
demanda sem tempo de espera adicional, diferentemente dos padres de submisso de outros
sistemas de larga-escala. O autor ainda estabelece perodos de tempo (longos ou curtos) para a
aquisio/liberao dos recursos. Para os perodos curtos, uma ou mais instncias so adquiridas
e liberadas repetidamente em poucos minutos, seguindo um processo de Poisson com taxa de
chegada menor que um segundo. Para os perodos longos, cada instncia adquirida e liberada
a cada 2 minutos no perodo de uma semana (IOSUP et al., 2011).
Neste cenrio a infraestrutura compartilhada por vrias tarefas independentes. Fo-
ram utilizados benchmarks tradicionais em conjuntos de tarefas para serem executadas isolada-
mente, reexecutando as amostras dos workloads MJMI. Para tal anlise, foi utilizado o HPCC
para todos os tipos de instncias possveis. Ao submeter o mesmo workload repetidamente para
cada tipo de instncia (MV), foram detectadas duas caractersticas de desempenho principais: A
estabilidade do makespan do workload, e o overhead tanto da aquisio/liberao de recursos,
como da execuo de tarefas, tornando possvel a anlise da proviso de recursos em tempo-real
(OSTERMANN et al., 2010).
Iosup et al. (2011) investiga e quantica a presena de componentes proto-MTC(Many-
Task Computing) em workloads de computao cientca. Em seguida so validadas as perfor-
mances de vrias plataformas de computao em nuvem (Amazon EC2, Mosso, ElasticHost e
GoGrid) utilizando os benchmarks da sute HPCC. Mais uma vez este benchmark utilizado,
agora somente para workloads de mltiplas instncias. Em seguida, o autor compara as perfor-
mances (entre computao em nuvens e computao cientca, grids e PPIs), baseando-se em
amostras de simulaes e em resultados de desempenho empricos.
38
Em ambos os trabalhos, foi vericado que a computao em nuvens uma alterna-
tiva vivel para aplicaes com deadlines curtos. Uma tarefa com tempo de resposta estvel
e baixo traz um atraso muito menor para qualquer modelo de nuvem, quando comparado ao
ambiente cientco. A tecnologia de computao em nuvens responde ecazmente aos critrios
de estabilidade, escalabilidade, baixo overhead, e tempo de resposta. Alm disso, uma plata-
forma de computao em nuvens no deixa tanto a desejar, em termos de desempenho, quando
comparada a uma plataforma de computao cientca. As estruturas de computao cientca
foram implementadas para tratar de workloads de grande capacidade e uxo, e portanto tem um
aproveitamento melhor nesta nalidade.
2.2.2 Cardoso
Cardoso (2011) referencia os benchmarks para a vericao do desempenho e das li-
mitaes da infraestrutura de computao em nuvens. Os benchmarks foram divididos em:
Benchmarks de desempenho da implementao (que tem como propsito o entendimento do
momento de implementao dos clusters virtuais), benchmarks individuais, e benchmarks de
cluster. Todos trazem consigo uma noo das perdas introduzidas pela virtualizao em ambi-
entes individuais ou multiprocessados.
O autor ainda realiza simulaes com o propsito de avaliar as mtricas de uso de
CPU/RAM, E/S de armazenamento, e de rede. Os benchmarks so divididos em trs categorias
de utilizao: CPU, E/S, e Misto. Foi vericado que os testes de utilizao de CPU possuem um
pequeno overhead introduzido pela virtualizao. Benchmarks de utilizao de E/S e Mistos,
apresentaram resultados no-consistentes onde as perdas de desempenho negativas mostram
que a virtualizao pode introduzir ganhos de desempenho.
Tal fato ocorre possivelmente pelo fato da virtualizao criar um novo nvel de cache,
gerando um grande impacto no desempenho de E/S. Por outro lado, tambm h componentes
que desempenham funes de E/S com grandes perdas de cache, deteriorando o desempenho e
tornando a cache intil. difcil, portanto, prever como uma tarefa especca que utiliza uma
grande quantidade de execues de E/S vai se comportar.
2.2.3 Huber
Huber et al. (2011) destaca o aumento da complexidade e dinamicidade na imple-
mentao de servidores virtualizados. O aumento na complexidade causado pela introduo
paulatina de recursos virtuais, e pela lacuna deixada pela alocao de recursos lgicos e fsicos.
O aumento na dinamicidade causado pela falta de controle direto sobre o hardware fsico,
e pelas interaes complexas entre aplicaes e workloads, que compartilham a infraestrutura
fsica introduzindo novos desaos na gesto do sistema.
39
Resultados de experimentos utilizando benchmarks mostraram que o overhead de de-
sempenho para virtualizao de CPU possui taxa em torno de 5%. Da mesma maneira, o
overhead de virtualizao de memria, E/S de rede, e de armazenamento, atingem 40%, 30%,
e 25% respectivamente. Alm da execuo dos testes, foram feitas comparaes com outros
modelos de hypervisor a m de especicar o desempenho individual de cada um, considerando
taxas de erro de desempenho (HUBER et al., 2010).
2.2.4 Comentrios
Para atender aos requerimentos mnimos do objeto de pesquisa dos trabalhos de Iosup
et al. (2011) e Ostermann et al. (2010), relacionados na Seo 2.2.1, foi utilizada uma plata-
forma fsica de data center disponibilizada pelo grupo de pesquisa de segurana da informao
(InSeRT) na Universidade Estadual do Cear. Foram geradas cinco instncias de MVs basea-
das no padro fornecido pela Amazon EC2 para a realizao das simulaes. A contribuio
destes trabalhos ca marcada pela metodologia e avaliao das mtricas envolvidas, alm do
pioneirismo relativo ideia de avaliar o desempenho de sistemas de computao em nuvem.
Neste trabalho submetemos vrios workloads para cinco tipos de instncias diferen-
tes, interconectadas e replicadas para prover uma simulao mais real do ambiente de nuvem.
Alm do HPCC, o PTS tambm foi utilizado para possibilitar uma maior cobertura dos recursos
avaliados. O makespan manteve-se estvel (constante), e o overhead atribudo virtualizao
considerado pequeno, porm suciente para alterar substancialmente os resultados de cada re-
curso em comparaes com outros sistemas no-virtualizados.
Tal qual a pesquisa de Cardoso (2011), utilizamos as sutes de benchmark HPCC e
PTS. Dividimos os benchmarks de acordo com os recursos, e os recursos em categorias de
utilizao. Consideramos tambm as perdas introduzidas pela virtualizao (overhead), e a
no-consistncia de alguns resultados, mostrando que a virtualizao pode introduzir ganhos de
desempenho.
Por ltimo, Huber et al. (2011) nos mostra as taxas de overhead introduzidas pela
virtualizao, e que estas devem ser levadas em considerao quando avaliamos o desempenho
dos recursos virtualizados. Assim, procedemos ao Captulo 3, onde ser proposta a metodologia
de avaliao de desempenho para sistemas de computao em nuvens. Mais detalhes sobre os
experimentos realizados sero disponibilizados na Seo 4.1.
40
3 PROPOSTA DE METODOLOGIA PARA ANLISE DE DESEMPENHO EM
SISTEMAS DE COMPUTAO EM NUVENS
Atravs das pesquisas realizadas para concepo deste trabalho, constatou-se que a
literatura estudada no trata da questo da avaliao do desempenho de sistemas de computao
em nuvens no contexto dos recursos de infraestrutura atravs de benchmarks. Mesmo com as
vantagens do sistema de computao em nuvens, a literatura normalmente referencia estruturas
de computao cientca, as quais oferecem uma grande capacidade de armazenamento atravs
de tcnicas de processamento paralelo.
Neste captulo descrita a metodologia proposta para a anlise de desempenho de sis-
temas de computao em nuvens. Tal metodologia avaliar as mtricas obtidas nos benchmarks
executados em conjunto com a metodologia DEA, gerando pesos por meio de uma anlise da
ecincia inerente cada recurso em cada instncia. Com a obteno destas mtricas, formu-
lada uma expresso matemtica que nos aponte os nveis de desempenho globais dos recursos
do sistema.
3.1 Metodologia
O hbito de hospedar dados na nuvem j comum para muitos usurios e entusiastas,
mesmo que estes no tenham conhecimento sobre o real funcionamento da estrutura, ou como
avaliar qual a opo mais ecaz atualmente em funcionamento para utilizao. Para compreen-
dermos melhor esta tecnologia, em termos de valor agregado ao desempenho, prope-se uma
metodologia de anlise do desempenho de sistemas de computao em nuvem, que leva em
considerao os pontos crticos de hardware e rede.
Primeiramente, aps o conhecimento da infraestrutura de hardware computacional,
implementamos as MVs baseadas no modelo fornecido pela Amazon EC2 (AMAZON, 2008),
apresentado anteriormente na Tabela 1. O desempenho total destes recursos no utilizado,
visto que a virtualizao gera overheads de comunicao no gerenciamento dos recursos, fato
que ser considerado na formulao matemtica proposta na Seo 3.1.6. Aps a alocao dos
recursos necessrios para a implementao, foram instaladas as sutes de benchmark utilizadas
para a execuo dos testes.
De acordo comJain (2008), o intervalo de conana s se aplica para amostras grandes,
as quais devem ser consideradas a partir de trinta iteraes. Portanto, realizamos os experimen-
tos referentes a cada recurso de cada instncia pelo menos trinta vezes, para garantir a obteno
de um intervalo de conana satisfatrio (95%). Aps a execuo dos testes, calcula-se a mdia
e o intervalo de conana dos resultados obtidos para apresentar o alto nvel de conabilidade
dos resultados atravs dos grcos da Seo 4.2. Maiores detalhes sobre a congurao dos
41
benchmarks sero apresentados no Captulo 4.
No sistema de computao em nuvens utilizado neste trabalho, utilizaremos bench-
marks para medir o desempenho dos recursos bsicos de hardware. A m de ponderar os ex-
perimentos executados optamos pela execuo da metodologia DEA, utilizando o modelo BCC
orientado a output (BCC-O), que envolve um princpio alternativo para extrair informaes de
uma populao de resultados.
Para determinar as ecincias dos recursos analisados em cada MV, executamos a me-
todologia DEA (modelo BCC-O), determinando os pesos inerentes s MVs e recursos ana-
lisados conforme foi explicado na Seo 2.1. Utilizamos os resultados de cada iterao de
benchmark em cada MV como entrada, obtendo ndices de ecinca como resultado. Calcula-
mos a mdia ponderada a partir destes ndices, obtendo os pesos para cada benchmark. Assim,
aplicamos este procedimento na formulao que ser apresentada mais adiante na Seo 3.1.6.
Em suma, analisa-se o desempenho de uma nuvem computacional simulando o com-
portamento de aplicaes atravs da execuo dos benchmarks. A partir dos resultados obtidos,
foi feita uma anlise da ecincia, atribuindo-se pesos cada experimento. Da props-se uma
formulao que evidenciou a proporo de consumo de cada recurso da plataforma, conside-
rando os overheads associados. Com isso, espera-se poder prover uma nova viso sobre a
anlise de desempenho de sistemas de computao em nuvens.
Figura 15: Fluxograma dos Processos da Metodologia Proposta.
Estabelecemos portanto, uma ordem de execuo das atividades apresentadas nesta
pesquisa, a m de esclarecer os passos da metodologia proposta. A Figura 15 representa o pro-
cesso de avaliao do desempenho de umsistema de computao emnuvens desde a modelagem
das MVs, passando pela manipulao dos benchmarks, o tratamento estatstico, a aplicao da
metodologia DEA, at o clculo dos ndices de desempenho.
42
3.1.1 Sutes de Benchmark
Benchmarking a execuo de softwares ou operaes, para avaliar o desempenho de
um sistema ou recurso realizando experimentos, testes e simulaes que provenham mtodos
de comparao de desempenho de subsistemas de diferentes arquiteturas, gerando assim, valor
agregado aos componentes analisados.
Nesta pesquisa foram utilizadas duas sutes de benchmarks, as quais mediro o de-
sempenhos dos pontos crticos do sistema de computao em nuvens, o HPCC e o PTS. Para
que rodem de maneira consistente, os benchmarks requerem a disponibilidade da biblioteca de
comunicao de dados para computao distribuda MPI (Data Envelopment Analysis) (DON-
GARRA et al., 1992) e da biblioteca matemtica BLAS (Basic Linear Algebra Subprograms)
(LAWNSON et al., 1979), as quais utilizamos nos testes executados.
3.1.2 HPCC - High Performance Computing Challenge
OHPCCimplantou uma viso indita da caracterizao do desempenho de umsistema,
capturando dados sob condies similares s dos sistemas reais, e permitindo uma variedade de
anlises de acordo com a necessidade do usurio nal (DONGARRA; LUSZCZEK, 2006). O
HPCC utiliza kernels computacionais reais, permitindo dados de entrada de tamanhos variveis
e tempos de execuo variante de acordo com a capacidade do sistema utilizado (DONGARRA;
LUSZCZEK, 2010).
Tanto nos testes preliminares executados localmente, como nos testes nais realizados
na estrutura de computao em nuvens, cada um dos testes compreendidos nesta sute obtiveram
resultados favorveis sua utilizao, mostrando independncia e adaptabilidade para funcionar
entre os ns da nuvem. A seguir, apresentaremos os testes e suas funcionalidades.
1. HPL
O HPL (PETITET et al., 2008) um pacote de software que tem como principal caracte-
rstica a medio da taxa de execuo de ponto utuante atravs de sistemas de equaes
lineares densos e aleatrios para resoluo de matrizes. Utiliza aritmtica de preciso du-
pla (double) de 64 bits em computadores de memria distribuda, e possui um programa
de teste e temporizao para quanticar a preciso da soluo obtida, bem como o tempo
que o sistema leva para comput-la.
Sua performance vai depender de uma grande variedade de fatores. Mesmo assim, com
algumas medidas restritivas referentes rede de interconexo, permite que a execuo do
algoritmo seja escalvel. A ecincia paralela mantida constante no que diz respeito ao
uso de memria por processador.
43
2. DGEMM
a rotina principal do benchmark Linpack, sendo responsvel pela execuo de vrias
outras rotinas. Simula mltiplas execues de ponto utuante sobrecarregando o proces-
sador atravs de multiplicaes entre matrizes de preciso dupla (DONGARRA et al.,
1989). Considera a participao expressiva do buffer de memria, a partir do posiciona-
mento do ponteiro da mesma com relao distncia do incio de cada linha/coluna das
matrizes no desempenho da operao.
3. PTRANS
Normalmente chamado de Parkbench Suite, possui vrios kernels onde pares de proces-
sadores comunicam-se entre si simultaneamente, testando a capacidade de comunicao
total da rede. O PTRANS realiza multiplicao de matrizes densas e transposio de ma-
trizes paralelas (HEY; DONGARRA; R., 1996) aplicando tcnicas de interleaving.
4. FFT
Realiza a medio da taxa de execuo de ponto utuante atravs de transformadas de
Fourier discretas (DFT) unidimensionais de preciso dupla em arrays de nmeros com-
plexos (FRIGO; JOHNSON, 2007).
5. STREAM
O STREAM (MCCALPIN, 2002) mede a largura de banda de memria que sustenta a
comunicao com o processador (em GB/s). Ainda mede o desempenho de quatro ope-
raes estruturais de vetor longo. O tamanho do array denido para que seja maior do
que o tamanho da cache da mquina onde est sendo realizado o teste. Toma como par-
metro a memria de comunicao direta com o processador, privilegiando a atualizao
do buffer de memria atravs da interdependncia entre memria e processador.
6. Random Acess
O benchmark Random Acess (KOESTER; LUCAS, 2008) mede o desempenho de atua-
lizaes do buffer da memria aleatria (principal), e da memria de acesso (cache) em
sistemas multiprocessados. Ambas sustentam a comunicao entre os processadores do
sistema, direcionando esforos para o desempenho das aplicaes em execuo. O pro-
cessador bastante decisivo para o desempenho do benchmark, controlando o uxo e
favorecendo a utilizao de maiores linhas de memria.
Retorna o resultado em GUPS (Giga Updates Per Second), calculado atravs da identi-
cao das locaes de memria atualizadas em um segundo. Obtivemos a quantidade
de GUPS identicando o nmero de locais de memria que podem ser atualizados ale-
atoriamente em um segundo, onde uma atualizao consiste em uma operao RMW
(leitura-modicao-escrita) controlada pelo buffer de memria e pelo processador.
44
7. b
e f f
O Bandwidth Efciency mede a ecincia da largura de banda (efetiva) de comunica-
o atravs do tempo de latncia estimado para que se processe, transmita e receba uma
mensagem padro, em sistemas computacionais paralelos ou distribudos (RABENSEIF-
NER; SCHULZ, 1999). So utilizadas mensagens de vrios tamanhos, padres e mto-
dos de comunicao diferentes, levando em considerao uma aplicao real. O tamanho
da mensagem enviada pelo benchmark vai depender da relao memria-processador de
cada instncia testada, sendo representado pelo resultado desta relao dividido por 128.
3.1.3 PTS - Phoronix Test Suite
Alm do HPCC, utilizamos outra sute de benchmarks, o PTS. Esta sute tambm foi
utilizada para possibilitar uma maior cobertura dos recursos avaliados e a m de reforar a
anlise de desempenho dos recursos previamente apresentados na Seo 1.1. Compreende mais
de 130 testes para anlise de um sistema, o que motivou a escolha inicial de um escopo maior
de benchmarks da sute PTS para a avaliao do sistema. A m de otimizar a utilizao dos
benchmarks, avaliamos a relevncia dos resultados obtidos a partir da execuo da metodologia
DEA.
Cada resultado gerado pelos benchmarks foi disposto como output no solver de pro-
gramao linear referenciado na Seo 4.4. Este solver foi utilizado para obter os ndices de
ecincia e os pesos atribudos a cada um dos benchmarks avaliados. De acordo com estes
resultados, selecionamos os testes de acordo com a sua importncia dentro do conjunto de ben-
chmarks, minimizando as possveis inconsistncias quanto s unidades de medida de cada teste.
Finalmente, os benchmarks selecionados para este trabalho foram: Loopback TCP, RAMspeed
SMP, e PostMark apresentados na Seo 3.1.3.
1. Loopback TCP Network Performance
uma simulao simples de conectividade ponto-a-ponto que mede o desempenho do
adaptador de rede em um teste de loopback atravs do desempenho do pacote TCP (LA-
RABEL; TIPPETT, 2008a). Este teste aperfeioado neste benchmark para transmitir
10GB via loopback. O dispositivo de loopback uma interface virtual de rede implemen-
tada por software completamente integrada infraestrutura de rede do sistema. Qualquer
trfego que um programa envie para a interface de loopback recebido imediatamente na
mesma interface.
45
2. RAMspeed SMP
Mede o desempenho da interao entre as memrias cache e principal de um sistema mul-
tiprocessado (HOLLANDER; BOLOTOFF, 2002). O benchmark aloca um determinado
espao de memria, e inicia um processo de escrita ou leitura utilizando blocos de dados
de 1Kb at o limite do array, vericando a velocidade das execues dos subsistemas de
memria principal e cache. Assim como as outras simulaes de memria citadas ante-
riormente, tambm depende do processamento atrelado memria, controlando o uxo
das execues repassadas ao buffer. A medio feita pela quantidade de blocos de dados
processados pela memria em GB/s.
3. PostMark
Este benchmark cria um grande pool de arquivos pequenos em constantes alteraes, a
m de medir a taxa de transaes dos workloads, simulando um grande servidor de e-
mail para Internet. O pool de arquivos de texto congurvel e compatvel com qualquer
sistema de arquivos. As transaes de criao, deleo, leitura, e anexao possuem
tamanhos mnimo e mximo xados entre 5Kb e 512Kb. Quando um arquivo criado,
o tamanho inicial do arquivo e do texto contido nele so selecionados aleatoriamente. A
deleo de arquivos simplesmente escolhe aleatoriamente um arquivo do pool, e o deleta.
O mesmo procedimento vlido para ao de leitura.
Por m, para anexar dados a um arquivo abre-se um arquivo do pool aleatoriamente,
procura-se pela parte nal deste, escrevendo uma quantidade aleatria de dados que no
ultrapasse o limite superior do arquivo. O Postmark (KATCHER, 1997) executa 25.000
transaes com 500 arquivos simultaneamente, e aps o trmino das transaes os ar-
quivos remanescentes so deletados tambm, produzindo estatstica referente a deleo
contnua destes arquivos.
Listados na Tabela 2, os benchmarks apresentados acima foram escolhidos para se-
rem utilizados no experimento aps simulaes locais, na estrutura de nuvem, e simulaes de
ecincia relativa atravs da metodologia DEA. Nenhum teste da sute HPCC foi descartado,
sendo todos de fundamental importncia para a anlise de desempenho quantitativo e qualitativo
deste trabalho. Os resultados sempre foram coesos, de fcil manipulao, e com terminologias
compatveis.
A sute PTS apresentou alguns problemas de terminologia, impossibilitando sua utili-
zao por falta de uma referncia no hardware analisado. Outros problemas surgiram quanto
similaridade dos resultados das simulaes realizadas na sute HPCC, o que apresentaria dupli-
cao destes. E por ltimo, observamos atravs da metodologia DEA que alguns benchmarks
no possuam ecincia relevante em alguns resultados, que no foram to satisfatrios no sis-
tema de computao em nuvens quanto quando executados localmente.
46
RECURSO BENCHMARK UNIDADE DE MEDIDA
CPU
HPL GFLOPs
DGEMM
PTRANS
FFT GB/s
MEM
STREAM GB/s
RAM Speed SMP
Random Access GUPS
STO PostMark Transaes/s
NET
b
e f f
s
Loopback TCP s
Tabela 2: Benchmarks utilizados por Recurso, e suas respectivas Terminologias.
RECURSO OVERHEAD (%)
E/S
Memria 40
Rede 30
Storage 25
CPU Processamento 5
Tabela 3: Overheads de Virtualizao (HUBER et al., 2011).
3.1.4 Recursos
Para simplicar a organizao da anlise do desempenho dos recursos de uma estru-
tura de computao em nuvens, podemos divid-los em dois grupos de requisitos: recursos de
CPU e de E/S. Estudos de desempenho utilizando benchmarks gerais, mostram que o overhead
devido virtualizao de recursos de CPU tem taxa em torno de 5% conforme mencionado
na Seo 2.2.3. Dentre os recursos bsicos de uma infraestrutura de computao em nuvens o
processamento representa um consumo menor do que o esperado, pois hospeda o hypervisor
diretamente controlando o hardware e gerenciando os sistemas operacionais vigentes, conse-
quentemente apresenta um overhead menor. A virtualizao tambm impe overheads aos
recursos de E/S (memria, Internet, e armazenamento) (HUBER et al., 2011) conforme mostra
a Tabela 3.
Aplicaes de nuvem possuem requerimentos especcos, de acordo com o seu obje-
tivo principal. Presente de forma crtica em todas estas aplicaes, a rede determina a veloci-
dade com a qual o restante dos recursos de E/S vo trabalhar. Em outras palavras, a rede deve
prover capacidade, disponibilidade, e ecincia suciente para alocar recursos sem maiores
atrasos. Como foi explicado no Seo 2.1, computao em nuvens um sistema de computao
de Internet, portanto, criticamente dependente do funcionamento da rede, servio que deve ser
mantido operante (zero downtime) e transparente ao usurio. Os recursos de E/S representam a
maior parcela do consumo total da infraestrutura.
47
Uma das aplicaes mais populares hoje em dia o armazenamento de contedo on-
line, onde o usurio pode acessar contedo de qualquer lugar do mundo com conexo Internet.
Alm deste servio, blogs, e-mails, servios de compartilhamento de fotos e vdeo, e aplicativos
de edio de textos, planilhas, e apresentaes, so servios em que o armazenamento em disco
(storage) afetado, e tem um consumo signicativo com relao ao sistema como um todo.
O desempenho dos recursos de armazenamento so to dependentes da taxa de atualizao do
buffer de memria, quanto da taxa de processamento que alimenta o buffer.
Por ltimo, ainda com relao aos recursos de E/S, a memria o recurso mais reque-
rido pelos servios providos pela nuvem. Em sistemas distribudos, considerada uma questo
crtica, pois trabalha juntamente com o processamento na atualizao da execuo dos aplicati-
vos, das requisies do usurio, na gravao e leitura de dados que chegam atravs do adaptador
de rede ou do componente de armazenamento. Tantas funes concentradas, muitas vezes so-
brecarregam o recurso, que representa o maior gargalo de toda a infraestrutura de nuvem.
De acordo com o que foi exposto, infere-se que cada recurso de hardware disponvel
dentro da infraestrutura de computao em nuvens possui uma parcela nica referente sua
utilizao, porm apresentando interdependncias entre si. Atribumos ento, pesos baseados
na importncia de cada recurso para o funcionamento ecaz da estrutura atravs da metodologia
DEA, aps a execuo de benchmarks especcos.
3.1.5 Aplicao do DEA
A metodologia DEA foi aplicada neste trabalho a m de parametrizar os valores gera-
dos pelos benchmarks para cada recurso em cada instncia. Os termos principais para a pon-
derao requerida na formulao proposta, so gerados a partir da execuo desta metodologia,
sendo possvel parametrizar a ecincia de cada experimento executado. Para a aplicao da
metodologia DEA utilizamos o modelo BCC-O, que permite que a metodologia seja orientada a
output, j que neste trabalho as variveis de input (recursos das MVs) so xas, conforme visto
na Seo 2.1.4.
O modelo matemtico BCC-O consiste no clculo dos pesos das variveis de input
(recursos de cada MV), e output (resultados dos benchmarks). Na funo objetivo do modelo
BCC, minimiza-se a soma ponderada dos inputs (produto do valor do input pelo seu respectivo
peso), sujeito a quatro restries, apresentadas na Figura 16 e explicadas a seguir:
1. A soma ponderada dos outputs seja igual a 1 (Equao 1).
2. A subtrao entre a soma ponderada dos outputs, a soma ponderada dos inputs, e o fator
de escala (v), deve ser menor ou igual a zero (Inequao 2).
3. O peso dos outputs deve ser maior ou igual a zero (Inequao 3).
48
4. O peso dos inputs deve ser maior ou igual a zero (Inequao 4).
Figura 16: Modelo Matemtico da Metodologia DEA (BCC-O) (BANKER; CHARNES; CO-
OPER, 1984).
Ao executar o modelo visto acima em um solver de programao linear, obtem-se os
valores dos pesos. A restrio da inequao 2 ser executada para cada uma das 150 iteraes
das instncias executadas. Ofator de escala (v) vai determinar apenas se os retornos de produo
sero crescentes, decrescentes ou constantes para um conjunto de insumos e produtos. Como
os pesos foram as nicas variveis utilizadas na formulao proposta no Captulo 3.1.6, tal fator
no ser considerado neste trabalho (v = 0).
O modelo permite que os pesos sejam escolhidos para cada DMU (iteraes de MVs)
da forma que lhe for mais conveniente. Os pesos calculados devem ser maiores ou iguais a zero,
conforme as inequaes 3 e 4. Os ndices de ecincia de cada DMU tambm so calculados
pela funo objetivo. Assim, em DEA, o nmero de modelos a ser resolvido igual ao nmero
de DMUs do problema.
49
A m de obter o melhor desempenho resultante dos benchmarks (outputs) executados
nas MVs, os pesos so obtidos por meio de uma mdia ponderada de acordo com a representati-
vidade de cada teste para o sistema. Os maiores valores possuiro maiores pesos. Considerando
que cada um dos dez benchmarks foi executado trinta vezes para cada uma das cinco MVs
utilizadas, contabiliza-se 1500 iteraes. Cada uma destas iteraes teve seu respectivo peso
calculado pela metodologia DEA. Executamos um solver de programao linear para calcular
a soma ponderada dos inputs, e outputs, obedecendo s restries da metodologia.
Quanto s restries, primeiramente temos que a soma ponderada dos outputs deve ser
igual a 1, estabelecendo um parmetro para a atribuio dos pesos em cada MV. Os pesos dos
inputs e outputs devem ser maiores ou iguais a zero, pois no existem pesos negativos, impondo
uma condio de existncia. E por ltimo, a subtrao entre as somas ponderadas dos inputs e
outputs e o fator de escala, deve ser menor ou igual a zero. O fator de escala um valor relativo
ao rendimento do output, e no ser considerado neste trabalho, pois o termo que nos interessa
o peso atribudo a cada um dos outputs. O modelo permite que os pesos sejam escolhidos para
cada DMU (iteraes de instncias) da forma que lhe for mais conveniente.
3.1.6 Formulao
Um sistema de computao em nuvens possui estrutura complexa por ser distribudo,
e possuir alocao de recursos dinmica. Os recursos requeridos so alocados automaticamente
de acordo com a necessidade. Todos eles possuem um nvel de overhead padro, e um nvel
de importncia varivel de acordo com o direcionamento da aplicao hospedada no ambiente.
Para analisar o desempenho deste tipo de sistema necessria a formulao de uma expresso
matemtica que evidencie os nveis de utilizao medidos, e as interaes entre os recursos do
sistema.
Deve-se levar em considerao que a execuo dos benchmarks vo simular uma apli-
cao que sobrecarregar o recurso avaliado. Adota-se IAD
G
R
como ndice de Avaliao do
Desempenho Global por Recurso, cuja varivel assumir o valor resultante do produto entre o
ndice de Desempenho Real por recursoIDR
R
e o ndice de Avaliao de Desempenho por
Recurso em cada instncia IAD
R
j
. A Equao 3.1 apresenta a frmula matemtica do ndice
de Avaliao de Desempenho Global por Recurso:
IAD
G
R
= IDR
R
IAD
R
j
(3.1)
Temos que IDR
R
o ndice de Desempenho Real por recurso, que resulta no percentual
de funcionamento real do recurso avaliado. O termo IDR
R
calculado pela diferena entre
o desempenho terico mximo do recurso (100%), e os overheads (Ov
R
) associados para cada
50
recurso em funcionamento na estrutura de computao em nuvens, apresentados na Tabela 3. A
Equao 3.2 apresenta a frmula matemtica do ndice de Desempenho Real por Recurso:
IDR
R
= (100%Ov
R
%) (3.2)
O IAD
R
j
o ndice de Avaliao de Desempenho Mdio por recurso (R) em cada
instncia (j) utilizada no experimento, que avalia o desempenho mdio dos experimentos. O
termo calculado como mostra a Equao 3.3 por meio da mdia de cada IAD
iR
j
, que representa
o ndice de Avaliao de Desempenho do benchmark (i) por recurso (R) em cada instncia
(j). O termo calculado pelo somatrio do produto entre os pesos (U
iR
j
), obtidos atravs da
metodologia DEA para o benchmark (i) por recurso (R) em cada instncia (j), e os valores
(X
iR
j
) obtidos atravs do benchmark (i) por recurso (R) em cada instncia (j) como mostra a
Equao 3.4.
IAD
R
j
= IAD
iR
j
n
j
(3.3)
IAD
iR
j
=
(U
iR
j
X
iR
j
) (3.4)
U
iR
o peso do benchmark (i) atribudo ao recurso (R). E X
iR
o valor obtido atra-
vs do benchmark (i) atribudo ao recurso (R). O termo n a quantidade de MVs em que os
benchmarks executados foram hospedados para cada recurso (R), ou seja, as cinco MVs imple-
mentadas com base no modelo da Amazon EC2, apresentadas na Tabela 5 no prximo captulo.
Procuramos reunir os experimentos que simulassem mais elmente as tarefas processadas por
um sistema de computao em nuvens de maneira geral, atendendo s demandas do sistema.
Conjuntos Descrio
j = {m1.small, c1.medium, m1.large, m1.xlarge, c1.xlarge} Instncias (MVs)
R = {CPU, MEM, STO, NET} Recursos
CPU
i
= {HPL, DGEM, FFT, PTRANS} Benchmarks de Processamento
MEM
i
= {STREAM, Random Access, RAM Speed SMP} Benchmarks de Memria
STO
i
= {PostMark} Benchmarks de Armazenamento
NET
i
= {b
e f f
, Loopback TCP} Benchmarks de Rede
Tabela 4: Conjuntos dos Parmetros da Formulao Proposta
Os benchmarks foram escolhidos de acordo com o perl do ambiente a ser analisado.
Caso o perl de um outro ambiente de nuvens seja o armazenamento de dados, devem ser
escolhidos benchmarks que avaliem este recurso crtico especco da estrutura. Os benchmarks
(i) so classicados com base nos recursos avaliados, de acordo com as instncias (j) e recursos
(R) utilizados. Tais parmetros so agrupados nos conjuntos apresentados na Tabela 4.
51
As suites de benchmark foram conguradas para simularem o comportamento de cada
recurso da infraestrutura de computao em nuvens, gerando workloads entre os ns da rede.
Calcularemos o ndice de Avaliao do Desempenho dos benchmarks (i) para cada recurso (R)
em cada instncia (j), considerando a execuo de cada benchmark para seu respectivo recurso
dentro de cada instncia do experimento representada pela Equao 3.4. As expresses para
IAD
iR
j
so desenvolvidas para cada recurso da seguinte forma:
IAD
iCPU
j
= (U
HPL
x X
HPL
) + (U
DGEMM
x X
DGEMM
) + (U
FFT
x X
FFT
) + (U
PTRANS
x X
PTRANS
)
IAD
iMEM
j
= (U
STREAM
x X
STREAM
) + (U
RA
x X
RA
) + (U
RSMP
x X
RSMP
)
IAD
iSTO
j
= (U
BB
x X
BB
) + (U
PM
x X
PM
)
IAD
iNET
j
= (U
BE
x X
BE
) + (U
LTCP
x X
LTCP
)
Aps calculado o IAD
iR
j
, calcula-se a mdia dos resultados encontrados para os recur-
sos (R) em cada instncia (j), onde n o nmero de instncias (MVs) utilizadas no experi-
mento. A formulao representada pela Equao 3.3, e desenvolvida a seguir:
IAD
CPU
j
= IAD
iCPU
j
n
j
IAD
MEM
j
= IAD
iMEM
j
n
j
IAD
STO
j
= IAD
iSTO
j
n
j
IAD
NET
j
= IAD
iNET
j
n
j
De posse dos resultados obtidos a partir das execues dos benchmarks e da execuo
da metodologia DEA, foi possvel calcular o ndice de Avaliao de Desempenho dos bench-
marks (i) para cada recurso (R) em cada instncia (j) (IAD
iR
j
). Consequentemente tambm foi
possvel calcular o ndice de Avaliao de Desempenho mdio de cada recurso (R) em cada
instncia (j) (IAD
R
j
). Com base nas notaes apresentadas neste captulo, o prximo passo
consiste na resoluo da notao de desempenho global, dada pela Equao 3.1, e desenvolvida
a seguir:
IAD
G
CPU
= (IDR
CPU
) x IAD
CPU
IAD
G
MEM
= (IDR
MEM
) x IAD
MEM
IAD
G
STO
= (IDR
STO
) x IAD
STO
IAD
G
NET
= (IDR
NET
) x IAD
NET
No Captulo 4 ser descrito um estudo de caso como forma de validar a metodologia
proposta, servindo como exemplo para a compreenso da formulao. Alm disso, ainda sero
apresentadas tabelas e grcos para uma melhor visualizao dos resultados obtidos.
52
4 ESTUDO DE CASO
Este captulo apresenta o estudo de caso no qual aplicamos a metodologia proposta.
Apresentaremos o cenrio/ambiente utilizados, os experimentos realizados considerando os re-
querimentos de computao em nuvens que analisaremos no estudo, e faremos uma discusso
das simulaes realizadas.
4.1 Ambiente
As simulaes foram realizadas no ambiente de cloud disponibilizado pelo grupo
de pesquisa de segurana da informao (InSeRT) na Universidade Estadual do Cear (IN-
SERT, 2007). A infraestrutura de computao em nuvens utilizada consiste em um data center
Dell Power Edge M1000e (DELL, 2011b) (enclosure) com 4 Blade Servers M710HD (DELL,
2011c). Duas Blades possuem processador Intel Xeon Six-Core (INTEL, 2010) x5640 de
2.26GHz commemria principal de 64GB(8x8GB) DDR3 de 1333MHz; mais duas Blades com
processador Intel Xeon Six-Core x5660 2.8GHz, com memria principal de 128GB (16x8GB)
DDR3 de 1333MHz. Todas as Blades possuem 12MB de memria cache e disco rgido de
146GB SAS com taxa de transferncia de 6GBps. Neste experimento utilizaremos apenas as
Blades de maior capacidade para hospedagem e execuo dos experimentos.
O data center interligado a um Storage Dell Compellent (DELL, 2011a) com seis
discos de 600GB SAS com taxa de transferncia de 6GBPs funcionando rotao de 15.000
rpm; mais seis discos de 2TB SAS com taxa de transferncia de 6GBps funcionando rotao
de 7.200 rpm. O sistema operacional o prprio hypervisor VMware ESXi 5.0.0 rodando
em nvel 0 (abstraindo diretamente a partir do hardware). Esta abordagem otimiza tanto o
desempenho quanto o custo nal (TCO), e chamada bare-metal (vide Figura 17).
Figura 17: Abordagem de Virtualizao Bare-Metal (VMWARE, 2012).
53
MV (CPU x Core) = UC RAM ARQ.[Bits] DISCO [GB]
m1.small (1 x 1) = 1 1,7 32 160
c1.medium (2 x 3) = 6 1,7 32 350
m1.large (2 x 2) = 4 15 64 850
m1.xlarge (4 x 2) = 8 15 64 1690
c1.xlarge (7 x 3) = 21 7 64 1690
Tabela 5: MVs utilizadas no Estudo de Caso.
Para o nosso experimento, criamos ambientes homogneos de 1 a 21 cores (ECUs) ba-
seados em cinco instncias Amazon EC2. A partir da implementao destas MVs apresentadas
na Tabela 5, optamos pela utilizao do sistema operacional de cdigo-aberto Linux Ubuntu
11.10 em cada uma das cinco instncias criadas. Para possibilitar a execuo dos experimentos
propostos, foram instaladas as sutes de benchmark referenciadas na Seo 3.1.1, as quais tem
como requisito fundamental, a instalao das bibliotecas matemticas BLAS e OpenMPI para
que possam trabalhar em um ambiente de Computao Distribuda.
4.2 Execues dos Benchmarks
Como foi exposto na Seo 3.1.4, especicamente na Tabela 3, a representatividade
do overhead operacional dos recursos para um sistema de computao distribuda fundamen-
tal para avaliar o desempenho da infraestrutura como um todo. Para tal, foram executadas
simulaes de desempenho (benchmarks) dos recursos essenciais que compem o sistema de
computao em nuvens a m de gerar valor para a formulao da metodologia proposta no
Captulo 3. Todos os valores sero dados em percentuais atravs de comparao com os picos
tericos de cada recurso.
Ao executar a sute de benchmarks HPCC, houve primeiramente a necessidade de con-
gurar seu arquivo de entrada, para que as simulaes se ajustem ao tamanho do problema
que queremos, e consequentemente, tambm no sobrecarreguem o sistema com capacidades
de workloads que provoquem buffer overow. A seguir veremos os campos principais para
congurao do arquivo de entrada hpccinf.txt e em seguida o seu contedo.
1. TAMANHO DO PROBLEMA (Dimenso da Matriz N)
Para que se possa medir o melhor desempenho do sistema, deve-se congurar um maior
tamanho de problema possvel. Porm, se o tamanho do problema for muito grande o de-
sempenho cai, o que requer sensibilidade no momento do ajuste do benchmark, para que
o sistema no interra negativamente na execuo do mesmo. A quantidade de memria
utilizada pelo HPCC praticamente do mesmo tamanho da matriz coeciente.
No caso, temos dois ns com 128 GB de memria cada, o que corresponde a 256 GB no
54
total. O workload cria uma matriz de tamanho representado por N
2
8 em bytes, onde
N equivale capacidade de cada n. Considerando os dois ns, temos 32 milhes de
elementos (de 8 bytes) de dupla preciso. Como temos 6 processadores por n, mltiplos
processos vo se espalhar pelos ns, e a memria alocada disponvel para cada processo
vai ser determinante. Consciente destes fatores, foram atribudos dois valores a N: 2000
e 4000.
2. TAMANHO DO BLOCO DE DADOS (NB)
O valor do parmetro NB o tamanho do bloco de dados que o sistema vai trabalhar,
tanto quanto distribuio dos dados na rede como para a granularidade computacional.
Quanto menor o seu valor, melhor o balanceamento de carga. Por outro lado, um valor
muito pequeno de NB limita o desempenho computacional, pois quase no haver reu-
tilizao de dados em uma alta utilizao de memria. O melhor valor atribudo a este
parmetro varivel, dentro do intervalo de 32 a 256. Foi prefervel deixar o valor padro
(80), para que no houvesse problemas de desempenho.
3. GRADES DE PROCESSOS (P x Q)
De acordo com as especicaes denidas anteriormente, atribui-se valores a P e Q, que
trabalharo como linha e coluna da matriz (N) e do bloco de dados (NB) dimensionados.
Denido o nmero de grades de processamento (4), temos que P e Q devem ser valores
aproximados, portanto atribumos 1x3, 2x1, 3x2, e 2x2.
Figura 18: Arquivo de Congurao do HPCC hpccinf.txt
.
55
4.2.1 Desempenho de CPU
Para este recurso teremos apenas os benchmarks HPL, DGEMM, FFT, e PTRANS
representando o HPCC. A sute PTS apresentou problemas de terminologia, e ecincia rela-
tiva; impossibilitando a parametrizao dos resultados obtidos, e produzindo resultados no to
relevantes no sistema de computao em nuvens quanto aqueles executados localmente.
Dentre as MVs utilizadas, temos que a c1.xlarge possui mais unidades computacionais
(21), o que nos leva a crer que esta dever obter melhor desempenho em meio s outras MVs.
Porm, cada benchmark tem sua peculiaridade, e no somente analisa o desempenho do pro-
cessamento, como tambm analisa a sua interdependncia e equilbrio para com os recursos de
memria.
Cada um dos experimentos tem como objetivo a execuo de instrues complexas,
am de sobrecarregar a CPU, simulando uma grande demanda de processos. Os resultados
destes experimentos so dados em GFLOPs e GB/s, tendo como referncia o desempenho de
pico para este processador em ambos os casos. De acordo com (INTEL, 2010) estes valores so
de 67.2 GFLOPs e 6.4 GB/s respectivamente. Portanto, quanto maiores os resultados obtidos,
melhor. O valor em GFLOPs ainda pode ser calculado levando em considerao trs parmetros
principais:
1. Nmero de FLOPS/ciclo.
Para o processador utilizado no experimento, este valor igual a 4 (SUGREE, 2007).
2. Frequncia de Clock em GHz.
Conforme exposto na Seo 4.1, este valor igual a 2,8GHz.
3. Nmero de Cores por Processador.
Este valor igual a 6.
O benchmark HPL vai executar mltiplas operaes de ponto utuante atravs de um
sistema de equaes lineares. Conforme executada a simulao, foi vericado que este seguiu
a lgica de concentrao de processamento (melhor desempenho para uma quantidade maior
de processamento proprietrio da MV). Como podemos visualizar no grco da Figura 19, o
melhor resultado foi obtido na MV c1.xlarge que possui maior poder de processamento. Foram
alcanados 18,48 GFLOPs, que equivale a 27,5% do desempenho de pico terico.
Consequentemente, as outras MVs tiveram desempenho relativo quantidade de uni-
dades processamento atreladas. A nica ressalva da anlise do HPL diz respeito MV m1.large
(4UC), que apresenta desempenho no consistente ligeiramente maior que a VM c1.medium
(6UC). Tal fato no pode ser determinado de maneira exata, pois a virtualizao pode introduzir
ganhos de desempenho criando um novo nvel de cache sobre o hypervisor.
56
0
2
4
6
8
10
12
14
16
18
20
m1.small c1.medium m1.large c1.xlarge m1.xlarge
G
F
L
O
P
s
CPU
HPL
DGEMM
FFT
Figura 19: HPCC Benchmark (CPU): HPL x DGEMM x FFT (GFLOPS)
O benchmark DGEMM tambm simula mltiplas operaes de ponto utuante, so-
brecarregando o processador atravs da multiplicao de matrizes de preciso dupla. Possui
participao expressiva do buffer de memria, controlando o uxo de dados. Observa-se ento
no grco da Figura 19, que o melhor desempenho encontrado entre as MVs foi em c1.medium
(8,9 GFLOPs), equivalente a 13% do desempenho de pico. A MV em questo, possui uma
relao processador/memria mais alta que todas as outras (6 UC/1,7 GB).
Como mantivemos a cache xa, somente a MV c1.xlarge, que tambm possui uma alta
relao processador/memria (21 UC/7 GB), consegue um resultado mais prximo. Uma MV
de menor custo (c1.medium) atingindo um desempenho superior a todas as outras denota uma
inconsistncia. Porm como possui menor capacidade, apesar da tima relao de equilbrio
processador/memria pode comprometer a alocao de recursos requerida para sistemas de
computao em nuvens. O restante das MVs obteve resultados insignicantes frente s MVs
citadas.
Em seguida, o grco da Figura 19 referencia o benchmark FFT, que tambm execu-
tar operaes de ponto utuante atravs de Transformadas de Fourier em arrays de nmeros
complexos. Bem como o HPL, o FFT leva em considerao a hierarquia de concentrao de
processamento. O melhor desempenho mais uma vez foi obtido na instncia c1.xlarge atingindo
3,08 GFLOPs (4,59%), resultado similar MV m1.xlarge. Fato que comprova que o experi-
mento mais uma vez privilegia o equilbrio da relao entre memria e processador das MVs,
tornando o buffer de dados o principal responsvel pelos resultados similares encontrados. O
restante das MVs obedeceu a hierarquia de processamento.
Observamos no grco da Figura 20 os resultados do benchmark PTRANS atravs da
57
0
0.5
1
1.5
2
2.5
3
G
B
/
s
CPU
PTRANS
Figura 20: HPCC Benchmark (CPU): PTRANS (GB/s)
transposio de matrizes paralelas e multiplicao de matrizes densas, aplicando interleaving.
O melhor resultado foi atingido pela instncia m1.xlarge (8 UC/15 GB) com 2,53 GB/s, que
equivale a 39% do desempenho de pico. Nota-se novamente que o experimento considera o
equilbrio entre memria e processador, acessando vrios locais de memria adjacente entre os
processadores (ns) da rede. Logo em seguida, a instncia c1.xlarge atinge 2,46 GB/s (38%),
um resultado bastante similar que remete relao processador/memria. Um resultado justo
e devidamente justicado, logo que o benchmark estabelece a medida do real "contato"entre
memria e processadores.
As MVs implementadas no sistema so baseadas nas instncias da Amazon EC2, e
classicadas quanto o seu tamanho e preo. Logo, podemos inferir que as instncias de maior
capacidade, as quais tambm so as de maior custo, so as mais recomendadas para um maior
desempenho de processamento, salvo excees de inconsistncia, porm deve-se averiguar com
cuidado a relao entre memria e processador para que no haja inconsistncia no processa-
mento de dados. Uma MV com capacidade de memria dspar em relao de processamento,
pode acarretar scrambling ou buffer overow. Ao adquirir alguma MV entre estas, o usurio
que possui aplicaes crticas de processamento ter realmente o que lhe prometido.
4.2.2 Desempenho de Memria
A questo da memria em sistemas distribudos crtica. Os experimentos tem como
objetivo avaliar o desempenho da memria, parametrizar os nveis de cache presentes no pro-
cessamento, medir a largura de banda e as taxas de atualizao do buffer de memria. Para
tanto, levaremos em considerao o valor de pico atingido pelo servidor Blade utilizado no
58
trabalho, que de 32 GB/s (DELL, 2011c).
Quanto s MVs utilizadas, as pertencentes famlia m1 possuem maior concentrao
de memria (15 GB), o que nos leva a crer que estas devero obter melhor desempenho em
meio s outras MVs. Porm, cada benchmark tem suas peculiaridades. Cada um deles no
analisa somente o desempenho da memria, como tambm verica a interdependncia com o
processamento, recurso essencial para o funcionamento do sistema. Quanto aos benchmarks
pertencentes sute HPCC, temos que o STREAM medir a largura de banda de memria que
sustenta a comunicao com o processador, pois toma como parmetro a memria de comuni-
cao direta com este.
5
6
7
8
9
10
11
12
13
14
15
G
B
/
s
Memria
STREAM
Figura 21: HPCC Benchmark (Memria): STREAM (GB/s)
Podemos inferir que este privilegia a atualizao do buffer de memria atravs da re-
lao memria/processador durante o experimento. Conforme o grco 21, visualizamos que
a MV m1.large (15 GB/4 UC) atingiu o melhor desempenho da simulao (14 GB/s), obtendo
43% do desempenho de pico. As instncias de maior capacidade (.xlarge) aparecem em se-
guida, com 41% e 37% cada.
Teoricamente podemos destacar tanto m1.large quanto a m1.xlarge (15 GB/8 UC)
como os melhores resultados, apesar de bastante prximos. Porm, a instncia c1.xlarge (7
GB/21 UC) apresenta uma inconsistncia (j que possui resultados melhores que m1.xlarge),
aqui justicada por possuir um nmero de processadores muito superior a qualquer outra ins-
tncia. Assim, c1.xlarge requer uma maior largura de banda de memria, paralelizada entre os
processadores, superando os 15 GB de sustentao da MV m1.xlarge; entretanto, no supera a
relao memria/processador de m1.large. O restante das MVs possui resultados distantes das
instncias maiores.
59
A relao custo-benefcio neste caso, algo difcil de parametrizar, pois as instncias
mais caras foram superadas por uma instncia de preo mdio. Mas necessrio observar, con-
tudo, que o desempenho da MV vai depender do equilbrio dos recursos crticos. Para uma
aplicao que necessite de bastante largura de banda de memria necessrio um processa-
mento que supra as necessidades do buffer.
Em outras palavras, quanto maior a relao memria/processador, melhor; salvo ex-
cees em que a capacidade de processamento supera em muito a capacidade de memria,
gerando overow.
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
G
U
P
s
Memria
Random Access
Figura 22: HPCC Benchmark (Memria): Random Access (GUPs)
O Random Access um benchmark da sute HPCC que mede o desempenho de atuali-
zaes do buffer da memria aleatria (principal) e da memria de acesso (cache) em sistemas
multiprocessados. Observa-se no grco da Figura 22 que as duas instncias maiores (*.xlarge)
atingiram uma taxa maior de atualizaes (GUPS) em relao s outras instncias, ambas em
torno de 0,015 GUPS, o que equivale a 11% do desempenho de pico (1,3 GUPS).
Mesmo com uma capacidade de memria menor do que a MV m1.xlarge, a MV
c1.xlarge possui uma taxa levemente superior, o que refora a explicao de que o processa-
dor decisivo quanto ao desempenho do benchmark, j que o primeiro controla o uxo da
memria a ser utilizada pelas aplicaes. Assim, o restante dos resultados segue descendente
conforme a capacidade de processamento.
A relao custo-benefcio mostra as duas instncias mais caras atingindo o maior resul-
tado, o que perfeitamente normal. A instncia c1.medium, apesar de ser mais barata, possui
um desempenho superior m1.large, denotando uma inconsistncia. Este fato justicado
tanto pela capacidade computacional como pela relao memria/processador da primeira ser
60
superior da ltima. A MV m1.large representa alta probabilidade de scrambling.
Partindo para a sute de benchmarks PTS, verica-se no grco da Figura 23 que a taxa
de atualizao do buffer do benchmark RAM Speed SMP se mantm praticamente constante,
independentemente do tipo do blocos de dados ser Integer ou Float. O maior resultado atingido
por meio da instncia c1.xlarge com 9 GB/S e 10 GB/s para Float e Integer respectivamente.
Esta MV no possui a maior concentrao de memria entre as MVs, mas possui maior poder
de processamento dentre todas, permitindo um controle maior do uxo dos blocos de dados
passantes pelo buffer de memria.
0
2000
4000
6000
8000
10000
M
B
/
s
Memria
RAM Speed Float
RAM Speed Integer
Figura 23: Phoronix Test Suite (Memria): RAM Speed SMP Integer x Float (MB/s)
Novamente, a questo do equilbrio de recursos fazendo a diferena nos resultados,
mesmo que mnima, pode ser justicada pelo equilbrio proporcionado pela estrutura virtuali-
zada das MVs. Mesmo que algumas possuam pouca concentrao de memria, so compensa-
das pelo controle de uxo proporcionado pelo processador e vice-versa, justicando assim, o
equilbrio dos resultados.
4.2.3 Desempenho de Disco
A sute de benchmarks HPCC no possui nenhum experimento voltado para o desem-
penho e interdependncia de disco. Utilizamos ento, a sute PTS para expor as impresses
sobre tal recurso. O benchmark que obteve os melhores resultados durante a fase de simulaes
locais foi o PostMark, que cria um grande pool de arquivos em constantes alteraes a m de
medir as taxas de transaes dos workloads, simulando um grande servidor de e-mail para In-
ternet. Temos que o desempenho de pico terico de 6 TB/s (DELL, 2011c), e o teste divide
o bloco de transferncia em 500 arquivos de at 512 Kb; o que resulta em um valor de pico em
61
torno de 24000 Transaes/s.
Observando a Figura 24, percebe-se trs resultados praticamente similares, o que nos
mostra apenas que as maiores instncias produzem os maiores resultados, onde foram proces-
sados com sucesso apenas 14% dos workloads da simulao. Tal percentual nos d valores em
torno de 3.500 transaes por segundo. A instncia m1.large porm, possui bem menos capa-
cidade de armazenamento que as instncias *.xlarge mesmo mantendo um resultado bastante
satisfatrio devido sua alta capacidade de buffer disponibilizada pela alta concentrao de me-
mria. Mais uma vez observa-se que o equilbrio das MVs determinante para o desempenho
do benchmark.
0
500
1000
1500
2000
2500
3000
3500
T
r
a
n
s
a
e
s
/
s
Disco
PostMark
Figura 24: Phoronix Test Suite (Storage): PostMark (Transaes/s)
Podemos inferir que o desempenho de disco bastante dependente primeiramente da
taxa de atualizao do buffer de memria, e em seguida da taxa de processamento que alimenta
este buffer. Verica-se que as instncias que possuem maior poder de armazenamento tiveram
sempre resultados timos, porm uma MV com metade desta capacidade conseguiu resultados
similares apenas contando com um bom desempenho da relao de equilbrio entre memria e
processamento.
4.2.4 Desempenho de Rede
Os benchmarks de rede so executados levando em considerao o desempenho do
acesso aos recursos interconectados, ou seja, a capacidade da rede de prover recursos sem atra-
sos ou maiores complicaes que comprometam a disponibilidade do servio em tempo-real.
Na sute HPCC, temos o benchmark b
e f f
que mede o tempo de latncia estimado para que se
processe uma mensagem-padro, considerando a largura de banda da rede emsistemas paralelos
62
e/ou distribudos.
Calculando os tamanhos das mensagens para cada MV, observa-se no grco da Figura
25 que as instncias m1 carregaro as mensagens de tamanho maior. Como o fator rede
bastante aleatrio devido s diversas conguraes possveis de implantao, atribuiremos um
percentual relativo a cada resultado obtido com relao a um padro, onde foi estabelecido que
o desempenho timo gira em torno de 0,7s, e o pior em torno de 100ms.
0
5
10
15
20
25
30
35
s
Rede
B
Eff
0
1
2
3
4
5
6
7
8
c1.medium m1.large c1.xlarge m1.xlarge
0
20
40
60
80
100
120
S
e
g
u
n
d
o
s
Rede
Loopback TCP
Figura 25: HPCC Benchmark (Rede): b
e f f
(s) x Loopback TCP (s).
A instncia mais afetada pelo tamanho da mensagem a ser transferido foi a m1.small,
que possui a menor capacidade de processamento dentre todas as MVs. Mesmo assim obteve
um resultado (26,8s) que no compromete o funcionamento ecaz da rede, pelo contrrio, um
desempeho muito bom (98,2%) apesar de ser o menor entre os experimentos realizados. As
demais MVs so menos afetadas pois possuem capacidade de processamento suciente para
lidar com a demanda gerada pelo benchmark.
A MV m1.large obteve um resultado atpico, levando em considerao sua alta ca-
pacidade de memria. Contudo, este resultado justicado pelo seu poder de processamento
relativamente baixo, que provoca scrambling dos dados no buffer, tornando a operao mais
lenta. Nada que comprometa o funcionamento ecaz do sistema, porm impactou negativa-
mente no resultado nal da simulao especicamente para esta MV. Portanto, podemos dizer
que quanto maior o buffer de E/S, melhor o desempenho de rede.
Na sute PTS, temos o benchmark Loopback TCP Network Performance que nada mais
que uma simulao de conectividade ponto-a-ponto que vai medir o desempenho do adaptador
de rede atravs do pacote TCP em um teste de loopback. O experimento especialmente con-
gurado para transmitir 10GB via interface de loopback. Como j foi justicado inicialmente,
estabelecemos que o desempenho timo gira em torno de 25s, e o pior em torno de 120s.
Mais uma vez a relao memria-processador dene as instncias com melhor desem-
penho, pois controla o uxo de pacotes transmitidos atravs da rede. As instncias de menor
porte tiveram um desempenho inferior s demais, pois no possuem capacidade de memria su-
63
ciente para manipular os 10GB gerados pela interface de loopback, levando mais tempo para
tranfer-los atravs da rede. Assim, podemos inferir que o desempenho da rede tambm est
ligado relao memria-processador, que vai funcionar como um controlador do uxo dos
pacotes provenientes da rede.
4.3 ndices dos Benchmarks
Aps a execuo de cada um dos benchmarks analisados, elaboramos a Tabela 6 com
os ndices de ecincia relativos ao desempenho mximo terico de cada um dos experimentos
realizados. Foi feito tratamento estatstico destes valores, calculando seu percentual de ecin-
cia, a m de utiliz-los na formulao proposta. A tabela apresentada a seguir.
BENCHMARKS m1.small c1.medium m1.large m1.xlarge c1.xlarge
CPU
HPL 4,64% 11,27% 14,84% 24,81% 27,51%
DGEMM 1,15% 13,27% 4,30% 8,54% 11,08%
FFT 0,94% 3,62% 2,49% 4,52% 4,59%
PTRANS 6,83% 27,86% 14,71% 39,63% 38,52%
MEM
RAMSpeed
SMP/Integer
22,01% 28,38% 25,7% 30,4% 30,77%
RAMSpeed
SMP/Float
24,46% 28,96% 26,30% 27,13% 31,36%
STREAM 19,53% 28,27% 44,02% 37,53% 41,36%
RandomAccess 0,41% 9,82% 3,73% 17,3% 17,6%
NET
b
e f f
98,2% 99,9% 98,8% 99,5% 99,4%
Loopback TCP 0,58% 62,07% 92,65% 94,34% 96,02%
STO PostMark 3,75% 4,42% 13,99% 13,00% 14,26%
Tabela 6: Resultados obtidos atravs dos Benchmarks para cada MV (X
iRj
).
4.4 ndices do DEA
A m de ponderar os experimentos executados na Seo 4.2 optamos pela execuo
da metodologia DEA, utilizando o modelo BCC-O, orientado a output. Tal metodologia pro-
picia a anlise da ecincia comparativa de organizaes complexas obtida pela revelao do
desempenho de outras unidades, de modo que a referncia no obtida apenas terica ou con-
ceitualmente, mas por meio da observao das melhores prticas.
O modelo BCC consiste, alm do clculo do ndice de ecincia, no clculo dos pesos
das variveis de output (benchmarks). Assim, minimiza-se a soma ponderada dos inputs divi-
dida pela soma ponderada dos outputs da DMU em questo. Aps a manipulao dos dados
com a metodologia DEA BCC-O, foram atribudos pesos a cada benchmark, por meio de um
64
solver, considerando cada instncia de acordo com sua inuncia nos resultados obtidos pelos
benchmarks apresentados na Tabela 6.
A Tabela 7 mostra os pesos obtidos atravs da metodologia DEA, que parametrizaro o
desempenho de cada recurso atrelado a cada benchmark em cada MV. Neste estudo de caso foi
apresentada a infraestrutura utilizada no trabalho, o cenrio proposto, os experimentos realiza-
dos, as discusses de avaliao sobre os resultados obtidos pelos benchmarks, e a utilizao de
um mtodo matemtico para qualicar os resultados de acordo com sua ecincia. No prximo
Captulo, os resultados obtidos atravs da aplicao da metodologia de formulao proposta
sero apresentados e discutidos.
BENCHMARKS m1.small c1.medium m1.large m1.xlarge c1.xlarge
CPU
HPL 0,77 0,13 0,66 0,28 0,51
DGEMM 0,88 0,42 0,23 0,29 0,20
FFT 0,003 0,58 0,25 0,5 0,58
PTRANS 0,15 0,32 0,07 0,33 0,43
MEM
RAMSpeed
SMP/Integer
0,38 0,78 0,17 0,42 0,37
RAMSpeed
SMP/Float
0,46 0,96 0,3 0,68 0,65
STREAM 0,14 0,18 0,67 0,33 0,61
RandomAccess 0,91 0,93 0,37 0,73 0,56
NET
b
e f f
0,42 0,59 0,48 0,55 0,43
Loopback TCP 0,24 0,43 0,33 0,28 0,48
STO PostMark 0,57 0,24 0,19 0,42 0,62
Tabela 7: Pesos atribudos aos Recursos para cada MV (U
iRj
).
65
5 RESULTADOS E DISCUSSO
Este captulo apresenta os resultados e a discusso relativa s simulaes realizadas a
partir dos benchmarks executados. Atribuiu-se percentuais aos desempenhos dos benchmarks
como pode ser observado na Tabela 6. Como cada experimento tem um foco especco, os
recursos tero taxas de desempenho variadas de acordo coma sua representatividade no sistema.
Os ndices de ecincia foram calculados atravs da metodologia DEA (BCC-O), e
apresentados na Tabela 7. Aseguir, apresentaremos umexemplo a mde elucidar a metodologia
da formulao proposta, e provar a conabilidade dos resultados aqui obtidos. Observa-se que
quanto mais o recurso utilizado, maior ser o peso atribudo.
A Equao 3.4, referente ao parmetro IAD
iR
j
, vai assumir valores referentes ao de-
sempenho dos benchmarks executados para cada recurso em cada instncia (X
iR
j
), levando em
considerao o peso atribudo (U
iR
j
) pela metodologia DEA a cada resultado de benchmark ob-
tido. Os respectivos valores foram apresentados anteriormente no Captulo 4, especicamente
nas Tabelas 6 e 7.
IAD
iCPU
m1.small
= (U
HPL
x X
HPL
) + (U
DGEMM
x X
DGEMM
) + (U
FFT
x X
FFT
) + (U
PTRANS
x
X
PTRANS
)
IAD
iCPU
m1.small
= (4,64 x 0,77) + (1,15 x 0,88) + (0,94 x 0,003) + (6,83 x 0,15)
IAD
iCPU
m1.small
= 3,57 + 1,01 + 0,002 + 1,02
IAD
iCPU
m1.small
= 5,6
...
IAD
iMEM
m1.small
= (U
RAM
int
x X
RAM
int
) + (U
RAM
f loat
x X
RAM
f loat
) + (U
STREAM
x X
STREAM
) + (U
RA
x
X
RA
)
IAD
iMEM
m1.small
= (22,01 x 0,38) + (24,46 x 0,46) + (19,53 x 0,14) + (0,41 x 0,91)
IAD
iMEM
m1.small
= 8,36 + 11,25 + 2,73 + 0,37
IAD
iMEM
m1.small
= 22,71
...
IAD
iSTO
m1.small
= (U
PostMark
x X
PostMark
)
IAD
iSTO
m1.small
= (3,75 x 0,57)
IAD
iSTO
m1.small
= 2,13
...
IAD
iNET
m1.small
= (U
b
e f f
x X
b
e f f
) + (U
LTCP
x U
LTCP
)
IAD
iNET
m1.small
= (98,2 x 0,42) + (0,58 x 0,24)
IAD
iNET
m1.small
= 41,24 + 0,13
IAD
iNET
m1.small
= 41,37
66
O clculo representado o exemplo da metodologia para calcular os ndices de de-
sempenho dos benchmarks (i) por recursos para a instncia m1.small (IAD
iR
j
). Calcula-se os
resultados apenas para a MV m1.small como exemplo, pois o procedimento se repete para as
demais instncias. A seguir os resultados obtidos a partir do desenvolvimento das expresses
(IAD
R
j
) so dispostos na Tabela 8.
MV CPU MEM STO NET
m1.small 5,6 22,71 2,13 41,37
c1.medium 18,03 67,14 1,06 85,63
m1.large 12,41 43,12 2,65 77,99
m1.xlarge 24,74 56,2 5,46 81,13
c1.xlarge 35,46 66,83 8,84 88,82
Tabela 8: ndices de Avaliao de Desempenho dos Benchmarks por Recurso em cada MVs
(IAD
iR
j
).
O clculo dos ndices de avaliao de desempenho de cada benchmark executado, para
cada recurso em cada MV implementada, nos possibilita analis-los a partir de dois aspectos
diferentes. O primeiro destaca a representatividade dos recursos, e seu funcionamento dentro
do sistema.
Observa-se no grco da Figura 26 que o desempenho de rede claramente maior que
todos os outros, sendo a memria o nico recurso que possui um ndice relativamente prximo.
Os recursos referenciados so justamente os donos dos maiores nveis de overhead destacados
na Tabela 3, justicando assim, a respectiva condio de gargalos do sistema.
0
10
20
30
40
50
60
70
80
90
CPU MEM STO NET
ndices de Desempenho dos Benchmarks por Recurso
m1.small
c1.medium
m1.large
m1.xlarge
c1.xlarge
Figura 26: Desempenho dos Benchmarks por Recurso.
67
O segundo aspecto destaca a representatividade de cada instncia implementada no
sistema. Tendo emvista que o equilbrio entre os recursos essencial para umbomdesempenho,
inferimos atravs do grco da Figura 27 que as instncias c1 possuemumdesempenho bastante
similar. Mesmo que a instncia mdia (c1.medium) possua uma capacidade de processamento
e memria bem menor que a instncia extra grande (c1.xlarge), ambas possuem uma relao
processador/memria que as permite alcanar nveis de desempenho bastante satisfatrios, de
acordo com sua capacidade individual.
O responsvel por estes alcances de desempenho o simples equilbrio entre os recur-
sos mais importantes dentro do sistema: memria e processador. O processador importants-
simo e bsico para qualquer sistema. Apesar de possuir uma taxa de overhead pequena, trabalha
em conjunto com a memria resolvendo as solicitaes de tarefas que chegam ao barramento
de E/S principal.
0
10
20
30
40
50
60
70
80
90
m1.small c1.medium m1.large m1.xlarge c1.xlarge
ndices de Desempenho dos Benchmarks por Recurso em cada MV
CPU
MEM
STO
NET
Figura 27: Desempenho dos Benchmarks por Instncia.
Aps a obteno dos ndices de avaliao de desempenho de cada benchmark execu-
tado para cada recurso em cada MV, teremos como prximo passo da metodologia proposta, o
clculo da mdia dos resultados encontrados para cada recurso (R) por MV (j) (IAD
R
j
), apre-
sentado na Equao 3.3.
IAD
CPU
= IAD
iCPU
j
= IAD
iCPU
m1.small
+ IAD
iCPU
c1.medium
+ ... + IAD
iCPU
c1.xlarge
5
IAD
CPU
= IAD
iCPU
j
= 5,6 + 18,03 + 12,41 + 24,74 + 35,46 5
IAD
CPU
= IAD
iCPU
j
= 19,24
...
IAD
MEM
= IAD
iMEM
j
= IAD
iMEM
m1.small
+ IAD
iMEM
c1.medium
+ ... + IAD
iMEM
c1.xlarge
5
IAD
MEM
= IAD
iMEM
j
= 22,71 + 67,14 + 43,12 + 56,2 + 66,83 5
68
IAD
MEM
= IAD
iMEM
j
= 51,2
...
IAD
STO
= IAD
iSTO
j
= IAD
iSTO
m1.small
+ IAD
iSTO
c1.medium
+ ... + IAD
iSTO
c1.xlarge
5
IAD
STO
= IAD
iSTO
j
= 2,13 + 1,06 + 2,65 + 5,46 + 8,84 5
IAD
STO
= IAD
iSTO
j
= 4,02
...
IAD
NET
= IAD
iNET
j
= IAD
iNET
m1.small
+ IAD
iNET
c1.medium
+ ... + IAD
iNET
c1.xlarge
5
IAD
NET
= IAD
iNET
j
= 41,49 + 85,63 + 77,99 + 81,13 + 88,82 5
IAD
NET
= IAD
iNET
j
= 75,01
Encontradas as mdias do somatrio do produto entre os Pesos (U
iR
j
) e Valores (X
iR
j
)
de cada recurso em cada instncia, partimos para o nal da formulao proposta, onde obtere-
mos o ndice de Avaliao de Desempenho Global por Recurso (IAD
G
R
) conforme apresentado
pela Equao 3.1.
IAD
G
CPU
= IDR
CPU
x IADCPU = (100 - Ov
CPU
) x 19,24 = (100 - 5)% x 19,24 = 18,28
IAD
G
MEM
= IDR
MEM
x IADMEM = (100 - Ov
MEM
) x 51,2 = (100 - 40)% x 51,2 = 30,72
IAD
G
STO
= IDR
STO
x IADSTO = (100 - Ov
STO
) x 4,02 = (100 - 25)% x 4,02 = 3,01
IAD
G
NET
= IDR
NET
x IADNET = (100 - Ov
NET
) x 75,01 = (100 - 30)% x 75,01 = 52,5
De acordo com os resultados encontrados utilizando a formulao proposta, foi pos-
svel vericar que o desempenho de rede e memria so os mais importantes para um sistema
de computao em nuvens. Mesmo que estes recursos possuam overheads de funcionamento
bastante altos, so os que possuem melhor desempenho, pois so os mais requeridos para este
ambiente, tal como mostra a Figura 28.
Cada servidor virtualizado deve possuir uma concentrao equilibrada de memria
e processamento. Quando um uxo de workloads chega ao sistema, este pr-processado e
enviado ao buffer de memria (armazenamento voltil), onde entrar numa la para que seja
devidamente processado em seguida. Caso haja muito mais memria do que capacidade de
processamento, o processador receber muitas requisies do buffer de memria , e car so-
brecarregado. E caso acontea o inverso, havendo muito mais capacidade de processamento do
que memria disponvel, teremos dois problemas passveis de se tornarem realidade.
O primeiro problema o buffer overow, onde h o estouro da capacidade da mem-
ria devido ao excesso de solicitaes de acesso enviadas pelo processador. O outro problema
a subutilizao do processador, caso o barramento de memria consiga dar conta do uxo
de solicitaes. Excetuando-se a rede, os recursos de memria e processamento praticamente
alavancam o sistema, provendo disponibilidade e capacidade to essenciais para sistemas deste
porte. Os recursos de rede e memria raticam sua condio de gargalos do sistema; seja pelos
69
0
20
40
60
80
100
CPU MEM STO NET
Recursos
ndice de Desempenho dos Recursos
Figura 28: Desempenho dos Recursos (IAD
G
R
).
overheads atrelados a eles como foi apresentado em Huber et al. (2010), seja pelo seu desem-
penho como est sendo apresentado neste trabalho.
Normalmente as aplicaes de computao em nuvens cam hospedadas em uma in-
fraestrutura, porm pouco sobrecarregam os recursos de storage e processamento. Na maioria
dos casos, o hypervisor prov uma tecnologia de snapshots, para que o sistema no necessite
sicamente dos recursos. O snapshot consiste em gravaes do estado atual de uma MV, per-
mitindo uma melhor exibilidade e segurana quanto a falhas em alteraes, erros, e/ou falhas.
Neste caso, quem trabalha desproporcionalmente so os recursos de memria e rede; que ne-
cessitam manter o snapshot disponvel dentro da memria de acesso rpido para livre utilizao
dos usurios, e exvel para para ser transmitido entre os ns da rede sem atrasos signicativos
e/ou perda de dados durante o processo.
A rede essencial, tendo importncia crtica para um sistema de computao em nu-
vens, que deve estar sempre conectado por conta do alcance da entrega que o provedor do
sistema deve oferecer. Alm da questo da conectividade, podemos dizer que a velocidade da
rede vai ditar o ritmo do uxo de dados que chegam plataforma de computao em nuvens,
alocando recursos mais rapidamente. Ambas caractersticas juntas proveem a disponibilidade e
a exibilidade prometidas pelos sistemas de computao em nuvens.
O storage (capacidade de armazenamento no-voltil) um recurso passivo, que vai
receber o uxo de dados processado pelo sistema. Embora tenha sido avaliado nesta pesquisa
como menos requerido, sua utilizao pode crescer de acordo com a funcionalidade especca
da estrutura. Caso haja uma estrutura de computao em nuvens dedicada a uma aplicao
que necessite de uma grande demanda especca de armazenamento online, inferimos que a
70
utilizao deste recurso ter um crescimento bastante considervel. Porm, no ter a mesma
relevncia dos outros recursos que so a base de qualquer sistema computacional.
Deduz-se, assim, que os resultados foram consistentes em relao ao trabalho de Huber
et al. (2010), raticando a condio dos recursos de rede e memria como gargalos do sistema.
71
6 CONCLUSES E TRABALHOS FUTUROS
Com a realizao deste trabalho, pudemos concluir que as infraestruturas de compu-
tao em nuvens so ferramentas imprescindveis dentro do novo paradigma tecnolgico atual.
Com acesso mobilidade, presenciamos o boom da Internet distribuda, com contedo dis-
ponibilizado em tempo-real, e uma demanda progressiva por este contedo. Tendo em vista
o crescimento da base de usurios, e consequentemente da demanda pelos recursos da estru-
tura, fez-se necessrio o questionamento deste trabalho quanto avaliao do desempenho dos
recursos dos sistemas de computao em nuvens.
Foi possvel vericar que os benchmarks atenderam bem s necessidades de simulao
em rede, sobrecarregando os recursos interconectados de maneira eciente, retornando resulta-
dos reais. A metodologia DEA nos ajudou a analisar a ecincia de cada experimento utilizado,
provendo ndices de ecincia (pesos) para os benchmarks em cada instncia implementada, e
para cada recurso avaliado. E por m, a formulao proposta evidenciou o poder de deciso do
overhead de funcionamento de cada recurso na avaliao do desempenho global, no obstante,
as ponderaes relativas ecincia dos experimentos nortearam a avaliao das simulaes.
Conclumos, nalmente, que o desempenho dos recursos de memria e rede so os
mais importantes para uma estrutura de computao em nuvens, e por este motivo so consi-
derados gargalos do sistema. Vericamos que o desempenho da grande maioria dos recursos
aqui avaliados diretamente proporcional taxa de overhead de funcionamento, atribuda con-
forme Huber et al. (2011). Mostra-se portanto, que tanto a memria quanto a rede, alavancam
o sistema fornecendo a disponibilidade e capacidade, to importantes para os sistemas de com-
putao em nuvens.
6.1 Contribuio
Como a tecnologia de computao em nuvens um produto novo no mercado de TI,
h ainda um certo receio em migrar para este tipo de tecnologia desconhecida. O que mais
aige gestores e usurios a falta de capacidade de gesto fsica dos recursos da estrutura. H a
necessidade de saber quanto de cada recurso ser exigido pelas aplicaes em execuo e de que
maneira estes recursos inuenciaro no desempenho do sistema. As contribuies apresentadas
para este trabalho, procuram facilitar a avaliao do desempenho dos recursos principais de
hardware e rede em uma estrutura de computao em nuvens.
Neste trabalho executamos benchmarks em um ambiente de nuvens, quando normal-
mente so executados em grids. Os experimentos sofreram adaptaes apresentadas na Seo
4.2, que possibilitaram sua utilizao para o ambiente tratado neste trabalho. Outro ponto im-
portante a ser frisado, a utilizao da metodologia DEA na obteno dos parmetros de ponde-
72
rao dos benchmarks, para cada recurso em cada MV. Outra contribuio observada quanto
raticao dos recursos de memria e rede como gargalos do sistema, o que torna este trabalho
bem sucedido.
6.2 Trabalhos futuros
Propomos a metodologia presente neste trabalho, pois a gesto do desempenho dos
recursos no transparente, dicultando a compreenso dos nveis de utilizao dos recursos
fsicos da infraestrutura. A todo momento surgem questes relevantes sobre computao em
nuvens, colocando os gestores dos sistemas em cheque. Algumas destas questes fornecem a
possibilidade de elucidar a questo do desempenho dos recursos por meio de outras abordagens.
Quanto de cada recurso a ser consumido por uma aplicao comum? Ser necessria a aquisi-
o de recursos extras para comportar todo o escopo de requisies de hardware da estrutura?
Como o sistema vai se comportar durante um processo de migrao de MVs? So perguntas
que podem ser respondidas apoiadas neste trabalho, e podem ser consideradas como provveis
propostas de trabalhos futuros.
Aps a realizao deste trabalho, foi natural a percepo de que se pode realizar muito
mais com respeito ao desempenho de sistemas de computao em nuvens, em vrios nveis. Em
uma prxima oportunidade poderamos desenvolver uma aplicao para ser hospedada em um
ambiente de nuvem, avaliando a taxa de consumo, ou o comportamento da aplicao para cada
recurso. Outra abordagem, seria analisar seu comportamento durante o processo de migrao
de MVs dentro da estrutura.
Tambm seria possvel congurar o benchmark HPCC de uma maneira mais agressiva,
gerando mais blocos de dados (maior granularidade de dados), e tambm congurando um
tamanho de problema maior. Poderamos implementar esta ideia em um ambiente com mais
ns, para analisarmos a perda de desempenho causada pela sobrecarga dos recursos. Outra
proposta de trabalho a questo crtica da migrao de MVs. A questo trataria da maneira
como a migrao das MVs afetaria o desempenho, tanto de uma aplicao hospedada na nuvem,
como da infraestrutura como um todo.
A utilizao de benchmarks essencial para avaliao do processo, provendo uma in-
nidade de possibilidades a serem trabalhadas com as mais diversas maneiras de abordagem.
Devemos ento, atentar para a constante evoluo dos sistemas de computao em nuvens, des-
tacando a evoluo do comportamento dos recursos da estrutura, para tornar possvel o aprovei-
tamento da abordagem proposta neste trabalho.
73
BIBLIOGRAFIA
AMAZON. Amazon Elastic Compute Cloud EC2. 2008. Website. ltimo acesso em 25 de
junho de 2011. Disponvel em: <http://aws.amazon.com/ec2>.
ARMBRUST, M. et al. Above the clouds: A berkeley view of cloud computing. [S.l.], 2009.
BANERJEE, P. et al. Everything as a Service: Powering the New Information Economy.
Computer, IEEE, v. 44, n. 3, p. 3643, 2011.
BANKER, R.D.; CHARNES, A.; COOPER, W.W. Some Models for Estimating Technical
and Scale Ineffciencies in Data Envelopment Analysis. Management Science, JSTOR, p.
10781092, 1984.
CARDOSO, N. Virtual Clusters Sustained by Cloud Computing Infrastructures. For Jury
Evaluation, 2011.
CHARNES, A.; COOPER, W.W.; RHODES, E. Measuring the Efciency of Decision Ma-
king Units. European Journal of Operational Research, Elsevier, v. 2, n. 6, p. 429444, 1978.
DEBREU, G. The Coefcient of Resource Utilization. Econometrica: Journal of Econometric
Society, JSTOR, p. 273292, 1951.
DELL. Dell Compellent Storage Center: Self-Optimized, Powerful. 2011. Website. ltimo
acesso em 06 de fevereiro de 2012. Disponvel em: <http://i.dell.com/sites/content/shared-
content/data-sheets/en/Documents/Family-Brochure_Final.pdf>.
DELL. Power Edge M1000e. 2011. Website. ltimo acesso em 06 de fevereiro
de 2012. Disponvel em: <http://i.dell.com/sites/content/business/solutions/engineering-
docs/en/Documents/server-poweredge-m1000e-tech-guidebook.pdf>.
DELL. Power Edge M710HD. 2011. Website. ltimo acesso em 06 de fevereiro
de 2012. Disponvel em: <http://i.dell.com/sites/content/business/solutions/engineering-
docs/en/Documents/M710HD-TechGuide-10012010-nal.pdf>.
DONGARRA, J. et al. Subroutine DGEMM. 1989. Website. ltimo acesso em 19 de janeiro
de 2012. Disponvel em: <http://www.netlib.org/blas/dgemm.f>.
DONGARRA, J. et al. The Message Passing Interface (MPI) Standard.
1992. Website. ltimo acesso em 19 de janeiro de 2012. Disponvel em:
<https://mcs.anl.gov/research/projects/mpi>.
DONGARRA, J.J.; LUSZCZEK, P. Overview of the HPC Challenge Benchmark Suite. In:
CITESEER. Proceeding of SPEC Benchmark Workshop. [S.l.], 2006.
DONGARRA, J.; LUSZCZEK, P. HPCC High Performance Computing Chal-
lenge. 2010. Website. ltimo acesso em 11 de janeiro de 2012. Disponvel em:
<http://icl.eecs.utk.edu/hpcc>.
FOCHEZATTO, A. Anlise da Ecincia Relativa dos Tribunais da Justia Estadual Bra-
sileira Utilizando o Mtodo DEA. Reunin de Estudios Regionales, Badajoz, 2010.
74
FOSTER, I. et al. Cloud computing and grid computing 360-degree compared. In: IEEE.
Grid Computing Environments Workshop, 2008. GCE08. [S.l.], 2008. p. 110.
FRIGO, M.; JOHNSON, S.G. benchFFT. 2007. Website. ltimo acesso em 9 de fevereiro de
2012. Disponvel em: <http://www.fftw.org/benchfft/>.
GONCALVES, D.B.; JUNIOR, J.C.V. White Paper - Virtualizao.
2010. Website. ltimo acesso em 14 de Abril de 2012. Disponvel em:
<http://www.sensedia.com/br/anexos/wp_virtualizacao.pdf>.
HEY, T.; DONGARRA, J.; R., Hockney. Parkbench Matrix Kernel Bench-
marks. 1996. Website. ltimo acesso em 9 de fevereiro de 2012. Disponvel em:
<http://www.netlib.org/parkbench/html/matrix-kernels.html>.
HOLLANDER, R.M.; BOLOTOFF, P.V. RAMspeed. 2002. Website. ltimo acesso em 09 de
fevereiro de 2012. Disponvel em: <http://alasir.com/software/ramspeed/>.
HUBER, N. et al. Analysis of the Performance-Inuencing Factors of Virtualization Plat-
forms. On the Move to Meaningful Internet Systems, OTM 2010, Springer, p. 811828, 2010.
HUBER, N. et al. Evaluating and Modeling Virtualization Performance Overhead for
Cloud Environments. In: 1st International Conference on Cloud Computing and Services Sci-
ence. [S.l.: s.n.], 2011. p. 79.
INFORMA, Adm. Cloud Computing. Exemplos e Aplicaes Prticas. 2011.
Website. ltimo acesso em 24 de maro de 2012. Disponvel em: <http://adm-
informa.blogspot.com.br/2012/04/5-facam-uma-descricao-sucinta-de-cloud.html>.
INSERT. Information Security Research Team. 2007. Website. ltimo acesso em 24 de Julho
de 2012. Disponvel em: <http://insert.uece.br>.
INTEL. Intel Xeon Processor 5600. 2010. Website. ltimo acesso em 06 de fevereiro de 2012.
Disponvel em: <http://www.intel.com/content/www/us/en/processors/xeon/xeon-5600-vol-1-
datasheet.html>.
IOSUP, A. et al. Performance analysis of cloud computing services for many-tasks scientic
computing. Parallel and Distributed Systems, IEEE Transactions on, IEEE, v. 22, n. 6, p. 931
945, 2011.
JAIN, R. The Art of Computer Systems Performance Analysis. [S.l.]: John Wiley & Sons,
2008. 206 p.
KATCHER, J. PostMark: A New File System Benchmark. 1997.
Website. ltimo acesso em 09 de fevereiro de 2012. Disponvel em:
<http://www.netapp.com/technology/level3/3022.html>.
KOESTER, D.; LUCAS, B. Random Acess. 2008. Website. ltimo acesso em 19 de janeiro de
2012. Disponvel em: <http://icl.cs.utk.edu/projectsles/hpcc/RandomAccess/>.
LAM, C. et al. Fiber optic communication technologies: Whats needed for datacenter
network operations. Communications Magazine, IEEE, IEEE, v. 48, n. 7, p. 3239, 2010.
75
LARABEL, M.; TIPPETT, M. Loopback TCP Network Performance.
2008. Website. ltimo acesso em 09 de fevereiro de 2012. Disponvel em:
<http://openbenchmarking.org/test/pts/network-loopback>.
LARABEL, M.; TIPPETT, M. Phoronix Test Suite. 2008. Website. ltimo acesso em 11 de
janeiro de 2012. Disponvel em: <http://www.phoronix-test-suite.com>.
LAWNSON, C.L. et al. Basic Linear Algebra Subprograms for FORTRAN Usage. ACM
Transactions on Mathematical Software (TOMS), ACM, v. 5, n. 3, p. 308323, 1979.
LEHTINEN, S.; LONVICK, C. The Secure Shell (SSH) Protocol Architec-
ture. IETF, jan 2006. RFC 4251. (Request for Comments, 4251). Disponvel em:
<http://www.ietf.org/rfc/rfc4251.txt>.
LINS, M.P.E.; MEZA, L.A.; ANTUNES, C.H. Anlise Envoltria de Dados e Perspectivas
de Interao no Ambiente de Apoio Deciso. [S.l.]: COPPE/UFRJ, 2000.
MCCALPIN, J.D. STREAM: Sustainable Memory Bandwidth in High Performance
Computers. 2002. Website. ltimo acesso em 19 de janeiro de 2012. Disponvel em:
<http://www.cs.virginia.edu/stream/>.
MEIRELES, A.M.R. Uma proposta de SADpara avaliao de ecincia do poder judicirio
do estado do Cear utilizando AED. Dissertao (Mestrado) Universidade Estadual do
Cear - UECE, Fortaleza, 2012.
MOORE, G.E. et al. Cramming more components onto integrated circuits. Proceedings of
the IEEE, Institute of Electrical and Electronics Engineering, 1963, v. 86, n. 1, p. 8285, 1998.
NARASIMHAN, B.; NICHOLS, R. State of Cloud Applications and Platforms: The Cloud
Adopters View. IEEE Computer, v. 44, n. 3, p. 2428, 2011.
OPTICOMM. Fiber-Optics.Info. 2008. Website. ltimo acesso em 23 de janeiro
de 2012. Disponvel em: <http://www.ber-optics.info/ber_optic_glossary/long-
haul_telecommunications>.
OSTERMANN, S. et al. A performance analysis of EC2 cloud computing services for sci-
entic computing. Cloud Computing, Springer, p. 115131, 2010.
PARKHILL, D.F. The challenge of the computer utility. [S.l.]: Addison-Wesley Reading,
MA, 1966.
PETITET, A. et al. HPL - A Portable Implementation of the High-Performance Linpack
Benchmark for Distributed-Memory Computers. 2008. Website. ltimo acesso em 19 de
janeiro de 2012. Disponvel em: <http://netlib.org/benchmark/hpl/>.
RABENSEIFNER, R.; SCHULZ, G. Effective Bandwidth Benchmark.
1999. Website. ltimo acesso em 9 de fevereiro de 2012. Disponvel em:
<https://fs.hlrs.de/projects/par/mpi//b_eff/>.
READ, J. Cloud Harmony: Benchmarking the Cloud. 2009. Website. ltimo acesso em 16
de novembro de 2011. Disponvel em: <http://www.cloudharmony.com>.
SOSINSKY, B. Cloud computing bible. [S.l.]: Wiley Publishing, 2011.
76
SUGREE, Y. Theoretically Measuring Performance of a Computer. 2007. Website. ltimo
acesso em 24 de maro de 2012. Disponvel em: <http://www.howforge.com/theoretically-
measuring-performance-of-a-computer>.
VMWARE. Secure Your Virtual Infrastructure: Hosted vs. Bare-Metal Virtualiza-
tion Overview. 2012. Website. ltimo acesso em 09 de fevereiro de 2012. Disponvel
em: <http://www.vmware.com/br/technical-resources/virtualization-topics/security/platform-
security/overview.html>.
WARDLEY, S. Bits or pieces? A node between the physical and digi-
tal. 2009. Website. ltimo acesso em 10 de agosto de 2011. Disponvel em:
<http://blog.gardeviance.org/2009/01/terms-that-i-use.html>.
WEISS, A. Computing in the clouds. COMPUTING, v. 16, 2007.
APNDICE

T4 Leonardo Menezes

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

T4 Leonardo Menezes

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDADE ESTADUAL DO CEAR

LEONARDO MENEZES DE SOUZA

Das könnte Ihnen auch gefallen