Dependabilidade PaaS Cloud Foundry

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO
UNIDADE ACADÊMICA DE GARANHUNS
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
RAMON SANTOS NASCIMENTO
AVALIAÇÃO DE DEPENDABILIDADE E ANÁLISE
DE SENSIBILIDADE DE UMA PLATAFORMA
COMO SERVIÇO (PAAS)
GARANHUNS – PE
2015

Trabalho de conclusão de curso apresentado
ao Curso de Bacharelado em Ciência da
Computação da Universidade Federal Rural
de Pernambuco da Unidade Acadêmica de
Garanhuns, como requisito para obtenção do
Grau de Bacharel em Ciência da Computação.
ORIENTADOR: Prof. MSc. Jean Carlos Teixeira de Araujo
GARANHUNS - PE
2015

Ficha Catalográfica
Setor de Processos Técnicos da Biblioteca Setorial UFRPE/UAG
N244a Nascimento, Ramon Santos
Avaliação de dependabilidade e análise de sensibilidade
de uma plataforma como serviço (PAAS).- Garanhuns,
2015.
73 fs.
Orientador: Jean Carlos Teixeira de Araujo
Monografia (Curso : Ciência da Computação) –
Universidade Federal Rural de Pernambuco - Unidade
Acadêmica de Garanhuns, 2015.
Referências
1. Ciência da computação. 2. Computação em nuvem. 3.
Diagrama de blocos de confiabilidade. 4. Cadeias de Markov.
I. Araújo, Jean Carlos Teixeira de II. Título
CDD: 004
1.

Trabalho de conclusão de curso apresentado
ao Curso de Bacharelado em Ciência da
Computação da Universidade Federal Rural
de Pernambuco da Unidade Acadêmica de
Garanhuns, como requisito para obtenção do
Grau de Bacharel em Ciência da Computação.
Aprovada em: 03 de Dezembro de 2015
BANCA EXAMINADORA
Prof. Jean Carlos Teixeira de Araujo (Orientador)
Universidade Federal Rural de Pernambuco – UFRPE
Unidade Acadêmica de Garanhuns – UAG
Prof. Bruno Costa e Silva Nogueira
Profa
. Kádna Maria Alves Camboim Vale

À minha mãe, que sempre acreditou em mim
e me apoia em todos os momentos.

Agradecimentos
Agradeço a Deus, pelo dom da vida, por cuidar das pessoas que eu amo e por me
iluminar nas decisões que tomei.
Agradeço a minha mãe e a minha avó materna pela criação e educação que me
deram e pelas orações que fizeram por mim. Agradeço a minha irmã pelo apoio que me deu
e por ter cuidado da minha mãe durante todo esse tempo em que estive ausente. Agradeço
a minha esposa pelo apoio, paciência e compreensão nesta fase final da minha graduação.
Agradeço a dona Marilene e Sr. João (In Memoriam) por me acolherem em sua
casa, pelo cuidado que tiveram comigo e pela força que me deram todo esse tempo.
Agradeço aos meus amigos Wagner, Artur Pedro, Witássio, João Chagas, Alexandro,
Luciano, Aline, Neto, Arnaldo, Isabelle, Lucas, Elisson, Anderson, Júlia, Vinicius, Marrone,
Felipe, João Bosco, Samuel, Valter, Erick, Tiago, Emanoel, Ana Raquel, Juan e tantos
outros pelo apoio, pelas madrugadas de estudo, por terem boa vontade para me ajudar e
pelos momentos descontração (geralmente tomando um café).
Agradeço a todos os meus professores por me proporcionaram conhecimento, pela
compreensão das minhas dificuldades, pelos momentos de descontração e pela amizade
dentro e fora da sala de aula.
Agradeço ao meu orientador, professor Jean, pela orientação, pelo incentivo, pela
paciência e pela dedicação em todas as etapas deste trabalho.

"Louvado seja Deus, senhor do universo, cle-
mente, misericordioso, soberano do dia do
juízo. Só a ti adoramos e só de ti imploramos
ajuda!"
(Alcorão, Al-Fátiha)

Resumo
A computação em nuvem está cada dia mais presente em nosso quotidiano, tanto na vida
de usuários domésticos, como em empresas, e organizações governamentais. Aconteceram
grandes melhorias na quantidade e qualidade do uso deste modelo de serviços nos últimos
anos, mas um fator de qualidade continua preocupando os provedores de serviços e usuário:
a dependabilidade. Dentre as modalidades de serviços mais populares de computação em
nuvem, encontram-se três: Infrastructure as a Service (IaaS), focado em administração
de sistemas e infraestrutura; Platform as a Service (PaaS), que possibilita a implantação,
hospedagem e gerenciamento de aplicações, onde os principais usuários são desenvolvedores
e gerentes de configuração; Software as a Service (SaaS), que geralmente são aplicativos
voltados ao usuário final. Nesse trabalho foram propostos cenários para a implantação
da PaaS (Platform as a Service) Cloud Foundry. Esses cenários foram modelados de
forma hierárquica e heterogênea com o uso de modelos analíticos de diagrama de bloco
de confiabilidade e cadeias de Markov. Com base nesses modelos, foram feitas análises
de disponibilidade, confiabilidade e de sensibilidade. Foram identificados gargalos para
a disponibilidade da plataforma e possíveis soluções para os mesmos. Com a análise de
sensibilidade, também foram mostrados cenários que suportavam alta disponibilidade como
menor uso de componentes redundantes.
Palavras-chave: Computação em Nuvem. Plataforma como um Serviços. Cadeias
de Markov de Tempo Contínuo. Diagrama de Blocos de Confiabilidade. Análise de
Sensibilidade. Avaliação de Dependabilidade. Sistemas Distribuídos. Cloud Foundry

Abstract
Cloud computing is becoming increasingly present in our daily lives, both in life of
the consumer, as companies and governmental organizations. Although, quantity and
quality have improved over the the last years, dependability is a role that still concerns
service providers and users. Amongst the role services of cloud computing, three of
them are the most popular: Infrastructure as a Service (IaaS), focuses on system and
infrastructure management; Plataform as a Service (PaaS), enabling the deployment,
hosting and application management, where main users are conﬁguration managers and
application developers; and Software as a Service (SaaS), that contains applications
directed to end users. This study proposes dependability assessment models for the cloud
computing system Cloud Foundry, which implements the model PaaS (Platform as a
Service). The proposed scenarios focus on the metrics of availability and reliability. A
heterogeneous modeling approach using models reliability block diagram and Markov
chains was adopted. Such models perform analysis of availability, reliability and sensitivity.
This work also identiﬁes bottlenecks and solutions on the platform availability, as well
as, sensitivity analysis shows supportive scenarios to high-availability with less use of
redundant components.
Keywords: Cloud Computing. Platform as a Service. Continuous-time Markov Chain.
Reliability Block Diagram. Sensitivity Analysis. Dependability Evaluation. Distributed
Systems. Cloud Foundry

Lista de Figuras
Figura 1 – Relação entre a Computação em Nuvem e a Computação Tradicional. . 25
Figura 2 – Árvore de Dependabilidade adaptada de (AVIŽIENIS et al., 2004). . . 26
Figura 3 – Exemplo de um RBD em Série. . . . . . . . . . . . . . . . . . . . . . . 32
Figura 4 – Exemplo de um RBD em Paralelo. . . . . . . . . . . . . . . . . . . . . 32
Figura 5 – Exemplo de uma CTMC. . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 6 – Etapas da Pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 7 – Arquitetura do Cloud Foundry. . . . . . . . . . . . . . . . . . . . . . . 41
Figura 8 – Modelo RBD para o cenário 1. . . . . . . . . . . . . . . . . . . . . . . 48
Figura 9 – Representação do UAA por CTMC. . . . . . . . . . . . . . . . . . . . . 49
Figura 10 – Representação do CC em RBD. . . . . . . . . . . . . . . . . . . . . . . 51
Figura 11 – Representação do DEA em RBD. . . . . . . . . . . . . . . . . . . . . . 52
Figura 14 – Conﬁabilidade dos Cenários. . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 15 – Variação de MTTF para o CC. . . . . . . . . . . . . . . . . . . . . . . 59
Figura 16 – Variação de MTTF para o DEA. . . . . . . . . . . . . . . . . . . . . . 60
Figura 17 – Variação de MTTF para o UAA. . . . . . . . . . . . . . . . . . . . . . 60
Figura 18 – Variação de MTTF para o Router. . . . . . . . . . . . . . . . . . . . . 60
Figura 19 – Variação de MTTR para o CC. . . . . . . . . . . . . . . . . . . . . . . 61
Figura 20 – Variação de MTTR para o DEA. . . . . . . . . . . . . . . . . . . . . . 61
Figura 21 – Variação de MTTR para o UAA. . . . . . . . . . . . . . . . . . . . . . 62
Figura 22 – Variação de MTTR para o Router. . . . . . . . . . . . . . . . . . . . . 62
Figura 23 – Resultados da Análise de Sensibilidade. . . . . . . . . . . . . . . . . . . 64
Figura 24 – Disponibilidade dos Cenários. . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 25 – Downtime anual dos cenários. . . . . . . . . . . . . . . . . . . . . . . . 65

Lista de tabelas
Tabela 1 – Comparação dos Trabalhos Relacionados. . . . . . . . . . . . . . . . . 18
Tabela 2 – Classiﬁcação dos Modelos Analíticos usados em Avaliação de Dependabilidade. 30
Tabela 3 – Dependências e linguagens de implementação dos componentes. . . . . 42
Tabela 4 – Parâmetros de Disponibilidade dos Componentes do Cloud Foundry. . 47
Tabela 5 – Valores de Disponibilidade para Software e Banco de Dados. . . . . . . 55
Tabela 6 – Disponibilidade dos Componentes do Cloud Foundry. . . . . . . . . . . 56
Tabela 7 – Disponibilidade dos Cenários. . . . . . . . . . . . . . . . . . . . . . . . 57
Tabela 8 – Parâmetros Avaliados com Variações nos Valores. . . . . . . . . . . . . 59
Tabela 9 – Fatores, níveis e valores da análise DoE. . . . . . . . . . . . . . . . . . 63
Tabela 10 – Distribuição dos Nós Redundantes. . . . . . . . . . . . . . . . . . . . . 66

Lista de Siglas
BS Blob Store
CC Cloud Controller
CF Cloud Foundry
CTMC Continuous-time Markov Chain
DEA Droplet Execution Agents
DoE Design of Experiments
IaaS Infrastructure as a Service
IR Interpretador Ruby
JVM Java Virtual Machine
MB Message Bus
MC Metrics and Logging
MTTF Mean Time to Failure
MTTR Mean Time to Repair
PaaS Platform as a Service
RBD Reliability Block Diagram
SaaS Software as a Service
SGBD Sistema de Gerenciamento de Banco de Dados
SLA Service Level Agreement
TI Tecnologia da Informação
UAA User Account and Authentication

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Estrutura do TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Conﬁabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Modelos Analíticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Diagrama de Blocos de Conﬁabilidade . . . . . . . . . . . . . . . . 31
2.3.2 Cadeias de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Análise de Sensibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Metodologia de Avaliação de Dependabilidade de um Sistema PaaS . 37
3.1 Metodologia do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Arquitetura Cloud Foundry . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Cloud Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2 Health Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.4 App Storage and Execution . . . . . . . . . . . . . . . . . . . . . 43
3.2.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.6 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.7 Message Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.8 Metrics and Logging . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Modelos Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Cenário 1 (Baseline) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1 Modelo de Disponibilidade para o UAA . . . . . . . . . . . . . . . 49
4.1.2 Modelo de Disponibilidade para o CC . . . . . . . . . . . . . . . . . 51

4.1.3 Modelo de Disponibilidade para o DEA . . . . . . . . . . . . . . . . 51
4.2 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Cenário 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Parâmetros de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Análise de Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Análise de Sensibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Referências Bibliográﬁcas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

14
1 Introdução
Atualmente o Brasil, assim como boa parte do mundo, está passando por uma
crise financeira que está diminuindo os postos de trabalho, fechando muitas empresas e
fazendo até com que o governo repense seus investimentos e políticas tributárias. Neste
cenário, setores e profissionais de Tecnologia da Informação (TI), que antes desempenhavam
apenas funções técnicas, estão ganhando espaço em setores de planejamento estratégico
nas empresas e organizações. O motivo disto é que muitos veem a TI como porta de
saída da crise, e esta "visão" do mercado faz com que os profissionais de TI ainda sejam
demandados e de certa forma valorizados.
A Computação em Nuvem (ou Cloud Computing em inglês) é um dos principais
exemplos desta mudança de perspectiva em relação ao mercado de TI nos últimos anos.
A adoção desta tecnologia permite que empresas escalonem suas infraestruturas virtuais
conforme a necessidade corrente, diminuindo assim, o custo de recursos (software, hardware,
recursos humanos entre outros) para criar e manter infraestruturas que, por ventura, podem
permanecer boa parte do tempo ociosa, devido à sazonalidade de alguns nichos do mercado
(VAQUERO et al., 2008; TAURION, 2009).
Outro fator positivo que a computação em nuvem possibilitou foi o surgimento de
uma infinidade de modelos de negócios digitais criados por empresas iniciantes (start-ups1
)
e que outrora era inimaginável, dado o montante de investimento inicial que precedia o
lançamento de serviços na web. O antigo modelo de distribuição em que o usuário compra
uma mídia física do software está dando lugar ao "as a Service", onde o usuário paga uma
quantia proporcional ao uso.
A computação em nuvem pode ser definida como um modelo que permite o acesso
conveniente a recursos computacionais (armazenamento, processamento, aplicações, ser-
viços, etc.) sob demanda que podem ser rapidamente provisionados e liberados com um
esforço mínimo de gerenciamento (MELL; GRANCE, 2011). Na computação em nuvem,
três paradigmas se tornaram bastante populares, são eles: Software as a Service (SaaS),
Platform as a Service (PaaS) e Infrastructure as a Service (IaaS), que tratam de diferentes
aspectos da computação tradicional e também possuem um público-alvo diferenciado (ver
1
O termo "start-up" define empresas recém-criadas que estão em fase de desenvolvimento de produto
ou serviço escalável e de alto impacto e trabalhando em condições de extrema incerteza. Muitas das
start-ups mais famosas trabalham com negócios digitais.

15
Seção 2.1 no Capítulo 2) (VAQUERO et al., 2008).
Neste contexto, soluções como a Plataforma como um Serviço (PaaS) estão mudando
a maneira como o software é produzido, distribuído e utilizado, afetando de forma positiva
o seu preço. Em geral, esses fenômenos ocorrem porque os provedores de PaaS oferecem
ferramentas para facilitar o desenvolvimento e implantação dos aplicativos e também tira
do desenvolvedor, ou empresa, o custo e a complexidade de comprar e gerir as camadas de
hardware e software subjacentes (GIESSMANN et al., 2014; MARSTON et al., 2011).
Na arquitetura tradicional de computação em nuvem, PaaS representa uma a
camada intermediária entre a IaaS e o SaaS, e seu propósito é prover um ambiente de
execução em que desenvolvedores externos (contratantes do serviço da plataforma) podem
implantar, executar, testar e gerir suas aplicações (VAQUERO et al., 2008; GIESSMANN
et al., 2014).
Nesta conjuntura, fatores de dependabilidade como disponibilidade e confia-
bilidade constituem os principais fatores de qualidade nestes negócios, pois quando um
serviço está indisponível ou operando de forma não satisfatória, o provedor do serviço
está gerando prejuízo, tanto por perder dinheiro por falta do uso dos serviços, quanto por
sofrerem multas por violações de Acordo de Nível de Serviço (SLA2
) e ainda prejuízos de
forma indireta, como por exemplo, ter sua imagem associada ao fornecimento de serviços
de baixa qualidade.
1.1 Motivação
Como foi destacado anteriormente, os atributos de dependabilidade são fatores de
qualidade importantíssimos para o provimento de serviços no modelos de computação em
nuvem. Também ficou claro o papel deste tipo de computação no mercado, reduzindo
custos de TI dentro das empresas e organização governamentais e fomentando o surgimento
de novos modelos de negócios digitais.
A avaliação de dependabilidade em ambientes de computação em nuvem é muito
importante para o planejamento, desenvolvimento e gerenciamento de serviços web que
estejam rodando sobre esta plataforma. Os fatores de dependabilidade na camada de IaaS
2
SLA é o acrônimo de "Service Level Agreement" em inglês, é uma documento que define o nível
de prestação de serviço entre uma empresa e seu cliente. Este tipo de contrato é muito usado por
provedores de serviços de TI.

16
já foram bastante exploradas na literatura, por outro lado, a camada de PaaS ainda carece
deste tipo de estudo.
A análise de dependabilidade pode ser feita de duas formas: a primeira é através de
medições no sistema real e a segunda é através do desenvolvimento de modelos analíticos.
A primeira abordagem é mais custosa e menos desejável, uma vez que este tipo de análise
é tipicamente feita de uma maneira a esperar que qualquer problema ocorra, o que pode
representar um problema em aplicações que já estejam em produção3
. Por outro lado, a
análise por modelagem pode ser feita de forma prévia e também é muito menos custosa
(OMIDI; MORADI, 2012).
Modelos analíticos são largamente usados para modelagem em várias áreas. Dentro
de TI, esses métodos já foram aplicados na avaliação de dependabilidade em: web services
(OMIDI; MORADI, 2012), computação em nuvem (camada de IaaS) (SOUSA et al.,
2014a), computação em nuvem móvel (MATOS et al., 2015), clusters virtuais (WEI et al.,
2011a), data centers (CALLOU et al., 2012), redes inteligentes (smart grid) (XIANG et
al., 2014), rejuvenescimento de software (KOUTRAS et al., 2009), infraestruturas de redes
(GUIMARÃES et al., 2011) entre outros. Em contrapartida, nos trabalhos de (ZHANG
et al., 2012) e (ZHOU et al., 2014), que também avaliam critérios de dependabilidade
(especificamente em PaaS), foram propostas estratégias que monitoram a plataforma
durante a execução e também foram desenvolvidas ferramentas com base nas propostas
para essa finalidade em ambos os trabalhos.
O presente estudo pode contribuir para que gestores de TI de empresas ou insti-
tuições governamentais, que oferecem serviços através da web, possam planejar melhor a
configuração de implantação de PaaS, mas especificamente o Cloud Foundry, que proporci-
one alta disponibilidade.
1.2 Objetivos
O objetivo deste trabalho é avaliar fatores de dependabilidade (disponibilidade e
confiabilidade) em PaaS tomando como estudo de caso a plataforma Cloud Foundry. Para
isso, serão empregadas técnicas como: modelagens hierárquicas e heterogêneas com cadeias
de Markov e diagrama de bloco de confiabilidade, análise de sensibilidade DoE e variações
3
Uma aplicação é considerada em produção quando esta já passou por todas as fases de desenvolvimento
(incluindo testes), foi implantada e já está sendo utilizadas por seus usuários.

17
paramétricas. Também serão propostos e examinados diferentes cenários de implantação
da plataforma Cloud Foundry. Pondo de forma mais específica, o presente trabalho possui
os seguintes objetivos:
• Propor modelos de dependabilidade para ambientes de PaaS;
• Identificar os componentes que mais influenciam na disponibilidade da plataforma;
• Recomendar uma configuração eficiente (em termos de recursos computacionais)
para a implantação de PaaS que suportem alta disponibilidade;
• Encontrar possíveis gargalos na dependabilidade da plataforma e sugerir mudanças
para supera-los.
1.3 Trabalhos Relacionados
Modelagem e avaliação de dependabilidade em sistemas computacionais estão em
alta. Entretanto, não foram encontrados estudos sobre modelagem de dependabilidade em
ambientes de PaaS através do uso de modelos analíticos até o momento. Desta forma, os
trabalhos relacionados estão divididos em dois grupos: trabalhos que avaliam aspectos de
dependabilidade aplicados no contexto de TI através de modelos analíticos, e trabalhos que
avaliam aspectos de dependabilidade especificamente em PaaS com o uso de outras técnicas.
A seguir, encontram-se alguns dos trabalhos que possuem maior relação com o presente, a
Tabela 1 exibe um comparativo entre os trabalhos, sendo que CTMC, SPN e RBD são os
modelos analíticos (ver Seção 2.3 no Capítulo 2) cadeias de Markov de tempo contínuo,
redes de Petri estocásticas e diagrama de blocos de confiabilidade respectivamente.
No trabalho de (BEZERRA et al., 2014), por exemplo, os autores avaliaram
a disponibilidade para serviço de streaming de vídeo (Video on Demand) sobre uma
plataforma de computação em nuvem (Eucalyptus4
). Foi usado uma estratégia hierárquica,
combinando CTMC e RBD para modelar a disponibilidade do sistema, bem com, uma
análise de sensibilidade para identificar os componentes mais críticos.
Em (SOUSA et al., 2014a) foi proposto uma estratégia de modelagem baseada
em uma modelagem hierárquica e heterogênea para o planejamento de infraestruturas
de computação em nuvem no estilo IaaS considerando exigências de dependabilidade e
de custo. Do mesmo modo, foi feito um estudo de caso com base em planejamento de
4
http://www.eucalyptus.com/

18
Tabela 1 – Comparação dos Trabalhos Relacionados.
Técnicas de Avaliação de Dependabilidade
Artigos
CTMC SPN RBD
Sem Modelos
Analíticos
Contexto / Aplicação em TI
(KOUTRAS; PLATIS, 2006)
√
Rejuvenescimento de Software
(ZHAO; SONG, 2008)
√
(KOUTRAS et al., 2009)
√
(CALLOU et al., 2010)
√ √
Data Centers
(WEI et al., 2011a)
√ √
Clusters Virtuais
(WEI et al., 2011b)
√ √ Data Center Virtuais Em
Nuvem
(GUIMARÃES et al., 2011)
√
Infraestrutura de Redes
(DANTAS et al., 2012b)
√ √
Computação em Nuvem / IaaS
(CALLOU et al., 2012)
√ √
Data Centers
(ZENG et al., 2012)
√ √
Redes Inteligentes
(DANTAS et al., 2012a)
√ √
(OMIDI; MORADI, 2012)
√ √
Web Services
(ZHANG et al., 2012)
√
Computação em Nuvem / PaaS
(SOUSA et al., 2013)
√ √
(OLIVEIRA et al., 2013)
√ √
Computação em Nuvem Móvel
(SOUSA et al., 2014a)
√ √
(XIANG et al., 2014)
√ √
Redes Inteligentes
(BEZERRA et al., 2014)
√ √
(SOUSA et al., 2014b)
√ √
(ZHOU et al., 2014)
√
(ARAUJO et al., 2014)
√ √ Aplicações mHealth em Nuvem
Móvel
(BRILHANTE et al., 2014)
√
(MELO et al., 2014)
√ √
(MATOS et al., 2015)
√ √
Computação em Nuvem Móvel
(SOUSA et al., 2015)
√ √
Este Trabalho
√ √
infraestrutura de nuvem para um ambiente virtual de aprendizagem (Moodle5
), com o
objetivo de ilustrar a viabilidade da estratégia da modelagem proposta.
No estudo desenvolvido por (MATOS et al., 2015) foi feita uma análise de sensi-
5
https://moodle.org/

19
bilidade em Mobile Cloud Computing utilizando diferentes técnicas, com o objetivo de
identificar quais os parâmetros que causam o maior impacto na disponibilidade deste
tipo de paradigma de computação em nuvem. Para isso, foi necessário uma modelagem
hierárquica através dos modelos analítico CTMC e RBD. O estudo encontrou um conjunto
reduzido de fatores que afetam de forma mais acentuada a disponibilidade, entre eles,
o destaque é o tempo necessário para substituição da bateria do dispositivo em caso de
descarga.
Em (WEI et al., 2011a) também foi escolhida uma estratégia de modelagem hierár-
quica e heterogênea, usando RBD e CTMC, para analisar a dependabilidade de clusters
virtuais. No trabalho, as máquinas virtuais e os servidores físicos foram representadas
por CTMC. Já para representar a estrutura global dos clusters foram utilizados RBD.
Dentre os atributos de dependabilidade analisados estão: confiabilidade, manutenabilidade
e disponibilidade. Ao final do trabalho, alguns resultados numéricos foram apresentados e
algumas sugestões úteis para projetar clusters virtuais, de forma eficaz, foram explanados
com base na análise dos resultados.
No artigo (WEI et al., 2011b) foi analisado a dependabilidade de data centers
virtuais em computação em nuvem. Novamente os pesquisadores utilizaram modelagem
hierárquica e heterogênea no estudo de caso. Entretanto, diferentemente do trabalho
anterior desenvolvido pelos mesmos pesquisadores (WEI et al., 2011a), neste a combinação
SPN e RBD foi adotada e os principais fatores de dependabilidade analisados foram
confiabilidade e disponibilidade.
O artigo de (DANTAS et al., 2012b) investiga os benefícios do mecanismo de
replicação warm-standy em diferentes arquiteturas baseadas na plataforma de computação
em nuvem Eucalyptus. A disponibilidade e o custo de aquisição foram mensurados no
estudo, e as falhas em hardware e software foram consideradas nos modelos analíticos
propostos. Novamente a técnica de modelagem hierárquica e heterogênea foi usada neste
estudo para melhor representar a estratégia de redundância e comparar a disponibilidade
para as arquiteturas apresentadas.
Em (ARAUJO et al., 2014) foram propostos um modelo de alto nível para ca-
racterizar o comportamento de Sistemas de Saúde Suportados por Dispositivos Móveis,
assim conhecidos na literatura como mHealth6
. Neste trabalho foram considerados a
6
mHealth ou m-health são abreviações do termo mobile health em inglês.

20
infraestrutura de computação em nuvem, a comunicação wireless7
e o dispositivo móvel
para a modelagem, que se deu através do uso dos modelos analíticos: SPN e RBD. O
estudo identificou que a métrica de maior impacto sobre a disponibilidade, no contexto
deste tipo de aplicações, é o tempo de espera das mensagens. Os resultados do estudo
sugerem que a troca por baterias mais eficientes, nos dispositivos móveis, podem melhorar
a disponibilidade.
Já no trabalho de (OMIDI; MORADI, 2012), a arquitetura de um sistema crítico
de votação pela internet baseado em web services foi descrita como um estudo de caso.
Atributos como confiabilidade, disponibilidade e segurança foram considerados. Também
foram propostas e comparadas arquiteturas com e sem redundância, onde a disponibilidade
usando redundância teve um aumento significativo em relação ao modelo sem redundância.
Diferentemente dos trabalhos acima, os trabalhos envolvendo avaliação de dependabilidade
em PaaS encontrados na revisão de literatura não o fazem através de modelos analíticos, e
sim através de estratégias que monitoram a plataforma em tempo de execução.
No artigo de (ZHANG et al., 2012) por exemplo, uma abordagem de modelagem de
desempenho em PaaS foi proposta e uma ferramenta para apoiar essa modelagem também
foi desenvolvida. Os autores usaram rastreamento na Layer Queue Network (LQN), ou
Camada de Fila de Rede em uma tradução literal, para modelar as interações entre a PaaS
e as aplicações nela hospedadas. O consumo de CPU, que é importante para a precisão
do modelo LQN, pôde ser refinado através do método de "Filtro de Kalman". Uma série
de experimentos de avaliação comparativa foram realizados e os resultados mostraram a
eficácia da abordagem.
Já no artigo de (ZHOU et al., 2014), foi apresentado uma estratégia e um template
base para a geração automática de scripts e casos de testes para mensurar o desempenho
de PaaS em nuvens privadas. Neste trabalho foi desenvolvida uma ferramenta chamada
Cloud Load Testing Framework (CLTF) que implementa a abordagem proposta no estudo.
Por fim, os pesquisadores fizeram um estudo empírico que mostrou que a abordagem
proposta pode diminuir significativamente o custo dos testes e ajudar a identificar possíveis
problemas de desempenho.
7
Comunicações sem fio.

21
1.4 Estrutura do TCC
Este TCC está organizado da seguinte forma. O Capítulo 2 apresenta os conceitos
fundamentais para o entendimento do estudo, como computação em nuvem e seus principais
paradigmas, avaliação de dependabilidade, modelos analíticos combinatórios e baseados
em estado e análise de sensibilidade. O Capítulo 3 mostra como foi desenvolvido o estudo
e uma descrição detalhada da plataforma avaliada no estudo de caso. O Capítulo 4 discute
primeiramente os modelos de mais alto nível na hierarquia e depois os de mais baixo
nível, que representam os Componentes ou Subsistemas da plataforma do estudo de caso.
Os resultados das avaliações de disponibilidade e confiabilidade bem como os da análise
de sensibilidade realizados no estudo de caso estão descritos no Capítulo 5. Por fim, o
Capítulo 6 apresenta as considerações finais deste estudo e propõe trabalhos futuros.

22
2 Fundamentação Teórica
Este capítulo introduz alguns conceitos fundamentais para o bom entendimento deste
trabalho, tais como: computação em nuvem na Seção 2.1, conceitos de dependabilidade
na Seção 2.2, modelos analíticos na Seção 2.3 e análise de sensibilidade na Seção 2.4. É
importante destacar que o conteúdo exposto ao longo deste capítulo serve como base para
melhor entender o trabalho, sendo que um material mais completo pode ser encontrado
nas referências.
2.1 Computação em Nuvem
A computação em nuvem (ou Cloud Computing em inglês) é um conceito que
surgiu na segunda metade da década de 2000, e revolucionou a forma como o software é
distribuído. A mídia física deu lugar ao pagamento de um valor referente ao uso de um
serviço.
Segundo o NIST (National Institute of Standards and Technology) (MELL; GRANCE,
2011), a computação em nuvem pode ser deﬁnida como um modelo que permite o acesso
conveniente a recursos computacionais (armazenamento, processamento, aplicações, servi-
ços e etc) sob demanda, que podem ser rapidamente provisionados e liberados com um
esforço mínimo de gerenciamento. O modelo de computação em nuvem é composto de
cinco características essenciais, três modelos de serviço e quatro modelos de implantação.
A seguir serão mencionados todos os aspectos de computação em nuvem encontrados em
(MELL; GRANCE, 2011).
Características Essenciais:
• Self-service sob demanda: Fazer com que o usuário possa providenciar capacidade
computacional (como processamento e armazenamento) de forma unilateral, conforme
necessário e sem precisar de interação humana com os provedores dos serviços.
• Acesso por Rede: Disponibilizar recursos através da rede e acessados através de
mecanismos padronizados que promova o uso por meio de um dispositivo cliente
(smartphones, tablets e computadores).
• Pooling de recursos: Providenciar os recursos computacionais em um pool para

23
servir múltiplos clientes, com diferentes recursos físicos e virtuais acolados dinami-
camente para suprir a demanda do usuário. A localização física destes recursos
computacionais é abstraída para o usuário final, podendo este apenas especificar a
localização geográfica em alto nível, como por exemplo o estado ou país.
• Elasticidade rápida: Possibilitar que recursos possam ser elasticamente provisi-
onados, em alguns casos automaticamente, para escalar rapidamente a demanda
do consumidor. Na perspectiva do usuário, os recursos disponíveis têm que parecer
ilimitados e acessível a qualquer momento e em qualquer quantidade.
• Serviço mensurável: Permitir que sistemas em nuvem controlem e otimizem, de
forma automática, o uso de recursos por meio de uma capacidade de medição em
algum nível de abstração apropriado para o tipo de serviço, como armazenamento,
processamento, largura de banda e contas ativas de usuários. De forma resumida, o
uso de recursos deve ser monitorado, controlado e relatado, proporcionando transpa-
rência para o provedor e o usuário do serviço utilizado.
Modelos de Serviços:
• SaaS: O modelo de Software como um Serviço (Software as a Service) proporciona
que o usuário use uma determinada aplicação disponível através da internet e acessível
via navegador ou por uma aplicação cliente em qualquer dispositivo. Em SaaS, o
usuário não gerencia nem controla a infraestrutura subjacente da nuvem, apenas
pode definir as configurações dos próprios aplicativos.
• PaaS: A Plataforma como um Serviço (Platform as a Service) providencia um
ambiente onde os desenvolvedores possam usar bibliotecas, serviços e ferramentas
disponibilizadas pelos provedores para criar, implantar e gerenciar aplicações. O
usuário (desenvolvedor) de PaaS não gerencia nem controla a infraestrutura subja-
cente na nuvem, porém tem controle sobre os aplicativos implantados e possivelmente
define as configurações no ambiente de hospedagem das aplicações.
• IaaS: A Infraestrutura como um Serviço (Infrastructure as a Service) é responsável
por fornecer processamento, armazenamento, rede e outros recursos computacionais
fundamentais que possibilitem o usuário implantar e executar um software arbitrário,
incluindo sistemas operacionais e aplicações. O usuário não pode gerir ou controlar
a infraestrutura subjacente da nuvem, mas tem o controle sobre os sistemas opera-

24
cionais, armazenamento e aplicativos implantados; e possivelmente tem o controle,
mesmo que limitado, de componentes de rede, como firewalls.
Modelos de Implantação:
• Nuvem privada: A infraestrutura de nuvem é implantada, localmente ou não,
para uso exclusivo por uma única organização, podendo ser gerenciada pela própria
organização, por terceiros ou ambos.
• Nuvem comunitária: A infraestrutura de nuvem é implantada para uso exclusivo
de um conjunto de organizações que compartilham dos mesmos interesses. O
gerenciamento dessa nuvem pode ficar por conta de algumas dessas empresas ou por
terceiros.
• Nuvem pública: A infraestrutura de nuvem é implantada nas instalações do
provedor e o serviço por ela oferecido é aberto e voltado para o público geral.
Este tipo de implantação pode ser gerenciada por empresas, instituições de ensino,
organizações governamentais ou uma combinação destas.
• Nuvem híbrida: Neste modelo de implantação, a infraestrutura de nuvem é com-
posta de dois ou mais infraestruturas distintas que permanecem como uma entidade
única, mas são ligadas por uma tecnologia padronizada ou proprietária que permita
a portabilidade de dados e aplicações.
Uma arquitetura típica de computação em nuvem é constituída por três paradigmas
principais, a IaaS, a PaaS e o SaaS (ver Figura 1). A IaaS é responsável por prover
uma infraestrutura com capacidade de processamento e armazenamento de forma virtual
e escalável. Já a PaaS tem como função hospedar as aplicações, ou seja, quando o
desenvolvedor (ou gerente de configuração), vai fazer a implantação da aplicação, essa fica
hospedada na PaaS. O SaaS é a camada de mais alto nível na computação em nuvem, e
em geral é constituída de uma aplicação e voltada para o usuário final, como por exemplo
o Moodle, Google Docs1
e Draw.io2
(VAQUERO et al., 2008; MELL; GRANCE, 2011). A
Figura 1, adaptada de (LV et al., 2010), mostra a relação entre a computação em nuvem e
a computação tradicional.
As PaaS estão mudando a maneira como o software é desenvolvido, utilizado e
1
https://www.google.com/docs/about/
2
https://www.draw.io/

25
Figura 1 – Relação entre a Computação em Nuvem e a Computação Tradicional.
distribuído. Na arquitetura convencional de computação em nuvem, a PaaS representa
uma camada intermediária entre a IaaS e o SaaS, e seu propósito é prover um ambiente de
execução em que desenvolvedores externos (contratantes do serviço da plataforma) podem
implantar, executar, testar e gerir suas aplicações (VAQUERO et al., 2008; GIESSMANN
et al., 2014).
Entre as principais plataformas de PaaS da atualidade estão: Google App Engine3
,
OpenShift4
, Cloud Foundry5
e Heroku6
(KRIZ, 2014). O Cloud Foundry foi selecionado
para o estudo de caso deste trabalho por ser uma plataforma de código aberto, gratuita e
popular no mercado. A Seção 3.2, e suas subseções, no Capítulo 3 descrevem com detalhes
a plataforma Cloud Foundry.
2.2 Dependabilidade
Em sua definição original, o termo dependabilidade (que é uma tradução literal do
termo Dependability, em inglês) diz respeito a capacidade de entrega de um serviço que
pode ser considerada confiável. O cuidado com dependabilidade não é algo exatamente
novo, em (AVIŽIENIS et al., 2001) há um relato sobre a preocupação com a confiabilidade
referente a Máquina Diferencial de Babbage em um artigo publicado em Julho de 1834,
intitulado "Babbages’s calculating engine" (LAPRIE et al., 1992; AVIŽIENIS et al., 2004).
Em TI a dependabilidade é fundamental para atrair novos usuários e manter a
satisfação e fidelidade destes. No entanto, a dependabilidade não é uma propriedade que
pode ser mensurada numericamente, pois se trata de um conceito integrado que engloba
3
https://appengine.google.com/
4
https://www.openshift.com/
5
https://www.cloudfoundry.org/
6
https://www.heroku.com/

26
vários atributos, podendo estes corresponderem a valores numéricos (AVIŽIENIS et al.,
2004). Entre os principais atributos de dependabilidade estão:
• Disponibilidade: A capacidade de um sistema estar de prontidão para prover um
serviço corretamente;
• Confiabilidade: A probabilidade que um sistema irá prover um serviço de forma
contínua até uma instante de tempo t;
• Segurança: Ausência de consequências catastróficas que poderiam afetar o(s)
usuário(s) e o ambiente;
• Integridade: Ausência de alterações impróprias no estado de um sistema;
• Manutenibilidade: A habilidade para sofrer reparos e modificações;
• Confidencialidade: Ausência de divulgação desautorizada de informação.
Figura 2 – Árvore de Dependabilidade adaptada de (AVIŽIENIS et al., 2004).
Avaliação da dependabilidade está ligada ao estudo do efeito de erros, defeitos e
falhas no sistema, uma vez que estes provocam um impacto negativo nos atributos de

27
dependabilidade. Uma falha (fault em inglês) é definida como a falha de um componente,
subsistema ou sistema que interage com o sistema em questão. Um erro é definido como
um estado que pode levar a ocorrência de uma falha. Um defeito (failure em inglês)
representa o desvio do funcionamento correto de um sistema (MACIEL et al., 2012).
Em (AVIŽIENIS et al., 2004) é apresentada, de maneira sistemática, uma exposição
dos conceitos de dependabilidade. A Figura 2 mostra a árvore de dependabilidade que
consistem em três partes, são elas:
• Atributos: os atributos possibilitam a obtenção de medidas quantitativas, que
muitas vezes são cruciais para a análise dos serviços oferecidos;
• Ameaças: que compreendem as falhas, os erros e os defeitos. A falha do sistema
representa o evento que ocorre quando a entrega do serviço não acontece de forma
correta;
• Meios: são os meios pelos quais a dependabilidade é atingida.
As próximas subseções descrevem de forma mais detalhada os principais atributos
de dependabilidade relacionados com o presente trabalho.
2.2.1 Confiabilidade
Na obra de (XIE et al., 2004) consta que a confiabilidade de um sistema é definida
como a probabilidade de que o sistema estaja operando de forma satisfatória e sem defeitos
durante um período de tempo específico. Matematicamente, a função de confiabilidade
R(t) representa a probabilidade de que um sistema será operado com sucesso sem falha no
intervalo de tempo de 0 até o tempo t, como mostra a Equação 2.1
R(t) = P(T > t), t ≥ 0 (2.1)
onde T é uma variável aleatória que representa o tempo para ocorrência de defeitos (XIE
et al., 2004).
Já a probabilidade de ocorrência de falha até um instante t, ou o inverso da
confiabilidade (unreliability), é mostrada através da Equação 2.2
F(t) = 1 − R(t) = P(T ≤ t) (2.2)

28
onde T é uma variável aleatória que representa o tempo para a ocorrência de falha no
sistema.
2.2.2 Disponibilidade
A disponibilidade é um atributo de dependabilidade que representa a capacidade
de um sistema em executar um serviço num determinado instante de tempo ou durante
um dado período de tempo (AVIŽIENIS et al., 2004). Possivelmente este é o atributo de
maior perceptividade do ponto de vista do usuário, principalmente através de sistemas
on-line. A importância deste fator é tanta, que na maioria dos SLA em serviços de TI
possuem cláusulas referentes a disponibilidade.
Neste quadro, duas medidas são muito importantes, uptime e downtime (XIE et al.,
2004). Uptime refere-se ao período de tempo em que um sistema está operacional. Já o
downtime diz repeito ao período de tempo em que um sistema está indisponível, também
conhecido popularmente como "fora do ar", devido a ocorrência de falhas ou até mesmo a
manutenção preventiva ou corretiva.
Algumas medidas em análise de disponibilidade possuem grande relevância, tais
como: tempo médio para falha (MTTF), tempo médio para reparo (MTTR) e tempo
médio entre falhas (MTBF). Esses índices serão descritos a seguir.
O MTTF (Mean Time to Failure) é o tempo médio para a ocorrência de falha no
sistema. Supondo que o a função de conﬁabilidade para um sistema é dada por R(t), o
MTTF pode ser calculado com a Equação 2.3 (XIE et al., 2004).
MTTF =
∞
0
t · f(t)dt =
∞
0
R(t)dt (2.3)
Quando por exemplo esse tempo médio segue a distribuição exponencial com
parâmetro λ, o MTTF pode ser representado pela Equação 2.4 (XIE et al., 2004). Em
(MACIEL et al., 2012) consta um resumo das distribuições.
MTTF =
∞
0
R(t)dt =
∞
0
exp(−λt)
=
1
λ
(2.4)
Por sua vez, o MTTR (Mean Time to Repair) é o tempo médio para reparo do
sistema. Quando a função de distribuição do tempo de reparo (tr) é representado por

29
uma distribuição exponencial com parâmetro µ, o MTTR é representado pela Equação 2.5
(XIE et al., 2004).
MTTR =
∞
0
1 − G(tr)dt =
∞
0
1 − exp(µ)tr
=
1
µ
(2.5)
Já o MTBF (Mean Time Between Failures) é o tempo médio entre ocorrências de
falha. O MTBF pode ser facilmente obtido através do MTTF e MTTR como é mostrado
na Equação 2.6 (XIE et al., 2004).
MTBF = MTTR + MTTF (2.6)
O valor de disponibilidade pode ser obtido em função do MTTF e do MTTR,
conforme a Equação 2.7 (XIE et al., 2004).
A =
MTTF
MTTF + MTTR
(2.7)
Quando o valor de MTTF é muito maior que o valor de MTTR, a disponibilidade
pode ser encontrada através da Equação 2.8 (MACIEL et al., 2012).
A =
MTBF
MTBF + MTTR
(2.8)
Existe ainda outras duas formas de representar a disponibilidade de sistemas, o
downtime anual e o número de noves, que são populares no mercado e frequentemente
usadas em SLA. O downtime anual representa o número estimado de horas em que um
sistema estará indisponível durante o período de um ano ou 8760 horas. Esse cálculo pode
ser feito com a Equação 2.9.
Downtimeanual = (1 − Disponibilidade) × 8760h (2.9)
A outra forma é usando o número de noves. O número de noves corresponde
a contagem dos algarismos 9 depois da vírgula. Por exemplo, dado um sistema com

30
disponibilidade de 0,9999 (ou 99,99%), o número de noves é igual a 4. O número de noves
é calculado com a Equação 2.10 (MARWAH et al., 2010).
Nof9s = −log10(1 − Disponibilidade) (2.10)
2.3 Modelos Analíticos
Modelos analíticos para modelagem de dependabilidade podem ser classificados
em dois grupos: modelos combinatórios (ou non-state space) e modelos baseados em
espaço de estado (ou state space). Entre os modelos analíticos combinatórios, os principais
são: Árvore de Falha (FT), Diagrama de Bloco de Confiabilidade (RBD) e Grafos de
Confiabilidade (RG). Já entre os modelos baseados em espaço de estados mais conhecidos,
estão: Cadeias de Markov de Tempo Contínuo (CTMC), Processos semi-Markov (SMP),
Redes de Petri Estocásticas (SPN) e Processo Regenerativo de Markov (MRGP). A Tabela
2, que foi adaptada de (TRIVEDI et al., 2009), mostra uma categorização destes modelos
(TRIVEDI et al., 1996; MACIEL et al., 2012).
Tabela 2 – Classificação dos Modelos Analíticos usados em Avaliação de Dependabilidade.
Modelos de Representação Formalismo
FT - Árvore de Falha
RBD - Diagrama de Bloco de ConfiabilidadeModelos Combinatórios
RG - Grafos de Confiabilidade
CTMC - Cadeias de Markov de Tempo Contínuo
SMP - Processos semi-Markov
SPN - Redes de Petri Estocásticas
GSPN - Redes de Petri Estocásticas Generalizadas
Modelos Baseados em Estados
MRGP - Processo Regenerativo de Markov
Os modelos baseados em estados representam o comportamento do sistema por
meio dos seus estados e a ocorrência de um evento é representada através de uma transição
entre estados. Tal transição pode ser uma função de distribuição, uma taxa ou uma
probabilidade. Esses modelos possibilitam a representação de relações mais complexas

31
entre os componentes, permitindo uma modelagem mais precisa de um sistema (MACIEL
et al., 2012).
Modelos baseados em estados são comumente usados para avaliação de dependabilidade,
no entanto, esses modelos tendem a ter um número bastante elevado de estados, criando
uma dificuldade na produção, armazenamento e solução dos mesmos. Por outro lado,
modelos combinatórios tiram proveito da estrutura do sistema evitando a geração e solução
de modelos baseados em estados. As limitações desses modelos combinatórios estão rela-
cionadas a suposições inerentes de independência estocástica e suposições de reparações
restritivas (VEERARAGHAVAN; TRIVEDI, 1994; NICOL et al., 2004).
Neste estudo foi adotada uma combinação entre os modelos analíticos RBD e CTMC
para melhor representar os aspectos da plataforma do estudo de caso, o Cloud Foundry.
Este tipo de modelagem é chamada de modelagem hierárquica e heterogênea. Hierárquica
porque faz o uso de um submodelo como um componente no "modelo principal". A
modelagem é considerado heterogênea por usar dois modelos analíticos diferentes. Essa
estratégia faz com que sejam aproveitadas as vantagens de cada classe de modelos analíticos.
2.3.1 Diagrama de Blocos de Confiabilidade
Diagrama de Blocos de Confiabilidade (Reliability Block Diagram ou RBD) é um
modelo combinatório que foi inicialmente proposto como uma técnica para cálculo de
confiabilidade em sistemas grandes e complexos usando diagramas de blocos intuitivos. Os
blocos são geralmente arranjados utilizando os seguintes mecanismos de composição: em
série, em paralelo, ponte e blocos k-out-of-n, uma combinação das composições anteriores
também é possível (TRIVEDI et al., 1996).
Um RBD é composto por arcos e por dois tipos de nós: blocos que representam
componentes do sistema e dummy nodes que representam o início e fim do diagrama. Em
qualquer instante de tempo, se existir um caminho no sistema a partir do dummy nodes
inicial até o dummy nodes final, ligados por arcos, o sistema é considerado operacional;
caso contrário, o sistema é considerado em falha. Se um componente (bloco) falha,
o caminho que passa por este componente deixa de existir, desta forma, os RBD são
recomendados para mapear as dependências de um sistema. Outra característica dos RBD
é a possibilidade de fazer cálculos de disponibibilidade e confiabilidade por intermédio de

32
fórmulas fechadas (NICOL et al., 2004; XIE et al., 2004).
Neste trabalho, os modelos representados por RBD estão arranjados em série ou em
combinação de série e paralelo. Supondo que um sistema é constituído por n componentes
(blocos) em série, a confiabilidade do sistema pode ser obtida com o cálculo da Equação
2.11. A Figura 3 representa visualmente um RBD em série, nela é possível notar que se
um dos componentes falhar, não existirá um caminho entre o nó inicial e final, tornando o
sistema indisponível caso isso ocorra.
Rs =
n
i=1
Ri (2.11)
Comp. 3Comp. 1 Comp. 2
Figura 3 – Exemplo de um RBD em Série.
Por outro lado, o arranjo em paralelo de um RBD permite que determinados
componentes falhem, desde que não todos, e mesmo assim exista um caminho entre o nó
inicial e o nó final. Considerando um sistema com n componentes numa composição em
paralelo, o número de componentes que podem falhar, mas mesmo assim manter o sistema
operando, é igual a (n − 1). A confiabilidade desse modelo pode ser calculada através da
equação 2.12. A Figura 4 ilustra um RBD com componentes em paralelo.
Comp. n
Comp. 1
Comp. 2
Figura 4 – Exemplo de um RBD em Paralelo.
Rp = 1 −
n
i=1
(1 − Ri) (2.12)

33
2.3.2 Cadeias de Markov
Uma Cadeia de Markov7
é um processo probabilístico, proposto em 1906 por
Andrey Markov, que apresenta a propriedade markoviana em que os estados anteriores
são irrelevantes para a predição dos estados seguintes, para isso, o estado atual deve
necessariamente ser conhecido. Esses modelos analíticos são muito usados em descrição
de análises estatísticas onde os parâmetros são valores temporais, sendo conhecidos como
processos estocásticos (CASSANDRAS; LAFORTUNE, 2006).
Um processo estocástico X(t), t ∈ T é um conjunto de variáveis aleatórias deﬁnidas
sobre o mesmo espaço de probabilidades, indexadas pelo parâmetro de tempo (t ∈
T) e assumindo valores no espaço de estados (si ∈ S). Desta forma, se T for um
conjunto discreto, o processo é dito de tempo discreto. Já se o conjunto T for formado de
parâmetros contínuos, o processo é chamado de Cadeias de Markov de Tempo Contínuo
(CASSANDRAS; LAFORTUNE, 2006).
As cadeias de Markov são aplicadas nas mais variadas áreas, como em economia,
física e em química. O modelos de Markov são largamente utilizados na modelagem de
dependabilidade desde os anos 50 (MACIEL et al., 2012). Em computação, os processos
Markovianos são adequados para descrever e analisar propriedades dinâmicas e complexas
de sistemas computacionais, como por exemplo, as dependências entre componentes
(BOLCH et al., 2006; BEZERRA et al., 2014).
Cadeias de Markov de tempo contínuo (Continuous-time Markov Chain ou CTMC)
é um modelo analítico baseado em estado, que representa o comportamento do sistema
em termos de estados (operacional e indisponível) e em probabilidade de ocorrência de
eventos (falha e reparo) entre as transições de estados. CTMC é um dos modelos baseados
em espaço de estados que possibilitam a derivação de uma fórmula fechada, no entanto,
essa tarefa pode ser inviável para ser feita por humanos, e geralmente são utilizados
softwares para essa ﬁnalidade, como o Wolfram Mathematica8
(MACIEL et al., 2012;
CHEN; TRIVEDI, 2002).
Matematicamente, uma CTMC pode ser representada através de uma matriz de
transição de estados Q, onde a probabilidade estacionária de cada estado πi corresponde à
7
Em homenagem ao Matemático Russo Andrey Andreyevich Markov
8
https://www.wolfram.com/mathematica/

34
solução da Equação 2.13
πQ = 0 (2.13)
As CTMC também podem ser representadas graficamente por meio de círculos
simbolizando os estados e arestas correspondendo as transições entre estados. A Figura
5 e a Equação 2.14 exemplificam uma cadeia de Markov de forma gráfica e matemática
respectivamente (BOLCH et al., 2006). Esse exemplo pode ser entendido como um sistema
com dois estados possíveis, disponível (U) e indisponível (D), com λ representando a taxa
de falha e µ representando a taxa de reparo.
Figura 5 – Exemplo de uma CTMC.
Q =





−λ λ
µ −µ





(2.14)
2.4 Análise de Sensibilidade
A análise de sensibilidade é uma técnica utilizada para determinar os fatores que
possuem maior relevância sobre as medidas ou saídas de um modelo. Em análise de
dependabilidade de sistemas computacionais, é possível aplicar a análise de sensibilidade
para auxiliar na identificação dos componentes que mais influenciam para a disponibilidade,
confiabilidade ou desempenho de um sistema (HAMBY, 1994).
De acordo com (HAMBY, 1994), existe um consenso entre autores que os modelos
são de fato sensíveis a duas formas distintas de parâmetros de entrada: a variabilidade, ou
incerteza, associada a um parâmetro de entrada sensível tem uma grande contribuição à

35
variabilidade da saída global; e pode haver uma alta correlação entre um parâmetro de
entrada e os resultados do modelo, ou seja, pequenas mudanças nos valores de entrada
resultam em mudanças significativas na saída.
Uma análise de sensibilidade pode ser feita por meio de diferentes métodos, entre eles
estão: análise diferencial, análise de correlação, análise de regressão, análise de perturbação
e DoE, que foi usado neste trabalho (HAMBY, 1994; BEZERRA et al., 2014).
Design of Experiments (DoE) é uma técnica que tem a finalidade de encontrar o
efeito de cada fator (componente) dentro de um experimento, considerando a interação
entre eles sobre uma métrica de interesse. Alguns termos são importantes em DoE,
como: variável resposta, fatores e níveis. As variáveis respostas são o resultado de em
experimento, como por exemplo o valor de disponibilidade. Os fatores são cada uma das
variáveis que podem afetar a variável resposta, um exemplo relacionado com este estudo
são os componentes da PaaS. Já os níveis tratam dos valores que cada fator pode assumir,
como exemplo a quantidade de instâncias que um determinado componente pode ter, ou
seja, considerando que um componente pode ter no mínimo uma instância e no máximo n
instâncias, os níveis deste componente (fator) seriam {1, 2, 3, ..., n} (JAIN, 1991).
São vários os tipos de DoE, sendo que os mais utilizados são os projetos simples, os
projetos fatoriais fracionários e os projetos fatoriais completos (JAIN, 1991).
Um projeto simples (ou simple designs) é um experimento feito com uma configura-
ção inicial básica e variando apenas um fator de cada vez a fim de observar o quanto este
afeta o resultado global. Este tipo de experimento é pouco eficiente se determinado fator
interage com outro, sendo que uma avaliação isolada do fator pode resultar em conclusões
erradas. O número n de experimentos desta abordagem pode ser conhecido com o cálculo
da Equação 2.15 (JAIN, 1991).
n = 1 +
k
i=1
(ni − 1) (2.15)
onde k é o número de fatores, com o i-ésimo fator tendo ni níveis.
Já em um projeto experimental de fatorial completo (ou DoE full factorial), todas
as possíveis combinações de fatores e níveis são utilizadas. A vantagem do DoE de fatorial
completo é que todas as combinações possíveis são examinadas. Em contrapartida, essa
abordagem pode ser muito onerosa caso o número de fatores ou de níveis seja elevado. A

36
Equação 2.16 permite obter o número total de experimentos (JAIN, 1991).
n =
k
i=1
(ni) (2.16)
onde k é o número de fatores, com o i-ésimo fator tendo ni níveis.
Uma alternativa muito popular para reduzir o custo com projeto de fatorial completo
é usar projetos 2k
. Este tipo de DoE consiste em reduzir o número de níveis de cada fator
para 2, e com isso, determinar a importância relativa de cada um dos fatores. Sendo assim,
o número de experimentos possíveis é encontrado com a Equação 2.17, sendo que k é o
número total de fatores. Após encontrar quais os fatores mais importantes, pode-se tentar
mais experimentos com uma quantidade maior de níveis por fator (JAIN, 1991).
n = 2k
(2.17)

37
3 Metodologia de Avaliação de
Dependabilidade de um Sistema
PaaS
Neste capítulo será apresentada a metodologia usada no desenvolvimento do estudo
e uma descrição da Plataforma com um Serviço usada no estudo de caso. A Seção 3.1
mostra como o estudo foi feito, através de um ﬂuxograma (ver Figura 6), e descreve cada
etapa deste. Já na Seção 3.2, a plataforma Cloud Foundry foi caracterizada com detalhes,
nela estão os principais componentes, como esses componentes interagem, dependências de
outros softwares e outros detalhes imprescindíveis para melhor modelar a plataforma.
3.1 Metodologia do Estudo
A metodologia para a avaliação de atributos de dependabilidade em PaaS realizada
neste estudo está dividida em 5 etapas, são elas: revisão de literatura, entendimento da
plataforma, identiﬁcação das métricas de interesse, modelagem e análises dos resultados.
A Figura 6 mostra um diagrama contendo as etapas do trabalho e a ordem em que as
mesmas foram realizadas.
Revisão de Literatura
Nesta primeira etapa foi feita uma revisão de literatura com o principal objetivo de
fazer um levantamento dos trabalhos que tratam de análises de dependabilidade em
sistemas de computacionais e modelagem através de modelos baseados em estados
e modelos combinatoriais. Entre as principais fontes de buscas, mas não as únicas,
estão ACM Digital Library1
, Web of Science2
, ScienceDirect3
, Springer Link4
e
IEEEXplore5
, essa última responsável pela maioria dos trabalhos.
1
http://dl.acm.org/
2
https://www.webofknowledge.com
3
http://www.sciencedirect.com/
4
http://link.springer.com/
5
http://ieeexplore.ieee.org/Xplore/home.jsp

38
Revisão de Literatura
Entendimento da Plataforma
Modelagem
Análise dos Resultados
Modelo
Representa a
Plataforma
Identificar Métricas de Interesse
Sim
Não
Figura 6 – Etapas da Pesquisa.
Entendimento da Plataforma
Nessa fase, o foco foi na compreensão da plataforma. Foram identificados quais os
principais componentes, suas funções, suas limitações, requisitos para operarem e
como eles interagem uns com os outros. A plataforma escolhida para o estudo de
caso foi o Cloud Foundry e os resultados desta etapa estão descritos detalhadamente
na Seção 3.2.
Identificar Métricas de Interesse
Nessa etapa foram definidas as métricas de dependabilidade que seriam avaliadas
neste trabalho. As métricas abordadas são disponibilidade e confiabilidade.
Modelagem
Na quarta etapa foram construídos os modelos com base em informações obtidas nas
etapas anteriores. Foi adotada a estratégia de modelagem hierárquica e heterogênea
para melhor capturar as peculiaridades da plataforma Cloud Foundry. Primeira-
mente foram feitos modelos, com CTMC ou RBD, para representar os subsistemas
da plataforma. Os valores de MTTF e MTTR encontrados através dos modelos dos

39
subsistemas serviram como entrada para os modelos dos cenários propostos feitos pos-
teriormente. No caso dos modelos não representarem corretamente o comportamento
do sistema, então o fluxo do estudo é direcionado para a etapa de entendimento da
plataforma novamente, como mostrado na Figura 6. Todos os modelos resultantes
desta etapa estão expostos ao longo do Capítulo 4.
Análise dos Resultados
Após todos os modelos estarem concluídos, foi possível extrair e analisar os resultados.
Dentre os resultados encontrados estão: a disponibilidade dos componentes da
plataforma; a disponibilidade e confiabilidade dos cenários propostos; o impacto da
variação de parâmetros como o MTTF e MTTR dos componentes, na plataforma;
componentes mais sensíveis a adição de nós redundantes. Essa fase é discutida no
Capítulo 5.
3.2 Arquitetura Cloud Foundry
Em (CORRADI et al., 2014) é definido que o Cloud Foundry é um software de
código aberto (ou open source) que provê Plataforma como um Serviço (PaaS). O Cloud
Foundry foi inicialmente desenvolvido pela VMware6
, em 2011, e escrito em Ruby7
. O
principal objetivo da plataforma é facilitar e acelerar a implantação e o gerenciamento de
aplicações nela hospedadas, abstraindo assim, boa parte da complexidade dessas tarefas.
Esse gerenciamento pode ser feito tanto através de uma interface web acessada por um
navegador qualquer, quanto através de um aplicativo via linha de comando (CLI) (HOSSNY
et al., 2013; KRIZ, 2014).
O Cloud Foundry é uma plataforma robusta e dinâmica, oferecendo suporte a uma
série de linguagens de programação, como Java8
, Ruby, Python9
e PHP10
, também suporta
alguns dos frameworks mais populares atualmente, como por exemplo o Ruby on Rails11
,
6
http://www.vmware.com/br
7
https://www.ruby-lang.org/
8
https://www.oracle.com/java/index.html
9
https://www.python.org/
10
http://www.php.net/
11
http://rubyonrails.org/

40
o Sinatra12
, o Node.js13
e o Spring14
(CLOUDFOUNDRYDOCS, 2015; KRIZ, 2014).
Além disso, o Cloud Foundry possibilita o uso de serviços externos, através do
componente "Services" (ver Subseção 3.2.6), como sistemas de gerenciamento de banco de
dados (SGBD) SQL (MySQL15
e PostgreSQL16
) e NoSQL (Redis17
, MongoDB18
e Cassan-
dra19
), ferramentas de integração contínua (Jenkins20
) e APIs Mobile para sincronização
de dados, notificações "push" e etc (CLOUDFOUNDRYDOCS, 2015; KRIZ, 2014).
Na escolha do Cloud Foundry como plataforma para o estudo de caso, duas caracte-
rísticas foram fundamentais: ser acessível e popular. O Cloud Foundry foi considerada uma
plataforma acessível por ter seu código fonte aberto21
e ser disponibilizada gratuitamente,
isso possibilitou que testes localmente (através do Nise Installer22
) e remotamente (por
intermédio do provedor Pivotal23
) fossem feitos para a obtenção de conhecimentos práticos,
além disso, a documentação oficial é completa e de qualidade (HOSSNY et al., 2013;
CLOUDFOUNDRYDOCS, 2015).
A popularidade da plataforma pode ser constatada pelo fato do projeto Cloud
Foundry ser apoiado por conceituadas empresas como General Electric24
, HP25
e IBM26
.
Outro aspecto que demostra a popularidade são os provedores de PaaS que utilizam o Cloud
Foundry, entre eles desatacam-se: Pivotal, IBM Bluemix27
, Swisscom28
, CenturyLink29
e
Anynines30
(CLOUDFOUNDRYORG, 2015; KRIZ, 2014).
Este trabalho adotou a versão corrente do Cloud Foundry (versão v2) que é composta
por vários componentes, os mais importantes e que serão tratados no estudo são: o Cloud
Controller (CC), o Health Manager (HM), o Router, os Droplet Execution Agents (DEA),
12
http://www.sinatrarb.com/
13
https://nodejs.org/en/
14
http://spring.io/
15
https://www.mysql.com/
16
http://www.postgresql.org/
17
http://redis.io/
18
https://www.mongodb.org/
19
http://cassandra.apache.org/
20
http://jenkins-ci.org/
21
https://github.com/cloudfoundry
22
https://github.com/yudai/cf_nise_installer
23
http://pivotal.io/platform
24
http://www.ge.com/
25
http://www8.hp.com/br/pt/home.html
26
http://www.ibm.com/br-pt/
27
http://www.ibm.com/Bluemix
28
https://www.swisscom.ch/en/business/enterprise/offer/cloud-data-center-services.html
29
http://www.centurylink.com/business/enterprise/cloud/cloud-computing.html
30
http://www.anynines.com/home

41
o User Account and Authentication (UAA), o Message Bus (MB), o Metrics Collector
(MC), o Blob Store (BS) e a interface para serviços de terceiros chamada de (Services)
(CORRADI et al., 2014; CLOUDFOUNDRYDOCS, 2015).
A Figura 7, que é uma adaptação da documentação oficial da plataforma, mostra
a arquitetura do Cloud Foundry, contendo seus principais componentes e separados por
camadas.
Figura 7 – Arquitetura do Cloud Foundry.
A maioria dos componentes do Cloud Foundry são horizontalmente escaláveis e
self-healing31
, desta forma, é possível adicionar várias cópias destes componentes conforme
necessário a fim de suportar a carga de entrada da nuvem. As comunicações internas,
geridas através do NATS, proporcionam um nível de interação em sua maior parte
assíncrona e sem bloqueio. Isto significa que um componente não corre o risco de acabar
em "impasse" à espera de uma resposta de outro. Além disso, todos os componentes
são de baixo acoplamento, não tendo conhecimento das definições dos outros módulos
(os componentes são dinamicamente detectados e eles podem ser lançados e escalado
em qualquer ordem). Em grandes ambientes distribuídos, cada componente pode ser
replicado a fim de gerir de forma segura o aumento da carga de trabalho e novas requisições
(CORRADI et al., 2014).
Nas próximas subseções serão apresentados maiores detalhes sobre os principais com-
ponentes da plataforma. A Tabela 3 mostras as dependências de software dos componentes
31
Em TI, o termo "self-healing" diz respeito a capacidade que um software tem em perceber que não
está funcionando corretamente e executar ações para corrigir as causas deste problema e voltar a
operar normalmente. Tudo este processo acontece sem nenhuma intervenção humana.

42
e suas respectivas linguagens de implementação.
Tabela 3 – Dependências e linguagens de implementação dos componentes.
Componente Dependências de Software
Linguagens de
Implementação
Router (gorouter) Não requer software adicional. Go32
UAA
JVM;
Tomcat33
;
SGBD (PostgreSQL ou MySQL).
Java
Cloud Controller
Nginx34
;
Interpretador Ruby (IR);
SGBD (PostgreSQL, MySQL ou SQLite35
).
Ruby
Health Manager Não requer software adicional. Go
DEA
Interpretador Ruby (IR);
Warden Container.
Ruby e Go
Message Bus (gnatsd) Não requer software adicional. Go
Metrics Collector Interpretador Ruby (IR). Ruby
3.2.1 Cloud Controller
O Cloud Controller36
(CC) é o subsistema responsável por gerenciar o ciclo de vida
das aplicações. Quando um desenvolvedor vai implantar uma aplicação no Cloud Foundry,
esse processo é iniciado no Cloud Controller, que em seguida armazena os binários, cria
um registro para rastrear os metadados e direciona um nó DEA para preparar e rodar
a aplicação. Além de manter metadados sobre a aplicação, este componente também
armazena informações sobre serviços, instâncias de serviços, funções de usuários e outras
conﬁgurações (CORRADI et al., 2014; CLOUDFOUNDRYDOCS, 2015).
32
https://golang.org/
33
http://tomcat.apache.org/
34
http://nginx.org/
35
https://www.sqlite.org/
36
https://github.com/cloudfoundry/cloud_controller_ng

43
Como o CC é escrito em Ruby, é necessário um interpretador para executar este
componente. Outra dependência deste componente é um SGBD, entre as possíveis opções
estão o MySQL, o PostgreSQL e o SQLite. O CC ainda possui outra particularidade,
a necessidade de um servidor de aplicação (Nginx), isto se dá porque este componente
precisa ser acessado "de fora" da plataforma.
3.2.2 Health Manager
O Health Manager37
(HM) é um subsistema que tem como objetivo principal o
monitoramento e a recuperação da aplicação em caso de falha ou mau funcionamento.
Quando o Health Manager detecta um problema em uma aplicação, ele executa deter-
minados procedimentos que "instruem" o Cloud Controller a criar uma nova instância
da aplicação. O monitoramento dessas aplicações é feito através de "heartbeats" e de
mensagens (droplet.exited) emitidas pelo DEA. Uma aplicação pode estar em vários esta-
dos, como por exemplo, running, stopped, crashed e etc. O Health Manager é escrito em
Go e não requer nenhum software adicional para ser executado (CORRADI et al., 2014;
CLOUDFOUNDRYDOCS, 2015).
3.2.3 Router
O funcionamento do subsistema Router38
é análogo ao dos roteadores, ou seja, sua
principal função é direcionar o tráfego de rede, externo, para os componentes apropriados,
geralmente o Cloud Controller ou uma aplicação que esteja sendo executada em algum nó
DEA. Outra função deste componente é fazer o balanceamento de carga (BERNSTEIN,
2014; CLOUDFOUNDRYDOCS, 2015). O Router também é escrito em Go e não possui
dependênias de outros softwares.
3.2.4 App Storage and Execution
Possivelmente a App Storage and Execution é a camada mais importante do Cloud
Foundry, pois é nela que a aplicação hospedada rodará. Esta camada é constituída de nós
37
https://github.com/cloudfoundry/hm9000
38
https://github.com/cloudfoundry/gorouter

44
DEA e do Blob Store (CLOUDFOUNDRYDOCS, 2015).
Os Droplet Execution Agents39
(DEA) têm várias funcionalidades fundamentais,
entre elas estão: executar as "ordens" vindas do Cloud Controller referentes ao ciclo de vida
de cada instância das aplicações e transmitir o status destas para outros componentes, como
o Health Manager. As instâncias das aplicações ﬁcam dentro de "containers" chamado
Warden, isso garante a execução isolada das instâncias e um compartilhamento justo de
recursos (CLOUDFOUNDRYDOCS, 2015; BERNSTEIN, 2014; CORRADI et al., 2014).
O Warden40
tem como principal objetivo fornecer uma API simples para o ge-
renciamento de ambientes isolados. Esses ambientes isolados, ou containers, podem ser
limitados em termos de uso da CPU, uso de memória, uso de disco e acesso à rede
(CLOUDFOUNDRYDOCS, 2015).
O DEA é escrito em Ruby e C, já o Warden é escrito em Go e Ruby. Este estudo
considerou apenas o DEA como componente do Cloud Foundry a ser modelado, com o
IR e o Warden como dependências, pois o Warden roda dentro de um nó DEA. Esse
encapsulamento faz sentido, dado que uma falha no Warden também derruba o DEA e
uma falha no Interpretador Ruby afeta ambos.
O outro componente da camada de App Storage and Execution é o Blob Store. O
Blob Store (BS) é o componente que detém o código fonte das aplicações, os Buildpacks e
os Droplets. É um dos poucos componentes que não podem ser horizontalmente escalados,
pois são executados em instâncias únicas (CLOUDFOUNDRYDOCS, 2015).
3.2.5 Authentication
O User Account and Authentication41
(UAA) é o serviço de gerenciamento de
identiﬁcação do Cloud Foundry. Este componente atua como um servidor OAuth242
onde
sua principal função é emitir tokens para as aplicações clientes. O Login Server43
é outro
componente da camada de autenticação, e este é responsável por autenticar os usuários
(desenvolvedores) com suas credenciais do Cloud Foundry (CLOUDFOUNDRYDOCS,
2015; BERNSTEIN, 2014).
39
https://github.com/cloudfoundry/dea_ng
40
https://github.com/cloudfoundry/warden
41
https://github.com/cloudfoundry/uaa
42
http://oauth.net/2/
43
https://github.com/cloudfoundry/login-server

45
Diferentemente da maioria dos outros componentes, esses dois são escritos em Java
e possuem a JVM como um requisito obvio. Ambos os subsistemas desta camada requerem
também um SGBD (PostgreSQL ou MySQL) e o servidor de aplicação Tomcat.
Na modelagem deste trabalho, apenas o UAA foi considerado, pois os modelos
analíticos usados partem da premissa que os componentes já estão em pleno funcionamento.
3.2.6 Services
O Cloud Foundry oferece a possibilidade de integrar serviços de terceiros a pla-
taforma por meio de Service Brokers. Os Services Brokers, ou simplesmente Services,
podem ser vistos como interfaces entre a plataforma e aplicações externas. Os Services
são qualquer tipo de add-on que pode ser provisionado ao lado de aplicações web, tais
como bancos de dados SQL e não-SQL, sistema de mensagens, APIs e etc (CORRADI et
al., 2014; KRIZ, 2014). No estudo, esse componente será considerado como sendo uma
única instância de um serviço genérico.
3.2.7 Message Bus
O Message Bus44
(MB) é um sistema de filas de mensagens distribuído que usa o
padrão de projeto publish-subscribe e é responsável por gerir a comunicação interna entre
os componentes (CLOUDFOUNDRYDOCS, 2015). O MB é escrito em Go e como os
demais, não requer software adicionais para seu funcionamento.
3.2.8 Metrics and Logging
Essa camada possui dois componentes, o Metrics Collector45
(MC) e o App Log
Aggregator. O Metrics Collector tem a função de coletar métricas dos outros componentes.
Já o App Log Aggregator pega o fluxo de logs da aplicação que está sendo executada,
essa característica é muito útil para os desenvolvedores (CLOUDFOUNDRYDOCS, 2015).
Assim como o Loggin Server, o App Log Aggregator será desconsiderado pelo fato de não
influenciar diretamente no fornecimento do serviço.
44
https://github.com/cloudfoundry/gorouter
45
https://github.com/cloudfoundry/collector

46
Uma observação importante neste componente é que ele é escrito em Ruby, logo
possui a dependência do IR, entretanto, não foi usada modelagem hierárquica para esse
subsistema, pois o único ponto de falha é justamente no IR.

47
4 Modelos Propostos
Este capítulo apresenta os modelos propostos no estudo. Uma modelagem hierár-
quica e heterogênea usando CTMC e RBD foi adotada para melhor representar os aspectos
arquiteturais da plataforma Cloud Foundry, modelada nos estudos de caso.
Ao todo foram propostos três cenários. O primeiro cenário trata da configuração
de implantação mais simples possível, sem nenhum componente redundante. A Seção
4.1 trata deste primeiro cenário, e em suas subseções são mostrados os modelos para
a obtenção dos valores de disponibilidade dos componentes compostos por mas de um
software, como é o caso do UAA (Subseção 4.1.1), do CC (Subseção 4.1.2) e do DEA
(Subseção 4.1.3). Não foi possível modelar o UAA por meio de RBD por conta de suas
especificações. Desta forma, optou-se por usar cadeias de Markov para essa finalidade. Os
demais componentes foram modelados com RBD e todos os componentes são mostrados
de forma gráfica e são formalizados matematicamente.
Tabela 4 – Parâmetros de Disponibilidade dos Componentes do Cloud Foundry.
Componente Parâmetro de Disponibilidade
Router DRouter
UAA DUAA
HM DHM
CC DCC
DEA DDEA
Message Bus DMB
Metrics Collector DMC
Blob Store DBS
Services DServices
O segundo cenário (Seção 4.2) foi inspirado na documentação oficial de plataforma
e introduz componentes redundantes. O terceiro cenário (Seção 4.3) aplica uma política
de redundância mais efetiva em alguns dos componentes. Vale ressaltar que foi possível
modelar todas os cenários através de RDB e que estes estão representados graficamente e

48
matematicamente. A Tabela 4 mostra os parâmetros de disponibilidade dos componentes
do Cloud Foundry que constam nas equações que representam os cenários propostos. Os
valores para esses parâmetros serão mostrados no Capítulo 5.
4.1 Cenário 1 (Baseline)
O primeiro cenário proposto é o mais simples e servirá de base para a comparação
com os demais, por este motivo, os subsistemas não possuem redundância. O cenário 1
está modelado com RDB. Isso foi viável graças a estratégia de modelagem hierárquica, ou
seja, os subsistemas mais complexos foram modelados a parte e estão representados por
um bloco nesse modelo.
A Figura 8 representa graficamente o modelo em RBD, sendo que os blocos com
preenchimento em cinza estão representando componentes que possuem submodelos, já
os blocos com preenchimento em branco não possuem submodelos. Os demais RBD que
representam os cenários propostos (Figuras 12 e 13) também estão usando blocos com
preenchimento cinza pelo mesmo motivo. A Equação 4.1 representa, matematicamente, o
cenário 1.
UAA HM CC DEA MB MS BS ServicesRouter
Figura 8 – Modelo RBD para o cenário 1.
DCenario_1 = DRouter × DUAA × DHM × DCC × DDEA ×
DMB × DMC × DBS × DServices (4.1)
Por se tratar de um modelo em série, a falha de um único componente compromete
a disponibilidade de todo o sistema, pois neste caso, não haveria um caminho ligando o nó
inicial ao nó final.
Vale salientar que esta é a configuração mínima para executar o Cloud Foundry.
Sendo assim, esta configuração não é indicada para ser implantada em ambientes de
produção, porém é indicada para ambiente de desenvolvimento, pois é o cenário que requer
menos recursos computacionais.

49
4.1.1 Modelo de Disponibilidade para o UAA
Como é possível observar na Tabela 3 (pág. 42), o componente UAA tem como
requisito três softwares, são eles: a JVM, o servidor de aplicação Tomcat e um sistema
de gerenciamento de banco de dados. É importante destacar que se a JVM deixar de
funcionar, o Tomcat também para, e isso ocorre porque o Tomcat também roda sobre a
JVM. Neste caso, a reparação da JVM e do Tomcat (µJV M−TC) são considerados como
sendo um único evento e a reparação apenas do Tomcat (µTC) outro. A modelagem deste
componente em cadeias de Markov é apresentada na Figura 9 e a fórmula fechada deste
modelo na Equação 4.2.
Figura 9 – Representação do UAA por CTMC.
DUAA =
µSGBD × µJV M−TC × (λJV M × µTC)
(λSGBD + µSGBD) × (λJV M + µJV M−TC) × (λJV M + λTC + µTC)
(4.2)
Na representação gráﬁca da CTMC (Figura 9) que modela o componente UAA, o
status dos componentes internos estão representados em temos de U (Up) e D (Down)
e ordenados na seguinte forma: JVM, Tomcat e SGBD. Para as taxas de falha e reparo
foram usadas as letras gregas λ e µ respectivamente. O valor da taxa de falha é obtido

50
através da divisão de 1 pelo MTTF, o mesmo cálculo é feito para a taxa de reparo, ou seja,
1 dividido pelo valor do MTTR. Além dessas letras gregas, cada "label" possui um sufixo
com um acrônimo do componente representado por ele. O estado com preenchimento em
cinza representa o estado onde o subsistema está disponível.
O estado inicial UUU (em cinza) significa que todos os três componentes represen-
tados nesse modelo estão em pleno funcionamento. Os demais estados representam algum
tipo de falha do sistema. Com a falha da JVM (λJV M ), o sistema vai para o estado DDU,
pois como o Tomcat precisa da JVM para funcionar, ele também é afetado. Nesse estado,
a JVM e o Tomcat podem ser reparados (µJV M_TC), e o sistema retorna para o estado
UUU. Ainda neste estado (DDU), pode acontecer uma falha no SGBD (λSGBD), com isso,
o sistema passaria para o estado DDD. O estado UUU possui mais duas possibilidades de
transição, uma delas é a falha apenas do Tomcat (λTC), fazendo com que o sistema vá
para o estado UDU; a outra é a falha no SGBD (λSGBD), direcionando o sistema para o
estado UUD.
Estando no estado UDU, uma reparação no Tomcat (µTC) leva o sistema para o
estado de disponibilidade UUU, uma falha no SGBD (λSGBD) direciona a plataforma para
o estado UDD e uma falha apenas na JVM (λJV M ) deixa o sistema no estado DDU. Já
se o sistema estiver no estado UUD, as seguintes transições são possíveis: uma falha no
Tomcat (λTC) leva o sistema para o estado UDD; uma falha na JVM (λJV M ) também
afetará o Tomcat, e neste caso, o sistema vai direto para o estado DDD; a última transição
deste estado está relacionada a reparação do SGBD (µSGBD), fazendo com que o sistema
vá para o estado UUU e fique disponível novamente.
Os outros dois estados são o UDD e o DDD. O estado UDD permite uma reparação
no Tomcat (µTC), fazendo com que o sistema seja direcionado para o estado UUD. A
segunda transição deste estado é feita com a reparação do SGBD (µSGBD) e encaminha o
fluxo para o estado UDU. Já a terceira transição possível é uma falha na JVM (λJV M),
levando o sistema para o estado DDD. No estado DDD, todos os componentes estão em
falha, logo, todas as possibilidades de transição estão relacionadas com os reparos dos
componentes. Um reparo no SGBD (µSGBD) faz uma transição para o estado DDU. Por
outro lado, o reparo da JVM e do Tomcat (µJV M_TC) promove uma transição para o
estado UUD.

51
4.1.2 Modelo de Disponibilidade para o CC
Ao contrário do UAA, os requisitos do CC são todos independentes entre si, no
entanto, todos precisam funcionar para o subsistema se manter operacional. Com essa
característica, é possível modelar esse subsistema com o uso de RBD. A disponibilidade
deste cenário pode ser facilmente encontrada resolvendo a Equação 4.3. A representação
gráfica do modelo deste cenário é apresentada na Figura 10.
IR SGBDNginx
Figura 10 – Representação do CC em RBD.
DCC = DNginx × DIR × DSGBD (4.3)
onde DNginx, DIR e DSGBD são os valores de disponibilidade para o Servidor de
aplicação Nginx, o Interpretador Ruby e o SGBD respectivamente.
Neste modelo em RBD, que representa o CC, os blocos estão dispostos em série,
ou seja, no caso da falha de um destes subcomponentes, o Cloud Controller também fica
indisponível. Isso acontece porque o CC é uma aplicação web escrita em Ruby e que acessa
um banco de dados. O primeiro bloco representa o servidor de aplicação (Nginx), que é
indispensável para qualquer tipo de aplicação web. O bloco IR representa o interpretador
da linguagem Ruby, sendo este responsável por ler e executar os códigos fontes (arquivos
.rb) da aplicação. Já o terceiro bloco diz respeito a um SGBD, podendo este ser o MySQL
ou o PostgreSQL, que também é necessário para o CC.
4.1.3 Modelo de Disponibilidade para o DEA
O DEA requer apenas dois softwares para se manter em pleno funcionamento,
mas a indisponibilidade de qualquer um deles também faz com que o sistema fique
indisponível. Novamente, os requisitos de software são independentes entre si, e isso
possibilita a modelagem através de RBD. O diagrama mostrado na Figura 11 representa

52
graﬁcamente o modelo de disponibilidade do subsistema. A fórmula fechada para o cálculo
de disponibilidade está descrita na Equação 4.4.
WardenIR
Figura 11 – Representação do DEA em RBD.
DDEA = DIR × DWarden (4.4)
onde DIR e DWarden são os valores de disponibilidade para o Interpretador Ruby e
o Warden respectivamente.
Novamente usou-se um RBD em série para modelar um componente da plataforma,
pois os subcomponentes são independentes entre si, no entanto, a falha em um deles
também afetará o DEA.
4.2 Cenário 2
O segundo cenário possui redundância e foi inspirado na documentação oﬁcial do
Cloud Foundry (CLOUDFOUNDRYDOCS, 2015). Neste cenário, todos os subsistemas
que suportam escalabilidade horizontal possuem um nó redundante, com exceção do DEA,
que possui dois nós, dado que este é o subsistema mais suscetível a erros e o que precisa
de mais recursos em momentos de alta demanda, pois é nele que as aplicações serão
executadas. A Figura 12 mostra o modelo em RBD deste cenário e a disponibilidade pode
ser encontrada com a Equação 4.5.
UAA 2 HM 2 CC 2
DEA 3
MB 2 MS 2
BS Services
Router 2
Router 1 UAA 1 HM 1 CC 1
DEA 1
DEA 2
MB 1 MS 2

53
DCenario_2 = (1 − (1 − DRouter)2
) × (1 − (1 − DUAA)2
) ×
(1 − (1 − DHM )2
) × (1 − (1 − DCC)2
) ×
(1 − (1 − DDEA)3
) × (1 − (1 − DMB)2
) ×
(1 − (1 − DMC)2
) × DBS × DServices (4.5)
4.3 Cenário 3
Como os subsistemas UAA, CC e DEA são os componentes que possuem uma maior
interação com outros subcomponentes necessários para o funcionamento destes, como é o
caso de interpretadores de linguagens e SGBDs por exemplo, optou-se por inserir mais
um nó redundante em cada um desses componentes no cenário 3 em relação ao cenário 2.
No terceiro cenário proposto também foi inserido mais um nó em paralelo do componente
DEA, novamente o motivo disto foi porque este componente é o mais suscetível a erros,
pois é nele que as aplicações estão rodando.
O propósito deste cenário é atacar os possíveis pontos de maior fraqueza em relação
ao Cenário 2. A Figura 13 mostra o modelo em RBD deste cenário e a Equação 4.6 pode
ser usada para encontrar o valor de disponibilidade.
UAA 3
HM 2
CC 3
DEA 5
MB 2 MS 2
BS Services
Router 2
Router 1
UAA 1
UAA 2
HM 1
CC 1
CC 2
MB 1 MS 1
DEA 1
DEA 2
DEA 3
DEA 4

54
DCenario_3 = (1 − (1 − DRouter)2
) × (1 − (1 − DUAA)3
) ×
(1 − (1 − DHM )2
) × (1 − (1 − DCC)3
) ×
(1 − (1 − DDEA)5
) × (1 − (1 − DMB)2
) ×
(1 − (1 − DMC)2
) × DBS × DServices (4.6)

55
5 Estudo de Caso
Neste capítulo serão mostrados os resultados encontrados nas análises feitas no
estudo de caso da plataforma Cloud Foundry. A Seção 5.1 mostra os parâmetros de
entrada dos subcomponentes. A Seção 5.2 discute a análise de dependabilidade, nela são
apresentados os resultados de disponibilidade e confiabilidade do sistema, considerando os
cenários de implantação propostos e uma análise de variação dos parâmetros de entrada
dos modelos dos cenários. Já na Seção 5.3 são expostos os resultados obtidos por meio da
análise de sensibilidade, como quais os componentes de maior impacto na adição de nós
redundantes, qual a configuração de melhor custo-benefício relacionando a disponibilidade
com o número de nós e qual a configuração mínima para se obter uma disponibilidade
maior que 99%.
5.1 Parâmetros de Entrada
Para os componentes que não necessitam de uma composição de software, como
máquinas virtuais, interpretadores, servidores de aplicação e sistemas de gerenciamento de
banco de dados, os valores de disponibilidade foram obtidos por intermédio dos trabalhos
de (DANTAS et al., 2012a) e (KIM et al., 2009), os demais (CC, DEA e UAA) foram
encontrados através de modelos analítico. A Tabela 5 mostra os valores de disponibilidade
para softwares e SGBD, que servem como parâmetros de entrada para os modelos dos
componentes.
Tabela 5 – Valores de Disponibilidade para Software e Banco de Dados.
Componentes MTTF (Horas) MTTR (Horas) Disponibilidade (%)
Software 788,4 1,0 99,8733215
SGBD 1440,0 1,0 99,9306037

56
5.2 Análise de Dependabilidade
O primeiro atributo de dependabilidade tratado nesta seção é a disponibilidade
dos componentes do Cloud Foundry. Como foi comentado na Seção 5.1, os valores de
disponibilidade dos componentes UAA, CC e DEA foram encontrados por intermédio de
modelos analíticos, os demais valores foram definidos com base na literatura.
Tabela 6 – Disponibilidade dos Componentes do Cloud Foundry.
Componente Disponibilidade (%) Disponibilidade (noves)
Router 99,87332 2,8972919453
UAA 99,67830 2,4925489391
HM 99,87332 2,8972919453
CC 99,67758 2,4915780264
DEA 99,74680 2,5965362987
MB 99,87332 2,8972919453
MC 99,87332 2,8972919453
Blob Store 99,87332 2,8972919453
Services 99,87332 2,8972919453
Os resultados para disponibilidade dos componentes do Cloud Foundry estão na
Tabela 6. Como é possível observar, os três componentes de menor disponibilidade são
o UAA, o CC e o DEA. O que esses componentes têm em comum são o fato de terem
dependências de outros software para funcionarem, e isso pode justificar o porquê dos
valores de disponibilidade serem menor que os demais componentes.
Os valores de disponibilidades dos três cenários propostos foram calculados e estão
resumidos na Tabela 7. A diferença de disponibilidade entre o cenário 1 e os demais é
bastante expressiva, e isso é facilmente justificável pelo fato dos componentes não terem
redundância. O Downtime anual de mais de 144 horas também chama a atenção, e
dependendo do contexto da aplicação que esteja rodando, esse fato pode se tornar um
empecilho para a viabilidade de um projeto.
Já os cenários 2 e 3 possuem uma diferença de disponibilidade relativamente pequena,
mesmo com a aplicação de uma política de redundância mais efetiva nos componentes de

57
Tabela 7 – Disponibilidade dos Cenários.
Métricas Cenário 1 Cenário 2 Cenário 3
Disponibilidade (%) 98,35446 99,74409 99,74616
Disponibilidade (No
de 9’s) 1,7836905 2,5919169 2,5954341
Uptime Anual (horas) 8615,7547 8737,5676 8737,7486
Downtime Anual (horas) 144,2553 22,4324 22,2514
menor disponibilidade no cenário 3. Esse efeito se deu por conta dos componentes Services
e Blob Store não serem horizontalmente escaláveis, desta forma, os cenários 2 e 3 ficaram
com dois pontos de falha únicos e isso deteriora a disponibilidade da plataforma.
Em relação aos componentes de instância única, uma estratégia para mitigar
possíveis problemas é manter uma rotina rígida de backups, como é o caso do Blog Store.
Já no caso do Services, a estratégia de mitigação pode variar muito de serviço para serviço,
mas no geral, se o Service em questão for uma interface para um SGBD, também é indicado
a prática de backups constantes.
A confiabilidade dos cenários também foi avaliada, para isso foi adotado um intervalo
de tempo entre 0 e 500 horas, dividido em 31 pontos com diferença de um pouco mais de
16 horas entre eles. A escolha do intervalo se deu por conta de todos os cenários estarem
muito próximos de 0.0 em 500 horas após o início da execução.
0
0.2
0.4
0.6
0.8
1
0 100 200 300 400 500
Confiabilidade
Tempo (horas)
Cenário 1
Cenário 2
Cenário 3
Figura 14 – Confiabilidade dos Cenários.
Os resultados da confiabilidade mostram que os cenários 2 e 3 ficaram muito
próximos, principalmente no início e no final do intervalo avaliado, enquanto que o cenário
1 ficou bem distante dos demais.

58
A Figura 14 mostra que a confiabilidade no momento inicial é igual a 1.0 (100%).
Logo nos primeiros momentos de tempo, por volta das 16 primeiras horas, o cenário 1
já se separa dos demais e tem uma queda drástica para menos de 80% de confiabilidade.
Aproximadamente ás 50 horas de execução, os valores de confiabilidade dos cenários 2 e
3 começam a se separar, já a diferença do cenário 1 para os demais é de quase 40%, e
isso se mantém até as primeiras 150 horas, quando essa diferença começa a diminuir. Em
aproximadamente 215 horas, o cenário 1 já está com a confiabilidade abaixo de 3% e após
282 horas a confiabilidade é menor que 1%. Conforme o tempo vai chegando em 300 horas,
a confiabilidade dos cenários 2 e 3 começam a se aproximar novamente. No instante de
tempo equivalente a 431 horas, todos os cenários estão com confiabilidade menor que 5%.
Foi observado com esta análise que a confiabilidade do cenário 1 sofre uma queda
brusca já primeiros instantes de tempo, já a confiabilidade dos cenários 2 e 3 vão caindo
de forma mais suave ao longo do tempo. O outro fenômeno identificado com a análise
foi que os cenários 2 e 3 possuem um comportamento similar ao longo do tempo, como
exceção do intervalo de tempo entre 50 e 150 horas aproximadamente.
Complementarmente às análises de disponibilidade e confiabilidade, foi possível
também, calcular as variações de alguns parâmetros usados nos modelos. Neste trabalho,
os parâmetros que tiveram essa avaliação estão relacionados na Tabela 8 em termos de
MTTF e MTTR. É importante observar que os parâmetros de MTTF e MTTR do Router
também estão representando os componentes HM, MB, MC, BS e Services. Esta convenção
foi adotada porque esses componentes possuem os mesmos MTTF e MTTR.
A variação nos parâmetros foi feita com base no cenário 1 (ver Figura 8 na pág.
48), ou seja, a disponibilidade do cenário 1 é calculada para cada um dos valores escolhidos
ao longo de um intervalo.
A variação paramétrica feita nos valores de MTTF dos componentes avaliou 19
instantes de tempo, começando de 100 horas e terminando em 1000 horas, sendo que
cada instante de tempo é incrementado em 50 horas. Os gráficos com essas variações
mostram a disponibilidade variando conforme o instante de tempo e uma linha tracejada
representando a disponibilidade baseline.
Os gráficos da variação de MTTF de CC (Figura 15) e do UAA (Figura 17) tiveram
um comportamento bastante parecido, isso se deu por conta da pequena diferença nos
valores de MTTF destes componentes.

59
Tabela 8 – Parâmetros Avaliados com Variações nos Valores.
Parâmetro Valor (Horas)
MTTFRouter 788,4
MTTRRouter 1,0
MTTFDEA 393,944707812
MTTRDEA 1,0
MTTFUAA 309,848616791
MTTRUAA 1,0
MTTFCC 309,1544569
MTTRCC 1,0
As variações do MTTF nos componentes CC (Figura 15), DEA (Figura 16) e UAA
(Figura 17) mostram que seria possível aumentar um pouco a disponibilidade da plataforma
por meio de medidas que aumentem o MTTF destes componentes. Em contrapartida, o
efeito causado com uma possível diminuição do MTTF teriam um efeito, negativo, mais
acentuado que o aumento do mesmo na disponibilidade destes componentes.
Já na variação de MTTF dos demais subsistemas, representados nesta análise pelo
Router (ver Figura 18), o ganho em disponibilidade através do aumento do MTTF é pouco
expressivo, possivelmente porque o valor de MTTF destes componentes são maiores que
os do CC, DEA e UAA. Analisando a diminuição do MTTF, é possível observar que
inicialmente a variação não inﬂuencia muito, a queda drástica na disponibilidade só iria
acontecer se o MTTF diminuísse para valor menores que 500 horas.
0.97
0.975
0.98
0.985
0.99
100 200 300 400 500 600 700 800 900 1000
Disponibilidade
MTTF CC (horas)
Baseline
Figura 15 – Variação de MTTF para o CC.

60
0.97
0.975
0.98
0.985
0.99
100 200 300 400 500 600 700 800 900 1000
Disponibilidade
MTTF DEA (horas)
Baseline
Figura 16 – Variação de MTTF para o DEA.
0.97
0.975
0.98
0.985
0.99
100 200 300 400 500 600 700 800 900 1000
Disponibilidade
MTTF UAA (horas)
Baseline
Figura 17 – Variação de MTTF para o UAA.
0.97
0.975
0.98
0.985
0.99
100 200 300 400 500 600 700 800 900 1000
Disponibilidade
MTTF Router (horas)
Baseline
Figura 18 – Variação de MTTF para o Router.
A variação paramétrica feita nos valores de MTTR foi realizada usando um intervalo
de tempo diferente da feita para os valores de MTTF. Desta vez avaliou-se 21 instantes de

61
tempo, com o instante de tempo inicial igual a 0.5 hora e no ﬁnal igual a 2.5 horas, sendo
que cada instante de tempo foi incrementado a cada 0.1 hora.
Ao contrário do MTTF, as variações dos valores de MTTR estão distribuídas
em retas descendentes. Os gráﬁcos referentes ao CC (Figura 19), DEA (Figura 20)
e UAA (Figura 21) estão bastante parecidos. As inclinações das retas dos valores de
disponibilidade mostram que estes componentes são muito sensíveis a variações, tanto
positivas quanto negativas, no MTTR. Ou seja, pequenas variações implicam em grande
efeito na disponibilidade.
Por outro lado, a variação no MTTR dos demais componentes (Figura 22) se
mostrou mais estável que nos três componentes anteriores. Logo, aumentos ou reduções
no valor de MTTR não teriam um impacto tão grande na disponibilidade como nos casos
do CC, DEA e UAA.
0.97
0.975
0.98
0.985
0.99
0.5 1 1.5 2 2.5
Disponibilidade
MTTR CC (horas)
Baseline
Figura 19 – Variação de MTTR para o CC.
0.97
0.975
0.98
0.985
0.99
0.5 1 1.5 2 2.5
Disponibilidade
MTTR DEA (horas)
Baseline
Figura 20 – Variação de MTTR para o DEA.

62
0.97
0.975
0.98
0.985
0.99
0.5 1 1.5 2 2.5
Disponibilidade
MTTR UAA (horas)
Baseline
Figura 21 – Variação de MTTR para o UAA.
0.97
0.975
0.98
0.985
0.99
0.5 1 1.5 2 2.5
Disponibilidade
MTTR Router (horas)
Baseline
Figura 22 – Variação de MTTR para o Router.
Através dessa análise foi possível identiﬁcar que variações nos parâmetros de
MTTR dos componentes causam maior impacto na disponibilidade da plataforma que os
parâmetros de MTTF. Essa conclusão sugere que os esforços, para alcançar um bom valor
de disponibilidade, sejam direcionados à diminuição do MTTR dos componentes do Cloud
Foundry. Essa redução do tempo de reparo dos componentes pode ser alcançada através
da identiﬁcação e solução rápida dos problemas que causaram a falha.
5.3 Análise de Sensibilidade
Para a análise de sensibilidade foi usada a técnica de projeto experimental de
fatorial completo (DoE). Nessa análise foram utilizadas combinações de nós que variam
do cenário 1 até o cenário 3, com um total de 720 experimentos. Foram adotados duas
variáveis resposta para cada uma dessas combinações, disponibilidade e número de nós.

63
Os fatores, níveis e valores usados na análise estão expostos na Tabela 9. O objetivo
dessa análise é identificar o impacto das políticas de redundância dos componentes na
disponibilidade da plataforma.
Tabela 9 – Fatores, níveis e valores da análise DoE.
Fator Níveis Valores
Router 2 1, 2
UAA 3 1, 2, 3
HM 2 1, 2
CC 3 1, 2, 3
DEA 5 1, 2, 3, 4, 5
MB 2 1, 2
MC 2 1, 2
Essa análise DoE foi dividida em três partes. A primeira parte tinha o objetivo
de identificar quais os componentes de maior sensibilidade em relação a adição de nós
redundantes. Já a segunda parte tinha como objetivo encontrar a configuração de melhor
custo-benefício se tratando de alta disponibilidade e menor número de nós, e ainda verificar
quão viável seria este resultado comparado aos cenários pospostos. Na terceira parte foi
feita uma variação no número de nós redundantes, da melhor forma possível, tomando como
base o cenário 1 e variando o número de nó até chegar em uma disponibilidade de 2 noves,
o objetivo era encontrar a quantidade mínima de nós para manter uma disponibilidade
maior ou igual a 99%, dado que essa disponibilidade já é aceitável para uma boa parcela
das aplicações.
Primeiramente foi identificado que os componentes de maior sensibilidade na adição
de nós redundantes são o UAA (Figura 23(b)), o CC (Figura 23(d)) e o DEA (Figura
23(e)), sendo que o DEA possui uma sensibilidade menor que os outros dois. Nessa parte da
análise foi usado apenas a disponibilidade como métrica de interesse. As linhas tracejadas
nos gráficos da Figura 23 representam a média da disponibilidade no experimento.
Como mostrado na Figura 23, a adição de um nó redundante eleva, de forma
significativa, a disponibilidade, mesmo nos componentes de menor sensibilidade, como
é o caso do Router, MB, HM e do MC. Já a adição de um terceiro nó redundante não

Dependabilidade PaaS Cloud Foundry

Dependabilidade PaaS Cloud Foundry

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Dependabilidade PaaS Cloud Foundry

Semelhante a Dependabilidade PaaS Cloud Foundry (20)

Dependabilidade PaaS Cloud Foundry