tcc: avaliação de dependabilidade e análise de sensibilidade de uma plataforma como serviço...

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ÁLISEDE 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 NogueiraUniversidade Federal Rural de Pernambuco – UFRPE


Profa. Kádna Maria Alves Camboim ValeUniversidade Federal Rural de Pernambuco – UFRPE


À 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)

ResumoA 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

AbstractCloud 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 configuration 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 identifies 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 – Confiabilidade 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 – Classificaçã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 Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.2 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Modelos Analíticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1 Diagrama de Blocos de Confiabilidade . . . . . . . . . . . . . . . . 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áficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 (ver1 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 dasstart-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 IaaS2 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 porprovedores 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ções3 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 de4 http://www.eucalyptus.com/

18

Tabela 1 – Comparação dos Trabalhos Relacionados.

Técnicas de Avaliação de DependabilidadeArtigos

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 a6 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 definida 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 e1 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 engloba3 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 confiabilidade 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 definidas

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 finalidade, 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 Markov8 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

PaaSNeste 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 fluxograma (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, identificaçã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.com3 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/br7 https://www.ruby-lang.org/8 https://www.oracle.com/java/index.html9 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 Installer 22) 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/cloudfoundry22 https://github.com/yudai/cf_nise_installer23 http://pivotal.io/platform24 http://www.ge.com/25 http://www8.hp.com/br/pt/home.html26 http://www.ibm.com/br-pt/27 http://www.ibm.com/Bluemix28 https://www.swisscom.ch/en/business/enterprise/offer/cloud-data-center-services.html29 http://www.centurylink.com/business/enterprise/cloud/cloud-computing.html30 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 componentes31 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 aoperar 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 Controller 36 (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

configuraçõ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 Manager 37 (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 Router 38 é 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ós37 https://github.com/cloudfoundry/hm900038 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 ficam 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

identificaçã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 Server 43 é 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_ng40 https://github.com/cloudfoundry/warden41 https://github.com/cloudfoundry/uaa42 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 Collector 45 (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/gorouter45 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 (µJVM−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 × µJVM−TC × (λJVM × µTC)

(λSGBD + µSGBD)× (λJVM + µJVM−TC)× (λJVM + λTC + µTC)(4.2)

Na representação gráfica 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 (λJVM ), 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 (µJVM_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 (λJVM) 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 (λJVM) 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 (λJVM),

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 (µJVM_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

graficamente 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 oficial 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

Co

nfi

ab

ilid

ad

e

Tempo (horas)

Cenário 1Cenário 2Cená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 influencia 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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

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 final 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áficos 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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

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

Dis

po

nib

ilid

ad

e

MTTR Router (horas)

Baseline

Figura 22 – Variação de MTTR para o Router.

Através dessa análise foi possível identificar 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 identificaçã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

64

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3

Méd

ia d

e D

isp

on

ibilid

ad

e

(a) Router

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3 3.5 4

Méd

ia d

e D

isp

on

ibilid

ad

e

(b) UAA

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3

Méd

ia d

e D

isp

on

ibilid

ad

e

(c) HM

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3 3.5 4

Méd

ia d

e D

isp

on

ibilid

ad

e

(d) CC

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 1 2 3 4 5 6

Méd

ia d

e D

isp

on

ibilid

ad

e

(e) DEA

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3

Méd

ia d

e D

isp

on

ibilid

ad

e

(f) MB

0.99

0.9905

0.991

0.9915

0.992

0.9925

0.993

0.9935

0 0.5 1 1.5 2 2.5 3

Méd

ia d

e D

isp

on

ibilid

ad

e

(g) MC

Figura 23 – Resultados da Análise de Sensibilidade.

eleva a disponibilidade de forma tão evidente, a Figura 23(e) exemplifica muito bem este

fenômeno, pois a partir de dois nós redundantes, a disponibilidade aparenta ser constante.

Na segunda parte da análise foi feita uma otimização através da análise DoE, só

que desta vez usando duas variáveis resposta, a disponibilidade e o número de nós. Foi

considerando como melhor resultado, a maior disponibilidade obtida com o menor número

de nós.

Com a otimização foi possível concluir que o cenário de melhor custo-benefício é

constituído de 11 nós, distribuídos da seguinte forma: 1 nó para o Router, MB, MC, BS e

Services; 2 nós para UAA, HM, CC e DEA. Este cenário oriundo da otimização ficou com

o valor de disponibilidade igual a 0, 9936534 (ou 2, 19745887261 em número de noves), a

Figura 24 mostra a diferença de disponibilidade entre os três cenários propostos e esse novo

cenário (Cenário DoE) resultante da otimização. Da mesma forma, a Figura 25 mostra o

65

downtime anual.

Embora a disponibilidade deste cenário esteja bem melhor que o cenário 1, ainda

não está perto da disponibilidade dos cenários 2 e 3, e isso acontece por conta dos pontos

únicos de falha.

0.98

0.985

0.99

0.995

1

#1 #2 #3 #DoE

Dis

po

nib

ilid

ad

e

Cenários

Baseline

Figura 24 – Disponibilidade dos Cenários.

0

20

40

60

80

100

120

140

160

180

#1 #2 #3 #DoE

Do

wn

tim

e A

nu

al (h

ora

s)

Cenários

Baseline

Figura 25 – Downtime anual dos cenários.

Por fim, foi feito uma variação do número de nó redundantes a fim de obter um

valor de disponibilidade de dois noves, o cenário 1 foi tomado como base para essa variação.

66

Observou-se que as prioridades de redundância estão nos subsistemas UAA, CC e DEA.

Com a adição de um nó redundante, o componente CC fica com 2 nós e a dispo-

nibilidade do sistema passa de 0, 9835445 para 0, 9867156. Com dois nós redundantes,

um no CC e outro no UAA, a disponibilidade do sistema aumenta para 0, 9898899. A

disponibilidade de dois noves só é alcançada com três nós redundantes, esse terceiro é

adicionado ao DEA e com isso a disponibilidade fica em 0, 9923963. Os Resultados desta

variação estão resumidos na Tabela 10.

Tabela 10 – Distribuição dos Nós Redundantes.

DistribuiçãoNúmero de Nós RedundantesUAA CC DEA

Disponibilidade (%)

0 0 0 0 98,35445

1 0 1 0 98,67156

2 1 1 0 98,98899

3 1 1 1 99,23963

67

6 Considerações Finais

Diante da revolução vivida no mercado de TI, onde a computação em nuvem

está mudando a forma como o software é distribuído, a qualidade dos atributos de

dependabilidade é cada dia mais determinante para o sucesso de negócios digitais. As

PaaS têm sua importância neste contexto, uma vez que esse modelo de serviço é o que

mais está "perto" das empresas.

Este estudo teve como objetivo explorar alguns fatores de dependabilidade em PaaS,

para encontrar possíveis problemas em sua implantação e propor solução para contorna-los.

Para alcançar esse propósito, foi selecionada uma plataforma (Cloud Foundry) para ser

desenvolvido um estudo de caso, onde alguns cenários de implantação foram considerados

e avaliados. Para tal avaliação, foram empregadas técnicas como análise de sensibilidade e

modelagem de dependabilidade por meio de RBD e CTMC.

Ao longo do estudo foram observados vários aspectos interessantes entre os cenários

propostos, um deles foi em relação confiabilidade dos cenários, onde o cenário 1 se

mostrou muito menos confiável que os demais. Outro ponto observado foi em relação ao

"comportamento" dos cenários 2 e 3, pois estes dois cenários tiveram resultados bastante

parecidos nas análises feitas.

A variação paramétrica nos valores de MTTR revelou que pequenas mudanças

podem afetar significativamente a disponibilidades da plataforma, e isso é um indício de

que os esforços para o aumento de disponibilidade devem ser concentrados na redução dos

tempos de reparo dos componentes.

Foi identificado que os componentes Services e Blob Store são os grandes responsáveis

por prejudicar a disponibilidade da plataforma, isso foi constatado em várias ocasiões

durante a interpretação dos resultados obtidos com a modelagem dos cenários. O principal

motivo para isso é que estes componentes não podem ser configurados para operarem com

redundância, fazendo com que surjam pontos únicos de falha.

Com a análise de sensibilidade foi possível encontrar os componentes mais sensíveis

a adição de nós redundantes, foram eles: DEA, UAA e CC. A análise de sensibilidade

também mostrou que a implantação da plataforma com dois nós para cada componente

melhora substancialmente a disponibilidade, por outro lado, uma configuração com três

nós por componente se mostrou pouco eficiente.

68

6.1 Trabalhos Futuros

Assim como qualquer pesquisa, esta também apresenta limitações. Uma das

limitações diz respeito a quantidade de estudos de caso, pois só foram realizadas análises de

dependabilidade em apenas uma plataforma. Outra limitação é que não foram considerados

fatores externos na modelagem, como por exemplo a camada de IaaS e o hardware.

Como trabalhos futuros, propõe-se explorar as limitação deste estudo, mencionadas

anteriormente. Para tanto, pretende-se realizar novos estudos de caso com outras PaaS

(OpenShift por exemplo) e considerando outros atributos de dependabilidade que não foram

cobertos neste trabalho. Outro possível estudo pode considerar a IaaS na modelagem.

69

Referências Bibliográficas

ARAUJO, J.; SILVA, B.; OLIVEIRA, D.; MACIEL, P. Dependability evaluation of amhealth system using a mobile cloud infrastructure. p. 1348–1353, Outubro 2014.

AVIŽIENIS, A.; LAPRIE, J.-C.; RANDELL, B. Fundamental Concepts of Dependa-bility. 2001.

AVIŽIENIS, A.; LAPRIE, J.-C.; RANDELL, B.; LANDWEHR, C. Basic concepts andtaxonomy of dependable and secure computing. Dependable and Secure Computing,IEEE Transactions on, v. 1, n. 1, p. 11–33, Janeiro 2004. ISSN 1545-5971.

BERNSTEIN, D. Cloud foundry aims to become the openstack of paas. Cloud Compu-ting, IEEE, v. 1, n. 2, p. 57–60, Julho 2014. ISSN 2325-6095.

BEZERRA, M. C.; MELO, R.; DANTAS, J.; MACIEL, P.; VIEIRA, F. Availabilitymodeling and analysis of a vod service for eucalyptus platform. 2014 IEEE Internatio-nal Conference on Systems, Man, and Cybernetics (SMC), IEEE, p. 3779–3784,Outubro 2014.

BOLCH, G.; GREINER, S.; MEER, H. de; TRIVEDI, K. Queueing Networks andMarkov Chains: Modeling and Performance Evaluation with Computer Sci-ence Applications. [S.l.]: Wiley, 2006. ISBN 9780471791560.

BRILHANTE, J.; SILVA, B.; MACIEL, P.; ZIMMERMANN, A. Dependability models foreucalyptus infrastructure clouds considering vm life-cycle. p. 1336–1341, Outubro 2014.

CALLOU, G.; MACIEL, P.; TUTSCH, D.; ARAUJO, J. Models for dependability andsustainability analysis of data center cooling architectures. p. 1–6, Junho 2012.

CALLOU, G.; SOUSA, E.; MACIEL, P.; TAVARES, E.; ARAUJO, C.; SILVA, B.; ROSA,N.; MARWAH, M.; SHARMA, R.; SHAH, A.; CHRISTIAN, T.; PIRES, J.; MAGNANI,F. Impact analysis of maintenance policies on data center power infrastructure. p. 526–533,Outubro 2010. ISSN 1062-922X.

CASSANDRAS, C. G.; LAFORTUNE, S. Introduction to Discrete Event Systems.Secaucus, NJ, EUA: Springer-Verlag New York, Inc., 2006. ISBN 0387333320.

CHEN, D.; TRIVEDI, K. S. Closed-form analytical results for condition-based maintenance.Reliability Engineering System Safety, v. 76, n. 1, p. 43 – 51, 2002. ISSN 0951-8320.

CLOUDFOUNDRYDOCS. Cloud Foundry Documentation. 2015. <http://docs.cloudfoundry.org/>. Online; Acessado em: 03/07/2015.

CLOUDFOUNDRYORG. Cloud Foundry. 2015. <https://www.cloudfoundry.org/>.Online; Acessado em: 03/11/2015.

CORRADI, A.; FOSCHINI, L.; FRATERNALE, S.; ARROJO, D.; STEINDER, M.Monitoring applications and services to improve the cloud foundry paas. Workshops,p. 1–6, Junho 2014.

http://docs.cloudfoundry.org/

http://docs.cloudfoundry.org/

https://www.cloudfoundry.org/

70

DANTAS, J.; MATOS, R.; ARAUJO, J.; MACIEL, P. An availability model for eucalyptusplatform: An analysis of warm-standy replication mechanism. p. 1664–1669, Outubro2012.

DANTAS, J.; MATOS, R.; ARAUJO, J.; MACIEL, P. Models for dependability analysisof cloud computing architectures for eucalyptus platform. International Transactionson Systems Science and Applications, v. 8, n. Dezembro, p. 13–25, 2012.

GIESSMANN, A.; KYAS, P.; TYRVAINEN, P.; STANOEVSKA, K. Towards a betterunderstanding of the dynamics of platform as a service business models. p. 965–974, Janeiro2014.

GUIMARÃES, A.; MACIEL, P.; MATOS, R. de S.; CAMBOIM, K. Impact analysis ofavailability on computer networks infrastructure. p. 171–175, Maio 2011.

HAMBY, D. A review of techniques for parameter sensitivity analysis of environmentalmodels. Environmental Monitoring and Assessment, Kluwer Academic Publishers,v. 32, n. 2, p. 135–154, 1994. ISSN 0167-6369.

HOSSNY, E.; KHATTAB, S.; OMARA, F.; HASSAN, H. A case study for deployingapplications on heterogeneous paas platforms. p. 246–253, Dezembro 2013.

JAIN, R. The Art of Computer Systems Performance Analysis - Techniques forExperimental Design, Measurement, Simulation, and Modeling. [S.l.]: Wiley,1991. I-XXVII, 1-685 p. (Wiley Professional Computing). ISBN 978-0-471-50336-1.

KIM, D. S.; MACHIDA, F.; TRIVEDI, K. Availability modeling and analysis of a virtuali-zed system. p. 365–371, Novembro 2009.

KOUTRAS, V.; PLATIS, A. Applying software rejuvenation in a two node cluster systemfor high availabilit. p. 175–182, Maio 2006.

KOUTRAS, V.; SALAGARAS, C.-P.; PLATIS, A. Software rejuvenation for higher levelsof voip availability and mean time to failure. p. 99–106, Junho 2009.

KRIZ, P. Survey on open source platform-as-a-service solutions for education. ACM, NovaYork, NY, USA, p. 176–184, 2014.

LAPRIE, J. C.; AVIŽIENIS, A.; KOPETZ, H. (Ed.). Dependability: Basic Conceptsand Terminology. Secaucus, NJ, EUA: Springer-Verlag New York, Inc., 1992. ISBN0387822968.

LV, C.; LI, Q.; LEI, Z.; PENG, J.; ZHANG, W.; WANG, T. Paas: A revolution forinformation technology platforms. p. 346–349, Junho 2010.

MACIEL, P. R.; TRIVEDI, K. S.; JR, R. M.; KIM, D. S. Performance and dependabilityin service computing: Concepts, techniques and research directions. In: . Hershey,PA, EUA: IGI Global, 2012. cap. 3, p. 53–97.

MARSTON, S.; LI, Z.; BANDYOPADHYAY, S.; ZHANG, J.; GHALSASI, A. Cloudcomputing - the business perspective. Decis. Support Syst., Elsevier Science PublishersB. V., Amsterdam, Holanda, v. 51, n. 1, p. 176–189, Abril 2011. ISSN 0167-9236.

71

MARWAH, M.; MACIEL, P.; SHAH, A.; SHARMA, R.; CHRISTIAN, T.; ALMEIDA, V.;ARAÚJO, C.; SOUZA, E.; CALLOU, G.; SILVA, B.; GALDINO, S.; PIRES, J. Quantifyingthe sustainability impact of data center availability. SIGMETRICS Perform. Eval.Rev., ACM, Nova York, NY, EUA, v. 37, n. 4, p. 64–68, Março 2010. ISSN 0163-5999.

MATOS, R.; ARAUJO, J.; OLIVEIRA, D.; MACIEL, P.; TRIVEDI, K. Sensitivity analysisof a hierarchical model of mobile cloud computing. Simulation Modelling Practiceand Theory, v. 50, n. 0, p. 151–164, 2015. ISSN 1569-190X.

MELL, P.; GRANCE, T. The nist definition of cloud computing. Computer Security Divi-sion, Information Technology Laboratory, National Institute of Standards and TechnologyGaithersburg, 2011.

MELO, R.; BEZERRA, M.; DANTAS, J.; MATOS, R.; FILHO, I. M.; MACIEL, P. Vod ineucalyptus platform: Availability modeling and sensibility analysis. p. 288–291, Novembro2014.

NICOL, D.; SANDERS, W.; TRIVEDI, K. Model-based evaluation: from dependability tosecurity. Dependable and Secure Computing, IEEE Transactions on, v. 1, n. 1, p.48–65, Janeiro 2004. ISSN 1545-5971.

OLIVEIRA, D.; ARAUJO, J.; MATOS, R.; MACIEL, P. Availability and energy consump-tion analysis of mobile cloud environments. p. 4086–4091, Outubro 2013.

OMIDI, A.; MORADI, S. Modeling and quantitative evaluation of an internet votingsystem based on dependable web services. p. 825–829, Julho 2012.

SOUSA, E.; LINS, F.; TAVARES, E.; CUNHA, P.; MACIEL, P. A modeling approach forcloud infrastructure planning considering dependability and cost requirements. Systems,Man, and Cybernetics: Systems, IEEE Transactions on, v. 45, n. 4, p. 549–558,Abril 2015. ISSN 2168-2216.

SOUSA, E.; MACIEL, P.; MEDEIROS, L.; LINS, F.; TAVARES, E.; MEDEIROS, E.Stochastic model generation for cloud infrastructure planning. p. 4098–4103, Outubro2013.

SOUSA, E.; SILVA, E.; LINS, F.; TAVARES, E.; MACIEL, P. Dependability evaluationof cloud infrastructures. p. 1282–1287, Outubro 2014.

SOUSA, E. Teixeira Gomes de; LINS, F. A.; TAVARES, E. G.; MACIEL, P. R. M.Performance and cost modeling strategy for cloud infrastructure planning. p. 546–553,Junho 2014.

TAURION, C. Cloud Computing - Computação em Nuvem - Transformando omundo da Tecnologia da Informação. 1. ed. Rio de Janeiro - RJ: BRASPORT, 2009.ISBN 978-85-7452-423-8.

TRIVEDI, K.; KIM, D. S.; ROY, A.; MEDHI, D. Dependability and security models. p.11–20, Outubro 2009.

TRIVEDI, K. S.; HUNTER, S.; GARG, S.; FRICKS, R. Reliability analysis techniquesexplored through a communication network example. 1996.

72

VAQUERO, L. M.; RODERO-MERINO, L.; CACERES, J.; LINDNER, M. A break inthe clouds: Towards a cloud definition. SIGCOMM Comput. Commun. Rev., ACM,New York, NY, EUA, v. 39, n. 1, p. 50–55, Dezembro 2008. ISSN 0146-4833.

VEERARAGHAVAN, M.; TRIVEDI, K. A combinatorial algorithm for performance andreliability analysis using multistate models. Computers, IEEE Transactions on, v. 43,n. 2, p. 229–234, Fevereiro 1994. ISSN 0018-9340.

WEI, B.; LIN, C.; KONG, X. Dependability modeling and analysis for the virtual clusters.v. 4, p. 2316–2320, Dezembro 2011.

WEI, B.; LIN, C.; KONG, X. Dependability modeling and analysis for the virtual datacenter of cloud computing. p. 784–789, Setembro 2011.

XIANG, M.; TAUCH, S.; LIU, W. Dependability and resource optimation analysis forsmart grid communication networks. p. 676–681, Dezembro 2014.

XIE, M.; POH, K.-L.; DAI, Y.-S. Computing System Reliability: Models andAnalysis. 1. ed. [S.l.]: Kluwer, 2004. I-XIII, 1-293 p. ISBN 978-0-306-48496-4.

ZENG, R.; JIANG, Y.; LIN, C.; SHEN, X. Dependability analysis of control centernetworks in smart grid using stochastic petri nets. Parallel and Distributed Systems,IEEE Transactions on, v. 23, n. 9, p. 1721–1730, Setembro 2012. ISSN 1045-9219.

ZHANG, W.; HUANG, X.; CHEN, N.; WANG, W.; ZHONG, H. Paas-oriented performancemodeling for cloud computing. p. 395–404, Julho 2012. ISSN 0730-3157.

ZHAO, L.; SONG, Q. Availability and cost analysis of a fault-tolerant software systemwith rejuvenation. p. 261–265, Dezembro 2008.

ZHOU, J.; ZHOU, B.; LI, S. Automated model-based performance testing for paas cloudservices. 2014 IEEE 38th International Computer Software and ApplicationsConference Workshops, IEEE, p. 644–649, Julho 2014.

tcc: avaliação de dependabilidade e análise de sensibilidade de uma plataforma como serviço...

Data & Analytics