tcc ita 1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

INSTITUTO TECNOLO´GICO DE AERONA´UTICA
Victor Gonc¸alves Elias
BENCHSTACK: UMA FERRAMENTA PARA
AVALIAC¸A˜O DE DESEMPENHO DE SERVIC¸OS
EM NUVEM
Trabalho de Graduac¸a˜o
2016
Curso de Engenharia da Computac¸a˜o
CDU 681.3.064:658
Victor Gonc¸alves Elias
BENCHSTACK: UMA FERRAMENTA PARA
AVALIAC¸A˜O DE DESEMPENHO DE SERVIC¸OS
EM NUVEM
Orientadora
Prof.a Dr.a Cec´ılia de Azevedo Castro Ce´sar (ITA)
ENGENHARIA DA COMPUTAC¸A˜O
Sa˜o Jose´ dos Campos
instituto tecnolo´gico de aerona´utica
2016
A` famı´lia, por tornar tudo poss´ıvel.
Agradecimentos
Agradec¸o aos grandes mestres que tive em toda minha vida acadeˆmica. Em especial
a` Prof.a Cec´ılia, por me acompanhar e me orientar na elaborac¸a˜o desse trabalho.
Agradec¸o tambe´m aos amigos de graduac¸a˜o do ITA por terem feito parte da minha
vida. Rechearam esses 5 anos de curso com o´timas experieˆncias e os tornaram mais
tolera´veis.
Resumo
O orquestrador OpenStack e´ um dos mais promissores sistemas operacionais de Nuvem
atuais. E´ uma ferramenta extremamente poderosa e flex´ıvel, sendo composta de diversos
mo´dulos que podem ser instalados e configurados individualmente e sa˜o responsa´veis por
tarefas espec´ıficas no data center. Por toda essa modularidade, e´ de implantac¸a˜o flex´ı-
vel mas tambe´m bastante complexa, o que torna dificil a decisa˜o por uma configurac¸a˜o
adequada. Neste trabalho, foi desenvolvida uma ferramenta de benchmarking que auxilia
nesse processo deciso´rio, fornecendo algo mensura´vel entre diferentes implantac¸o˜es, para
que administradores do sistema possam tomar deciso˜es mais orientadas sobre qual adotar.
A ferramenta desenvolvida foi enta˜o validada, mensurando-se limites de desempenho de
um servic¸o web sob diferentes configurac¸o˜es da plataforma de Nuvem.
Abstract
The OpenStack orchestrator is currently one of the most promising Cloud operating
systems. It’s an extremely flexible and powerful tool composed by several modules which
can be installed and configured separatedly and are responsible for specific tasks in the
Data Center. Because of all this modularity, it has an incredibly flexible deployment
but also incredibly complex, which makes it hard to decide on certain configurations. In
this work a benchmarking tool was developed to facilitate in this decision-making process
by providing something measurable between different deployments, in such a way that
system administrators can take more informed decisions on which configurations to make.
The developed tool was then validated by measuring performance limits of a web service
under different configurations of the Cloud platform.
Lista de Figuras
FIGURA 3.1 – Representac¸a˜o dos principais componentes do OpenStack. (OpenS-
tack Open Source Cloud Computing Software, 2016) . . . . . . . . . . . . 18
FIGURA 3.2 – Interface do MAAS listando as ma´quinas gerenciadas. . . . . . . . . 21
FIGURA 3.3 – Interface gra´fica do Juju representando servic¸os instalados e relac¸o˜es
entre eles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FIGURA 3.4 – Diagrama esquema´tico com representac¸a˜o da infraestrutura do OpenS-
tack implantada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
FIGURA 3.5 – Interface do OpenStack Horizon mostrando algumas ma´quinas vir-
tuais instanciadas na infraestrutura. . . . . . . . . . . . . . . . . . . 28
FIGURA 4.1 – Gra´fico da distribuic¸a˜o de probabilidade para distribuic¸o˜es chi-quadrado
com diferentes graus de liberdade. (Wikimedia Commons, 2010) . . . . 41
FIGURA 4.2 – Diagrama com as principais classes implementadas para o BenchStack. 42
FIGURA 5.1 – Diagrama com a representac¸a˜o generalizada do ambiente de execu-
c¸a˜o do BenchStack nos casos de teste realizados. . . . . . . . . . . . 46
Lista de Tabelas
TABELA 3.1 – Distribuic¸a˜o de hardware entre as ma´quinas f´ısicas dispon´ıveis. . . . 20
TABELA 3.2 – Distribuic¸a˜o dos charms do Juju entre as ma´quinas gerenciadas pelo
MAAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
TABELA 4.1 – Dados e estat´ısticas relativas a` gerac¸a˜o de objetos para o banco
MongoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
TABELA 4.2 – Distribuic¸a˜o de probabilidade de execuc¸a˜o de cada uma das classes
de requisic¸o˜es definidas . . . . . . . . . . . . . . . . . . . . . . . . . 39
TABELA 5.1 – Tipos das ma´quina virtuais do OpenStack utilizadas nos testes. . . . 47
TABELA 5.2 – Casos de teste montados e avaliados para validac¸a˜o da ferramenta. . 48
TABELA 5.3 – Resultados obtidos para os casos de teste apresentados. . . . . . . . 49
Suma´rio
1 Introduc¸a˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Definic¸a˜o de Hipo´tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Revisa˜o Bibliogra´fica . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Implantac¸a˜o do OpenStack . . . . . . . . . . . . . . . . . . . . 17
3.1 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Ferramentas de Apoio . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Utilizac¸a˜o do OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Ferramenta desenvolvida . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Implementac¸a˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1 PokeStack – O servidor web . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.2 BenchStack – A ferramenta de benchmarking . . . . . . . . . . . . . . 37
5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Testes Realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Discussa˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Conclusa˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Refereˆncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1 Introduc¸a˜o
O OpenStack e´ uma plataforma de software aberta e open-source para gerenciamento
de data centers e possibilitac¸a˜o ou facilitac¸a˜o do fornecimento de Infraestrutura como
Servic¸o para aplicac¸o˜es de Nuvem (do ingleˆs, “Infrastructure as a Service” ou IaaS).
O projeto foi iniciado em 2010 juntamente entre a Rackspace Hosting e a NASA, e
hoje e´ mantido pela OpenStack Foundation, uma organizac¸a˜o sem fins lucrativos formada
em setembro de 2012 com o objetivo de promover o OpenStack e sua comunidade.
O OpenStack e´ conhecido tambe´m, em outras palavras, por ser um“Sistema Operacio-
nal”ou“Orquestrador”de Nuvem, justamente por gerenciar grande parte dos componentes
e funcionalidades essenciais de um data center, como a rede, armazenamento, autentica-
c¸a˜o, telemetria, provisionamento de ma´quinas virtuais, entre outros. A sua arquitetura
e´ caracterizada por ser extremamente modularizada, com cada uma dessas funcionali-
dades principais estando isolada em um projeto separado, podendo ser utilizada ou na˜o
numa determinada implantac¸a˜o do OpenStack, dependendo das necessidades do sistema
em questa˜o.
Mais informac¸o˜es sobre a plataforma e suas funcionalidades sa˜o facilmente encontradas
na internet, bem como em outros artigos cient´ıficos publicados que fazem uma exposic¸a˜o
ou ate´ comparac¸a˜o das caracter´ısticas do OpenStack com outras plataformas de nuvem
de co´digo aberto. Um exemplo e´ (BASET, 2012), no qual e´ feita uma comparac¸a˜o de
funcionalidades
com a plataforma CloudStack, e enta˜o feito um detalhamento sobre alguns
mo´dulos do OpenStack incluindo seu funcionamento interno.
Todos esses mo´dulos diferentes expandem enormemente a gama de aplicac¸o˜es poss´ı-
veis da tecnologia do OpenStack, mas em compensac¸a˜o tambe´m complicam bastante o
processo de decisa˜o por qual configurac¸a˜o se utilizar para uma determinada implantac¸a˜o
da plataforma num determinado sistema. Na˜o so´ decidir quais mo´dulos sera˜o necessa´-
rios para uma aplicac¸a˜o espec´ıfica, como e´ tambe´m necessa´rio configurar cada um desses
mo´dulos extensivamente para o melhor comportamento no sistema em questa˜o, coisa que
nem sempre e´ fa´cil de se determinar.
CAPI´TULO 1. INTRODUC¸A˜O 13
1.1 Definic¸a˜o de Hipo´tese
A hipo´tese assumida nesse trabalho e´ de que a existeˆncia de um sistema ou ferra-
menta capaz de mensurar o desempenho de uma determinada implantac¸a˜o do OpenStack
seria de grande utilidade para facilitar na decisa˜o por uma determinada configurac¸a˜o da
plataforma.
Essa hipo´tese sera´ testada atrave´s da implementac¸a˜o de uma ferramenta de benchmar-
king e concepc¸a˜o de diversas implantac¸o˜es diferentes que demonstrem que a ferramenta
e´ capaz de realmente determinar a superioridade de determinadas configurac¸o˜es. Para
verificac¸a˜o da veracidade desta hipo´tese, paraˆmetros de desempenho sera˜o selecionados,
mensurados e seus resultados enta˜o comparados para validac¸a˜o da ferramenta constru´ıda.
1.2 Objetivos
O objetivo desse trabalho e´ de construir um componente capaz de medir o desempenho
de uma certa implantac¸a˜o de um Orquestrador de Nuvem, atrave´s da execuc¸a˜o de cena´rios
padronizados sobre a infraestrutura provisionada, fornecendo enta˜o resultados nume´ricos
compara´veis entre diferentes execuc¸o˜es desse programa de benchmarking.
A partir desses resultados nume´ricos, seria enta˜o poss´ıvel a determinac¸a˜o da melhor
configurac¸a˜o do sistema para uma determinada implantac¸a˜o da plataforma, a fim de
facilitar esse processo de configurac¸a˜o da mesma. Num cena´rio real, essas comparac¸o˜es
atrave´s da medic¸a˜o de desempenho seriam feitas pelo administrador do sistema, de modo
que pudesse escolher entre as diferentes configurac¸o˜es analisadas.
2 Revisa˜o Bibliogra´fica
Existe uma extensa literatura e estudos publicados sobre o OpenStack, sendo uma
grande quantidade deles fazendo apenas mais uma abordagem sobre a estrutura da pla-
taforma e explicando suas principais caracter´ısitcas, funcionalidades e funcionamento.
Existem tambe´m muitas comparac¸o˜es entre as funcionalidades de diferentes plataformas
de nuvem open-source, nas quais o OpenStack quase sempre esta´ inclu´ıdo dada a sua
grande popularidade.
Em (MULLERIKKAL; SASTRI, 2015), temos uma comparac¸a˜o entre o OpenStack e o
CloudStack, provavelmente a segunda plataforma mais popular nesse ramo, mas com um
foco na˜o so´ nas diferenc¸as funcionais como tambe´m no desempenho dos mesmos. Utiliza
alguns programas de benchmarking para medir o desempenho do sistema como um todo e
desempenho do sistema de entrada/sa´ıda. Conclui ainda que o OpenStack apresenta um
desempenho e uma estabilidade (e maturidade) superiores ao CloudStack, sendo apenas
mais complicado no processo de configurac¸a˜o e implantac¸a˜o, exatamente o problema que
pretendemos enderec¸ar com esse trabalho.
Outro trabalho com esse conceito e´ o (PARADOWSKI et al., 2014), que faz ainda mais
comparac¸o˜es de desempenho entre as mesmas duas plataformas (OpenStack e CloudS-
tack). Faz 6 experimentos diferentes, conduzindo ana´lises sobre o efeito do nu´mero de
CPUs, tamanho da memo´ria e do disco nos tempos de criac¸a˜o e delec¸a˜o de VMs, e ainda
do tamanho do disco na utilizac¸a˜o de CPU na ma´quina hospedeira. Mais uma vez, a
performance do OpenStack e´ destacada como superior a` do CloudStack, sendo na˜o so´
mais ra´pido como tambe´m mais esta´vel que esse u´ltimo. Nesse artigo tambe´m se destaca
a existeˆncia na verdade de poucos trabalhos fazendo ana´lises comparativas de desempe-
nho entre plataformas de nuvem (abertas ou na˜o), focando a maioria desses apenas nas
diferenc¸as de funcionalidades entre as mesmas. Fica aberta ainda a oportunidade, visto
que mesmo esse estudo na˜o chegou a fazer comparac¸o˜es entre diferentes implantac¸o˜es de
uma mesma plataforma sob diferentes configurac¸o˜es, exatamente o que se pretende fazer
nesse trabalho com o OpenStack.
Apenas para destacar e validar a nossa hipo´tese sobre a dificuldade de configurac¸a˜o do
OpenStack, temos ainda esse trabalho de graduac¸a˜o (TUFTE et al., 2014), focado exclusi-
CAPI´TULO 2. REVISA˜O BIBLIOGRA´FICA 15
vamente na implantac¸a˜o do OpenStack na infraestrutura da universidade em questa˜o. O
processo e´ ta˜o complexo e cheio de detalhes que diversos scripts foram escritos para auto-
matizar e simplificar o processo para os administradores do sistema. Alguns desses scripts
podera˜o ainda ser reutilizados (ou ao menos servir de base) nesse trabalho, auxiliando no
processo de preparac¸a˜o dos cena´rios de teste a serem executados, de forma a automatizar
o processo e deixar a aplicac¸a˜o a ser desenvolvida o mais simples poss´ıvel.
Em (ZHANG et al., 2015), temos um estudo sobre a performance do sistema de arquivos
distribuido Ceph rodando numa implantac¸a˜o do OpenStack, apesar de que sem nenhuma
menc¸a˜o a` utilizac¸a˜o do mo´dulo Cinder que ja´ possui integrac¸a˜o com esse sistema. A
instalac¸a˜o e configurac¸a˜o do mesmo parece ter sido feita manualmente, e enta˜o diferentes
programas de benchmarking sa˜o utilizados para mensurar o desempenho do sistema ainda
sob diferentes configurac¸o˜es e cena´rios. Os resultados obtidos foram bons, apresentando
um bom desempenho e boa escalabilidade do Ceph numa instalac¸a˜o do OpenStack. Esse
trabalho nos da´ ainda mais ideias de que tipos de teste incluir na aplicac¸a˜o a ser imple-
mentada, ale´m de levantar a importaˆncia de se fazerem testes desse tipo sobre diferentes
configurac¸o˜es de uma mesma plataforma, nesse caso tambe´m o OpenStack.
Num outro artigo de 2014 (SAHAI, 2014), temos mais outra ideia do que seria poss´ıvel
se mensurar para comparar diferentes configurac¸o˜es de uma mesma plataforma. Nesse
artigo, diferentes configurac¸o˜es de ma´quinas virtuais sa˜o analisadas para mensurar e pre-
ver o consumo de energia das mesmas. Em (BELOGLAZOV; BUYYA, 2015) enta˜o, temos a
implementac¸a˜o de uma framework para consolidac¸a˜o dinaˆmica de ma´quinas virtuais, resul-
tando tambe´m em economias de energia que podem ser medidas. Ale´m de implementar a
framework Neat (BELOGLAZOV, 2015), foi criado tambe´m um programa de benchmarking
utilizado para comparac¸a˜o entre diferentes algoritmos de consolidac¸a˜o de VMs. Ambos
artigos fornecem mais ideias sobre poss´ıveis testes a serem inclu´ıdos na aplicac¸a˜o proposta
nesse trabalho.
Finalmente, temos em (BENZ; BOHNERT, 2014) um estudo sobre a performance de
diferentes configurac¸o˜es do Pacemaker do OpenStack. Pacemaker e´ o pacote de alta dis-
ponibilidade e balanceamento de carga do OpenStack, responsa´vel por realizar o failover
de servic¸os que necessitam de alta disponibilidade na plataforma. E´ mensurada a me´dia
do tempo para recuperac¸a˜o sob diferentes configurac¸o˜es do pacote, e poˆde-se observar
diferenc¸as de ate´ 7.5 vezes entre diferentes configurac¸o˜es. Essa diferenc¸a e´ absurda con-
siderando que se trata de uma funcionalidade essencial e das mais importantes para um
servic¸o que deve estar sempre dispon´ıvel na nuvem, e demonstra a importaˆncia de se ter
o conhecimento e as ferramentas necessa´rias para configurar corretamente a plataforma.
Para entender um pouco mais do funcionamento interno do OpenStack (especifica-
mente do mo´dulo de
rede utilizado neste trabalho), pode-se fazer leitura tambe´m dos
artigos (SIWCZAK, 2012b) e (KIRPICHEV, 2012). Esses artigos tomam uma abordagem
CAPI´TULO 2. REVISA˜O BIBLIOGRA´FICA 16
relativamente pra´tica, mas o fazem de maneira bem orientada e instru´ıda, se destacando
de outros guias encontrados na internet por fornecerem bastante conhecimento sobre o
funcionamento do servic¸o interno do OpenStack que foi abordado. Os mesmos foram uti-
lizados de refereˆncia nesse trabalho para auxiliar na implantac¸a˜o feita do OpenStack nas
ma´quinas utilizadas, visto que teˆm um bom balanceamento entre teoria e pra´tica, como
mencionado.
Tambe´m em (SIWCZAK, 2012a), temos outro artigo no mesmo estilo, que explica um
pouco mais sobre o sub-mo´dulo Nova Network e se aprofunda mais no conceito de floating
IPs e como esses podem ser configurados numa infraestrutura utilizando esse sistema.
Esses 3 u´ltimos artigos foram de extrema utilidade na implantac¸a˜o do OpenStack durante
o desenvolvimento desse trabalho, e se destacaram pelo n´ıvel de detalhamento descritivo
sobre o funcionamento interno do nova-network, auxiliando na˜o so´ a correta configurac¸a˜o
do servic¸o mas tambe´m o entendimento do seu funcionamento interno.
Nota-se tambe´m que esses 3 u´ltimos artigos mencionados sa˜o relativamente antigos.
Isso se explica pelo fato de que o servic¸o de gerenciamento de rede utilizado nesse trabalho,
o Nova Network, hoje se encontra obsoleto, substitu´ıdo pelo mais moderno Neutron, um
mo´dulo separado do OpenStack. Esse mo´dulo mais novo necessita de uma infraestrutura
mais completa pore´m, onde mu´ltiplas ma´quinas possuam pelo menos 2 placas de rede,
o que na˜o estava dispon´ıvel para desenvolvimento desse trabalho. O Nova Network foi
suficiente para os objetivos desse trabalho pore´m, e apesar da maior dificuldade em se
encontrar material de instruc¸a˜o sobre sua instalac¸a˜o, apenas esses artigos mencionados ja´
foram de grande utilidade e quase suficientes para configurac¸a˜o completa do mesmo.
Temos ainda (CEPPI, 2014), onde e´ desenvolvido um exemplo de instalac¸a˜o e confi-
gurac¸a˜o mı´nima do OpenStack com apenas 2 ma´quinas. Esse cena´rio foi utilizado de
base para a implantac¸a˜o do OpenStack nas ma´quinas utilizadas nesse trabalho. As mes-
mas ferramentas foram utilizadas, mas dota´vamos de mais ma´quinas dispon´ıveis portanto
pudemos fazer uma implantac¸a˜o ligeiramente mais complexa.
Finalmente, como refereˆncia para o desenvolvimento de um programa de benchmar-
king, podemos citar tambe´m esse artigo (RABELER, 2016) escrito por um engenheiro da
Microsoft, descrevendo o processo de avaliac¸a˜o de desempenho utilizado pelos times do
Azure para classificar os bancos de dados oferecidos pelo seu servic¸o de Nuvem. Esse
artigo serve de exemplo de um tipo de avaliac¸a˜o de desempenho que pode ser feita para
servic¸os de nuvem, e serviu de base inclusive para a aplicac¸a˜o que foi desenvolvida com
esse trabalho. A relac¸a˜o exata de como esse tipo de avaliac¸a˜o pode ser relevante para o
contexto que estamos aplicando sera´ desenvolvida e explicada no decorrer desse relato´rio,
no cap´ıtulo referente ao desenvolvimento da aplicac¸a˜o, Sec¸a˜o 4.1.2.
3 Implantac¸a˜o do OpenStack
Para desenvolvimento desse trabalho, foi necessa´rio a princ´ıpio a familiarizac¸a˜o com
o sistema para o qual se desejava desenvolver a ferramenta de benchmarking. Montou-se
enta˜o um cluster de ma´quinas que estavam dispon´ıveis para o estudo, onde foi implantada
uma versa˜o funcional do OpenStack com a qual poderia-se fazer qualquer tipo de teste
necessa´rio para validac¸a˜o da soluc¸a˜o produzida.
A seguir vamos entrar em mais detalhes sobre a plataforma OpenStack, sobre a in-
fraestrutura dispon´ıvel para implantac¸a˜o, seguido de como esse ambiente OpenStack foi
implantado e utilizado, para enta˜o no pro´ximo cap´ıtulo descrevermos a ferramenta de
avaliac¸a˜o de desempenho implementada.
3.1 OpenStack
Como servic¸o de Nuvem utilizado para teste e validac¸a˜o da ferramenta de bench-
marking constru´ıda, decidiu-se utilizar o OpenStack, a mais popular e mais promissora
plataforma OpenSource gerenciadora de Data Centers na e´poca de elaborac¸a˜o deste tra-
balho.
Como descrito na introduc¸a˜o, o OpenStack e´ extremamente modularizado, possuindo
mo´dulos que podem ser instalados e distribu´ıdos pela infraestrutura individualmente, que
tera˜o responsabilidades individuais dentro do Data Center, das va´rias tarefas e requi-
sitos necessa´rios pela plataforma para seu funcionamento. Alguns desses componentes
principais do OpenStack sa˜o:
• Nova (computing): Mo´dulo responsa´vel pelo gerenciamento do poder computacio-
nal do cluster, seja atrave´s do provisionamento de ma´quinas virtuais ou ate´ alocac¸a˜o
de hardware “puro” para as aplicac¸o˜es (por uma API). Interopera com diversas pla-
taformas de virtualizac¸a˜o como por exemplo KVM, Xen e QEMU, e e´ o componente
mais ba´sico e principal do OpenStack.
• Neutron (rede): Sistema de gerenciamento da rede no data center, com alocac¸a˜o
de enderec¸os de IP, gerenciamento de sub-redes, LANs virtuais, etc. Pode ainda
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 18
utilizar tecnologias de redes definidas por software como OpenFlow e possui exten-
so˜es para habilitar ainda outras funcionalidades como detecc¸a˜o de intrusos na rede,
balanceamento de carga e VPN.
• Cinder (armazenamento): Fornece funcionalidade de armazenamento de dados em
blocos, ou seja, abstrac¸a˜o mais ba´sica utilizada por um Sistema Operacional. Pode
utilizar armazenamento local nas ma´quinas ou tambe´m va´rias plataformas de ar-
mazenamento diferentes (Ceph, CloudByte, IBM Storage, etc.) que va˜o habilitar
diferentes funcionalidades ou aplicac¸o˜es diferentes.
• Os 3 acima sa˜o os componentes mais importantes do OpenStack, mas existem
ainda diversos outros para outras funcionalidades de suporte (ou mais espec´ıficas),
como por exemplo: Keystone (autenticac¸a˜o), Swift (armazenameto de entidades),
Horizon (portal de gerenciamento, ou Dashboard), Ceilometer (telemetria) entre
outros.
Uma visualizac¸a˜o dos principais componentes do OpenStack descritos bem como a
forma com que eles alguns deles interagem pode ser vista na figura 3.1 a seguir.
FIGURA 3.1 – Representac¸a˜o dos principais componentes do OpenStack. (OpenStack Open
Source Cloud Computing Software, 2016)
Vamos agora descrever o hardware que estava dispon´ıvel para implantac¸a˜o dos mo´dulos
desejados do OpenStack, voltando a` utilizac¸a˜o da plataforma propriamente dita apo´s
descric¸a˜o tambe´m de como foi feita sua implantac¸a˜o.
3.2 Hardware
Para implantac¸a˜o do OpenStack e desenvolvimento e validac¸a˜o do BenchStack, esta-
vam dispon´ıveis 7 ma´quinas Dell OptiplexTM 960, cada uma com um processador Intel
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 19
Core 2 DuoTM E8400 de 3GHz (2 nu´cleos sem HyperThreading), e um disco r´ıgido de
250 GB e 7200RPM. Havia tambe´m uma disponibilidade de 11 GiB1 de memo´ria RAM
em pentes de 1 e 2 GiB a serem distribu´ıdos livremente entre as ma´quinas, e de 1 placa
de rede adicional que poderia ser alocada onde desejado (ale´m da NIC onboard na placa
ma˜e de cada uma das ma´quinas).
Enquanto esse hardware poderia ser mais que o suficiente para desenvolvimento e/ou
execuc¸a˜o de aplicac¸o˜es simples, o OpenStack e´ um sistema que foi desenvolvido para
grandes Data Centers e portanto pressupo˜e uma infraestrutura muito mais poderosa.
Ferramentas de instalac¸a˜o automa´tica do OpenStack como o Autopilot possuem requi-
sitos mı´nimos de hardware bem mais exigentes, como nesse caso espec´ıfico, ao menos 5
ma´quinas com 2 discos cada, sendo 2 delas com 2 placas de rede (so´ t´ınhamos 1 adicional).
Portanto, na˜o seria poss´ıvel
a utilizac¸a˜o dessas ferramentas de instalac¸a˜o automa´tica
mais gene´ricas devido a limitac¸o˜es do hardware dispon´ıvel. Partiu-se enta˜o para implanta-
c¸a˜o e instalac¸a˜o manual de cada um dos mo´dulos do OpenStack, utilizando algumas ferra-
mentas de facilitac¸a˜o desse processo, como sera´ explicado em detalhes a seguir. Escolheu-
se como sistema operacional para as ma´quinas o Ubuntu Server, reconhecido como o mais
popular dentre as diversas implantac¸o˜es do OpenStack mundialmente (OPENSTACK.ORG,
2016), ale´m de possuir diversas ferramentas que facilitariam toda a configurac¸a˜o da infra-
estrutura.
Foi resolvido ainda na˜o utilizar todas as ma´quinas dispon´ıveis, visto que os componen-
tes de software a serem utilizados possu´ıam requisitos relativamente exigentes de modo
que na˜o haveria hardware suficiente para instalac¸a˜o do sistema em todas as ma´quinas.
Apenas 5 das 7 ma´quinas foram utilizadas, e o disco r´ıgido de umas das ma´quina removida
do conjunto foi instalado em uma das ma´quinas utilizadas, de forma que esta pudesse ser
utilizada para o servic¸o de armazenamento do OpenStack.
Va´rias tentativas de implantac¸a˜o foram feitas tambe´m, e percebeu-se que o desem-
penho do sistema como um todo ficava bastante comprometida sempre que t´ınhamos
ma´quinas principais (com servic¸os do OpenStack) rodando com apenas 1 GiB de memo´ria
RAM. Dessa forma, o hardware dispon´ıvel foi distribu´ıdo da seguinte maneira na confi-
gurac¸a˜o final do ambiente:
Todas essas ma´quinas estavam conectadas a um u´nico Switch de alto desempenho
(1 Gigabit), e uma delas, com a placa de rede adicional que estava dispon´ıvel, conectada
tambe´m a` Internet e servindo de gateway para as outras ma´quinas do cluster, de modo
que estivessem todas conectadas entre si e a` Internet.
Essa ma´quina configurada com as duas placas de rede foi a CTL, utilizada como a
ma´quina de controle mais ba´sico e como “porta de entrada” para a infraestrutura, onde
1Usamos a notac¸a˜o de Gibibytes quando nos referimos a (210)3
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 20
TABELA 3.1 – Distribuic¸a˜o de hardware entre as ma´quinas f´ısicas dispon´ıveis.
Nome da ma´quina Placas de Rede Memo´ria Disco
CTL 2 (onboard + NIC) 1 GiB 1x250 GB
Base 1 2 GiB 1x250 GB
S 1 2 GiB 2x250 GB
C1 1 4 GiB 1x250 GB
C2 1 2 GiB 1x250 GB
na˜o foi instalado nenhum componente do OpenStack em si mas apenas o servidor (de
cluster e rack) do gerenciador mais ba´sico do hardware livre (MAAS). Por ela que era
feita a maior parte da interac¸a˜o com o cluster tambe´m.
As outras ma´quinas foram utilizadas para implantac¸a˜o do pro´prio OpenStack. A
ma´quina Base foi utilizada como base de instalac¸a˜o da ferramenta de gerenciamento de
servic¸os (Juju), ale´m de utilizada para instalac¸a˜o de alguns dos servic¸os base do OpenS-
tack. A ma´quina S ficou como “no´ de armazenamento”, sendo a u´nica com dois discos
r´ıgidos e onde foi instalado o Cinder, ale´m de alguns outros servic¸os base do OpenStack,
para desafogar um pouco a ma´quina Base. E finalmente, as ma´quinas C1 e C2 foram
utilizadas como os “no´s de computac¸a˜o”, possuindo apenas a instalac¸a˜o dos mo´dulos de
hospedagem de ma´quinas virtuais do Nova.
A seguir descreveremos essas ferramentas de apoio utilizadas e instaladas nas ma´quinas
Base e S ate´ chegar na instalac¸a˜o e utilizac¸a˜o do OpenStack em si.
3.3 Ferramentas de Apoio
Primeiramente, fez-se instalac¸a˜o da ferramenta gerenciadora de hardware, o MAAS,
na ma´quina Base. O MAAS (Metal-as-a-Service) , e´ um sistema de automac¸a˜o do geren-
ciamento de servidores f´ısicos, desenvolvido como servic¸o para administrac¸a˜o mais baixo
n´ıvel das ma´quinas de um Data Center, automatizando a detecc¸a˜o de hardware, controle
remoto do estado de cada uma das ma´quinas, boot e instalac¸a˜o de sistemas operacionais
pela rede, ale´m de servic¸os ba´sicos de configurac¸a˜o da rede interna de comunicac¸a˜o entre
as ma´quinas, podendo servir ainda de servidor interno DHCP e DNS. Configurou-se o ser-
vidor DHCP para a rede interna com a sub-rede 172.16.0.0/16, atribuindo os enderec¸os
de IP na regia˜o 172.16.2.0/24 para as ma´quinas inicializadas pelo pro´prio MAAS (no´s),
e na regia˜o 172.16.1.0/24 para outros dispositivos que entrassem na rede (como seriam
detectados tambe´m os LXC criados pelo Juju, ver na pro´xima sec¸a˜o).
O MAAS disponibiliza tambe´m uma interface web para gerenciamento simplificado que
foi utilizada extensivamente para configurac¸a˜o e gerenciamento das ma´quinas utilizadas.
Note que a pro´pria ma´quina CTL na˜o aparece na interface do MAAS, visto que o servic¸o
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 21
e´ feito para rodar numa ma´quina controladora independente que gerenciara´ apenas as
outras ma´quinas do Data Center.
FIGURA 3.2 – Interface do MAAS listando as ma´quinas gerenciadas.
Apo´s a configurac¸a˜o do MAAS, partiu-se para a instalac¸a˜o do OpenStack propriamente
dito, onde foi feito uso da outra ferramenta de gerenciamento denominada Juju, instalada
na ma´quina Base.
O Juju e´ mais uma ferramenta de gerenciamento automa´tico, focada na implantac¸a˜o
de servic¸os modularizados em infraestruturas multi-servidor (de Nuvem), ou seja, ideal
para o cena´rio e caracter´ısticas do OpenStack. Ele possui uma interface por linha de
comando e uma GUI, tambe´m por uma interface web, que pode ser instalada usando-se
o pro´prio Juju em um ambiente previamente criado pela linha de comando.
O Juju funciona por um sistema de mo´dulos independentes, nele denominado charms,
que simplificam a forma como diferentes servic¸os podem ser instalados, configurados e
relacionados entre si. O Juju e´ na˜o so´ uma ferramenta local, como tambe´m uma plata-
forma de compartilhamento desses mo´dulos, onde desenvolvedores podem criar charms
e disponibiliza´-los para que outros desenvolvedores possam importa´-los em suas pro´prias
infraestruturas gerenciadas pelo Juju.
Outro conceito sa˜o as chamadas “relac¸o˜es”, que possibilitam a interac¸a˜o entre os di-
ferentes charms instalados no sistema. Quando os charms sa˜o criados, nele se definem
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 22
algumas relac¸o˜es identificadas que podem ser satisfeitas por outros charms. Essas relac¸o˜es
podem definir por exemplo o banco de dados que algum servic¸o vai utilizar para persistir
seus dados ou, no caso do OpenStack, o servic¸o gerenciador de Identidade para prover
autenticac¸a˜o para usua´rios e servic¸os.
Ele funciona de forma abstrata a partir de uma servic¸o gerenciador de ma´qunias (f´ısicas
como o MAAS ou mesmo virtuais), bastando ser configurado apropriadamente para usar
o sistema existente. Interage perfeitamente com o MAAS, mas pode ser utilizado tambe´m
com servic¸os de Nuvem pu´blicos como o Amazon Web Services, Microsoft Azure, Google
Cloud Platform, ou ate´ mesmo o pro´prio OpenStack (seja uma Nuvem pu´blica como o
RackSpace ou uma Nuvem privada).
Os servic¸os instalados podem ainda ser instalados na ma´quina “crua” diretamente, ou
criando-se os chamados LXCs (Linux Containers), uma forma simplificada de virtualizac¸a˜o
no n´ıvel do sistema operacional, que realiza o isolamento de mu´ltiplos sistemas para uma
mesma ma´quina f´ısica utilizando a mesma Kernel do Linux. Utiliza a funcionalidade de
cgroups da Kernel do Linux que permite a limitac¸a˜o e priorizac¸a˜o individual dos recursos
do sistema como CPU, rede e I/O, ale´m de uma visa˜o isolada para cada contaˆiner do
ambiente de execuc¸a˜o, como lista de processos, interfaces de rede, etc., tudo isso sem a
necessidade de criac¸a˜o de uma ma´quina virtual propriamente dita.
Finalmente, o Juju foi enta˜o utilizado, interagindo com o MAAS previamente confi-
gurado e fazendo-se a instalac¸a˜o dos diversos
charms existentes do OpenStack, disponibi-
lizado por um time denominado de openstack-charmers. Existem charms para cada cada
um dos mo´dulos do OpenStack e instruc¸o˜es de como realizar a instalac¸a˜o dos mesmos e
suas dependeˆncias que devem ser tambe´m satisfeitas.
Na ma´quina Base que se realizou a instalac¸a˜o do ambiente Juju, que funciona tam-
be´m a partir de uma ma´quina principal dentro do Data Center que controlara´ as outras
ma´quinas vizinhas. Os diferentes charms instalados e utilizados foram:
• juju-gui : Mo´dulo que proveˆ a interface gra´fica do Juju. U´nico servic¸o implantado
diretamente na ma´quina principal onde ocorre a instalac¸a˜o do ambiente do Juju (os
outros ficam sob LXCs isolados).
• nova-cloud-controller : Mo´dulo principal do OpenStack Nova, fornecendo a API do
Nova para criac¸a˜o e gerenciamento de ma´quinas virtuais (nova-api), o “agendador”,
responsa´vel por fazer a alocac¸a˜o das ma´quinas virtuais nas diferentes ma´quinas
hospedeiras dispon´ıveis (nova-scheduler), e o “condutor”, responsa´vel por abstrair
as operac¸o˜es de acesso ao banco de dados pelos no´s de computac¸a˜o propriamente
ditos do Nova (nova-conductor).
• nova-compute: Mo´dulo do OpenStack Nova a ser instalado nas ma´quinas hospe-
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 23
deiras de ma´quinas virtuais, recebe comandos do agendador descrito acima para
criac¸a˜o das ma´quinas virtuais e sua configurac¸a˜o. Instalado diretamente (na˜o em
LXCs) nas ma´quinas f´ısicas C1 e C2 para maior desempenho.
• mysql : Banco de dados principal do OpenStack utilizado por va´rios dos mo´dulos
para persistir seus estados e configurac¸o˜es. Numa Nuvem de produc¸a˜o esse banco de
dados deve ser replicado de forma segura e altamente dispon´ıvel, visto que guarda
o estado de todo o sistema.
• glance: U´nico charm do OpenStack Glance, responsa´vel por gerenciar as imagens
de sistemas operacionais que podem ser instaladas nas ma´quinas virtuais criadas.
• keystone: U´nico charm do OpenStack Keystone, reponsa´vel pela autenticac¸a˜o de
usua´rios e servic¸os em suas interac¸o˜es com os outros servic¸os da Nuvem.
• openstack-dashboard : Mo´dulo responsa´vel pelo portal do OpenStack (denominado
Horizon), por onde a interac¸a˜o com a infraestrutura pode ocorrer.
• rabbitmq-server : Servic¸o de passamento de mensagens entre os diferentes servic¸os,
utilizado internamente pelos mo´dulos do OpenStack para comunicar-se entre si.
• cinder : Charm principal do mo´dulo Cinder do OpenStack, responsa´vel pelo forneci-
mento de armazenamento de dados como um servic¸o, atrave´s da criac¸a˜o de volumes
que podem ser enta˜o associados a`s ma´quinas virtuais para servir de discos raiz ou
discos adicionais. Pode ser ainda instalado e associado com outros charms que for-
nec¸am servic¸os mais complexos de armazenamento, o mais popular deles sendo o
Ceph . Por simplicidade, optamos por na˜o utilizar esses mo´dulos adicionais visto
que so´ possu´ıamos uma ma´quina para servic¸os de armazenamento, a denominada
S, e esse mo´dulo necessita de uma ma´quina com 2 discos r´ıgidos, sendo um deles
para instalac¸a˜o do sistema e o outro onde os volumes sera˜o criados. Esse mo´dulo
tambe´m foi instalado diretamente nas ma´quinas f´ısicas (fora de um LXC), ja´ que
precisa interagir com os discos r´ıgidos do sistema no mais baixo n´ıvel, e encontrou-se
erros ao executa´lo dentro de um contaˆiner.
• ceilometer : Charm principal do mo´dulo homoˆnimo de telemetria do OpenStack.
Esse e´ o servic¸o centralizado que gerencia o armazenamento dos dados coletados
pelos agentes individuais implantados em cada ma´quina que sera´ monitorada.
• ceilometer-agent : Agente individual do Ceilometer, implantado como um charm “su-
bordinado”. Definimos apenas uma relac¸a˜o do mesmo com o servic¸o nova-compute,
e o mesmo e´ instalado e implantado automaticamente nas mesmas ma´quinas em
que esse u´ltimo estiver instalado. Realiza as medic¸o˜es de desempenho propriamente
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 24
ditas (como uso de CPU, memo´ria, I/O etc.), enviando-as para o agente centralizado
do mo´dulo do Ceilometer que fara´ o armazenamento no banco de dados.
• mongodb: Banco de dados utilizado pelo Ceilometer para armazenamento das me´-
tricas de desempenho coletadas.
Esses mo´dulos foram instalados nas ma´quinas dispon´ıveis e suas relac¸o˜es necessa´rias
devidamente satisfeitas. Teoricamente bastaria adicionar-se as relac¸o˜es entre os mesmos
pelo Juju e os servic¸os deveriam funcionar, mas algumas configurac¸o˜es espec´ıficas foram
ainda necessa´rias nos servic¸os para configurac¸o˜es que na˜o foram devidamente abstra´ıdas
para qualquer tipo de instalac¸a˜o. Infelizmente essas configurac¸o˜es foram feitas apenas
posteriormente ao se encontrar erros tentando realizar operac¸o˜es no sistema ja´ instalado.
A interface gra´fica do Juju fornece ainda uma visualizac¸a˜o amiga´vel de como os charms
esta˜o implantados e distribu´ıdos na infraestrutura, representando cada um deles como um
no´ em um grafo e as relac¸o˜es cadastradas entre eles como arestas. Essa visualizac¸a˜o na˜o
representa como os mesmos esta˜o dsitribu´ıdos entre as ma´quinas f´ısicas pore´m, servindo
apenas para visualizac¸a˜o dos servic¸os que esta˜o instalados e as relac¸o˜es entre os mesmos,
como visto na figura 3.3.
FIGURA 3.3 – Interface gra´fica do Juju representando servic¸os instalados e relac¸o˜es entre
eles.
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 25
3.4 Utilizac¸a˜o do OpenStack
Com todos esses charms instalados e devidamente configurados, o OpenStack fornece
uma infraestrutura funcional com seus servic¸os mais ba´sicos de computac¸a˜o, armazena-
mento e telemetria. Optou-se por na˜o utilizar o mo´dulo de rede definida por software
do OpenStack, o Neutron, visto que na˜o estavam dispon´ıveis placas de rede adicionais
suficientes para todas as ma´quinas, um requisito desse mo´dulo visto que necessita de uma
rede pro´pria que possa ser gerenciada livremente. Isso gerou algumas complicac¸o˜es na
implantac¸a˜o do sistema, ja´ que o mo´dulo antigo de gerenciamento de rede do OpenStack,
o Nova Network (embutido no Nova), na˜o e´ ta˜o poderoso assim, ale´m de ser muito menos
documentado por ser considerado obsoleto. A distribuic¸a˜o dos mo´dulos entre as ma´quinas
utilizadas pode ser vista na tabela 3.2.
TABELA 3.2 – Distribuic¸a˜o dos charms do Juju entre as ma´quinas gerenciadas pelo
MAAS.
Nome da ma´quina
Charms
Diretamente (root) Sob LXCs
Base juju-gui
nova-cloud-controller, mysql, openstack-
dashboard, keystone, mongodb
S cinder glance, ceilometer, rabbitmq-server
C1 nova-compute
ceilometer-agent (na˜o num LXC, mas su-
bordinado ao nova-compute)
C2 nova-compute
ceilometer-agent (na˜o num LXC, mas su-
bordinado ao nova-compute)
Na ma´quina Base alocou-se os servic¸os de gerenciamento mais gerais do OpenStack,
inclusive os bancos de dados administrativos do ambiente. Esses sa˜o, principalmente, os
servic¸os que na˜o va˜o interagir diretamente com as ma´quinas virtuais e portanto na˜o afeta-
riam o desempenho das mesmas de forma significativa. Essa ficou sendo a ma´quina mais
sobrecarregada em nu´mero de servic¸os, mas todos eles sa˜o relativamente leves no quesito
de demanda computacional, de modo que na pra´tica ficou relativamente balanceada com
as outras.
Ja´ na ma´quina S, concentrou-se principalmente os servic¸os de armazenamento de dados
dos usua´rios/ma´quinas propriamente ditos e na˜o responsa´veis pelas operac¸o˜es gerenciais
principais do Data Center. Ale´m do Cinder, Glance e Ceilometer que se adequam a essas
caracter´ısticas, estava nela tambe´m o servidor de roteamento de mensagens RabbitMQ,
dealocado da ma´quina de gerenciamento Base para distribuir um pouco o carregamento na
mesma. Esse
servic¸o e´ relativamente leve tambe´m, portanto na˜o afeta significativamente
os outros servic¸os alocados nessa ma´quina, especialmente por terem demandas por recursos
diferentes, os outros mais de disco e este mais de rede/processamento.
Finalmente, configurou-se dois no´s denominados de “no´s de computac¸a˜o” (C1 e C2),
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 26
contendo apenas o servic¸o de hospedagem das ma´quinas virtuais propriamente ditas e o
mo´dulo de telemetria subordinado. Essas ma´quinas foram propositadamente mantidas
mais livres, visto que sa˜o as que mais teriam influeˆncia sobre o desempenho das instaˆncias
de usua´rios propriamente ditas. De forma a se obter um comportamento mais consistente
nas ma´quinas virtuais, essa alocac¸a˜o mais conservadora para esses servic¸o foi realizada.
Uma visualizac¸a˜o da implantac¸a˜o com os servic¸os e conexo˜es principais entre as ma´-
quinas representadas pode ser vista na figura 3.4.
Uma diferenc¸a fundamental dessa implantac¸a˜o em relac¸a˜o a`s que sa˜o comumente apre-
sentadas em guias ou exemplos online e´ a auseˆncia de redes dedicadas para o gerenciamento
ou acesso a` Internet, pelo mesmo motivo que na˜o foi utilizado o mo´dulo dedicado a` rede
do OpenStack: insuficieˆncia de placas de rede adicionais para as ma´quinas. Desse modo,
tanto a comunicac¸a˜o interna dos servic¸os do OpenStack, quanto a comunicac¸a˜o entre as
instaˆncias de ma´quinas virtuais e a de todos esses com a Internet e´ feita utilizando-se as
mesmas interfaces, rede e Switch internos. Esse poderia ser um problema no caso de uma
implantac¸a˜o de produc¸a˜o, onde va´rios servic¸os seriam instalados e executados simultane-
amente, mas como t´ınhamos apenas um servic¸o rodando de cada vez no sistema fazendo a
avaliac¸a˜o de desempenho, esse pode ser considerado como um na˜o-limitante para os casos
de teste realizados.
FIGURA 3.4 – Diagrama esquema´tico com representac¸a˜o da infraestrutura do OpenStack
implantada.
A interac¸a˜o com o OpenStack foi feita tanto pelo portal Horizon quanto pelas inter-
faces de linha de comando que forneciam algumas operac¸o˜es adicionais (especialmente
relacionadas ao Nova Network). A interac¸a˜o com o OpenStack na˜o foi completamente
fluida como se esperaria apo´s a obtenc¸a˜o de uma versa˜o funcional do mesmo, visto que
encontrou-se mais documentac¸a˜o e orientac¸o˜es sobre como fazer a instalac¸a˜o do OpenS-
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 27
tack do que como interagir com o mesmo apo´s uma instalac¸a˜o teoricamente funcional.
Como uma primeira contribuic¸a˜o desse trabalho, tambe´m consolidamos aqui instruc¸o˜es
para criac¸a˜o completa de uma ma´quina virtual apo´s primeira implantac¸a˜o do sistema. Os
passos necessa´rios ate´ a criac¸a˜o da primeira ma´quina virtual funcional, que na˜o foram
encontrados indicados em sua completude em lugar algum, foram:
1. Acesso ao portal Horizon e login inicialmente com a conta de administrador do sis-
tema, seguida da criac¸a˜o de um “projeto”. O projeto e´ uma abstrac¸a˜o do OpenStack
para isolamento de recursos para certos usua´rios em conjunto, para o qual podem ser
ajustados limites de acesso para a infraestrutura. Criac¸a˜o tambe´m de um usua´rio
nesse projeto para acesso na˜o privilegiado ao sistema;
2. Login com esse novo usua´rio criado, que da´ enta˜o visa˜o ao menu individual do
projeto onde as entidades da Nuvem podem ser criadas.
3. Inicialmente, pore´m, e´ necessa´rio acessar o menu de “Acesso e Seguranc¸a”, e baixar
o arquivo de credenciais para acesso a` API do OpenStack pela linha de comando;
4. De um computador que tenha acesso a` API do OpenStack (no caso da auseˆncia de
IPs realmente pu´blicos para os servic¸os, como e´ o caso da implantac¸a˜o em questa˜o),
importar o arquivo de credenciais baixado no passo anterior utilizando o comando
source da linha de comando Linux;
5. Criar uma rede no Nova Network utilizando o comando nova network-create com
opc¸o˜es de configurac¸a˜o das extenso˜es de IPs reservados e da interface de rede nos no´s
hospedeiros de ma´quinas virtuais que sera´ associada a` mesma. Como so´ t´ınhamos
uma interface de rede em todas as ma´quinas utilizadas no OpenStack, a escolha foi
o´bvia. Escolheu-se tambe´m uma extensa˜o de IPs ainda dentro da sub-rede criada
pelo servidor DHCP do MAAS, mas numa regia˜o que na˜o seria atribu´ıda para outras
ma´quinas pelo mesmo (172.16.16.0/24), de modo a na˜o existirem conflitos;
6. Usando tambe´m o comando de gerenciamento do nova, criar um pool de IPs “pu´bli-
cos” flutuantes com o comando nova-manage floating create, que dara˜o acesso
a`s ma´quinas virtuais criadas para fora da ma´quina hospedeira. Esse comando deve
ser executado da ma´quina onde o charm nova-cloud-controller esta´ sendo executado,
caso contra´rio na˜o tera´ efeito real nenhum. A mesma lo´gica do passo anterior foi
utilizada para escolha da extensa˜o de IPs (172.16.32.0/24);
7. De volta a` interface web do Horizon, ainda no menu de acesso, importar um par
de chaves SSH para acesso remoto a`s ma´quinas virtuais que sera˜o criadas. Acessar
tambe´m a aba de grupo de seguranc¸a e criar regras de rede para permitir acesso a`s
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 28
portas que forem necessa´rias (ou simplesmente liberar todo o acesso TCP, UDP e
ICMP);
8. Acessar menu de “Imagens”, e realizar a importac¸a˜o de imagens dos sistemas ope-
racionais desejados usando provedores dispon´ıveis publicamente. Realizou-se a im-
portac¸a˜o de imagens do Ubuntu Server verso˜es 14.04 e 16.04 (LTS), dispon´ıveis no
portal do Ubuntu Cloud Images. Nesse ponto deve-se ter cuidado tambe´m ao definir
um valor para a arquitetura da imagem, visto que o Glance/Nova fazem uma mera
comparac¸a˜o de strings para determinar compatibilidade. Ao definir amd64 no lugar
de x86_64 por exemplo (que se referem a` mesma arquitetura), as imagens na˜o foram
aceitas na hora de criar um servidor, e as mensagens de erro na˜o sa˜o muito expli-
cativas quanto ao que esta´ errado, mesmo a operac¸a˜o sendo executada da interface
de usua´rio;
9. Finalmente, criar uma ma´quina virtual na aba de “Instaˆncias” no portal Horizon.
Atentar para relacionamento entre as configurac¸o˜es de imagem com as de disco e tipo
de instaˆncia, visto que dependendo das configurac¸o˜es feitas na criac¸a˜o das imagens,
podera´ haver conflito com os outros paraˆmetros escolhidos (tamanho mı´nimo de
volume e memo´ria RAM);
10. Ainda, voltar a` linha de comando e associar enta˜o um IP flutuante para a ma´-
quina virtual criada com comando nova floating-ip-create seguido de nova
floating-ip-associate. So´ assim a mesma podera´ ser acessada fora do no´ hospe-
deiro e tera´ acesso a` internet (dado que as configurac¸o˜es para interface pu´blica do
nova-compute estejam adequadas para o sistema onde esta´ implantado).
FIGURA 3.5 – Interface do OpenStack Horizon mostrando algumas ma´quinas virtuais
instanciadas na infraestrutura.
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 29
Vale ressaltar que, apesar de ser uma sequeˆncia de passos relativamente complicada
(por tambe´m na˜o estar indicada em lugar algum), apo´s a configurac¸a˜o inicial novas ma´-
quinas virtuais podem ser criadas mais facilmente, bastando seguir os passos a partir de
9. Mesmo apo´s a configurac¸a˜o inicial completa, pore´m, chegou-se a encontrar erros na
criac¸a˜o de ma´quinas ou volumes por motivos arbitra´rios na˜o especificados nas mensagens
de erro e que so´ puderam ser resolvidos refazendo-se a implantac¸a˜o da infraestrutura por
completo.
Dessa forma, podemos dizer que o OpenStack e´ uma plataforma poderosa, mas que
sua configurac¸a˜o e´ realmente cheia de particularidades e minuciosidades que devem ser
atentadas para um funcionamento correto e
consistente do sistema. Sua interface gra´fica
e´ um pouco limitada, de modo que na˜o e´ suficiente para realizac¸a˜o de todas as operac¸o˜es
necessa´rias para criar ma´quinas virtuais, ao menos sem utilizac¸a˜o de todos os mo´dulos
mais complexos do OpenStack (como de gerenciamento de rede, ja´ explicado).
Ale´m disso, as mensagens de erro sa˜o raramente u´teis, mesmo em caso de erros cau-
sados por ac¸o˜es do usua´rio final e na˜o da configurac¸a˜o da implantac¸a˜o do OpenStack em
si. Usua´rios finais da infraestrutura do OpenStack na˜o podem portanto estar comple-
tamente abstra´ıdos de como os servic¸os esta˜o configurados internamente, ou podera˜o ter
bastante trabalho interagindo com a ferramenta. Esse na˜o e´ um requisito muito incoerente
a se fazer para um sistema focado em Nuvens privadas pore´m, visto que grande parte da
implantac¸a˜o, configurac¸a˜o e utilizac¸a˜o dos servic¸os se concentraria em times internos espe-
cializados nas instituic¸o˜es que teriam conhecimento extensivo da infraestrutura utilizada,
ou que ofereceriam suporte especializado e dedicado para quem fosse utilizar o servic¸o.
Foram observados ainda alguns paraˆmetros interessantes de configurac¸a˜o dos mo´dulos
do OpenStack que poderiam ter um impacto real no desempenho do sistema, e portanto
possivelmente interessantes para testes a serem realizados, seriam eles (apresentados na
forma charm:configurac¸a˜o):
• cinder:worker-multiplier : Multiplicador utilizado pelo Cinder para determinar o
nu´mero de processos utilizados pelo mesmo a partir do nu´mero de CPUs no sistema
em que estiver instalado.
• cinder:ceph-osd-replication-count : Controla nu´mero de re´plicas que o Ceph fara´ de
todo objeto ou dado deixado sob sua responsabilidade, quando o Cinder e´ configu-
rado para usar o Ceph de tecnologia de armazenamento subjacente. Esse na˜o foi
o caso nessa instalac¸a˜o, visto que t´ınhamos apenas um no´ de armazenamento, na˜o
se fazendo necessa´ria uma tecnologia mais complexa por exemplo de replicac¸a˜o de
dados.
• nova-compute:cpu-mode: Modelo de correspondeˆncia do modo de CPU entre as
CAPI´TULO 3. IMPLANTAC¸A˜O DO OPENSTACK 30
ma´quinas f´ısicas e as ma´quinas virtuais instanciadas pelo Nova (pode por exemplo
repassar o mesmo modelo de CPU da ma´quina hospedeira ou simular uma arquite-
tura espec´ıfica).
• nova-compute:disk-cachemodes : Me´todo de caching utilizado para diferentes tipos
de disco utilizado para as VMs (por exemplo para arquivos de disco virtual ou para
utilizac¸a˜o de algum servic¸o de armazenamento por blocos).
• nova-compute:hugepages : Quantidade da memo´ria RAM para utilizar para pa´ginas
de memo´ria de tamanho maior que o normal do sistema.
• nova-compute:virt-type: Tecnologia de virtualizac¸a˜o (hipervisor) para utilizar para
as ma´quinas virtuais. As tecnologias dispon´ıveis sa˜o: Xen (utilizada no AWS),
QEMU, KVM (otimizac¸a˜o embutida na Kernel do Linux), LXC (utilizado pelo Juju
para os charms), LXD e UML.
• nova-cloud-controller:cpu-allocation-ratio: Multiplicador utilizado para determinar
nu´mero ma´ximo de nu´cleos virtuais para alocar a partir do nu´mero de CPUs f´ısicas
das ma´quinas hospedeiras.
• nova-cloud-controller:ram-allocation-ratio: Mesma lo´gica do item anterior, mas para
memo´ria RAM. Note que esses multiplicadores definem o limite cumulativo para
todas as ma´quinas virtuais alocadas numa mesma ma´quina f´ısica, na˜o o limite indi-
vidual. Assim, caso o paraˆmetro ram-allocation-ratio fosse igual a 3 por exemplo,
uma ma´quina f´ısica com 2 GiB de RAM na˜o podera´ ser utilizada para alocar uma
VM de 4 GiB, mas poderia ser utilizada para alocar ate´ 3 ma´quinas de 2 GiB cada.
• nova-cloud-controller:worker-multiplier : Mesma lo´gica do paraˆmetro homoˆnimo do
Cinder.
Nem todos esses paraˆmetros chegaram a ser configurados, ate´ porque alguns deles na˜o
se aplicam a` implantac¸a˜o em questa˜o (do Ceph), mas eles servem para dar uma ideia de
como e´ bastante poss´ıvel de se causar alguma mudanc¸a no desempenho do sistema como
um todo apenas mexendo nesses paraˆmetros de configurac¸a˜o dos servic¸os do OpenStack
instalados, e aos quais os usua´rios poderiam ficar comprometidos sem oportunidade ou
possibilidade de mudanc¸a.
Apo´s algumas iterac¸o˜es de implantac¸a˜o e configurac¸a˜o, adquiriu-se conhecimeto sufi-
ciente sobre o funcionamento dos mo´dulos utilizados de forma que o ambiente de teste
cumpriu o seu papel em fornecer uma infraestrutura versa´til para execuc¸a˜o de testes de
desempenho utilizando a ferramenta BenchStack desenvolvida. No pro´ximo cap´ıtulo des-
creveremos em mais detalhes o desenvolvimento dessa ferramenta e em seguida os testes
realizados com a mesma utilizando a implantac¸a˜o funcional do OpenStack.
4 Ferramenta desenvolvida
BenchStack foi o nome dado para a ferramenta de benchmarking desenvolvida, fazendo-
se um jogo verbal entre a funcionalidade principal da aplicac¸a˜o com o nome do servic¸o
principal para o qual a mesma foi pensada. Stack tambe´m e´ o termo mais utilizado para
descrever o conjunto de softwares e servic¸os gerenciadores de Data Centers, dando ainda
mais sentido ao nome da ferramenta na˜o so´ atrelado ao OpenStack propriamente dito,
mas para quaisquer servic¸os desenvolvidos ou implantados em Nuvens.
Uma das primeiras e principais deciso˜es que precisaram ser tomadas para desenvol-
vimento da ferramenta foi como seria poss´ıvel medir o desempenho de um sistema ta˜o
gene´rico quanto o OpenStack. Praticamente qualquer servic¸o pode ser implantado numa
infraestrutura gerenciada pelo mesmo, e na˜o so´ isso como existem diversas operac¸o˜es que
podem ser realizadas no servic¸o, seja de criac¸a˜o ou remoc¸a˜o de ma´quinas virtuais ou volu-
mes, migrac¸a˜o ao vivo de VMs entre hospedeiras, configurac¸a˜o de redes ou atribuic¸o˜es de
IPs a`s ma´quinas, orquestrac¸a˜o de servic¸os, criac¸a˜o de bancos de dados, e muitas outras.
A maior parte dessas operac¸o˜es na˜o sa˜o instantaˆneas, e portanto podem ser mensuradas e
podem ainda ter um impacto positivo ou negativo na experieˆncia que o usua´rio tera´ com
a plataforma.
E´ bastante va´lido o questionamento pore´m se o desempenho dessas operac¸o˜es gerenci-
ais sa˜o o que realmente importam no desempenho de um sistema provedor de servic¸os de
computac¸a˜o de Nuvem, onde sera˜o executadas aplicac¸o˜es potencialmente paralelizadas e
distribu´ıdas numa infraestrutura de mu´ltiplos servidores. Muito mais importante do que
se uma ma´quina virtual sera´ inicializada em 1 ou 2 minutos e´ se a mesma vai apresentar
um desempenho ta˜o bom quanto uma ma´quina f´ısica ou se havera˜o tantos overheads de
virtualizac¸a˜o e/ou gerenciamento da mesma que a CPU sera´ consumida e limitada por
causa dessas atividades. Muito mais importante que se uma rede interna e´ criada em
10 ou 20 segundos e´ se a mesma suportara´ uma banda ininterrupta de 1 Gbps ou tera´
interrupc¸o˜es e perdas de pacotes atingindo uma banda efetiva que seja a metade disso.
Por esses motivos, optou-se por na˜o se prender a` mensurac¸a˜o do desempenho de opera-
c¸o˜es do OpenStack por si so´, mas na verdade do fornecido pelo mesmo para as aplicac¸o˜es
que ira˜o de fato executar em sua infraestrutura e que podem ser ate´ mesmo mais relevan-
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 32
temente afetadas por ma´s configurac¸o˜es da infraestrutura, como por exemplo uma escolha
equivocada de tecnologia de virtualizac¸a˜o, um gargalo no fluxo de pacotes na rede que
limite seu desempenho, um exagero no ajuste da replicac¸a˜o ou back-up de volumes ou ate´
mesmo uma colec¸a˜o de telemetria das instaˆncias frequente/invasiva demais que poderia
degradar o desempenho do sistema (alguns exemplos de paraˆmetros desse tipo no cap´ıtulo
anterior).
Ainda existe um problema
nesse caso, pore´m, que seria como exatamente medir es-
ses paraˆmetros de desempenho das instaˆncias criadas e disponibilizadas pelo OpenStack
para os usua´rios, e mesmo quais deles medir e como possivelmente agrega´-los para rea-
lizar a comparac¸a˜o entre diferentes medic¸o˜es realizadas para implantac¸o˜es diferentes da
plataforma.
A soluc¸a˜o proposta nesse trabalho enta˜o foi, de forma simplificada: a implementac¸a˜o,
em uma infraestrutura existente do OpenStack, de um cena´rio padronizado de uma apli-
cac¸a˜o espec´ıfica, na qual se executara´ algum tipo de carga de trabalho fixa e se medira´
algum paraˆmetro agregado e relevante de desempenho espec´ıfico da aplicac¸a˜o. De forma
mais concreta, um passo a passo seria:
1. O administrador do sistema realiza a instalac¸a˜o do OpenStack na infraestrutura de
interesse, adicionando e configurando os mo´dulos que se julgarem necessa´rios ou
desejados para a implantac¸a˜o final do servic¸o;
2. Apo´s ter uma implantac¸a˜o funcional do sistema, o administrador realizara´ a instan-
ciac¸a˜o de alguns componentes (ma´quinas, volumes) pela interface do OpenStack,
componentes esses especificados pelo benchmark a ser executado;
3. De prefereˆncia de forma automatizada, realiza-se a instalac¸a˜o de alguma aplicac¸a˜o
nesses componentes criados, tambe´m especificada pelo benchmark;
4. Com essas aplicac¸o˜es instaladas nesses componentes, algum tipo de identificador
sera´ fornecido para a aplicac¸a˜o de benchmark, seja por IDs dos componentes do
OpenStack, enderec¸os de rede, enderec¸os f´ısicos ou forma de acesso gene´rica.
5. Dotado dessas informac¸o˜es de acesso a`s aplicac¸o˜es enta˜o, o benchmark e´ executado
e efetuara´ algum tipo de carga sobre as mesmas, processo durante o qual o mesmo
realizara´ algum(s) tipo de medic¸a˜o relacionada ao desempenho do sistema, como a
lateˆncia me´dia ou vaza˜o ma´xima.
6. Esse valor medido sera´ enta˜o o resultado do benchmark.
De forma ainda mais elucidativa, alguns exemplos de aplicac¸o˜es pass´ıveis de serem
utilizadas nessa aplicac¸a˜o de benchmarking seriam:
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 33
• Uma aplicac¸a˜o de streaming de mı´dia para um ou va´rios clientes. Poderia ser medido
o nu´mero ma´ximo de clientes que a mesma suporta mantendo-se uma banda fixa,
ou qual a banda ma´xima atingida dado um nu´mero fixo de clientes.
• Um servidor e/ou uma aplicac¸a˜o de VoIP, do qual seria medida a lateˆncia ma´xima
ou me´dia atingida quando N clientes esta˜o realizando alguma chamada.
• Ainda na a´rea de chamadas de voz e CDN (Content Delivery Network, ou Rede de
Fornecimento de Conteu´do), um servidor conversor de mı´dia do qual seria medido o
vaza˜o ma´xima de dados convertidos para um certo nu´mero de clientes (ou nu´mero
de clientes varia´vel).
• Uma rede distribu´ıda de ma´quinas onde se realizara´ um procedimento fixo de map-
reduce com alguma tecnologia padra˜o. Poderia-se medir o tempo levado ate´ execu-
c¸a˜o completa da tarefa.
• Uma aplicac¸a˜o de inteligeˆncia artifical paralelizada/distribu´ıda, como por exemplo
a AlphaGo desenvolvida pelo Google que foi capaz de derrotar o campea˜o mundial
no jogo Go recentemente. Dela poderia-se medir o tempo tomado para treinamento
de modelos a partir de uma entrada fixa, ou o tempo levado para ca´lculo das jogadas
em posic¸o˜es fixas do jogo, dado um estado inicial tambe´m fixo.
• Um servidor web apoiado por um banco de dados, do qual se mediria o nu´mero
ma´ximo de requisic¸o˜es simultaˆneas que consegue servir.
Vale notar que podemos fixar a aplicac¸a˜o a ser utilizada, e enta˜o o paraˆmetro de
desempenho medido pelo benchmark determinara´ na˜o um valor absoluto ating´ıvel para
aquele tipo de aplicac¸a˜o, mas um valor que sera´ va´lido principalmente para compara-
c¸o˜es entre diferentes execuc¸o˜es desse benchmark em diferentes ambientes de execuc¸a˜o ou
instalac¸a˜o, dado que algumas caracter´ısticas ba´sicas do set-up sejam mantidas, como por
exemplo a proximidade entre a aplicac¸a˜o cliente da aplicac¸a˜o de servidor, de modo que
atrasos de rede arbitra´rios na˜o influenciem no resultado do teste realizado. Em poucas
palavras, a me´trica de desempenho realizada resultara´ num valor relativo e na˜o absoluto
de comportamento do sistema.
Dessa forma enta˜o, sem perda de generalidade, optou-se pela implementac¸a˜o da u´ltima
opc¸a˜o listada acima, do servidor web apoiado por um banco de dados, visto que poderia
ser feita em tempo ha´bil para demonstrac¸a˜o e comprovac¸a˜o do conceito para esse trabalho
de graduac¸a˜o.
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 34
4.1 Implementac¸a˜o
A aplicac¸a˜o desenvolvida consiste de dois mo´dulos principais, um deles o servidor web
propriamente dito que seria instalado diretamente em alguma ma´quina virtual instanciada
pelo OpenStack, e uma aplicac¸a˜o de benchmarking desse servidor web, a ser executada
de prefereˆncia numa unidade isolada, em quesito de desempenho, da ma´quina onde o
servidor web estara´ sendo executado. Esse servidor web utiliza ainda um banco de dados
na˜o-relacional, que poderia ser implantado na mesma ma´quina do servidor Web ou na˜o.
Mais especificamente, essa aplicac¸a˜o web consiste de um servidor REST desenvolvido
utilizando-se a tecnologia Node.js (JOYENT, 2016), e o banco de dados utilizado foi o
MongoDB (MONGODB, 2016), onde era gerada inicialmente uma populac¸a˜o aleato´ria au-
toma´tica de valores primordialmente a` execuc¸a˜o do servidor, que enta˜o faria leituras e/ou
escritas nesse banco em toda requisic¸a˜o.
A aplicac¸a˜o cliente do benchmark foi desenvolvida em Java 8, utilizando-se de algu-
mas bibliotecas para algumas tarefas auxiliares ou complementares espec´ıficas, fora isso
inteiramente desenvolvida desde o princ´ıpio.
Entraremos em mais detalhes sobre cada uma dessas aplicac¸o˜es a seguir.
4.1.1 PokeStack – O servidor web
O servidor web, como ja´ descrito, foi desenvolvido utilizando a tecnologia Node.js e
va´rios de seus pacotes de software disponibilizados livremente atrave´s do seu gerencia-
dor de pacotes npm (NPM, 2016). O servidor disponibiliza uma API REST simplificada
(utilizando apenas requisic¸o˜es HTTP de tipo POST e GET), recebendo argumentos para
execuc¸a˜o das requisic¸o˜es e respondendo em formato JSON.
O servidor utiliza enta˜o um servidor MongoDB como banco de dados, e todas as requi-
sic¸o˜es REST realizam acessos a` esse banco de dados, executando operac¸o˜es de inserc¸a˜o,
leitura, atualizac¸a˜o, ou remoc¸a˜o (CRUD1) de objetos nesse banco praticamente constantes
para cada tipo de requisic¸a˜o. Ha´ tambe´m requisic¸o˜es que executam operac¸o˜es em memo´-
ria no processo do servidor Node.js, realizando uma se´rie de processamentos e ca´lculos de
forma a sobrecarregar a CPU da ma´quina (caso so´ esse tipo de requisic¸a˜o fosse realizada).
Ha´ tambe´m algumas tabelas de diferentes tamanhos nesse banco de dados, de forma
que podem-se realizar operac¸o˜es leves ou pesadas de cada um dos tipos CRUD mencio-
nados. Cada uma dessas requisic¸o˜es pretende enta˜o sobrecarregar o servidor e o banco de
dados de uma maneira e intensidade diferentes.
Desenvolveu-se para essa aplicac¸a˜o ainda dois bina´rios principais, um deles responsa´vel
1Create, Read, Update, Delete
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 35
por popular o banco de dados inicial da aplicac¸a˜o com objetos gerados de forma aleato´ria,
e o outro que executa o servidor web propriamente dito utilizando a biblioteca Express
dispon´ıvel no npm.
Para a gerac¸a˜o de conteu´do, utilizou-se ainda principalmente a biblioteca mongo-seed
que fornece uma forma automatizada de gerac¸a˜o e envio de dados para um banco MongoDB.
A biblioteca foi desenvolvida inicialmente para escrita de testes de unidade, mas por for-
necer uma forma
de gerac¸a˜o de entradas para o banco utilizando-se uma func¸a˜o gene´rica
a ser definida pelo usua´rio da biblioteca, a mesma poˆde ser utilizada para gerac¸a˜o de um
banco de dados inicial para a aplicac¸a˜o. Durante o desenvolvimento, foram encontrados
nessa biblioteca alguns erros de programac¸a˜o, para os quais foram submetidas algumas
pull requests com mudanc¸as e melhoramentos (nesse momento ja´ aceitas pelo autor e
incorporadas ao co´digo principal).
Utilizou-se ainda algumas outras bilbiotecas de diciona´rios de palavras (wordo ), no-
mes de pessoas (nombres ) e gerac¸a˜o de nu´meros aleato´rios (randgen ) mais complexa
que a dispon´ıvel na biblioteca padra˜o do JavaScript, todas elas para auxiliar a gerac¸a˜o
aleato´ria dos registros nas tabelas do banco de dados.
De forma a na˜o manter o desenvolvimento do sistema de forma muito abstrata, foi utili-
zada ainda uma analogia do sistema desenvolvido com um servidor do jogo PokemonGo ,
lanc¸ado recentemente e que ficou famoso por ter tido uma demanda absurda no seu lanc¸a-
mento que levou seus desenvolvedores a desafios inimagina´veis de ampliac¸a˜o e escalamento
de infraestrutura, tornando-se uma opc¸a˜o interessante para o contexto a que estamos apli-
cando.
A tabela mais populosa gerada refere-se a va´rios Poke´monsTM espalhados pelo “globo”
(possuem uma latitude e longitude). Outras tabelas menores incluem “PokeStops”, esta´-
dios e treinadores, ale´m de uma tabela de usua´rios que sera´ apenas ta˜o extensa quanto o
nu´mero de requisic¸o˜es simultaˆneas que sera˜o realizadas simultaneamente ao servidor.
A gerac¸a˜o de entradas para as tabelas sa˜o geradas em batches (“lotes” ou “remessas”),
de forma que consiga-se gerar no total uma quantidade de dados que na˜o caberia na
memo´ria do sistema gerador dos mesmos. Esse bina´rio possui ainda algumas opc¸o˜es de
linha de comando, de forma que o nu´mero de batches a serem gerados e as configurac¸o˜es
de execuc¸a˜o (como n´ıvel de concorreˆncia) e as operac¸o˜es auxiliares a serem realizadas no
banco de dados (como iniciar com uma delec¸a˜o de todos os dados anteriores) possam ser
alteradas. O script termina enta˜o definindo alguns ı´ndices nas tabelas utilizadas para os
tipos de acesso aos dados que sera˜o mais frequentes, assim como faria uma aplicac¸a˜o real
usando essas tecnologias. Na tabela 4.1 temos alguns dados sobre os objetos gerados em
cada batch.
Vale notar ainda que o MongoDB realiza alguns tipos de compressa˜o dos dados ar-
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 36
TABELA 4.1 – Dados e estat´ısticas relativas a` gerac¸a˜o de objetos para o banco MongoDB.
Tabela Tamanho aprox.
por objeto
Objetos gerados
por batch
Tamanho aprox.
total por batch
pokemon 417 bytes 10000 4.17 MB
pokestop 191 bytes 1500 287 kB
stadium 244 bytes 200 48.8 kB
trainer 258 bytes 50 12.9 kB
user - 0 0
(Total) 384.5 bytes 11750 4.52 MB
mazenados no disco, de forma que o espac¸o final ocupado na˜o sera´ exatamente igual a
esses tamanhos descritos multiplicado pelo nu´mero de batches gerados. Observou-se uma
compressa˜o a` aproximadamente 57% do tamanho original desses dados gerados aleatori-
amente, no MongoDB versa˜o 3.2.10 executado localmente. A tabela user sera´ populada
durante a execuc¸a˜o do BenchStack, como ja´ mencionado, sendo criado 1 usua´rio por re-
quisic¸a˜o simultaˆnea realizada ao servidor web. O nu´mero de batches gerados ficaria a
cargo do caso de teste sendo feito, mas como veremos mais a` frente, foi utilizado um valor
de 100 para todas as execuc¸o˜es nesse trabalho.
As tabelas stadium e trainer podem parecer pequenas, mas o intuito desses objetos
na˜o e´ a realizac¸a˜o de operac¸o˜es de entrada/sa´ıda pesadas, mas sim de participarem das
operac¸o˜es em memo´ria pesadas em processamento na ma´quina servidora. Desempenham
um papel fundamental nessas requisic¸o˜es, ale´m de servirem tambe´m para as operac¸o˜es
de leitura e escrita “leves” (visto que qualquer acesso a` tabela de Poke´mons por exemplo
provavelmente geraria um cache miss e uma conseguinte operac¸a˜o de leitura de disco).
As operac¸o˜es pesadas em CPU sa˜o principalmente de 2 tipos, sendo elas de “batalhas”
entre usua´rios e treinadores, esta´dios ou Poke´mons ou de “captura” de Poke´mons. Nessas
requisic¸o˜es sa˜o executadas mu´ltiplas operac¸o˜es probabil´ısticas, fazendo-se o ca´lculo de
nu´meros aleato´rios propositadamente complexos computacionalmente de forma a forc¸ar a
CPU da ma´quina hospedeira. Foram definidos tambe´m os ı´ndices necessa´rios no MongoDB
para otimizac¸a˜o dos principais tipos de consultas realizadas no mesmo, assim como uma
aplicac¸a˜o real tambe´m faria.
Apesar de se basear no jogo PokemonGO, o servidor implementado na˜o se trata de
um jogo propriamente dito, e quase todas as requisic¸o˜es utilizadas da˜o prefereˆncia a` ma-
nutenc¸a˜o de um desempenho mais consistente entre diferente execuc¸o˜es do que para uma
lo´gica de jogo realmente consistente. Como exemplo, ao pesquisar por elementos inexis-
tentes no banco de dados (que tenham sido deletados por outra requisic¸a˜o simultaˆnea,
por exemplo), no lugar de retornar um erro os servic¸os de buscas pelos objetos foram
modificados para retornar um objeto “dummy” aleato´rio a partir do qual o processamento
sera´ continuado, de modo que o mesmo nu´mero de operac¸o˜es sejam executadas ao todo.
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 37
Com isso encerramos a descric¸a˜o do servidor web desenvolvido. Partiremos agora para
o BenchStack propriamente dito, que implementa um cliente para esse servidor com diver-
sas modificac¸o˜es e aleatorizac¸o˜es para distribuic¸a˜o entre todos esses tipos de requisic¸o˜es
implementadas.
4.1.2 BenchStack – A ferramenta de benchmarking
O BenchStack se trata da aplicac¸a˜o avaliadora de desempenho propriamente dita. E´
configurado no momento de execuc¸a˜o (atrave´s de uma opc¸a˜o na linha de comando) com
o enderec¸o do servidor web PokeStack no qual sera´ feita a carga de trabalho e avaliado o
desempenho. O mesmo tambe´m posui classes com interfaces apropriadas para interac¸a˜o
com o PokeStack, de forma a fazer as chamadas apropriadas nos caminhos espec´ıficos de
cada um dos tipos de requisic¸a˜o implementados no Node.js.
Essa aplicac¸a˜o de benchmarking foi desenvolvido em Java, visto que a linguagem ofe-
rece diversas abstrac¸o˜es e facilitac¸o˜es ja´ na biblioteca padra˜o para desenvolvimento de
programas concorrentes com va´rias threads, ale´m de facilitac¸o˜es tanto inclusas na biblio-
teca padra˜o quanto atrave´s de terceiros para realizac¸a˜o de requisic¸o˜es de rede ou HTTP.
Ale´m disso, tambe´m e´ suficientemente consolidada e bem estabelecida de forma a forne-
cer um desempenho suficientemente bom para execuc¸a˜o do programa de benchmarking
extremamente paralelizado. Foi utilizada a versa˜o 8 do Java, que proveˆ ainda estruturas
sinta´ticas mais modernas e amiga´veis como func¸o˜es lambda e programac¸a˜o funcional em
geral, ale´m de novas APIs na biblioteca padra˜o tambe´m mais modernas.
A base do algoritmo implementado para o benchmark e´ estat´ıstica, e foi baseada no
me´todo utilizado pela Microsoft para determinar a me´trica de desempenho utilizada para
os seus servic¸os de Bancos de Dados fornecidos na sua infraestrutura do Azure (RABELER,
2016).
A lo´gica principal do programa consiste em, dependendo da quantidade de carga que
pretende-se impor sobre o sistema, definida pelo nu´mero de requisic¸o˜es simultaˆneas dese-
jadas, cria-se o nu´mero de threads correspondentes para realizar cada uma — em me´dia
— uma requisic¸a˜o por segundo ao sistema sob teste, em outras palavras, uma me´dia de
uma thread por requisic¸a˜o por segundo. Na˜o se trata exatamente de uma thread, mas
podemos nos referir dessa maneira
por ora por simplicidade da explicac¸a˜o.
Para cada uma dessas requisic¸o˜es a serem realizadas, e´ realizado um sorteamento
balanceado (de pesos determinados) de cada tipo de requisic¸a˜o dispon´ıvel do servidor.
Todas as requisic¸o˜es sa˜o pass´ıveis de serem feitas a qualquer momento, portanto foram
simplesmente distribu´ıdos pesos de probabilidades para cada um dos tipos de requisic¸o˜es
dispon´ıveis e uma delas e´ escolhia aleatoriamente garantindo-se que a distribuic¸a˜o de
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 38
probabilidades seja garantida apo´s um tempo suficiente de execuc¸a˜o do benchmark.
Para chegar nesse ponto, cada uma das requisic¸o˜es definidas no servidor foram inicial-
mente atribu´ıdas a uma das classificac¸o˜es de requisic¸o˜es poss´ıveis, baseadas na utilizac¸a˜o
de recursos predominante das mesmas. As classificac¸o˜es de requisic¸o˜es e tipos de requisi-
c¸o˜es atribu´idas a`s mesmas foram:
• Leitura Leve (ReadLite): Requisic¸o˜es de buscar detalhes do usua´rio sendo utilizado
pela thread, detalhes de algum esta´dio ou de algum treinador do qual se tenham
identificadores.
• Leitura Me´dia (ReadMedium): Requisic¸o˜es de busca pelas 10 PokeStops mais pro´-
ximas a` posic¸a˜o atual do usua´rio ou pelos 200 esta´dios mais pro´ximos (mais esta´dios
para compensar a sua tabela ser menor).
• Leitura Pesada (ReadHeavy): Requisic¸o˜es para busca dos 30 Poke´mons mais pro´-
ximos do usua´rio no momento, ou das listas de Poke´mons do usua´rio atual ou do
treinador ou esta´dio mais pro´ximos (leitura da tabela de Poke´mons e´ pesada).
• Atualizac¸a˜o Leve (UpdateLite): API de coleta dos itens dispon´ıveis na PokeStop
mais pro´xima para a bolsa de itens do usua´rio ou de largar alguns itens da bolsa do
usua´rio no cha˜o (ambas atualizac¸o˜es apenas no objeto do usua´rio).
• Atualizac¸a˜o Me´dia (UpdateMedium): 99% de chance da chamada de “melhora-
mento” das 20 PokeStops mais pro´ximas e 1% de chance da requisic¸a˜o de “movi-
mento” do usua´rio para uma posic¸a˜o aleato´ria completamente diferente da atual.
• Atualizac¸a˜o Pesada (UpdateHeavy): Incremento do n´ıvel dos 100 Poke´mons mais
pro´ximos do usua´rio (tabela mais pesada).
• Inserc¸a˜o Leve (InserLite): API de criac¸a˜o de 10 novos Poke´mos pro´ximos a` PokeStop
mais pro´xima do usua´rio no momento.
• Inserc¸a˜o Pesada (InserLite): Mesma da anterior, mas de 200 Poke´mons.
• Delec¸a˜o Leve (DeleteLite): Requisic¸a˜o “curinga” de dizimac¸a˜o dos 10 Poke´mons
mais pro´ximos de alguma localizac¸a˜o qualquer, sorteada no servidor.
• Delec¸a˜o Pesada (DeleteHeavy): Mesma da anterior, mas dizimando 200 Poke´mons.
• CPU Leve (CPULite): API de captura do Poke´mon mais pro´ximo do usua´rio.
• CPU Pesada (CPUHeavy): APIs de batalha seja com um Poke´mon, um esta´dio ou
um treinador mais pro´ximos.
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 39
Todas as requisic¸o˜es atribu´ıdas a uma mesma classificac¸a˜o enta˜o teˆm a mesma proba-
bilidade dentro dessa classificac¸a˜o, e precisamos calcular apenas qual classe de requisic¸a˜o
que sera´ executada no loop atual. A u´nica excec¸a˜o a` essa regra e´ a requisic¸a˜o de “movi-
mento” do usua´rio. Essa requisic¸a˜o e´ considerada de “atualizac¸a˜o me´dia” mas na verdade
tem consequeˆncias de invalidac¸a˜o de caches tanto do cliente quanto do banco de dados
dos objetos mais pro´ximos do usua´rio que sa˜o utilizados nas outras requisic¸o˜es. Dessa
forma a probabilidade desse tipo de requisic¸a˜o foi diminu´ıdo de forma a ser executado
mais raramente.
Ainda, a distribuic¸a˜o de probabilidades utilizada entre as diferentes classes de requisi-
c¸o˜es pode ser visualizada pela tabela a seguir 4.2. Essa distribuic¸a˜o baseou-se na utilizada
pela Microsoft na sua avaliac¸a˜o de desempenho de bancos de dados (RABELER, 2016), que
por sua vez aproxima a frequeˆncia de distribuic¸a˜o dos dados tipos de requisic¸o˜es em apli-
cac¸o˜es reais de usua´rios hospedados em sua infraestrutura. E´ relevante exatamente por
isso, de forma que se simule uma aplicac¸a˜o real por aproximac¸a˜o.
TABELA 4.2 – Distribuic¸a˜o de probabilidade de execuc¸a˜o de cada uma das classes de
requisic¸o˜es definidas
Classe de Requisic¸a˜o Peso de Probabilidade
Leitura Leve 35
Leitura Me´dia 20
Leitura Pesada 5
Atualizac¸a˜o Leve 12
Atualizac¸a˜o Me´dia 5
Atualizac¸a˜o Pesada 3
Inserc¸a˜o Leve 3
Inserc¸a˜o Pesada 2
Delec¸a˜o Leve 3
Delec¸a˜o Pesada 2
CPU Leve 6
CPU Pesada 4
Realizaremos agora uma breve descric¸a˜o das principais classes desenvolvidas para exe-
cuc¸a˜o do benchmark. Desde as classes criadas de mais baixo n´ıvel, para agendamento de
tarefas recorrentes por exemplo, ate´ a lo´gica de mais alto n´ıvel de conduc¸a˜o benchmark
em si. Essas classes na˜o englobam todo o co´digo desenvolvido para o BenchStack, mas
representam a porc¸a˜o mais densa do mesmo que conte´m a lo´gica mais pesada de execuc¸a˜o.
O co´digo completo (inclusive do PokeStack) encontra-se dispon´ıvel no reposito´rio Open
Source no GitHub: v1ct04/benchstack .
Como ja´ mencionado, as requisic¸o˜es HTTP cujas classificac¸o˜es foram enumeradas
anteriormente sa˜o executadas em um loop por uma thread cada. O que chamamos
aqui de threads, pore´m, sa˜o na verdade “tarefas reagenda´veis” implementadas na classe
CAPI´TULO 4. FERRAMENTA DESENVOLVIDA 40
ReschedulingTask . Essas sa˜o classes auxiliares implementadas para definic¸a˜o de tarefas
que executem a um passo varia´vel definido usando uma func¸a˜o externa configura´vel. Essas
tarefas na˜o sa˜o associadas a threads 1:1, utilizando-se em sua maior parte na verdade ser-
vic¸os de execuc¸a˜o agendada do Java (ScheduledExecutorService ) para agendamento
de suas execuc¸o˜es no momentos apropriados. Esse agendamento e´ feito inicialmente e re-
feito ao te´rmino de cada execuc¸a˜o da tarefa, de modo que cada tarefa fica se re-agendando
automaticamente ate´ encontrar um erro de execuc¸a˜o ou ser explicitamente cancelada.
Assim, na˜o ha´ uma associac¸a˜o direta entre o nu´mero de requisic¸o˜es sendo executadas
por segundo e o nu´mero de threads de fato existentes no sistema, mas por simplificac¸a˜o
da explicac¸a˜o pode-se pensar dessa maneira, uma vez que cada tarefa fica associada a um
ID de usua´rio do PokeStack e sua ac¸a˜o executa´vel (que faz uma chamada como o usua´rio
correspondente) so´ e´ executada por uma thread de cada vez, mas na˜o necessariamente
sempre a mesma.
Caso o sistema esteja sob uma carga muito alta pore´m (de modo que a maior parte das
requisic¸o˜es levem pro´ximo de 1 segundo para executar), acaba-se por fazer a utilizac¸a˜o do
nu´mero de threads aproximadamente igual ao nu´mero de requisic¸o˜es por segundo sendo
realizadas, mas nunca mais que isso. Esse na˜o e´ o caso normal de execuc¸a˜o do benchmark
pore´m, e acontece principalmente quando occore um overshoot na estimativa de nu´mero
de tarefas simultaˆneas que o sistema sendo testado suporta.
O passo varia´vel dessas tarefas e´ definido ainda de modo que seja aleato´rio mas com
me´dia fixa em 1 segundo. Mais especificamente, utiliza-se uma distribuic¸a˜o Chi-quadrado
de 4 graus de liberdade e valor esperado 1, ou seja, e´ feita a soma do quadrado de 4
varia´veis aleato´rias gaussianas normais (µ = 0 e � = 1), a definic¸a˜o de uma distribuic¸a˜o
Chi-quadrado de 4 graus de liberdade, e esse valor e´ enta˜o dividido por 4. O valor esperado
de uma distribuic¸a˜o Chi-quadrado de k graus de liberdade e´ demonstradamente igual a
k, de forma que ao dividir pelo nu´mero de graus de liberade obtemos um valor esperado
de 1 para a varia´vel aleato´ria resultante.
Escolheu-se essa distribuic¸a˜o por ser relativamente simples de ser implementada a
partir das bibliotecas ja´ existentes, e 4 graus de liberdade de forma a se obter um ba-
lanceamento entre a complexidade