Avaliação Da Disponibilidade de Video Surveillance As A Service (Vsaas) - Carlosmagno - Vfinal

Carlos Mgno
AVALIAO DA DISPONIBILIDADE DE VIDEO SURVEILLANCE AS

A SERVICE (VSAAS)
Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE
2015
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Carlos Mgno
AVALIAO DA DISPONIBILIDADE DE VIDEO SURVEILLANCE AS

A SERVICE (VSAAS)
Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Prof. Dr. Paulo Romero Martins Maciel
RECIFE
2015
Catalogao na fonte
Bibliotecria Jane Souto Maior, CRB4-571
M198a Mgno, Carlos

Avaliao da disponibilidade de video surveillance as service
(VSAAS) / Mgno Carlos. Recife: O Autor, 2015.
113 f.: il., fig., tab.
Orientador: Paulo Romero Martins Maciel.
Dissertao (Mestrado) Universidade
Pernambuco. CIn, Cincia da Computao, 2015.
Inclui referncias e apndices.
Federal
de
1. Computao nas nuvens. 2. Dependabilidade. 3. Avaliao

de desempenho. I. Maciel, Paulo Romero Martins (orientador). II.
Ttulo.
004.678.2
CDD (23. ed.)
UFPE- MEI 2015-179
Dissertao de Mestrado apresentada por Carlos Mgno Ps-Graduao em Cincia da

Computao do Centro de Informtica da Universidade Federal de Pernambuco, sob o
ttulo AVALIAO DA DISPONIBILIDADE DE VIDEO SURVEILLANCE AS A
SERVICE (VSAAS) orientada pelo Prof. Paulo Romero Martins Maciel e aprovada
pela Banca Examinadora formada pelos professores:
______________________________________________
Prof. Eduardo Antnio Guimaraes Tavares
Centro de Informtica/UFPE
______________________________________________
Prof. Francisco Vieira de Souza
Departamento de Informtica e Estatstica/UFPI
_______________________________________________
Prof. Paulo Romero Martins Maciel
Centro de Informtica / UFPE
Visto e permitida a impresso.

Recife, 04 de setembro de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.
Dedico esta dissertao ao Senhor Deus, por mostrar a luz

nos momentos mais difceis.
Agradecimentos
Meus sinceros agradecimentos a todos que contriburam para o desenvolvimento deste
trabalho, desde as que continuam presentes, assim como, as que por algum motivo no esto
prximas.
Meu incomensurvel agradecimento ao meu orientador, professor Dr. Paulo Maciel, que
me acompanhou desde o incio desta jornada, com sua cobrana e conselhos, confundidos a de
um pai querendo o bem de um filho, sem os quais a concluso estaria ameaada. Ele ser um
exemplo a ser seguido na minha vida. Muito obrigado por acreditar em mim.
Agradeo a todos do grupo MoDCS pela amizade e parceria, em especial, minha turma:
Igor, Eliomar, Vernica, Maria Clara, Jlio, Rosngela, Jonathan e Leandro Marques. Agradeo
a Matheus pelo primeiro contato com a pesquisa dentro do Mestrado e a Jean que nessa reta final
foi um dos grandes responsveis pela concluso deste trabalho.
Meu muito obrigado a minha famlia, especialmente a minha me, Sueli pelo amor
incondicional e o acolhimento nos momentos de desespero e de lgrimas. Tambm ao meu pai,
Jos Carlos, pelo apoio e experincias passadas. Todas as minhas decises e conquistas obtidas
em minha vida so dedicadas a eles, inclusive este meu sonho que sempre foi uma promessa
feita a minha me, quando eu ainda tinha 14 anos: ser um cientista da Computao. Mesmo
estando ausente por inmeras vezes, nunca esqueci de vocs e os amo muito: Painho e Mainha.
Agradeo a minha irm Magda Priscila, por confabularmos juntos vrios sonhos acadmicos.
Agradeo a todos os parentes, sobretudo a uma pessoa que no posso esquecer, minha
adorvel V, dona Zefinha, que sempre perguntou por onde eu estava nos momentos ausentes e
fazia a maior alegria quando passava 5 minutos conversando comigo; este trabalho tambm
dedicado a ela.
A minha namorada, Evelyne, obrigado por me mostrar alguns sentidos na vida, entre eles
a felicidade e companheirismo, abrindo novas possibilidades e resgatando a pessoa desafiadora
e alegre que h em mim. Quero que nosso amor seja eterno enquanto dure. Obrigado pela
pacincia e cumplicidade.
Ao Centro de Informtica (CIn) da UFPE e ao Conselho Nacional de Desenvolvimento
Cientfico e Tecnolgico (CNPq), por todo o suporte recebido.
Por fim, quero agradecer ao Criador do Universo, DEUS. S ele sabe o que passei
nos momentos mais complicados da minha vida, por vrias indefinies e problemas pessoais.
Obrigado por me dar foras a cada vez que eu perguntei o PORQU.
"Sem crise no h desafios, sem desafios, a vida uma rotina."

ALBERT EINSTEIN
Resumo
Nos ltimos anos, sistemas de Video Surveillance as a Service (VSaaS) apresentam
um aumento significativo na demanda por tcnicas de segurana que elevem os nveis de
confiabilidade do servio. Em paralelo, o paradigma de Computao em Nuvem tornou-se uma
importante ferramenta para servios remotos da computao. O VSaaS entrega armazenamento
de grande quantidade de dados. Em 2012, 50% do armazenamento em big data que necessitou
serem analisados foram de vdeo de vigilncia. Em geral, os vdeos tm um alto significado para
seus proprietrios, no permitindo longos perodos de interrupo. Com o objetivo de evitar
baixos desempenhos e ampliar a qualidade dos servios de vdeo so necessrios mecanismos
para garantir alta disponibilidade em VSaaS. Entretanto, esta tarefa difcil sem gerar impacto
no custo. O presente trabalho prope dois sistemas de VSaaS que foram submetidos a anlise
de disponibilidade, por meio de modelos analticos (RBD, CTMC e SPN). O primeiro sistema,
denominado domstico, foi caracterizado pelos elementos essenciais para uma estrutura bsica do
VSaaS para ser utilizado em casas e pequenos comrcios. Estes sistemas geraram trs arquiteturas
que foram modeladas para a obteno de frmulas fechadas, elas so importantes para realizao
de anlises. O modelo da arquitetura 1 foi validado e as outras arquiteturas variaram dessas. A
arquitetura 3 teve a maior disponibilidade entre as outras arquiteturas, por possuir a quantidade
maior de componentes replicados. O downtime (em horas) desta arquitetura comparada com a
sem replicaes foi em 36,89%. Por ela ter a maior disponibilidade, foi realizada uma anlise
de sensibilidade que mostrou o componente Node como o de maior impacto. No segundo
sistema, foi apresentado um VSaaS de uma empresa, chamado empresarial, gerando 18 (dezoito)
arquiteturas, uma delas comparada a arquitetura A1 (sem redundncia), obteve uma reduo
significativa do downtime de 30% com um pequeno aumento no custo na ordem de 7%. Caso
um determinado servio exija um downtime menor, outra anlise apontou uma arquitetura com
reduo de 80% ao aumentar 30% do custo. Diante desse panorama foram propostas e analisadas
arquiteturas que podem auxiliar administradores a tomar importantes decises na implementao
de VSaaS.
Palavras-chave: Computao em Nuvem, Disponibilidade, VSaaS, Modelos Analticos, RBD,
SPN, CTMC.
Abstract
In the last few years, Video Surveillance as a Service VSaaS has shown the significant
increase in demand for security mechanisms to ensure reliability higher levels. In parallel, the
Cloud Computing paradigm has become an important tool for remote computing services. VSaaS,
for example, allows for storage large amounts of data. In 2012, 50% of big data storage were
surveillance video and in general, videos have a high significance for their owners, not allowing
long periods interruption. To avoid video services with low performance and increase the quality,
mechanisms to ensure high availability in VSaaS are required. However, this task is difficult
without generating a major impact on cost, so this paper proposes two VSaaS systems who
underwent an availability analysis, using analytical models (RBD, CTMC, and SPN). The first
system, entitled domestic, was characterized by essential elements of a basic structure VSaaS, for
use in homes and small businesses. This system generated three architectures that were modeled
to obtain closed formulas; they are important to performing analyzes. The model architecture
one was validated, and other architectures vary these. The architecture three had the highest
availability of the other architectures, by owning the largest number of replicated components.
The downtime (in hours) this architecture compared to a without replication was 36.89%. For
having the highest availability, a sensitivity analysis showed the "Node"component as the most
relevant. In the second system, was showed a VSaaS in a company and has generated eighteen
architectures. One of them compared to a baseline, we obtained a significant reduction in
downtime (30%) and a small increase in cost (on the order of 7%). In case, of the service requires
less downtime, another analysis pointed an architecture with a reduction 80% of downtime and
increased 30% in the cost. We propose and analyze architectures that can help administrators
make important decisions in the VSaaS implementation.
Keywords: Cloud Computing, Availability Disponibilidade, VSaaS, Analytical Models, RBD,
SPN, CTMC.
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Modelos de negcio de Computao em Nuvem . . . . . . . .

Curva da Banheira . . . . . . . . . . . . . . . . . . . . . . .
Sistema disponvel. . . . . . . . . . . . . . . . . . . . . . . .
Sistema indisponvel. . . . . . . . . . . . . . . . . . . . . . .
Componentes em srie. . . . . . . . . . . . . . . . . . . . . .
Componentes em paralelo. . . . . . . . . . . . . . . . . . . .
Componente em k-out-of-n. . . . . . . . . . . . . . . . . . . .
Exemplo de cadeia de Markov. . . . . . . . . . . . . . . . . .
Elementos de uma rede de Petri . . . . . . . . . . . . . . . . .
Rede de Petri representando um dia . . . . . . . . . . . . . .
Elementos das SPNs que estendem o comportamento das PNs.
Estrutura do VSaaS, da empresa Security Station . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
29
31
31
31
32
32
33
35
36
36
44
3.1
3.2
3.3
3.4
3.5
3.6
Metodologia . . . . . . . . . . . . . . .
Pataforma VSaaS. . . . . . . . . . . . .
Arquitetura 1 - Bsica. . . . . . . . . .
Arquitetura 2 - Com redundncia. . . .
Arquitetura 3 - Com redundncia. . . .
Arquitetura de uma empresa com VSaaS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
49
49
51
52
53
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Modelo RBD da arquitetura 1. . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelo RBD do arquitetura 2 da arquitetura bsica com a estratgia de redundncia 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo RBD da arquitetura 3 com a estratgia de redundncia 2. . . . . . . . .
CTMC do subsistema LiveVideo sem redundncia. . . . . . . . . . . . . . . .
Cadeia de Markov do LiveVideo com Redundncia . . . . . . . . . . . . . . .
Fluxo de trabalho para validao dos modelos. . . . . . . . . . . . . . . . . . .
Cmera AXIS utilizada no estudo . . . . . . . . . . . . . . . . . . . . . . . .
Modelo RBD da Arquitetura de VSaaS da Empresa X . . . . . . . . . . . . . .
Rede de Petri dos componentes Cmera e LiveVideo relacionados com redundncia.
57
58
60
61
64
65
68
69
5.1
5.2
Disponibilidade das arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . .

downtime das arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
77
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
Anlise de Sensibilidade - Grfico com parmetros de maior impacto .

Anlise de Sensibilidade - Grfico com parmetros de menor impacto
Disponibilidade do RBD da Cmera com o servio LiveVideo . . . .
Disponibilidade das estratgias analisadas . . . . . . . . . . . . . . .
downtime das estratgias analisadas . . . . . . . . . . . . . . . . . .
Resultado da Availability Importance . . . . . . . . . . . . . . . . . .
Disponibilidade das arquiteturas da empresa X . . . . . . . . . . . . .
downtime das arquiteturas da empresa X . . . . . . . . . . . . . . . .
Custos das arquiteturas da empresa X . . . . . . . . . . . . . . . . .
Apresentao das arquiteturas com prioridades iguais . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
82
83
84
85
85
88
89
89
91
Lista de Tabelas
1.1
Relao entre a proposta desta dissertao e outros trabalhos relacionados . . .
20
2.1
Anlise de SWOT do paradigma computao em nuvem, (HERBERT; ERICKSON, 2011) e (MARSTON et al., 2011) . . . . . . . . . . . . . . . . . . . . .
26
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Estados do subsistema LiveVideo sem redundncia. . . . . . . . . . . . . . . .

Taxas do subsistema LiveVideo sem redundncia. . . . . . . . . . . . . . . . .
Estados do subsistemas do LiveVideo com redundncia. . . . . . . . . . . . . .
Componentes do ambiente de testes do experimento de Injeo de Falhas. . . .
Parmetros de Entrada para o Mtodo de Keese. . . . . . . . . . . . . . . . . .
Validao das disponibilidades . . . . . . . . . . . . . . . . . . . . . . . . . .
Atributos das transies dos LiveVideos do modelo SPN cold-standby. . . . . .
Atributos das transies das cmeras do modelo SPN cold-standby. . . . . . . .
Atributos das transies de disparo da Cmera Reserva do modelo SPN coldstandby. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
62
64
67
67
70
71
72
5.1
Parmetros da Cmera, WiFi, conexo 3G, Streaming Transmitter, Node, Frontend e LiveVideo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Resultados da comparao entre os modelos. . . . . . . . . . . . . . . . . . . .
5.3 Ranking de Sensibilidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Estratgias adotadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Resultado da Availability Importance . . . . . . . . . . . . . . . . . . . . . . .
5.6 Apresentao das Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7 Descrio e valor dos componentes . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Apresentao do resultados da disponibilidade, downtime e custo das Arquiteturas
5.9 Normatizao e distncia euclidiana nas arquiteturas . . . . . . . . . . . . . .
5.10 Ranking das Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11 Comparao das arquiteturas considerando prioridades . . . . . . . . . . . . .
76
76
79
84
85
87
87
91
92
92
93
Lista de Acrnimos
C
Cmera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
CAGR
Compound Annual Gowth Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CCTV
Closed-circuit television . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
CTMC
Continuous-Time Markov Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DTMC
Discrete-Time Markov Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
IaaS
Infraestrutura como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
IDC
International Data Corporation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
LV
Live Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
MTBF
Mean Time Between Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
MTTF
Mean Time To Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
MTTR
Mean Time To Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
PaaS
Plataforma como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
QoS
Qualidade de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
RBD
Reliability Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SaaS
Software como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
SLA
Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SPN
Stochastic Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
ST
Streaming Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
VSaaS
Video Surveillance as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
VSCQ
Cobertura da Qualidade Visual de Vigilncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
SAI
Security Industry Association Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
SHARPE
Symbolic Hierarchical Automated Reliability and Performance Evaluator . . . . 46
WiFi
Wireless Fidelity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Sumrio
1
Introduo
1.1 Contexto . . . . . . . . .
1.2 Motivao e Justificativa
1.3 Objetivos . . . . . . . .
1.4 Trabalhos Relacionados .
1.5 Estrutura da Dissertao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referencial Terico
2.1 Computao em Nuvem . . . . . . . . . . .
2.2 Dependabilidade . . . . . . . . . . . . . . .
2.3 Tcnicas de Modelagem para Disponibilidade
2.3.1 Diagrama de Bloco de Confiabilidade
2.3.2 Cadeias de Markov . . . . . . . . . .
2.3.3 Rede de Petri Estocsticas . . . . . .
2.4 Intervalo de Confiana da Disponibilidade . .
2.5 Anlise de Sensibilidade . . . . . . . . . . .
2.6 Availability Importance . . . . . . . . . . . .
2.7 Video Surveillance as a Service . . . . . . . .
Metodologia de Avaliao e
Arquiteturas VSaaS
3.1 Metodologia de Avaliao de Disponibilidade
3.2 Arquiteturas VSaaS . . . . . . . . . . . . . .
3.2.1 Arquiteturas do Sistema Domstico .
3.2.2 Arquiteturas do Sistema Empresarial .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modelos de Disponibilidade
4.1 Modelagem das Arquiteturas do Sistema Domstico .
4.1.1 Modelos RBDs . . . . . . . . . . . . . . . .
4.1.2 Modelos CTMCs . . . . . . . . . . . . . . .
4.1.3 Validao . . . . . . . . . . . . . . . . . . .
4.2 Modelagem das Arquiteturas do Sistema Empresarial
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
17
18
18
21
.
.
.
.
.
.
.
.
.
.
22
22
26
29
30
32
35
39
40
41
42
.
.
.
.
45
45
47
48
52
.
.
.
.
.
55
55
56
58
63
68
14
5
Estudos de casos
5.1 Estudo de Caso 1 - Sistema Domstico .
5.1.1 Anlise de Sensibilidade . . . .
5.2 Estudo de Caso 2 - Sistema Empresarial
5.2.1 Availability Importance . . . . .
5.2.2 Custo versus Downtime . . . . .
Concluses e Trabalhos Futuros
Referncias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
74
78
82
84
86
94
98
Apndice
105
A Scripts de Injeo de falha do Cliente
106
B Scripts de Injeo de falha do Frontend
107
C Scripts de Injeo de falha do Node
108
D Scripts de Injeo de falha do LiveVideo
109
E Scripts de Monitoramento do Cliente
110
F Scripts de Monitoramento do Frontend
111
G Scripts de Monitoramento do Node
112
H Scripts de Monitoramento do LiveVideo
113
15
1
Introduo
Se soubssemos o que era que estvamos fazendo, no seria chamado
pesquisa, seria?
ALBERT EINSTEIN
Este Captulo apresenta uma explanao acerca dos sistemas de vigilncia em nuvem no
contexto financeiro, alm da importncia da avaliao de disponibilidade desse servio atravs de
modelos matemticos. Em seguida, descreve-se o foco da pesquisa na apresentao da motivao,
justificativa, objetivos da pesquisa, trabalhos relacionados e a estrutura desta Dissertao.
1.1
Contexto
Os vdeos de vigilncia, esto contribuindo para crescimento de big datas, apresentando

uma fatia importante no universo digital. Esse fenmeno pode ser percebido pela presena de
cmeras em elevadores, paredes de edifcio e vias de trnsito, tanto para fiscalizao quanto
para proteo familiar. Outras reas como laboratrios de pesquisa, escolas, empresas privadas,
rea mdica, pesquisa e monitoramento de fauna e flora, monitoramento de relevo, condies
climticas e at mesmo controle de linhas de produo de fbricas.
A rea de pesquisa em sistemas de vigilncia na nuvem ainda emergente (CHEN
et al., 2014). Em sistemas de vigilncia tradicionais, uma variedade de recursos relacionados
infraestrutura necessria para realizar as operaes de vigilncia. Nos sistemas de vigilncia
baseados em nuvem a infraestrutura provida pelo fornecedor da nuvem e geralmente cobrado
pela quantidade de cmeras que esto monitorando.
O processo de modelagem consiste na arte de transformar situaes da realidade em
problemas matemticos e resolv-los (BASSANEZI, 2002). A modelagem usada para analisar
1.1. CONTEXTO
16
um servio possibilita os benefcios aumentando a flexibilidade na alternncia de parmetros ou

substituio de componentes, reduo do tempo de implementao e custos quando comparados
ao desenvolvimento e construo de sistemas ou prottipos reais. Alm do risco de uma
implementao de um servio ou prottipo real podem no apresentar os resultados esperados,
desperdiando tempo e recursos financeiros da empresa (CHEN et al., 2014; CARVALHO, 2003;
PRADO, 2000).
A computao em nuvem surgiu como uma opo vivel para melhorar o desempenho e
a confiabilidade das aplicaes, tais como sistemas de vigilncia em nuvem, video on-demand e
armazenamento de dados. A fim de alcanar bons indicadores de qualidade de servio (Qualidade
de Servio (QoS)) e cumprimento de acordos de nveis de servios, do ingls Service Level
Agreement (SLA), o comportamento desses sistemas precisam ser cuidadosamente caracterizados
e compreendidos (CALHEIROS et al., 2011; CHEN et al., 2014).
Os sistemas de computao em nuvem geralmente so projetados para estarem disponveis a todo o momento. Um exemplo o que acontece com os sistemas de vigilncia, onde a
confiana de que o sistema estar disponvel importante. H muitos desafios que devem ser
superados para se chegar aos nveis de confiabilidade desejados (SUN et al., 2010). Os sistemas
de vdeos de vigilncia ainda so frequentemente encontrados no ambiente tradicional de circuito
fechado de televiso (Closed-circuit television (CCTV)), vinculado aos servidores dedicados
e mdias de armazenamento. Este tipo de servio pode aproveitar os benefcios da nuvem e
melhorar o seu fornecimento e aumentar sua confiabilidade.
Considere no decurso de um assalto onde o servidor seja roubado. Consequentemente,
a prova do crime estar perdida. Esse tipo de ocorrncia poderia ser evitada caso os vdeos
estivessem armazenados em uma nuvem. A facilidade de transmisso de vdeo de cmeras de
vigilncia atravs da web uma vantagem do sistema em nuvem. Neste caso, temos a situao
que uma pessoa em viagem poder monitorar e verificar a segurana de sua residncia por meio
de um computador ou dispositivo mvel com acesso internet.
Diante do que foi exposto, este trabalho tem por finalidade analisar o comportamento
da disponibilidade do VSaaS, um sistema para uso domstico e outro para o setor empresarial.
Esta pesquisa restringe sua anlise na captura do vdeo no ambiente e na disponibilizao do
servio na nuvem. Em sua metodologia o ponto de partida foi a definio das arquiteturas VSaaS
a serem utilizadas no processo de modelagem hierrquica heterognea, atravs de componentes
sequenciais e paralelos representados em Diagrama de Blocos de Confiabilidade (Reliability
Block Diagrams (RBD)) para comportamentos simples (KUO; ZUO, 2003; MACIEL et al.,
2012), enquanto comportamentos mais detalhados e com dependncias foram modelados com
Cadeia de Markov de Tempo Contnuo (Continuous-Time Markov Chain (CTMC)) (TRIVEDI,
1.2. MOTIVAO E JUSTIFICATIVA
17
2002) e Redes de Petri Estocsticas (Stochastic Petri Net (SPN)).

Um dos modelos do sistema domstico foi submetido a um processo de validao
por meio de um experimento de injeo de falhas, e para obter o intervalo de confiana da
disponibilidade foi utilizado o mtodo proposto por (KEESEE, 1965). Nesta sistema, realizou-se
uma anlise de sensibilidade paramtrica na arquitetura trs, que possui redundncia warmstandby em alguns componentes, para identificar os pontos crticos da disponibilidade que podem
ser melhorados.
O sistema empresarial, baseado em empresas de pequeno porte, iniciou-se com a definio
de uma estratgia de disponibilidade para as cmeras. Na sequncia, foi realizada uma anlise de
importncia (Availability Importance) para apontar os componentes que tm maior contribuio
para a disponibilidade do servio e apoiou a proposio de novas arquiteturas. Por fim, uma
anlise entre custo e downtime foi aplicado nas 18 arquiteturas, sem e com redundncias. Nesta
anlise, a alternncia de prioridade foi considerada. Sendo utilizada para contribuir na deciso
dos gestores de tecnologia da informao no momento de aumentar a disponibilidade do VSaaS.
1.2
Motivao e Justificativa
Vigilncia por vdeo baseado em nuvem um novo servio de computao em nuvem que
evoluiu como tema de investigao emergente (XIONG et al., 2014). Este novo modelo de servio
chamado VSaaS foi recentemente introduzido como uma alternativa para o desenvolvimento
e gesto de sistemas de vigilncia. O modelo permite uma maior escalabilidade de recursos a
um baixo custo e pela concentrao dos recursos computacionais presentes na nuvem podero
atender a mais de um cliente. Desta forma, evita que um cliente invista em uma arquitetura com
100 cmeras e a necessidade real seja de 40.
Para entender a grandeza desse tipo de servio, uma pesquisa da International Data
Corporation (IDC) (IDC, 2013), em 2012, revela que 50% de todos os materiais importantes a
serem analisados no mundo digital foram de vdeos de vigilncia e para 2015 espera-se alcanar
o percentual de 65%. No Brasil, segundo a Security Industry Association Brasil (SAI) (SIA,
2014), no ano de 2011, este mercado de vdeos de vigilncia teve um volume de negcios de
R$ 1,2 bilhes, e at 2017 espera-se um crescimento de 20,6%, atingindo R$ 3,7 bilhes.
um mercado que tende a crescer no s no Brasil, mas em todo o mundo, pela importncia e
necessidade de dados armazenados.
Uma pesquisa mundial realizada pela MarketsandMarkets (MARKETSANDMARKETS,
2012), sobre a expectativa do mercado de VSaaS, mostra que esperado um crescimento de
$474,00 milhes em 2011 para $2.390,90 milhes em 2017, com uma Taxa Composta de
1.3. OBJETIVOS
18
Crescimento Anual (Compound Annual Gowth Rate (CAGR)) de 31,5% de 2012 at 2017.
Um mercado com boas oportunidades financeiras, considerando essa taxa comparada com PIB
Mundial esperado pelo FMI1 em 2015 de 3,5%.
Como so apresentadas na literatura, as pesquisas existentes preveem um potencial
significativo de Video Surveillance as a Service (VSaaS). No entanto, algumas questes como o
custo (NEAL; RAHMAN, 2012), privacidade (PEARSON, 2009) e segurana (SABAHI, 2011)
fazem algumas organizaes ficarem em dvida por optar ou no pelas solues baseadas em
nuvem (SABAHI, 2011).
Saranya e Vijayalakshmi (SARANYA; VIJAYALAKSHMI, 2011) afirmam a existncia
de benefcios que a infraestrutura de computao em nuvem pode oferecer para VSaaS: melhorar
a disponibilidade, a centralizao do armazenamento, memria, processamento e requisitos de
banda larga; a reduo de hardware e software, bem como os custos com licenas, a prestao
de servios de armazenamento de dados e de rede rpida e segura. Isto mostra que alm de ser
uma condio vivel financeiramente, h ganhos de segurana e processamento.
1.3
Objetivos
Esta Dissertao tem por objetivo geral a concepo de modelos para avaliao da
disponibilidade de Video Surveillance as a Service, por meio da combinao de modelos
hierrquicos, utilizao de redundncia, anlise de sensibilidade e validao de modelo para
as arquiteturas propostas. Para atingirmos o objetivo geral, necessrio cumprir os seguintes
objetivos secundrios:
Propor uma metodologia de avaliao de disponibilidade para o VSaaS;
Desenvolver scripts para a injeo de falhas e monitorao dos componentes do sistema;
Analisar a sensibilidade dos parmetros do sistema para encontrar componentes crticos.
1.4
Trabalhos Relacionados
Avaliaao de disponibilidade em ambientes VSaaS tem sido tema de pesquisas que

aborda o ambiente em diversas perspectivas, no entanto, foram encontrados poucos trabalhos
que abordem a utilizao de modelagem analtica para mtricas de dependabilidade. Foram
realizadas pesquisas nas engines IEEEXplore, ACM, Scopus, ScienceDirect, SpringerLink e, em
trabalhos publicados no perodo de 2008 a 2015.
1 Fundo
Monetrio Nacional
1.4. TRABALHOS RELACIONADOS
19
Os trabalhos que norteiam esta pesquisa foram divididos nas teorias usadas e nos trabalhos de VSaaS. Das teorias, encontram-se a modelagem analtica usada para analisar mtricas de dependabilidade, anlise de sensibilidade e anlise de custo. Dos trabalhos de VSaaS
encontraram-se implementaes, arquiteturas e conceitos de dependabilidade em VSaaS. Estes
trabalhos so explanados a seguir com suas respectivas contribuies a esta Dissertao.
Em XIONG et al. (2014) propuseram um projeto e mtodo de implementao para
sistemas de vdeo de vigilncia baseado em nuvem. No prottipo, permite ao usurio posicionar
uma webcam em determinado local que requer vigilncia e realizar o monitoramento por um
navegador. Dentre as vantagens apresentadas pelo trabalho, cita-se: utilizao da computao
paralela para tratar o grande ganho de espao de armazenamento e fcil expansibilidade, o
pouco investimento e baixo custo com manuteno, a alta portabilidade e segurana de dados
superiores e, o bom compartilhamento. Isso mostra que a computao em nuvem, neste contexto,
capaz de resolver muitos problemas associados aos sistemas convencionais, tais como: alto
custo de manuteno de dispositivos, insegurana na camada de dados, mau desempenho e baixa
confiabilidade.
A pesquisa de KARIMAA (2011) estudou os conceitos de dependabilidade para a
expanso da tecnologia de vigilncia de vdeo atravs da infraestrutura de nuvem. Este conceitos
foram a disponibilidade, segurana, confiabilidade e manuteno das solues, alm de apresentar
as potencialidades identificadas nesta tecnologia. No entanto, no houve a proposio ou anlise
de modelos matemticas neste contexto.
No trabalho de SUVONVORN (2008) foi implementado sob o framework .NET um
sistema flexvel para anlise de vdeo em tempo real, com aspectos aplicveis no domnio de
vigilncia, tais como, aquisio, anlise, armazenamento, alerta e componentes de reproduo.
Uma anlise de performance nas mtricas de deteco de movimento e de face foi realizada.
O artigo de SONG; TIAN; ZHOU (2014) projetou uma soluo de um display remoto
que permite aos usurios de vigilncia assistam aos vdeos em tempo real e compartilhem as
atualizaes de tela entre os usurios de um desktop remoto. Foram adotados vrios codificadores
e mtodo de codificao paralelo em display remoto para atender a qualidade de requisito do
servio em situaes variadas. O sistema trata com carga de trabalho dinmica melhor do que
os mtodos tradicionais de displays remotos. As tarefas de vigilncia e de codificao foram
gerenciados separadamente. Uma arquitetura de VSaaS apresentada e dois modelos de filas
foram projetados para lidar com o problema de provisionamento de recursos para diferentes
codificadores. As mtricas de desempenho analisadas foram consumos de largura de banda e da
Unidade Central de Processamento do cliente.
A Dissertao de MELO (2014) props um conjunto de modelos matemticos para
1.4. TRABALHOS RELACIONADOS
20
Tabela 1.1: Relao entre a proposta desta dissertao e outros trabalhos relacionados
3
3
3
3
3
3
3
3
3
VSaaS
Mtrica de Dependabilidade
Anlise de Sensibilidade
Custos
3
3
Uso de Modelos
Computao em Nuvem
Computao em Nuvem
Computao em Nuvem
Nuvem Privada
Nuvem Privada
Sistema de vigilncia
Nuvem Privada
Validao
Esta dissertao
(XIONG et al., 2014)
(KARIMAA, 2011)
(MELO, 2014)
(DANTAS, 2012)
(SUVONVORN, 2008)
(SONG; TIAN; ZHOU, 2014)
Arquiteturas VSaaS
Contexto
Principais contribuies da dissertao
3
3
3
3
3
avaliao de disponibilidade na plataforma de computao em nuvem privada OpenNebula.

Enfatizou-se o rejuvenescimento de software atravs de Live Migration de mquinas virtuais.
Para aumentar a confiabilidade do modelo proposto, um dos modelos, foi submetido ao processo
de validao por meio de experimentos de injeo de falhas. Essa pesquisa adotou a abordagem
de validao igual.
Na Dissertao, DANTAS (2012) concebeu um conjunto de modelos analticos para
avaliao de dependabilidade das infraestruturas de computao em nuvem e utilizou a plataforma
Eucalyptus. No segundo estudo de caso, as disponibilidades e os custos foram comparados entre
as arquiteturas possveis na construo redundante da nuvem Eucalyptus. Das arquiteturas foram
calculadas as distncias euclidianas at o ponto de origem (0), com a finalidade de apontar a
arquitetura considerada boa, de acordo com estas mtricas. No presente trabalho foi discutido o
trade-off entre custo e downtime entre as arquiteturas propostas no sistema empresarial. Havendo
um diferencial em relao a esta anlise, que so resultados baseados em prioridades.
Na Tabela 1.1 apresentado um estudo comparativo entre pontos de trabalhos relacionados e a pesquisa. Procurou-se com esses pontos saber qual o contexto do trabalho e se houve
proposio de arquiteturas, utilizao de tcnicas de modelagem, validao de modelos, anlises
de sensibilidade, mtricas de dependabilidade e por fim, se aborda VSaaS.
1.5. ESTRUTURA DA DISSERTAO
1.5
21
Estrutura da Dissertao
Este Captulo contextualizou o tema da pesquisa ao tratar da relevncia em avaliar a

disponibilidade atravs de modelos matemticos e o aspecto financeiro favorvel. Em seguida,
apresentou-se a motivao, justificativa e objetivos. Trabalhos relacionados a esse estudo foram
selecionados e comentados as suas contribuies.
O Captulo 2 apresenta o referencial terico, abordando conceitos acerca da Computao
em Nuvem, Dependabilidade, Intervalo de Confiana da Disponibilidade, Anlise de Sensibilidade e Video Surveillance as a Service. Primeiro so introduzidos os conceitos bsicos de
computao em nuvem, seus modelos de servios, benefcios e desvantagens deste paradigma.
Em seguida iniciada uma explicao sobre dependabilidade, em especial sobre disponibilidade,
tema que aplicado neste trabalho. Alm de elucidar os tipos de modelos que podem ser
utilizados para encontrar mtricas de dependabilidade, esta Dissertao faz uso de RBD, CTMC
e SPN. Para o entendimento sobre o processo validao detalhada a obteno dos intervalos de
confiana de disponibilidade pelo mtodo de Keesee. Por fim, so explicadas tcnicas de anlise
de sensibilidade e conceitos de Video Surveillance as a Service.
O Captulo 3, composto por duas importantes sees: a metodologia e as arquiteturas
propostas. Na Seo 3.1, apresentada uma metodologia para auxiliar a avaliao de disponibilidade de um sistema VSaaS. As arquiteturas de VSaaS usadas nos estudos de casos so
encontradas nesta Seo 3.2, com as respectivas restries e funcionalidades dos componentes
integrantes de uma plataforma VSaaS.
No Captulo 4, so justificados os modelos concebidos em RBDs, CTMCs e SPNs,
gerados com base nas arquiteturas utilizadas. Alm disso, a validao do modelo da arquitetura
bsica apresentada nesse Captulo.
Os resultados esto contidos no Captulo 5, atravs dos estudos de casos que avaliam a
mtrica de disponibilidade nas arquiteturas propostas. Tambm apresentada uma anlise de
sensibilidade e availability importance. Na concluso dos resultados realizado um comparativo
entre custo e disponibilidade nas arquiteturas do sistema empresarial.
Por fim, no Captulo 6 so apresentadas as concluses desta pesquisa e as principais
contribuies e sugestes para possveis trabalhos futuros.
22
2
Referencial Terico
As oportunidades multiplicam-se medida que so agarradas.
SUN TZU (A Arte da Guerra)
H conhecimentos bsicos para esta Dissertao ser compreendida. Ressaltam-se neste

Captulo, os subsdios necessrios para o entendimento das tcnicas aplicadas ao longo deste
trabalho e os conceitos podem ser melhor entendidos a partir das referncias apontadas. Este
Captulo aborda os temas da seguinte forma: incialmente os conceitos bsicos de computao em nuvem, bem como, suas vantagens e desvantagens. Em seguida, os conceitos sobre
dependabilidade so explicados conforme a mtrica de disponibilidade. Posteriormente, so
apresentadas as tcnicas de modelagem para a disponibilidade. Para a validao do modelo foi
necessrio entender o obteno do intervalo de confiana da disponibilidade. Por fim, a anlise
de sensibilidade foi fundamentada e conceitos como trajetria, mercado e vantagens do VSaaS
so abordados.
2.1
Computao em Nuvem
Computao em nuvem um paradigma em contnuo desenvolvimento que foi originado

da combinao de diferentes tecnologias (SOUSA et al., 2012). Os recursos como: poder de
processamento, rede, armazenamento e softwares so ofertados e acessados remotamente pela
Internet. Algumas definies de computao em nuvem so encontradas na literatura, por exemplo: um sistema paralelo e distribudo consistido de uma coleo de computadores interligados e
virtualizados que so provisionados dinamicamente e apresentados como um ou mais recursos
de computao unificados. So baseados em acordo de nvel de servio estabelecido atravs da
negociao entre o fornecedor e o consumidor (BUYYA; YEO; VENUGOPAL, 2008).
2.1. COMPUTAO EM NUVEM
23
Em BAKSHI (2009), a computao em nuvem definida como recursos de TI e servios

que so abstrados da infraestrutura subjacente e so fornecidos on-demand e em escala num
ambiente de vrios utilizadores. A computao em nuvem um modelo que permite o acesso
rede sob demanda para um conjunto de recursos computacionais configurveis partilhados (por
exemplo, redes, servidores, armazenamento, aplicativos e servios) que podem ser rapidamente
provisionados e liberados, com o mnimo esforo de gesto ou de interao com quem fornece os
servios (MELL; GRANCE, 2014). A computao em nuvem composta por cinco principais
caractersticas (MELL; GRANCE, 2014):
On-demand self-service (autoatendimento sob demanda) - um consumidor pode, unilateralmente, abastecer-se dos recursos computacionais, tais como tempo de servidor e armazenamento de rede, conforme necessidade, de maneira automtica e sem requerer interao
humana com o provedor de servio;
Broad network access (amplo acesso rede) - os recursos esto disponveis sobre a rede, sendo
acessado por mecanismos padres que promovem o uso por plataformas de clientes finos e
grossos, heterogneos (exemplo: smartphones, tablets, laptops e estaes de trabalho);
Resource pooling (gerao de pools de recursos) - os recursos de computao (armazenamento,
processamento, memria e largura de banda) so reunidos para servir a mltiplos consumidores usando um modelo multi-inquilino (multi-tenant), com recursos fsicos e virtuais
diferentes atribudos dinamicamente e realocados de acordo com a demanda do cliente.
O modelo multi-inquilino uma arquitetura essencial para um ambiente em nuvem, pois
permite que mltiplos inquilinos (empresas/clientes) compartilhem os mesmos recursos
fsicos, o que acontece com um sistema integrado de gesto ao permanecer os mdulos
relevantes, logicamente isolados;
Rapid elasticity (elasticidade rpida) - recursos podem ser provisionados e liberados elasticamente, em alguns casos automaticamente, escalando rapidamente para dentro e para
fora, de acordo com a demanda. Para o usurio, os recursos disponveis para fornecimento
parecem ilimitados e podem ser utilizados em qualquer quantidade e a qualquer momento;
Measured service (servio medido) - sistemas de nuvem podem monitorar, controlar e informar
o uso de recursos pela capacidade de medio em nveis de abstrao adequada para o tipo
de servio. Oferecendo transparncia tanto para o fornecedor quanto para o consumidor
dos servios utilizados.
O princpio bsico de computao em nuvem atribuir computao a grande nmero de
computadores distribudos, em vez de computadores locais ou servios remotos. Caracterizada
24
pela utilizao eficiente dos recursos, empregando virtualizao, monitoramento de recursos e

mecanismos de balanceamento de carga (SARANYA; VIJAYALAKSHMI, 2011).
H trs principais modelos de negcio de Computao em Nuvem, pela National Institute
of Standards and Technology (NIST) (MELL; GRANCE, 2014). So eles: Software como
Servio (SaaS), Plataforma como Servio (PaaS) e Infraestrutura como Servio (IaaS), conforme
a Figura 2.1.
SaaS - Software
PaaS - Plataforma
IaaS
Infraestrutura
Figura 2.1: Modelos de negcio de Computao em Nuvem
IaaS - atravs do uso da virtualizao, este modelo de negcio particiona os recursos de um

datacenter entre os usurios sobre a forma de recursos virtualizados. Neste modelo de
negcio, geralmente o usurio paga pelo servio de acordo com a capacidade da mquina
virtual (Virtual Machine - VM) alocada e pela quantidade de tempo que a VM permanece
em execuo. O usurio no gerencia ou controla a infraestrutura de nuvem subjacente,
mas responsvel por controlar sua prpria pilha de software na qual os seus servios iro
executar, o sistema operacional e o armazenamento.
PaaS - neste modelo o provedor de servio abstrai a VM e o sistema operacional, oferecendo
ao usurio uma plataforma de software de alto nvel. Este modelo tem como vantagem o
dimensionamento transparente dos recursos de hardware durante a execuo dos servios
(VAQUERO et al., 2008). Com PaaS os usurios podem desenvolver, compilar, debugar e
ainda realizar testes na nuvem.
SaaS - este modelo voltado para usurios comuns de Internet, em vez de desenvolvedores e
administradores de sistema. Os softwares e os dados gerados por eles ficam armazenados
na nuvem e podem ser acessados a partir de qualquer computador conectado Internet.
Atrelado a esta comodidade de acesso aos dados e ao software est vantagem financeira
que o cliente pagar um valor relativamente menor do que o valor de compra do software.
25
Nas sociedades modernas, a maior parte dos servios essenciais so disponibilizados

de uma forma transparente. O abastecimento de gua, eletricidade, gs e telefone, bens imprescindveis no nosso dia a dia, tm esta caraterstica. A sua explorao feita com o modelo
de pagamento baseado no uso, PAYG (GOMES, 2012). Esses modelos de negcios seguem
o conceito de "pague pelo que usar". O valor pago pelo servio flexvel de acordo com a
necessidade de utilizao da organizao em qualquer tempo.
Os recursos computacionais so mantidos e gerenciados na nuvem por provedores. Entre
suas particularidades no fornecimento dos servios aos seus clientes, alguns focam na reduo de
custo da operao e outros podem ter interesse em entregar um servio com maior confiabilidade
e segurana de dados (ZHANG; CHENG; BOUTABA, 2010). Dessa forma, trs tipos de modelos
de implantao de Nuvem so considerados e apresentados, a seguir (MELL; GRANCE, 2014):
Nuvem Privada: a infraestrutura da nuvem fornecida para uso exclusivo de uma
organizao que possui mltiplos clientes. Por exemplo, um centro de dados de uma empresa
sediada numa nuvem;
Nuvem Pblica: a infraestrutura fornecida para uso aberto ao pblico geral que
permanecem entidades nicas, mas sero unidas por uma padronizao ou uma tecnologia
proprietria que possibilitar a portabilidade dos dados e das aplicaes. Os recursos so
disponibilizados dinamicamente e numa perspectiva self-service a partir da Internet;
Nuvem Hbrida: caracterizada quando a nuvem composta de duas ou mais infraestruturas distintas (privada, comunitria ou pblica), que continuaro como entidades nicas. A
vantagem deste modelo a economia de custos e o acesso a uma infraestrutura escalvel com
mecanismos de segurana. Pela agregao das vantagens dos dois outros modelos, privado e
pblico. Esta metodologia uma opo interessante para as empresas. Porm, as nuvens hbridas
introduzem uma complexidade adicional que se refere distribuio de aplicaes pelos dois
modelos (SUBRAMANIAN, 2011).
A computao em nuvem importante para a distribuio e acesso de recursos de
computao, oferecendo algumas vantagens de recursos computacionais (ARAUJO et al., 2011).
Na Tabela 2.1, possvel verificar atravs de uma anlise de SWOT do modelo computacional
de computao em nuvem, realizada por (HERBERT; ERICKSON, 2011) e (MARSTON et al.,
2011), em que elencou os pontos fortes e fracos, alm das oportunidades e ameaas, considerando
sua evoluo, integrao e as perspectivas de mercado.
Sucintamente, dos benefcios em utilizar os servios da nuvem destacam-se: gesto
centralizada, reduo de consumos energticos e diminuio dos custos de manuteno das
infraestruturas tradicionais. A nuvem disponibiliza uma diversidade de servios, onde a rapidez
de acesso a recursos virtuais favorece a agilidade do negcio (MILLER, 2008; TERRY, 2011).
2.2. DEPENDABILIDADE
26
Tabela 2.1: Anlise de SWOT do paradigma computao em nuvem, (HERBERT;

ERICKSON, 2011) e (MARSTON et al., 2011)
2.2
Pontos fortes
- Servio escalvel em curto prazo;
- Reduo dos custos iniciais de
gesto de energia e de servidores
subutilizados;
- Configuraes predefinidas de
servidores e de mquinas virtuais
com controle dos recursos adquiridos;
- O acesso e a gesto do sistema
organizacional, a partir de API,
so disponibilizados pelos
fornecedores, atravs de
dispositivos com inferiores
capacidades computacionais.
Pontos fracos
- Os consumidores podem perder o
controle dos dados alojados na nuvem;
- Os fornecedores no garantem
total qualidade e disponibilidade
de servio, durante todo o ano, o
que pode ser insuficiente para as
empresas;
- Possibilidade de falha nos
servios disponibilizado pelos
fornecedores da nuvem.
Oportunidades
- Sem necessidade dos tradicionais
gastos iniciais, as empresas tm
facilitada criao e a expanso
de negcios;
- Criao de mashups, pginas Web
que combinam diversos servios
externos, originando novos servios
e novas oportunidades de negcio;
- Uso mais racional da energia e
dos recursos naturais.
Ameaas
- Possibilidade de falncia dos
fornecedores da nuvem;
- Preocupao com a segurana,
a confiabilidade e o desempenho
dos servios da nuvem;
- Regulamentao varivel e sujeita
a eventuais alteraes, conforme
as decises nacionais, no que
respeita privacidade, aos requisitos
de auditoria e de localizao
de dados.
Dependabilidade
O desempenho e a dependabilidade so duas importantes caractersticas para a anlise de

sistemas. Usualmente, devem ser avaliadas separadamente, considerando que a primeira assume
que o sistema e seus componentes iro falhar, e que a segunda baseia-se nas anlises da falha
e do reparo e na estrutura do sistema (DAS, 1998). O termo dependabilidade uma traduo
literal do termo ingls dependability, que indica a qualidade do servio fornecido por um dado
sistema e a confiana depositada no servio fornecido.
Muitas caractersticas esperadas em sistemas distribudos, includas nos ambientes em
nuvem, so relatadas com a concepo de dependabilidade. No h uma simples definio
27
de dependabilidade, mas pode ser entendida como a capacidade de entregar uma determinada
funcionalidade especfica que pode ser justificadamente confivel (AVIZIENIS et al., 2004;
SALEH; MAHMOUD; ABDEL-SALAM, 2013).
No desenvolvimento de um sistema com os atributos de dependabilidade desejados, um
conjunto de mtodos e tcnicas devem ser empregadas. Esses mtodos e tcnicas so classificados
e citados a seguir (WEBER, 2003):
Preveno de falhas - impede a ocorrncia ou introduo de falhas. Envolve a seleo de
metodologias de projeto e de tecnologias adequadas para os seus componentes;
Tolerncia a falhas - fornece o servio esperado mesmo na presena de falhas. Tcnicas comuns: mascaramento de falhas, deteco de falhas, localizao, confinamento, recuperao,
reconfigurao, tratamento;
Validao - remoo de falhas e verificao da presena de falhas;
Previso de falhas - estimativas sobre presena de falhas e estimativas sobre consequncias
de falhas.
Com o passar das trs ltimas dcadas, dependabilidade um conceito que integra os
seguintes atributos (AVIZIENIS et al., 2004): Disponibilidade - prontido de um sistema para
entregar o servio correto para um usurio. Confiabilidade - continuidade com o servio correto.
Segurana - ausncia de consequncias catastrficas sobre o usurio e o ambiente. Integridade
- ausncia de alteraes imprprias no sistemas. Manutenabilidade - capacidade de sofrer
modificaes e reparos.
Este estudo focado no conceito de disponibilidade, que est relacionado com confiabilidade. Confiabilidade a probabilidade que o sistema S no ir falhar em um tempo t. Um dos
atributos mais importantes para sistemas computacionais a disponibilidade. Disponibilidade
pode ser expressa como a relao da expectativa do sistema ativo em um total de tempo observado
(AVIZIENIS et al., 2001) (AVIZIENIS et al., 2004), como apresentado na Equao 2.1.
Disponibilidade =
TempoAtivo
TempoAtivo + TempoInativo

2.1
A disponibilidade em sistemas online (ex. sistemas bancrios, sites da Internet) um dos

pontos cruciais que garantem a qualidade do servio, uma vez que as solicitaes geradas a esses
servios so frequentes e necessitam de respostas imediatas. Alm disso, importante estimar
a disponibilidade do sistema porque paralisaes e interrupes inesperadas na entrega dos
servios acarretam prejuzos financeiros e podem comprometer a reputao de seus provedores
(HAGEN; SEIBOLD; KEMPER, 2012).
28
No processo de avaliao da disponibilidade de sistema por intermdio de medies

significa uma operao custosa. As medidas mais importantes na avaliao so Tempo Mdio
para Falha (Mean Time To Failure (MTTF)) e para Reparo (Mean Time To Repair (MTTR))
(MACIEL et al., 2012).
O MTTF representa o tempo mdio para falhar. uma mtrica que corresponde ao tempo
estimado para acontecer uma falha. O MTTF pode ser calculado atravs da Equao 2.2.
Z

2.2
R(t) dt
O MTTR, por sua vez, o tempo mdio para reparo. O MTTR baseado num atributo
conhecido como manutenabilidade. Entende-se como manutenabilidade, a probabilidade de um
Sistema S ser reparado com um tempo t. Geralmente a manutenabilidade denotada pela funo
M(t) (MACIEL et al., 2011). A obteno do MTTR pode ser realizada pela Equao 2.3.
Z
M(t) dt

2.3
O MTTF e MTTR sendo exponencialmente distribudos podem ser representados pelas

variveis e , respectivamente e so denotadas de taxas. Observe que pode ser calculado
como o inverso do tempo mdio de falha do sistema, enquanto que o inverso do tempo mdio
de reparo. As taxas mostram a quantidade de ocorrncias de falhas/reparos em um determinado
intervalo de tempo. Dessa forma, pode-se encontrar a disponibilidade atravs da Equao 2.4:
Disponibilidade =
,
+

2.4
Com a obteno de disponibilidade, duas novas frmulas podem ser expressadas, formando mtricas de dependabilidade. A primeira delas, a indisponibilidade, representa a probabilidade do sistema no estar disponvel e calculada pela Equao 2.2. A outra, o downtime,
significa estimar o intervalo de tempo que o sistema ficou em interrupo. Por exemplo, para
encontrar o downtime anual em horas, usaramos o resultado da Indisponibilidade quantidade
anual de horas, conforme Equao 2.2.
Indisponibilidade = 1 Disponibilidade
DowntimeAnual = Indisponibilidade 8760

A curva da banheira representa o comportamento da taxa de falhas de um equipamento
ou sistema produtivo ao longo do tempo. Suas fases esto associadas ao fator de forma de uma
2.3. TCNICAS DE MODELAGEM PARA DISPONIBILIDADE
29
eventual distribuio de Weibull que descreva a confiabilidade do equipamento, conforme se

observa na Figura 2.2 e descrito seus comportamentos a seguir:
Figura 2.2: Curva da Banheira
a) Taxa de Falha Decrescente - acontece no incio da vida de um componente, onde suas

falhas comeam elevadas, porm decrescente. Na fabricao de hardwares ou mquinas essas
falhas so justificadas pelos erros de fabricao, erros de projeto, peas defeituosas, processos
de fabricao inadequados, mo de obra destreinada, entre outros. Essa taxa de falha diminui
conforme so detectados e corrigidos os erros;
b) Taxa de Falha Constante - o sistema entra numa fase chamada de vida til, haja
visto que o valor mdio da taxa de falha constante. As falhas ocorrem por causas aleatrias,
geralmente externas ao equipamento, na maioria das vezes so de difcil controle;
c) Taxa de Falha Crescente - nesta fase inicia-se o perodo final de vida e caracterizada
pelo desgaste do componente. Sua taxa torna-se crescente.
2.3
Tcnicas de Modelagem para Disponibilidade
Vrios tipos de modelos analticos podem ser usados para avaliao de disponibilidade. Diagrama de Blocos de Confiabilidade (Reliability Block Diagram - RBD), (MACIEL
et al., 2012), rvore de Falhas (KUO; ZUO, 2003), Cadeias de Markov de Tempo Contnuo
(Continuous-time Markvov Chain - CTMCs) (TRIVEDI, 2002) e Redes de Petri Estocsticas
(Stochastic Petri Net - SPNs) (KARTSON et al., 1994; AJMONE MARSAN; CONTE; BALBO,
1984) tm sido tcnicas de modelagem utilizadas para modelar sistemas tolerantes a falha e
avaliar mtricas de dependabilidade. Esses tipos de modelos divergem em dois aspectos: sua
facilidade em ser usado em aplicaes especficas e o respectivo poder de modelagem. Sendo
assim, o sucesso pode ser alcanado atravs da composio de modelos distintos.
30
Os modelos RBDs e rvores de falhas representam as condies sob as quais um sistema

pode se encontrar em falha, ou estar operacional, em termos de relaes estruturais entre
seus componentes, so classificados como modelos combinatrios. Modelos CTMC e SPN
representam o comportamento do sistema (atividades de falha e reparo) por seus estados e
ocorrncia de eventos expressados em transies de estados marcados. Estes permitem restries
e so classificados como modelos baseados em estados (MACIEL et al., 2012).
A combinao de ambos os tipos de modelo tambm possvel, permitindo obter o
melhor dos dois mundos, atravs da modelagem hierrquica (MALHOTRA; TRIVEDI, 1993;
KIM; GHOSH; TRIVEDI, 2010). Diferentes modelos, do mesmo tipo ou de tipos distintos,
podem ser combinados em diferentes nveis de compreenso levando a modelos hierrquicos
maiores (MALHOTRA; TRIVEDI, 1993).
Modelos hierrquicos heterogneos tm sido usados para lidar com a complexidade de
vrios tipos de sistemas, como por exemplo: redes de sensores (KIM; GHOSH; TRIVEDI, 2010),
redes de telecomunicao (TRIVEDI et al., 2006) e nuvens privadas (DANTAS et al., 2012).
2.3.1
Diagrama de Bloco de Confiabilidade
Diagrama de Blocos de Confiabilidade um tipo de modelo combinatorial proposto para

analisar a confiabilidade de sistemas baseados nas relaes de seus componentes. Entendido
como um mtodo utilizado para mostrar como a confiabilidade de um componente pode contribuir
para o sucesso ou o fracasso de um sistema complexo. Por conseguinte, esse formalismo foi
ampliado para a anlise de disponibilidade e manutenibilidade. Nesta seo, atentaremos para o
uso de RBDs para o clculo de disponibilidade, uma vez que este o foco deste trabalho.
Um RBD formado pelos vrtices de origem e de destino, componentes representados
por blocos, e arcos conectando os blocos e os vrtices. Sua estrutura organizada com base
essencial para o sistema funcionar, ou seja, o diagrama representa o modo operacional do
ambiente que est sendo modelado (MELO et al., 2013). O modo operacional apresenta quais
componentes do sistema devem estar em funcionamento para que o sistema deva responder
corretamente.
Para o RBD est disponvel necessrio que exista algum caminho do vrtice de origem
at o vrtice de destino, no qual componentes indisponveis representam uma interrupo em
uma parte do caminho. Na Figura 2.3 est mostrado que o sistema continua disponvel mesmo
acontecendo a falha de um dos componentes, uma vez que h um caminho contnuo dos vrtices
de incio e fim do RBD. Na Figura 2.4 a falha do componente crtica para o sistema, porque ele
impede que se repita o comportamento do caminho no RBD.
Em um modelo de diagrama de blocos de confiabilidade os componentes so represen-
31
Figura 2.3: Sistema disponvel.
tados com blocos combinados com outros blocos. Se os componentes forem ligados em srie,
Figura 2.5, todos os componentes devero estar operacionais para que conjunto esteja disponvel.
Nos paralelos, Figura 2.6, necessrio que pelo menos um esteja funcionando. Por fim, outra
estrutura tpica a k-out-of-n, na Figura 2.7, determina que k componentes devem estar em
funcionamento de uma determinada quantidade n de componentes, ou ainda em combinaes
entre essas organizaes (TRIVEDI et al., 1996; MACIEL et al., 2011).
Figura 2.4: Sistema indisponvel.
A confiabilidade de dois blocos conectados em srie obtida atravs da Equao 2.5:

RS = R1 R2
onde:
R1 descreve a confiabilidade do bloco 1.
R2 descreve a confiabilidade do bloco 2.
Figura 2.5: Componentes em srie.

2.5
32
A confiabilidade de dois blocos conectados em paralelo obtida atravs da Equao 2.6:

2
RP = 1 (1 Ri )
i=1

2.6
Figura 2.6: Componentes em paralelo.
A confiabilidade de blocos conectados em k-out-of-n obtida pela Equao 2.7:

n
Rkouto f n (t) = P(X = i)

ik

2.7
Figura 2.7: Componente em k-out-of-n.
Modelos RBDs so utilizados, geralmente, em sistemas modulares que consistam de

muitos mdulos independentes, em que cada um pode ser facilmente representado por um bloco
de confiabilidade. Assim, havendo a necessidade de modelar sistemas complexos, onde se
exige a adio de redundncia em mdulos do sistema. O usurio deve recorrer as tcnicas de
modelagem hierrquica, que utiliza em conjunto modelos como CTMC e RBD ou RBD e SPN,
na tentativa de obter resultados mais expressivos.
2.3.2
Cadeias de Markov
Cadeia de Markov (STEWART, 1994), (TRIVEDI et al., 2006) um formalismo matemtico para a modelagem de sistemas, modelando o funcionamento de um sistema atravs de um
conjunto de estados e transies entre os estados, tanto para fins descritivos quanto preditivos
33
(MENASCE et al., 2004). Entendido ainda, como uma mquina de estados, em que os ns so
estados e os arcos representam as transies entre os estados do modelo.
Na cincia da computao, em particular, este formalismo bastante conveniente para
descrever e analisar propriedades dinmicas de sistemas computacionais (BOLCH et al., 2006).
As transies so modeladas por um processo estocstico de tempo contnuo ou discreto, definido
por distribuies exponenciais ou geomtricas, respectivamente (SOUSA, 2009). Por isso, h
duas classificaes para modelos que seguem o formalismo de cadeia de Markov (STEWART,
1994; TRIVEDI et al., 2006): Cadeias de Markov escala de Tempo Contnuo CTMC ou Cadeias
de Markov escala de Tempo Discreto (Discrete-Time Markov Chain (DTMC)). A diferena
entre essas classificaes que, em modelos CTMC, suas transies entre estados podem ocorrer
em qualquer instante de tempo e no em pontos discretos de tempo.
Figura 2.8: Exemplo de cadeia de Markov.
Sua representao grfica similar a dos autmatos, como um diagrama de estado, onde
os vrtices representam os estados e os arcos do diagrama representam as possveis transies
entre os estados. As transies entre estados representam a ocorrncia de eventos (MACIEL
et al., 2011). A Figura 2.8 apresenta um exemplo de CTMC com dois estados e duas transies.
Neste modelo o estado 1 representa que o sistema estar funcionando. A partir deste a falha pode
ocorrer ( ), levando ao estado 2. Do estado 2 apenas o reparo () possvel.
Cadeias de Markov tambm so representadas em forma de matriz, a chamada matriz de
taxa de transio Q. Na matriz Q esto contidas as informaes sobre as transies dos estados
na cadeia de Markov e utilizada para a resoluo de cadeias de Markov. Cada elemento localizado
fora da diagonal principal representa a taxa de ocorrncia dos eventos que efetivam a transio
dos estados do sistema. Os elementos contidos na diagonal principal so os valores necessrios
para que a soma dos elementos de cada linha seja igual a zero. Por exemplo, utilizando a CTMC
da Figura 2.8, teremos a matriz da Equao 2.8.
Q=

2.8
As probabilidades de transio dos estados podem ser calculadas atravs da Equao 2.9.
pi, j (s,t) = PX(t) = j|X(s) = i
34

2.9
A anlise estacionria de uma cadeia de Markov consiste em encontrar a probabilidade de o sistema alcanar determinado estado durante um longo tempo de execuo. Estas
probabilidades so independentes do estado inicial do sistema e so representadas pelo vetor
= [1 , 2 , ..., n ], onde a probabilidade estacionria para o estado i. Uma vez que a cadeia
de Markov considerada, uma cadeia ergdica, podemos encontrar as probabilidades estacionrias atravs do sistema linear formado pelas Equaes 2.10 e 2.11 (BOLCH et al., 2006). Se em
uma cadeia de Markov possvel alcanar qualquer estado a partir de qualquer estado, em um
nmero n finito de passos, esta cadeia dita ergdica.
Q = 0,
n
i = 1
i=1

2.10

2.11
No qual (Equao 2.10), Q a matriz de estados e (vetor de probabilidade) o

autovetor correspondente ao autovalor unitrio da matriz de transio. Ressalta-se que a soma
dos elementos do vetor de probabilidade deve ser igual 1, ou seja |||| = 1 (ARAUJO, 2009).
A Equao 2.11 a condio de normalizao, adicionada para assegurar que a soluo obtida
um nico vetor de probabilidade. A Equao 2.10 tem um conjunto de solues infinitas.
Normalizando as solues, chega-se a um nico vetor de probabilidades.
Para os modelos em CTMC, a matriz de transio de estados Q denominada de gerador
infinitesimal, onde cada elemento no diagonal da linha i e coluna j da matriz representa a taxa
de transio do estado i para o estado j do modelo. Os elementos diagonais de Q representam o
ajuste necessrio para que a soma dos elementos de cada linha seja zero. Para os modelos em
DTMC, a matriz de transio de estados Q denominada de matriz estocstica, em que cada
elemento representa a probabilidade de transio entre os estados do modelo.
Desta forma, as cadeias de Markov tm papel fundamental no processo de modelagem
de sistemas redundantes, comportamentos especiais em pilhas de softwares e avaliao de
dependabilidade em diversos sistemas. A utilizao de CTMCs permite avaliaes tanto de
desempenho, quanto de disponibilidade. Suas aplicaes vo desde a quantificao da vazo
de uma linha de produo at a determinao de tempos de falha e reparo em sistemas crticos
(BAIER et al., 2003).
Como ser apresentado na prxima seo, Redes de Petri estocsticas podem ser analisadas atravs da obteno da cadeia de Markov associada. De forma similar, a teoria de redes
35
de filas, uma fila pode ser reduzida a uma cadeia de Markov e analisada e, alm disso, alguns
teoremas importantes desta teoria so provados atravs de modelos markovianos (KLEINROCK,
1975).
2.3.3
Rede de Petri Estocsticas
Propostas por Carl Adam Petri em 1962 (PETRI, 1962), em sua tese de doutorado
intitulada Comunicao com autmatos, as Redes de Petri (PN) constituem uma ferramenta de
modelagem grfica e matemtica aplicvel a vrias categorias de sistemas. As Redes de Petri so
adequadas para descrever e estudar sistemas caracterizados por serem concorrentes, assncronos,
distribudos e paralelos (MURATA, 1989).
A representao grfica das Redes de Petri formada por lugares (Figura 2.9(a)), transies (Figura 2.9(b)), arcos (Figura 2.9(c)) e tokens (Figura 2.9(d)). Os lugares equivalem s
variveis de estado e as transies correspondem s aes realizadas pelo sistema (MACIEL;
LINS; CUNHA, 1996). Esses dois componentes so ligados entre si atravs de arcos dirigidos.
Os arcos podem ser nicos ou mltiplos. A distribuio de tokens nos lugares da Rede de Petri
determinam o estado do sistema ou a quantidade de recursos.
(a) Lugar
(b) Transio
(c) Arco
(d) Token
Figura 2.9: Elementos de uma rede de Petri
Na Figura 2.10, apresenta-se uma Rede de Petri a qual os lugares representam os perodos
do dia (dia e noite), j as transies alteram o perodo do dia (amanhecer ou anoitecer). Nesse
exemplo, o arco dirigido do lugar dia para a transio anoitecer indica que, para que anoitea,
necessrio que haja um token no lugar dia. Tal qual, o arco dirigido do lugar noite para a
transio amanhecer indica que, para que amanhea, necessrio que haja um token no lugar
noite. A localizao do token na rede indicar, portanto, se dia (Figura 2.10(a)) ou noite (Figura
2.10(b)).
As Redes de Petri possui extenses, onde uma delas so as redes temporizadas que
buscam acrescentar s redes de Petri a possibilidade de anlise no domnio de tempo (MARRANGHELLO, 2005). As SPNs oferecem possibilidade de unir a habilidade do formalismo
de Redes de Petri para descrever sistemas com atividades assncronas, concorrentes e nodeterminsticas, alm de conflitos ou mecanismos de redundncia cold-standby ou warm-standby,
(a) Dia
36
(b) Noite
Figura 2.10: Rede de Petri representando um dia
com um modelo estocstico, permitindo a descrio de um comportamento dinmico na modelagem de desempenho e dependabilidade de sistemas (MARSAN; BALBO; CONTE, 1986),
(GERMAN, 2000), (MURATA, 1989).
Segundo Sales (SALES, 2002), uma caracterstica importante do formalismo de Redes
de Petri estocsticas que ele pode ser facilmente compreendido por pessoas que no tenham
familiaridade com mtodos de modelagem probabilstica.
Graficamente, as transies estocsticas e os arcos inibidores costumam ser representados
conforme exibido na Figura 2.11. So atribudas as transies estocsticas (Figura 2.11(a)) uma
taxa obedecendo a uma distribuio exponencial. A taxa da transio inversamente proporcional
ao tempo x, de modo, taxa ser de 1/x.
Os arcos inibidores ((Figura 2.11(b))), originalmente no presentes em Redes de Petri,
so utilizados para inibir o disparo das transies da rede. De maneira semelhante aos arcos
tradicionais, eles tambm podem ter um peso associado. A introduo da concepo de arco
inibidor aumenta o poder de modelagem de Rede de Petri, adicionando a capacidade de testar se
um lugar no tem tokens. Arcos inibidores e transies estocsticas podem ser substitudos por
guardas associadas s transies.
(a) Transio estocstica
(b) Arco Inibidor
Figura 2.11: Elementos das SPNs que estendem o comportamento das PNs.
As SPNs (CIARDO, 1994), (BALBO, 2001), (GERMAN, 2000) so obtidas atravs da
37
associao de um tempo exponencialmente distribudo com o disparo de cada transio da rede.

H muitas maneiras diferentes de representar SPNs. Este trabalho adota uma definio genrica
adotada em (GERMAN, 2000), na qual uma SPN uma tupla definida da seguinte forma:
Definio 1: Uma SPN definida pela 9-tupla SPN = (P, T, I, O, H, , G, M0 , Atts), onde:
P = {p1, p2, ..., pn} o conjunto de lugares;
T = {t1,t2, ...,tm} o conjunto de transies imediatas e temporizadas, P T = ;
I (Nn N)nm a matriz que representa os arcos de entrada (que podem ser dependentes
de marcaes);
O (Nn N)nm a matriz que representa os arcos de sada (que podem ser dependentes de
marcaes);
H (Nn N)nm a matriz que representa os arcos inibidores (que podem ser dependentes
de marcaes);
Nm um vetor que associa o nvel de prioridade a cada transio;
G (Nn {true, false})m o vetor que associa uma condio de guarda relacionada a
marcao do lugar cada transio;
M0 (Nn ) o vetor que associa uma marcao inicial de cada lugar (estado inicial).
Atts = (Dist, Markdep, Policy, Concurrency, W )n compreende o conjunto de atributos associados s transies:
Dist N F uma funo de distribuio de probabilidade associada ao tempo de
cada transio, sendo que 0 F . Esta distribuio pode ser dependente de marcao;
Markdep {constante, enabdepg}, define se a distribuio de probabilidade associada
ao tempo de uma transio constante ou dependente de marcao (enabdepg - a distribuio
depende da condio de habilitao atual);
Policy {fprd, prsg} define a poltica de memria adotada pela transio (fprd - preemptive repeat different, valor padro, de significado idntico race enabling policy; prsg
-preemptive resume, corresponde age memory policy);
Concurrency {ss, is} o grau de concorrncia das transies, onde ss representa a
semntica single server e is representa a semntica infinity server.
W N R+ a funo peso, que associa um peso (wt ) s transies imediatas e uma
taxa t s transies temporizadas.
38
O formalismo de Redes de Petri estocsticas permite duas classes diferentes de transies

no modelo: transies imediatas e transies temporizadas (HAVERKORT, 1998). As transies
imediatas possuem um tempo de disparo igual a zero com prioridade superior s transies
temporizadas e so representadas graficamente no modelo por barras finas. Estas transies
disparam assim que so habilitadas. Nveis de prioridade podem ser atribudos s transies.
Para solucionar conflitos de disparos das transies so aplicados pesos s transies imediatas
(HAVERKORT, 1998).
Uma transio temporizada dispara aps um tempo aleatrio, distribudo exponencialmente, associado mesma quando habilitada. Estas transies so representadas graficamente
no modelo por barras espessas. As taxas de disparos esto associadas somente s transies
temporizadas, e estas podem ser dependentes da marcao da SPN para serem habilitadas e
disparadas (SALES, 2002), (HAVERKORT, 1998).
As transies temporizadas podem ser caracterizadas por diferentes semnticas e indicam
quantos disparos podem ser feitos por unidade de tempo numa transio. Conhecidas como
single server, multiple server e infinite server, mostradas a seguir (MARSAN; BALBO; CONTE,
1986):
Single server - Apenas um token disparado por vez, ou seja, a capacidade de um lugar/transio 1. Utilizada em modelos de disponibilidade, considerando-se a existncia de uma
nica equipe de manuteno, quando vrios componentes do sistema passam para o estado
de falha;
Multiple server - possvel fazer k disparos por vez, ou seja, a capacidade de um lugar/transio um k inteiro. Em modelos de disponibilidade usada quando existe um nmero de
equipes de manuteno menor do que o nmero de componentes em falha, deixando-os
em excesso na fila;
Infinite server - possvel fazer infinitos disparos de uma nica vez. utilizada em modelos
de disponibilidade, quando h uma equipe de manuteno exclusiva e independente para
cada componente que falhar. Nesse tipo de semntica, todas as marcaes so processadas
em paralelo.
As SPNs marcadas com um nmero finito de lugares e transies so isomrficas s
cadeias de Markov (HAVERKORT, 1998), (MARSAN et al., 1994). O isomorfismo de um
modelo SPN com uma cadeia de Markov obtido a partir do grfico de alcanabilidade reduzido,
que dado atravs da eliminao dos estados volteis e do rtulo dos arcos com as taxas das
transies temporizadas e dos pesos das transies imediatas.
2.4. INTERVALO DE CONFIANA DA DISPONIBILIDADE
39
Os modelos SPN descrevem as atividades de sistemas atravs de grficos de alcanabilidade. Esses grficos podem ser convertidos em modelos Markovianos, que so utilizados para
avaliao quantitativa do sistema analisado. As medies de desempenho e dependabilidade
so obtidas atravs de simulaes e de anlises em estado estacionrio e transiente baseadas na
cadeia de Markov embutida no modelo SPN (BOLCH et al., 2006).
2.4
Intervalo de Confiana da Disponibilidade
As tcnicas de modelagem apresentadas anteriormente resultaram em modelos matemticos, que por sua vez, precisam de dados de entrada. Esses dados so derivados de medio ou
pesquisas anteriores. H casos de modelos criados a partir da unio de um ou mais componentes
que foram estudados anteriormente. Portanto, esses novos modelos precisam passar por um
processo de validao que compare o modelo proposto com o ambiente real.
A validao pode ser realizada usando o mtodo de Keesee (KEESEE, 1965). Este
mtodo determina um intervalo de confiana da disponibilidade. Considerando que o resultado
esteja em um intervalo, possvel indicar uma correlao entre o modelo e o ambiente real.
Considera-se satisfatrio quando o resultado do modelo est contido no intervalo. Neste processo
so usadas duas mtricas de falha e reparo: tempo de execuo e nmero de ocorrncias. Estes
dados so extrados de um experimento real e servem como entrada para as frmulas abaixo
apresentadas.
Primeiro adaptada a equao da disponibilidade, simplificando-a conforme apresentado na Equao 2.12.
A=
1
1
=
=
+
1+
1+

2.12
Assume-se que a relao entre . Considera-se para o experimento o n sendo os

eventos de falha e reparo. Para o tempo total de falha Sn e o tempo total de reparo Yn . No
trabalho, prope-se um mtodo para estimar o valor de , o qual definido na equao.
= n
Sn

2.13
Um intervalo de confiana 100*(1 - ) para dado por uma distribuio Qui-quadrada

com os parmetros definidos na Equao 2.14.
2
2
X2n;1
X
2n; 2
2
(
,
)
2Sn
2Sn

2.14
2.5. ANLISE DE SENSIBILIDADE
40
Para estimar , segue o mesmo processo usado para calcular , de acordo com a Equao
2.15.

2.15
n
M =
Yn
Para o intervalo de confiana 100*(1 - ) para similar a Equao 2.14, conforme

Equao reajustada 2.16.
2
2
X2n;1
X
2n; 2
2
(
,
)
2Yn
2Yn
Consequentemente, o estimador de probabilidade mxima para a relao

pela Equao 2.17
=
=
M
n
Sn
n
Yn
Yn
Sn

2.16
definida
,

2.17
Um intervalo de confiana para dado entre l e u, seguindo uma funo de probabilidade da distribuio F, vista na Equao 2.18.
l =
e u =
f 2n; 2n; 2
f 2n; 2n; 1 2

2.18
Finalmente, o estimador de probabilidade mxima para a disponibilidade A = 1+1 . Isto

acontece porque A uma funo monotonicamente decrescente de e o intervalo de confiana
100*(1-) para A a apresentada na Equao 2.19.
(
2.5
1
1
,
)
1 + u 1 + l

2.19
Anlise de sensibilidade um conjunto de tcnicas usadas para determinar os fatores

mais crticos em relao s medies ou sadas de um modelo (HAMBY, 1994). A tcnica mais
simples adotada para avaliar a sensibilidade de uma mtrica com seus respectivos parmetros
escolher um parmetro para variar enquanto mantm os outros fixos. Isso uma forma de
obter um ranking de sensibilidade que registra as mudanas da sada do modelo correspondente
variao nos parmetros de entrada (HAMBY, 1994).
Quando relacionada com modelos analticos como cadeias de Markov, RBD e SPN,
a anlise de sensibilidade paramtrica torna-se uma tcnica importante para que os efeitos
2.6. AVAILABILITY IMPORTANCE
41
causados atravs de mudanas nas taxas de transio nas mtricas de interesse sejam computados.
Essa abordagem utilizada para detectar gargalos de desempenho ou confiabilidade no sistema,
guiando a otimizao dos processos (BLAKE; REIBMAN; TRIVEDI, 1988; ABDALLAH;
HAMZA, 2002). Anlise de sensibilidade beneficia a identificao dos parmetros que podem
ser removidos sem efeitos significantes aos resultados. Modelos grandes, com uma dzia de
taxas, podem ser drasticamente reduzidos atravs do uso dessa abordagem.
Entre outras tcnicas aplicveis para anlise de sensibilidade incluem projetos experimentais fatoriais, anlise de correlao, anlise de regresso, anlise de perturbao (PA) bem
como anlise diferencial, conhecida como anlise de sensibilidade paramtrica ou mtodo direto
(HAMBY, 1994), (Matos Jnior, 2011), (MATOS et al., 2012). A anlise diferencial foi escolhida para esse trabalho porque pode ser eficientemente realizada nos tipos de modelos analticos,
normalmente empregados nos estudos de disponibilidade e desempenho. Na anlise diferencial
as derivadas parciais das mtricas de interesse so calculadas dos respectivos parmetros de
interesse. Se mtrica Y depende de um parmetro ( ), a sensibilidade de Y com respeito a
calculada pela Equao 2.20 ou 2.21, quando adotado a sensibilidade escalada (FRANK, 1978).
Y

Y
S (Y ) =
Y
S (Y ) =

2.20

2.21
Outros mtodos de escala podem ser empregados, dependendo da natureza do parmetro,

entre eles a mtrica de interesse, a necessidade para compensar grandes diferenas em unidades
e magnitude de medida (Matos Jnior, 2011). S (Y ) e S (Y ) tambm so referidos como
coeficientes de sensibilidade (HAMBY, 1994), cujos valores so ordenados em um ranking, que
compara o grau de influncia entre todos os parmetros.
2.6
Availability Importance
A importncia de componentes pode ser analisada em termos de confiabilidade, de

disponibilidade e destas relacionadas com custos. Este trabalho restringir a importncia do componentes em relao a disponibilidade, denominada Availability Importante. Essa anlise destaca
quais componentes tem maior impacto na disponibilidade do sistema, ou quais componente
que, aumentando sua disponibilidade, aumentaro mais significativamente a disponibilidade
(FIGUEIRDO; ROMERO MARTINS MACIEL, 2011).

O ndice de Availability Importante IiA baseado no ndice de Reliability Importance.
Este considera o tempo mdio para falha dos componentes, justificado por ser uma mtrica de
2.7. VIDEO SURVEILLANCE AS A SERVICE
42
confiabilidade. Para o avaliador ao executa os clculos, ao invs de utilizar a confiabilidade,

a mtrica utilizada a disponibilidade, incluindo, alm do tempo mdio para falha, o tempo
mdio de recuperao dos componentes. O clculo utilizado mostrado na Equao 2.22, e
os resultados normalizados pelo maior valor calculado pela Equao 2.23 (FIGUEIRDO;
ROMERO MARTINS MACIEL, 2011).
IiA = As (1i , pi ) As (0i , pi )

2.22
Onde pi representa o vetor de disponibilidades dos componentes com o isimo componente removido; 0i representa a condio quando o componente i falho e 1i a condio quando
o componente i est no modo operacional.
Ini =
Ii
Ix

2.23
Onde Ini o ndice normalizado para o componente i; Ii o valor do ndice no normalizado para o componente i e, Ix o valor do maior ndice no normalizado entre os componentes.
Essa tcnica de anlise ser usada na subseo 5.2.1, do Captulo 5. Com o objetivo
de apontar quais componentes sero replicados no Estudo de Caso II, referente ao contexto do
sistema empresarial.
2.7
Video Surveillance as a Service
Servios de live video streaming so proferidos na Internet (PICCONI; MASSOULI,

2008). Ao mesmo tempo, os desafios especficos desta tecnologia, tais como taxa bits constantemente varivel, transmisses especiais de agendamento, bem como a necessidade de mtodos
de gerenciamento de armazenamento para lidar com trfego intenso (CHANG; VETRO, 2005),
esto incentivando consideravelmente as pesquisas e desenvolvimentos nesta rea. Um dos
principais representantes dos servios de live video streaming o VSaaS. Em pesquisa da IMS
Research, sobre as tendncias em matria de tecnologias vigilncia visuais prev crescente
demanda de nuvem baseadas solues de vigilncia LAWTON (2009). O conceito de sistema de
vigilncia de vdeo baseada em nuvem est em sua fase de infncia SHARMA; KUMAR (2014).
O conceito VSaaS bastante novo. Os servios so restritos, principalmente, ao armazenamento de dados de vdeo na nuvem, redirecion-los o cliente, ou para enviar relatrios
analticos aps a triagem manual dos dados SHARMA; KUMAR (2014).
Dificilmente, h prestadores de servios que conseguem transmitir e analisar os fluxos
de vdeos em tempo real, porque existem vrios desafios para alcanar este nvel de operao
43
simultnea. A Smartvues lista 10 desafios para VSaaS M (2012). Entre estes a largura de
banda, velocidade, gesto de dados, segurana e transferncia so desafios chaves. Com a
transmisso realizada pelas tecnologias 3G e 4G a soluo das questes como a largura de banda
e a velocidade esto quase l SHARMA; KUMAR (2014).
Alm disso, os servios VSaaS comearam a compreender as preocupaes dos seus
clientes relacionadas com a segurana e privacidade, ento eles apresentaram polticas mais
transparentes e justas relativas ao armazenamento e uso de dados de vdeo dos clientes SHARMA;
KUMAR (2014).
Com a maturidade do mercado de VSaaS nos ltimos anos o servio oferecido em trs
modelos de negcios: o servio hospedado, o sistema gerido pelo fornecedor ou um modelo
hbrido no qual os potenciais clientes precisam perceber as principais diferenas. O primeiro
modelo o servio hospedado de vigilncia por vdeo que grava as imagens fora das instalaes
do cliente com as imagens a serem transferidas sobre a rede do cliente para o fornecedor data
centers, onde so geridas e armazenadas, implicar em capital de investimentos para aquisio
dos equipamentos de armazenamento.
O segundo modelo o servio gerido de vigilncia por vdeo, onde a gravao das
imagens realizada nas instalaes do cliente e a vigilncia gerida remotamente pelo fornecedor.
O ltimo modelo o hbrido. Neste caso, as imagens so transmitidas para o site do fornecedor,
mas tambm so armazenadas nas instalaes do cliente de vrias maneiras nas cmaras, em
um aparelho suplementar ou em um suporte de armazenamento anexado rede ou NAS (Network
Attached Storage).
Por muitas razes, incluindo segurana e a popularidade das cmeras IP para vdeos
de vigilncia esto crescendo rapidamente. Na Terceira gerao dos sistemas de vdeo de
vigilncia, so necessrias informaes dos vdeos, como o fluxo ou sequncia das imagens
digitais, fornecendo uma abordagem inteligente e eficiente para anlise automtica de sistemas.
No mercado de VSaaS, existem algumas empresas ofertando esse servio, entre elas:
a Axis, Ivideon, MagonCam, K Group Companies, Neovsp, Security Station. A seguir esto
listadas algumas vantagens apresentadas pela empresa IVIDEON na utilizao do servio de
VSaaS:
Servio Global - Acessar todas as suas cmeras em diferentes continentes;
Incorporar o vdeo em seu website - adicionar um vdeo ao vivo da sua cmera em um
website ou blog, ou compartilhar um link direto para o Facebook;
Compatibilidade - Utilizar uma Cmera IP cara, uma CCTV ou at uma simples webcam;
44
Dar acesso a outros usurios - definir a permisso de acesso de vrios usurios as cmeras
de forma simultnea;
Aplicativos Mveis - v o que est acontecendo em qualquer lugar usando um navegador ou
um aplicativo mvel para iPhone, iPad e Android;
Marcar as cmeras em um mapa - Criar marcao de todas suas cmeras no Google Maps;
Segurana - Todos os dados - incluindo transmisses de vdeo - so criptografados;
Arquivos armazenados em nuvem - opo de armazenar os vdeos localmente ou mant-los
seguros na nuvem.
A empresa Security Station, esboa na Figura 2.12 como a forma de funcionamento do
VSaaS oferecido por ela. A empresa utiliza Cmeras IP que so gerenciadas por uma nuvem,
que tambm pode realizar a gravao dos vdeos. Esta nuvem disponibiliza para o usurio final
a visualizao das imagens em tempo real por meio dos navegados dos dispositivos (tablet,
smarthphone e computador).
Visualizao
Cmeras IP
Gerenciamento e gravao
baseada em Nuvem
Figura 2.12: Estrutura do VSaaS, da empresa Security Station
45
3
Metodologia de Avaliao e
Arquiteturas VSaaS
No desista nas primeiras tentativas, a persistncia amiga da conquista.
Se voc quer chegar onde a maioria no chega, faa o que a maioria no faz.
BILL GATES
Este Captulo apresenta a metodologia utilizada nessa pesquisa e os sistemas utilizados

nos estudos de casos com suas respectivas arquiteturas modeladas analiticamente.
3.1
Metodologia de Avaliao de Disponibilidade
Nesta Seo externa-se uma metodologia para auxiliar a avaliao e os modelos de disponibilidade para VSaaS. A metodologia prope diversas etapas, entre as quais, o entendimento
do sistema, definio de mtricas de interesse, obteno dos modelos, validao do modelo,
avaliao do sistema e, por fim, a interpretao dos resultados atraves de anlises. Na Figura 3.1
as etapas da metodologia adotada so exibidas em forma de fluxograma.
A primeira etapa da metodologia ora proposta diz respeito compreenso dos sistemas
VSaaS, dos seus componentes e das suas interaes. nesta fase que so adquiridos os insumos
necessrios para a modelagem do sistema. Caso o entendimento do sistema no seja claro, o
avaliador provavelmente cometer erros de interpretao e, consequentemente, comprometer
as etapas seguintes. Esta etapa tambm divide o sistema em subsistemas menores para mitigar
a complexidade na avaliao do modelo final do sistema. Tal subdiviso facilitar na etapa de
obteno dos modelos.
3.1. METODOLOGIA DE AVALIAO DE DISPONIBILIDADE
46
Figura 3.1: Metodologia
Com base nos entendimentos do sistema e atrelado a pesquisas encontradas e/ou visitas
em organizaes, os sistemas e suas arquiteturas a serem utilizadas durante o estudo so definidas
nessa etapa. Nesta fase, deve-se obter os parmetros de entrada para avaliao dos modelos,
procurando o MTTF, MTTR ou Mean Time Between Failures (MTBF) de todos componentes
que compem a arquitetura. Esses parmetros foram obtidas atravs de pesquisas anteriormente
publicadas, porm eles poderiam ser obtidos por meio de medio.
Na segunda etapa so definidas as mtricas relevantes para a avaliao de um sistema
VSaaS, bem como a definio de mtricas de dependabilidade. As mtricas usadas foram
disponibilidade, downtime anual e custo. Essas mtricas foram especificadas no Captulo 2 e
sero formuladas no Captulo 4 seguindo a sintaxe suportada pelas ferramentas de avaliao
utilizadas.
Em seguida, os modelos so criados para cada subsistema utilizando a tcnica de modelagem mais adequada, como RBD, CTMC ou SPN (para citar apenas os modelos adotados
neste trabalho). Tais modelos so ento adotados para obter as mtricas de interesse. Nesta etapa,
deve-se realizar a escolha das ferramentas apropriadas para modelar (entre as quais Symbolic Hierarchical Automated Reliability and Performance Evaluator (SHARPE), Mercury e TimeNet),
em funo da tcnica usada e ferramentas matemticas (o Mathematica) para anlise e obteno
de frmulas fechadas.
A etapa de validao responsvel por verificar se o modelo representa o sistema de
3.2. ARQUITETURAS VSAAS
47
forma satisfatria ou se no cumpre os requisitos do sistema. Um mtodo vivel de realizao

destes estudos atravs de injeo automatizada de falhas, permitindo observar o comportamento
do sistema sob muitas condies. Para esse experimento de injeo de falha, foi necessrio a
montagem do ambiente de teste, onde instalado e configurado o sistema conforme a arquitetura
bsica. Por conseguinte, desenvolveu-se algoritmos em Shell Script para inserir falhas nos
componentes do sistema com o intuito de simular o comportamento do ambiente real, e outro
para monitorar o servio com a finalidade de verificar se o sistema est operacional ou no.
As taxas de falha e reparo dos componentes usadas no experimento so tempos exponencialmente distribudos, ressalva-se que estas taxas foram aceleradas, a fim de reduzir o tempo
total do experimento, tendo em vista que falhas so imprevisveis e podem levar um longo
tempo para se manifestar. Este processo mais bem detalhado na Seo 4.1.3. Com a execuo
do experimento obtido resultados que sero utilizadas no processo de validao do mesmo.
Para que o modelo seja considerado vlido, necessrio que este proporcione o clculo de
mtricas com erros de exatido dentro de nveis considerados aceitveis, denominado intervalo
de confiana da disponibilidade. Uma vez que satisfaa as exigncias, o processo segue o passo
seguinte, de outro modo, os ajustes nos modelos devem ser realizados de modo a representar
corretamente o comportamento do sistema.
O prximo passo muito importante porque onde a disponibilidade ser avaliada. Os
modelos de subsistema so avaliados considerando vrias arquiteturas que foram propostas
mediante a avaliao da arquitetura inicial, considerada baseline. As arquiteturas criadas devem
representar as situaes de interesse. Essas arquiteturas sero comparadas com finalidade de
determinar se certa estratgia de redundncia satisfatria ou no.
Por fim, os resultados obtidos so analisados de forma adequada com apoio de ferramentas matemticas (Mathematica, Mercury e o Minitab). Pode-se identificar o impacto dos
diferentes parmetros na disponibilidade do sistema. responsabilidade do avaliador interpretar
os dados e apontar as possveis melhorias na infraestrutura. Os resultados podem apontar pontos
de falhas da infraestrutura mais crticos que outros. As tcnicas que auxiliam o avaliador nessa
intepretao foram Availability Importance, Anlise de Sensibilidade Paramtrica e Anlise de
Custo, por meio da distncia euclidiana at seu ponto de origem. Alm disso, a concluso das
arquiteturas com grficos e tabelas auxiliam a apresentao desses resultados.
3.2
Arquiteturas VSaaS
Nesta Seo sero detalhados os dois sistemas adotados nesta Dissertao. O primeiro
deles denominado Domstico para ser utilizada em casos simples, por exemplo, casas, escolas
48
ou comrcios. No segundo, tratou-se de uma concepo dirigida empresa, chamado Empresarial.

Por inmeras particularidades possveis de outras arquiteturas, esse trabalho prope escolher
restries genricas que possibilitem aplic-las em outras situaes. As restries, os recursos,
operaes, componentes e as explicaes sobre o funcionamento desses sistemas so apresentadas
nas subsees a seguir.
3.2.1
Arquiteturas do Sistema Domstico
A primeira arquitetura do sistema domstico teve um papel fundamental, porque serviu

de entendimento do VSaaS para implantao do ambiente de experimento e sua validao. Esta
arquitetura foi adaptada da plataforma VSaaS do trabalho de Xiong (XIONG et al., 2014) e
ilustrada pela Figura 3.2.
Vale ressaltar a importncia de compreender os motivos pelo qual este estudo optou
analisar um sistema de vigilncia em nuvem, ao invs do sistema convencional. Os sistemas
convencionais so entendidos com uma central de monitoramento na prpria empresa. Desta
forma, pode haver problemas do custo inicial elevado na implantao e uma segurana que pode
se transformar em insegurana, tendo em vista que a central pode ser alvo dos criminosos. Ento,
com o servio nas nuvens, existe o benefcio de baixo custo na instalao (pela escalabilidade
dos recursos) e o aumento nos nveis de segurana.
Uma plataforma VSaaS, normalmente, possui dois momentos com a interao do cliente.
O primeiro em relao a gerao das streaming de vdeo e o segundo no acesso remoto as essas
imagens. Os vdeos gerados so enviados pela Internet at uma nuvem privada, que no nosso
estudo foi o OpenNebula 3.6 1 . Esta plataforma privada de nuvem composta por Frontend,
Node, dispositivo de armazenamento e uma mquina virtual, esta por sua vez possui um servidor
web (Apache2 com uma aplicao que recebe e disponibiliza a streaming de vdeo (Ffmpeg3 ).
Contudo, esta pesquisa limita-se a verificar a disponibilidade da arquitetura do conjunto
de cmeras no lado do cliente at um ambiente de nuvem que oferece a transmisso pelo servio
web, no considerando a visualizao e monitoramento do usurio atravs de qualquer que seja
o dispositivo com acesso Internet e um navegador. Da mesma forma, tambm no foram
considerados o componente e o software de armazenamento.
Salienta-se que nos experimentos e na modelagem no se detm aos problemas do link
de conexo com a Internet, tais como: jitter, latncia, perda de pacotes e taxa de transferncia.
Esses aspectos no foram levados em considerao pelas dificuldades dos provedores de Internet
1 http://opennebula.org/
2 http://www.apache.org/
3 https://www.ffmpeg.org/
49
Figura 3.2: Pataforma VSaaS.
em garantir taxas constantes de transmisso. Utilizou-se ainda, tecnologias de conexo sem fio
(a 3G e WiFi) que podem receber interferncia do ambiente. Desta forma, deixa-se explcito que
esses aspectos podem afetar os resultados desta pesquisa.
Na Figura 3.3 visualizada a arquitetura 1, denominada bsica, por possuir apenas os
componentes necessrios para o seu funcionamento. Percebe-se que uma arquitetura com
ausncia de componentes replicados. Esses componentes so apresentados com suas respectivas
interaes. Sendo composto por Cmera (C), um computador de apoio chamado de Streaming
Transmitter (ST), conexes de Wireless Fidelity (WiFi), Frontend (F), Node (N) e subconjunto
denominado Live Video (LV), todos esses componentes sero explicados adiante.
Figura 3.3: Arquitetura 1 - Bsica.
Quanto ao modo operacional dessa arquitetura, entende-se que a plataforma estar

indisponvel quando ocorrer alguma falha na cmera, no streaming transmitter, na WiFi, no
50
Frontend ou no servio LiveVideo, dessa forma, o modo operacional para arquitetura da Figura
3.3 pode ser sintetizado na Expresso Lgica 3.1, (onde os componentes so representados por C,
ST, WiFi, F, N e LV, respectivamente). Uma falha na cmera impossibilita o acesso as imagens e
compromete o funcionamento do sistema. Essas imagens podem sofrer interrupes no lado do
cliente caso o ST ou a conexo de rede WiFi falhem. No mbito do ambiente de nuvem a falha
do F afetar todos os componentes do sistema, tornando o servio da plataforma indisponvel.
Da mesma forma, um defeito no N ocasionar na indisponibilidade do servio, bem como uma
falha no conjunto do LV que pode ocorrer em qualquer um dos componentes de software que
formam a pilha de servio ilustrada na Figura 3.3.
ArqV SaaS1Ativa = C ST WiFi F N LV

3.1
Explicando o funcionamento desses componentes, a Cmera o componente que

caracteriza esta arquitetura em um sistema de vdeo de vigilncia, tendo a finalidade de gravar
e transmitir as imagens dos locais definidos estrategicamente. Porm, saber qual o melhor
posicionamento, com a menor extenso de pontos cegos no uma deciso fcil. Para esta
deciso, as arquiteturas 2 e 3 com redundncia (das Figuras 3.4 e 3.5) considera-se o trabalho
de (SUTOR et al., 2008). Neste trabalho apresentada uma Cobertura da Qualidade Visual
de Vigilncia (Cobertura da Qualidade Visual de Vigilncia (VSCQ)), que um parmetro
de desempenho usado para determinar a localizao, distribuio e nmero de cmeras que
asseguram a cobertura mnima, se uma ou mais cmeras falharem. Assume-se para estas
arquiteturas o parmetro chamado de VSCQ1 (cobertura total do espao), o que requer que pelo
menos duas das trs cmeras funcionem. considerado um tipo alternativo de redundncia que
aumenta os nveis de segurana mesmo como possvel fracasso de uma cmera.
O Streaming Transmitter responsvel pela gesto das cmeras no ambiente que ser
monitorado, recebimento da streaming de vdeo e a transmisso para a plataforma. Este sistema
composto por um computador e um software de transmisso Ffmpeg. Este foi incluso na
arquitetura bsica em funo do baixo custo do computador (considerando a aquisio e o
consumo de energia) e principalmente pela facilidade na configurao de diferentes tipos de
cmeras, desde uma simples webcam at uma cmera IP (escolhida para o modelo estudado). No
entanto, este componente pode ser substitudo por cmeras que se ligam diretamente Internet
ou a um dispositivo de rede que receba e envie streaming de vdeo.
As Conexes de Rede permitem o acesso Internet via Wi-Fi ou 3G para transmisso.
Estas conexes podem ser usadas separadas ou de forma redundantes de acordo com a disponibilidade desejada, na arquitetura 1 considera-se apenas Wi-Fi. J nas arquiteturas 2 e 3 foram
integrada conexo 3G, conforme visto nas Figuras 3.4 e 3.5, respectivamente. O ambiente de
51
computao em nuvem estruturado com um Frontend e vrios Nodes que formam um cluster.
A gesto dos recursos da infraestrutura e controle de Nodes atribuio do Frontend, alm de
decidir pelas instanciao das VMs nos Nodes. Por sua vez, os Nodes executaro o servio
de LiveVideo e poder programar polticas de alta disponibilidade, tais como (heartbeat4 ), live
migration ou balanceamento de carga.
O subsistema LiveVideo composto de uma VM e um servidor web (Apache5 ). Este
componente permite que o usurio monitore (via computadores ou dispositivos mveis) as
imagens que esto sendo capturadas. Para as transmisses ser utilizado um mesmo aplicativo de
streaming de vdeo do (FFmpeg). Outra funo desempenhada neste subsistema a compactao
do vdeo para um formatado desejado, j que o administrador pode optar por maior qualidade
de imagem possuindo uma rpida conexo de Internet ou uma menor qualidade para no haver
travamento nas imagens ao serem assistidas.
A segunda arquitetura do sistemas domsticos exibida na Figura 3.4, nesta h redundncia na cmera e no servio LiveVideo, justificada pelo VSCQ1 do trabalho (SUTOR et al.,
2008). Alm desta, a 3G foi incorporada como outro componentes redundante na conexo de
rede. O modo operacional desta arquitetura sintetizada na Expresso Lgica 3.2 e difere do
modo operacional da arquitetura bsica, pelo fato da redundncia. No caso das cmeras, para
estarem disponvel necessrio as seguintes combinaes, C1 e C2, ou C1 e C3 ou C2 e C3
estarem funcionando. Esta mesma lgica aplicada para o LiveVideo. Para as conexes de rede
basta a WiFi ou o 3G funcionarem para o sistema est disponvel.
Figura 3.4: Arquitetura 2 - Com redundncia.

4 http://linux-ha.org/wiki/Heartbeat
5 http://www.apache.org/
52
ArqV SaaS2Ativa = ((C1 C2 ) (C1 C3 ) (C2 C3 )) ST (WiFi 3G) F N

((LV1 LV2 ) (LV1 LV3 ) (LV2 LV3 ))

3.2
A ltima arquitetura do sistema domstico (Figura 3.5) semelhante segunda, apenas

com redundncia no componente Node. O modo operacional desta arquitetura encontra na
Expresso Lgica 3.3. O princpio para o componente Node esteja em funcionamento o mesmo
utilizado para o conjunto das cmeras.
Figura 3.5: Arquitetura 3 - Com redundncia.
ArqV SaaS3Ativa = ((C1 C2 ) (C1 C3 ) (C2 C3 )) ST (WiFi 3G) F

((N1 N2 ) (N1 N3 ) (N2 N3 )) ((LV1 LV2 ) (LV1 LV3 ) (LV2 LV3 ))
3.2.2

3.3
Arquiteturas do Sistema Empresarial
Mediante visita a uma empresa de contabilidade do municpio de Caruaru, que por

motivo de privacidade ser chamada de Empresa X. Os componentes so os mesmo utilizados na
arquitetura bsica da Seo anterior, com suas respectivas funcionalidades. Porm, as restries
que compreendem a disponibilidade, ausncia da conexo de rede 3G e a organizao na
distribuio das cmeras so diferentes. Este sistema foi rotulada de Empresarial e apresentado
na Figura 3.6.
A Empresa X formada por cinco andares, onde cada um deles constitudo por um
corredor que d acesso a quatro salas. Em um contexto, sem adotar redundncia, em cada sala e
53
Figura 3.6: Arquitetura de uma empresa com VSaaS
nos corredores foram implantadas as cmeras direcionadas as portas de acesso de cada sala, com
o intuito de registrar a entrada e a sada das pessoas.
Em uma das salas possui o Streaming Transmitter que tem a funo de receber o sinal de
todas as cmeras da empresa e, por meio de uma conexo (WiFi) com a Internet, comunica e
distribui os vdeos com o ambiente de Computao em Nuvem. Este componente, possibilita
compreender uma diferena entre o sistema de vdeo de vigilncia convencional com o VSaaS.
O sistema convencional monitorado em tempo real por uma guarda ou ter de armazenar tudo
que gravado pelas cmeras. Com isso, ir gerar um risco de segurana, onde o computador
poder ser roubado ou quebrado, consequentemente perdendo todos os dados. Custos elevados
so necessrios para montar um servidor de armazenamento localmente, sendo importante saber
que em um dos seus modelos de negcios, o VSaaS oferece o servio de armazenamento.
No funcionamento de VSaaS, o ambiente em nuvem proporcionar um menor custo, pelo
fato de seu uso ser sob demanda e os dados no serem armazenados localmente, resolvendo o
problema de segurana em caso de roubo ou o computador ter um dano irreparvel. Todavia,
no contexto de segurana em VSaaS encontra-se a gerao de novos problemas, como o caso
da invaso de privacidade. No caminho da transmisso dos dados, hackers podem ter acesso s
imagens. Ento, algo que tambm se deve ter cuidado. Mas, com os avanos da computao
em Nuvem esse problema vem sendo trabalhado e os riscos minimizados.
Na atuao do Frontend, Node e LiveVideo que compem a infraestrutura na nuvem,
somente o Node teve restrio. Foi limitada a instanciao de 10 VMs para cada Node que
continuar com as funcionalidades de gerenciar os recursos de processamento e disponibilizando
pela Internet os vdeos de vigilncia.
Porm, como afirmar que o VSaaS desta empresa esteja disponvel? Se o modo operacional fosse que todas as cmeras devessem estar funcionando para ser considerado ativo teria uma
baixa disponibilidade por causa da restrio rgida que poderia ser utilizada, porm nem sempre
o radicalismo a estratgia mais sensata. Ento, a pesquisa considerou a restrio do modo
54
operacional definido por andar, onde cada um deles possui cinco cmeras. Se considerarmos
que todas as informaes e materiais importantes esto nas salas, pode-se afirmar que, de modo
operacional, pelo menos quatro das cinco cmeras estejam funcionando para que o sistema
continue ativo. Por exemplo, considera-se que, caso uma das cmeras instaladas nas salas falhe
por meio da cmera implantada no corredor, ser descoberto quem teve acesso ao local. Da
mesma forma, se a cmera do corredor falhar no haver influncia na disponibilidade, j que
todas as outras salas tiveram os contedos gravados.
Nesta arquitetura, tem-se uma nova abordagem em relao ao servio LiveVideo e a
cmera. Considera-se, pois que a cmera um esteja associada ao servio LiveVideo um. Com
isso, uma Expresso Lgica 3.4 foi gerada para encontrar modo operacional. Ressalva que est
Expresso Lgica utilizada para entender a disponibilidade de um andar.
ArqV SaaSEmpresarialAtivo = CameraLiveVideoAtivo WiFi F (N N N)

3.4
A notao nica da cmera um com o LiveVideo ficou estabelecido em CLV . A notao

dos demais componentes j apresentados nas arquiteturas da Seo Anterior. Para no comprometer a esttica e compreenso na apresentao das informaes, optou por apresentar o modo
operacional da cmera com servios LiveVideo a parte, na Expresso Lgica 3.5. Esta estratgia
melhor explicada no Captulo 5.
CameraLiveVideoAtivo = (CLV1 CLV2 CLV3 CLV4 ) (CLV5 CLV2 CLV3 CLV4 )

(CLV1 CLV5 CLV3 CLV4 ) (CLV1 CLV2 CLV5 CLV4 )
(CLV1 CLV2 CLV3 CLV5 ) (CLV1 CLV2 CLV3 CLV4 CLV5 )
3.5
Portanto, o uso da estratgia das cmeras e dos servios LiveVideo um bom exemplo
de segurana que se combina com alta disponibilidade. Porm, outras interpretaes podem
ser geradas, por exemplo, se duas ou trs das cinco cmeras estiverem funcionando em cada
andar, ser que aumentar a disponibilidade? Para se ter essa percepo estas trs interpretaes
so verificadas em parte do estudo de caso 2. Com base nesta arquitetura inicial do Sistema
Empresarial outras arquiteturas foram propostas com o uso da tcnica de availability importance.
Por fim, sero aplicadas uma anlise comparativa de custo e o downtime das arquiteturas, com
o objetivo de encontrar uma arquitetura eficaz. Para isso, os dados das arquiteturas sero
normatizados para calcular a distncia euclidiana e encontrar a menor distncia em relao a
origem, entre os resultados obtidos.
55
4
Modelos de Disponibilidade
A nica maneira de enfrentar o obstculo maior ultrapassar os obstculos
menores.
(JULIO VERNE)
Este captulo apresenta a fase de modelagem analticas das arquiteturas dos sistemas
domstico e empresarial, com suas respectivas variaes. O modelo da primeira arquitetura
proposta foi submetido ao processo de validao. As tcnicas de modelagem mediante complexidade que surgiu durante o concebimento dos modelos, foram utilizadas RBD, CTMC e SPN. Os
mecanismos de redundncia incorporados nas arquiteturas so elucidados. Por meio dos modelos
gerados foi possvel obter as frmulas fechadas, importantes para calcular mtricas de disponibilidade e realizao da anlise de sensibilidade e do availibity importance. As modelagens partem
da tcnica RBD para os comportamentos simples, por indicar como que o funcionamento dos
componentes que forma um sistema pode afetar no funcionamento de determinado sistema. Por
RBD possibilita o clculo de mtricas de dependabilidade, como a disponibilidade (MACIEL
et al., 2011), mtrica principal dessa Dissertao. Alguns componentes dos modelos RBD so
formados por outros componentes, onde alguns podem ser representados por outros RBDs,
enquanto que outros apresentam interaes mais complexas entre seus componentes, justificando
o uso de modelos baseados em estados em tais situaes, como o caso do CTMC ou SPN
(MACIEL et al., 2011).
4.1
Modelagem das Arquiteturas do Sistema Domstico
Para a modelagem e a validao desta arquitetura, esta seo ser divida em trs subsees: a primeira contm os componentes que foram modelados com RBD; a segunda contm os
4.1. MODELAGEM DAS ARQUITETURAS DO SISTEMA DOMSTICO
56
componentes modelados pela CTMC, caso especfico do servio LiveVideo; e por conseguinte,
so explicados os resultados do processo de validao.
A Figura 4.1 representa o resultado da fase de modelagem da arquitetura bsica ilustrada
na Figura 3.3, na Seo 3.2. Este modelo de alto nvel est representado por um conjunto de
RBDs, no total de seis submodelos. Suas notaes foram simplificadas para possibilitar que
as frmulas fechadas sejam expressas: Cmera (C), Streaming Transmitter (ST), WiFi (WF),
Frontend F), Node (N) e LiveVideo (LV). Alguns blocos esto com sombreamento e sinalizam
blocos que so representados por submodelos de forma hierrquica, por outros blocos RBDs ou
aplicada outra tcnica de modelagem, CTMC.
4.1.1
Modelos RBDs
Figura 4.1: Modelo RBD da arquitetura 1.
Para facilitar a didtica de apresentao s trs variaes desta arquitetura inicial, as

frmulas fechadas so exibidas mediante ilustrao das figuras nos respectivos modelos. Elas
foram usadas para calcular a disponibilidade destas arquiteturas. O resultado da frmula fechada
do modelo da Figura 4.1 a Equao 4.1. Os componentes ST, F e N esto sombreados para
indicar o fato que foram avaliados por outros modelos RBDs e o LV foi por CTMC. A AArquitetura1
a disponibilidade da arquitetura bsica, sendo formada pela multiplicao das disponibilidade
dos componentes AC , AST , AW F , AF , AN e ALV .
Sua particularidade da modelagem ter somente blocos em srie, justamente pela
inexistncia de componentes redundantes. No esquecendo o servio LiveVideo, explicado
adiante, que utiliza uma CTMC para sua modelagem e no possui redundncia.
AArquitetura1 = AC AST AW F AF AN ALV

4.1
A partir da arquitetura bsica, alguns mecanismos de redundncia so acrescentados
57
nos componentes. Para evitar a repetio dos submodelos nas figuras das arquiteturas com
redundncia, optou-se por exibir o primeiro nvel do modelo. Na Figura 4.2, que representa a
arquitetura 2, trs componentes so replicados, presentes na Equao 4.2: a AC e o ALV com
blocos de operao 2-out-of-3, significa que das trs cmeras ou servios LiveVideo, pelo menos
duas devem funcionar para o subsistema esteja operacional. Sua frmula se d por 1 , mesmo
sendo o exemplo da cmera, o mesmo usado para outros componentes do tipo. A cmera em
2-out-of-3 AC mais trs vezes AC 2 vezes 1 menos AC .
A ALV a disponibilidade resultada de uma CTMC com mecanismo de redundncia, so
duas redundncias em um mesmo servio. Por fim, uma redundncia na conexo de rede com a
Internet obtida com a adio da tecnologia 3G com o WiFi por meio de blocos paralelos. Este
representado por 1 e significa que a disponibilidade (1 - (1 AW F ) (1 - A3G )).
Figura 4.2: Modelo RBD do arquitetura 2 da arquitetura bsica com a estratgia de

redundncia 1.
AArquitetura2 = 1 (AST ) (1 (1 AW F ) (1 A3G )) (AF ) (AN ) 1

4.2
onde,
1 = (AC 3 + (3 AC 2 (1 AC ))
1 = (ALV 3 + (3 ALV 2 (1 ALV ))
Na Figura 4.3, da arquitetura 2, existe uma diferenciao com a arquitetura 2 que a
redundncia no componente AN que tambm usar o bloco de operao 2-out-of-3. Conforme
a Equao 4.3 equivalente a Figura 4.3. Esta arquitetura considerada a de maior nmero de
redundncias, totalizando cincos.
AArquitetura3 = 1 (AST ) 1 (AF ) 1 2
onde,
1 = (AC 3 + (3 AC 2 (1 AC ))
1 = (1 (1 AW F ) (1 A3G ))

4.3
58
Figura 4.3: Modelo RBD da arquitetura 3 com a estratgia de redundncia 2.
1 = (AN 3 + (3 AN 2 (1 AN ))
2 = (ALV 3 + (3 ALV 2 (1 ALV ))
Os trs subsistemas RBDs representados por blocos de cinza na Figura 4.1 (Transmisso
Transmitter, Node e Frontend) contm trs componentes de srie, representando o hardware
(HW), o sistema operacional (SO) e uma aplicao que varia de acordo com o subsistema
especfico. A Streaming Transmitter inclui um aplicativo de transmisso de vdeo (T); Frontend
possui um servio de gerenciamento da nuvem (MT), e por ltimo, o Node inclui um virtualizador
de mquinas virtual (KVM). As Equaes 4.4, 4.5 e 4.6 permitem o clculo da disponibilidade dos
subsistemas ST, F e N, respectivamente. E, como todos os blocos so em srie a disponibilidade
obtida com a multiplicao entre si das disponibilidades destes componentes.
4.1.2
AST = AHW ASO AT

4.4
AF = AHW ASO AMT

4.5
AN = AHW ASO AKV M

4.6
Modelos CTMCs
Como descrito nas especificaes dos componentes no Captulo 3, o subsistema LV

composto por uma VM e os softwares Apache e Ffmpeg. Optou-se por utilizar uma CTMC em
sua modelagem para verificar duas relaes comportamentais entre os componentes. Primeiro
verificar se o Apache e o Ffmepg esto sob o funcionamento de uma VM. Caso essa mude seu
estado para inativo, resulta em ambos os sistemas fiquem inativos e devem ser recuperados os
trs componentes. A segunda a independncia do Apache em relao ao Ffmpeg e vice versa,
porque uma falha no Apache deixar o componente indisponvel, porm no causa danos ao
funcionamento do Ffmpeg. O mesmo acontece com a falha do Ffmpeg que no interfere no
59
Apache.
Tabela 4.1: Estados do subsistema LiveVideo sem redundncia.
Estado
UUU
UUD
UDU
UDD
DDD
Descrio
O Sistema est Ativo
O Sistema est Inativo, o FFmpeg est Inativo
O Sistema est Inativo, o Apache est Inativo
O Sistema est Inativo, o FFmpeg e Apache esto Inativo
O Sistema est Inativo, todos os componentes esto Inativo
O modelo CTMC para o subsistema LV sem redundncia ilustrado na Figura 4.4.

Seus estados esto listados e descritos na Tabela 4.1 e suas taxas descritas na Tabela 4.2. Foi
utilizada a notao XXX, onde X {U, D} representa a condio de cada componente: U para
ativo, e D para inativo. A primeira caractere representa a VM, a segunda o Apache e a ltima o
Ffmpeg. O estado UUU (sombreado) indica que o sistema est disponvel, uma vez que todos
os trs componentes esto operacionais. Todos os outros estados, UUD, UDU, UDD e DDD
representam que o subsistema LV encontra-se com algum problema de funcionamento e est
interrompido.
Tabela 4.2: Taxas do subsistema LiveVideo sem redundncia.
Taxa
A
F
V
A
F
V
Descrio
Falha do Apache
Falha do Ffmpeg
Falha do VM
Reparo do Apache
Reparo do Ffmpeg
Reparo do VM
Iniciando com o estado UUU, ao ocorrer falha em FFmpeg, com taxa de F , causa a
indisponibilidade do servio, indicado pelo estado UUD. A reparao da aplicao FFmpeg
ocorre com a taxa de F , retornando para o estado UUU. Enquanto esteja no estado UUU
falhas podem ocorrer no Apache, ou na VM, representada pelas transies com taxas A e V ,
respectivamente. Quando ocorre no Apache o estado UDU alcanado. Podendo ser reparado
com a taxa de A e o modelo atinge o estado UUU.
Quando h falhas simultnea de ambos (Apache e FFmpeg) o estado UDD e uma
reparao de qualquer deles se torna possvel, disparando uma transio para UDU ou UUD.
Falhas podem ocorrer antes que o sistema esteja completamente reparado, isso acontece quando
a VM falha (com a taxa de V ) e o estado de DDD alcanado, no importando o estado de
60
Figura 4.4: CTMC do subsistema LiveVideo sem redundncia.
origem, porque Apache e FFmpeg so dependentes da VM. Por essa dependncia os estados
DUU, DDU e DUD no so alcanados nesta CTMC.
Para obteno das frmulas fechadas das CTMCs foram utilizadas duas ferramentas, a
Mercury (SILVA et al., 2012; CALLOU et al., 2013) usadas para modelagem de todos os modelos
apresentados neste Captulo e a ferramenta Mathematica1 . Com a ferramenta Mercury, aps o
trmino da modelagem foi possvel exportar o modelo formatado para o prprio Mathematica e
ento gerada a frmula fechada obtida para disponibilidade do subsistema LV, Equao (4.7).
Pelo tamanho da expresso foi necessrio realizar reduo em conjuntos menores.
ALV =
A F 1 + 2V + F V
1 F + V + F 1 + V + F V + V

4.7
onde,
1 = A + F + A
1 = A + V + A
A Figura 4.5 descreve o servio LiveVideo em que usa redundncia Warm-Standby
utilizando um modelo CTMC. Esta redundncia do servio atravs de uma VM de reposio
configurada de forma idntica a VM primria (inclusive com Apache e Ffmpeg). Foi utilizada
a notao XXX_XXX, onde X {U, D,W } representa a condio de cada componente: U para
ativo, D para inativo e W para espera. O primeiro caractere representa a VM, a segunda o Apache
e a terceira o Ffmpeg. Do quarto caractere at a final, segue a mesma sequncia dos caracteres
iniciais, porm, elas compem a VM reserva. Os estados em cinza (UUU_WWW e UDD_UUU)
representam o sistema disponvel. Todavia, os estados restantes simbolizam o sistema com mau
1 www.wolfram.com/mathematica
61
funcionamento, so eles: UUD_WWW, UDU_WWW, UDD_WWW, DDD_UUD, DDD_UDU,

DDD_UDD e DDD_DDD. Todos os estados so descritos na Tabela 4.3 e as taxas foram as
mesma da CTMC sem redundncia.
Figura 4.5: Cadeia de Markov do LiveVideo com Redundncia
O modelo atinge o estado UDU_WWW quando Apache falha, ou UUD_ VWAWFW

quando FFmpeg falha e outras falhas podem acontecer durante a reparao de cada um desses
componentes. Quando ocorrem falhas no Apache ou FFmpeg, o reparo acontece com as taxas de
A e F , respectivamente. A VM secundria ativada somente com a falha da VM principal (por
meio da transio V ), atingindo o estado DDD_UUU. Um reparo pode ser realizado na VM
que falhou e assim o sistema retorna ao estado inicial, colocando a VM secundria na condio
de Warm-Standby novamente. No entanto, Apache e FFmpeg tambm pode falhar na VM
secundria aps sua ativao, atingindo os estados DDD_UDU e DDD_UUD, respectivamente.
Quando a VM secundria falhar enquanto ativada, o sistema atinge o estado de DDD_DDD, com
62
Tabela 4.3: Estados do subsistemas do LiveVideo com redundncia.
Estado
UUU_WWW
UUD_WWW
UDU_WWW
UDD_WWW
DDD_UUU
DDD_UUD
DDD_UDU
DDD_UDD
DDD_DDD
Descrio
O Sistema est Ativo
O Sistema est Inativo, o FFmpeg e Apache est Inativo
O Sistema est Ativo, a VM secundria Ativa e VM principal Inativa
O Sistema est Inativo, o FFmpeg e Apache est Inativo
O Sistema est Inativo
todos os componentes para inativo.

Por esta CTMC possui as mesmas relaes de dependncia entre os componentes, os
estados DUU_WWW, DUD_WWW, DDU_WWW, DDD_DUU, DDD_DUD, DDD_DDU so
inatingveis neste modelo. No representada a falha da segunda VM no modelo durante a VM
principal esteja em funcionamento, porque se entende e considera a redundncia Warm-Standby
em nvel do Node que instancia essa VM secundria.
A Equao 4.8 representa a expresso da frmula fechada para esse modelo.
ALV =
(1 2 + A 3 F + 4 4 V (1 + 1 1 2 + A 3 V + 4 (6 + 4 5 )))
((A + 3 )1 (A + 4 )(1 5 + A (V 2 1 1 + 4 (3 2 )))
onde,
1 = A V
2 = F + V + A
3 = V + A
4 = V + F
5 = V + VAF
6 = F V
1 = F + 4
2 = A 1
3 = 6 5 + 4
4 = 2 + F
1 = 2 1
2 = F + 23 + F
3 = 6 + 3 4
4 = 3 4

4.8
63
1 = F + 23 + 4 1 2 V + 3 V 2
2 = V 2 + V V + V 2
4.1.3
Validao
Ao lidar com modelos analticos, geralmente importante verificar se o comportamento

do modelo da Figura 3.3 da Seo 3.2.1 do captulo anterior, se o modelo no tem evidncias para
ser rejeitado como um modelo que representa o ambiente de execuo (GOEL, 1985). Ento,
um experimento de injeo de falhas foi realizado, onde modelo e ambiente de execuo foram
submetidos s mesmas condies de entrada. Por conseguinte, realizou-se a validao do modelo
atravs dos clculos estatsticos propostos por (KEESEE, 1965), para calcular o intervalo de
confiana da disponibilidade.
A validao de modelos de desempenho realizada por meio da comparao dos resultados do modelo com as medidas extradas a partir de um ambiente real (LAVENBERG,
1983). Validao de modelos de dependabilidade pode ser mais difcil, pois as falhas reais so
imprevisveis e podem levar um longo tempo para se manifestar (frequentemente mais de um
ano (SCHROEDER; GIBSON, 2007)).
Este obstculo superado pelo emprego de tcnicas de injeo de falhas (ARLAT et al.,
1993). Tais tcnicas empregam um software ou hardware para gerar elemento de falhas nos
componentes do sistema de uma forma controlada. A taxa de falha de um componente pode ser
acelerado, a fim de reduzir o tempo total do experimento (CHAN, 2004; VACARO; WEBER,
2006). Um sistema de monitoramento geralmente incorporado ao lado de um testbed de injeo
de falhas para observar como o sistema reage na presena de falhas.
Essa arquitetura foi baseada na plataforma de nuvem privada OpenNebula 3.6, Os nodes
da nuvem utilizam o KVM2 (verso 1.0) como hypervisor, implantada em um ambiente real
composto por quatro mquinas fsicas (apresentadas na Tabela 4.4), um roteador e uma cmera
do tipo AXIS M103 (Figura 4.7).
Para aumentar o grau de confiana dos resultados obtidos a partir do estudo de caso, um
processo de validao foi realizado no modelo. O processo de injeo de falhas foi baseado em
(SOUZA et al., 2013), que emprega uma ferramenta de software (Eucabomber) para avaliar a
disponibilidade de um ambiente de nuvem. Este trabalho utilizou para a validao o fluxo de
trabalho proposto por (MELO, 2014) e apresentado na Figura 4.6:
Conceber o modelo seleo do modelo a ser validado de acordo com o ambiente estudado;
2 http://www.linux-kvm.org/
3 http://www.axis.com/sk/en/products/axis-m1031-w
64
Tabela 4.4: Componentes do ambiente de testes do experimento de Injeo de Falhas.
Nome
Frontend
Descrio
Gerente da nuvem
Node
N executor da nuvem
Stresser
Monitor da nuvem
Streaming
Transmitter
Gerenciar cmeras
Processador
Intel Core i3
4 ncleos de 3.10 GHz
Intel Core i3
4 ncleos de 3.10 GHz
Intel Core 2 Quad
4 ncleos de 2.66Gh
Intel Core i5
4 ncleos de 2.50Gh
RAM
4 GB
4 GB
4 GB
4 GB
SO
12.04 Ubuntu Server
12.04 (kernel 3.2.0-23)
12.04 Ubuntu Server
12.04 (kernel 3.2.0-23)
12.04 Ubuntu Desktop
12.10 (kernel 3.5.0-36))
12.04 Ubuntu Desktop
12.10 (kernel 3.5.0-36))
Figura 4.6: Fluxo de trabalho para validao dos modelos.
Obter os parmetros de entrada o MTTF e MTTR so determinados atravs de medies

ou encontrados em relevante literatura. Nesta pesquisa, os tempos de falhas foram ajustados
de acordo com um fator de acelerao de 400;
Desenvolver scripts para injeo de falhas Os scripts foram baseado no Algoritmo 1,
durante o tempo que o componente estiver ativo gerado um tempo exponencial da taxa
de falha dele (a ferramenta R4 foi utilizada nesta gerao), ento injetada a falha e os
dados de ordem da falha, tempo de falha e horrio da falha so coletados. Sabendo que ele
no est ativo, ento entra o processo reparo que tambm precisa da gerao de um tempo
4 www.r-project.org
65
Figura 4.7: Cmera AXIS utilizada no estudo
exponencial, agora para reparo. Por fim, os mesmo dados sero coletados para os reparos.
Em paralelo outro script responsvel por monitorar a disponibilidade do sistema.
Estes scripts foram elaborados a partir do Shell Script, que esto ao final deste trabalho
nos Apndices A, B,C e D, que representam os scripts de injeo de falhas e reparos dos
mdulos cliente, frontend, node e livevideo. Em mesma ordem, os Apndices E, F,G e H
so usados para monitorar estes mdulos. Os scripts so explicados a seguir.
O ambiente foi supervisionado durante um perodo de 3 semanas. Com interrupes
porque a validao foi fragmentada em quatro mdulos. O mdulo denominado cliente
engloba as cmeras, streaming transmitter e WiFi. Para injetar a falha e o reparo neste
mdulo utilizou-se o protocolo de Protocolo de Fluxo Contnuo em Tempo Real (RealTime Streaming Protocol - RTSP). Este protocolo utilizado no transporte de streaming de
vdeo das cmeras do modelo Axis, usada no experimento. Para monitor-lo foi utilizada a
ferramenta nmap para escutar a porta 554.
O mdulo Frontend foi composto por um sistema operacional, hardware e o sistema
oneadmin, responsvel por gerenciar a nuvem. Para provocar sua falha aplicou o comando
shutdown que desliga o computador. Sendo o reparo realizado por meio do comando
wakeonlan que consegui ligar um computador que esteja conectado na mesma rede do
computador que solicitou o comando. O monitoramento foi realizado pelo comando ping
que retorna up se o computador conectou a rede ou down caso o computador no
esteja conectado, nesse caso, entendido que o computador est desligado.
Este processo de injeo de falha, reparo e monitoramento, explicado no mdulo anterior
foi o mesmo utilizado no mdulo Node. Por fim, o mdulo livevideo formado pela Mquina
Virtual, Apache e Ffmpeg, foi escolhido o servio do Apache para ora utilizar o comando
stop e simular uma falha e na recuperao usou-se o comando start do servio. Para
monitor-lo se fez o uso da ferramenta nmap para escutar a porta 80.
Executar o experimento de injeo de falhas os scripts de injeo de falhas so executados
66
de acordo com o comportamento do sistema real com os valores dos parmetros obtidos a
partir da segunda etapa. Os scripts de injeo e monitoramento foram executadas em um
computador paralelo a estrutura da nuvem OpenNebula e estava conectado na mesma rede,
este foi denominado Stresser;
Monitorar o ambiente um monitor observa o estado de funcionamento do sistema e seus
componentes, enquanto os experimentos esto sendo executados. Um relatrio chamado
log produzido, que inclui os dados captados pelo monitor, ou seja, os eventos de falha e
reparo ao longo do tempo. Este relatrio essencial para a comparao dos resultados dos
experimentos com os resultados do modelo;
Sintetizar os resultados do experimento os resultados serviro de base para o clculo do
intervalo de confiana de disponibilidade;
Algorithm 1 Injetor de Eventos
while true do
if ComponenteEstaAtivo then
TempoFalha = TempoExponencial(TaxaDeFalhaComponente);
Esperar(TempoFalha);
In jetarFalhaComponente();
ColetarDados(OrdFalha, TempoFalha,timestamp)
else
TempoReparo = TempoExponencial(TaxaDeReparoComponente);
Esperar(TempoReparo);
In jetarReparoComponente();
ColetarDados(OrdReparo, TempoReparo,timestamp)
end if
end while
Avaliar o modelo a disponibilidade em estado estacionrio do modelo calculado usando
os parmetros de entrada descritos na segunda etapa. Estes resultados so comparados com
o intervalo de confiana para a disponibilidade (KEESEE, 1965) obtido anteriormente;
Confrontar os resultados para validao os resultados do modelo so analisados para
verificar se eles esto dentro dos limites do intervalo de confiana. Se assim for, ento o
modelo considerado coerente com o sistema real.
67
Na Tabela 4.5, encontram-se os valores dos parmetros de entrada para frmula que
gera o intervalo de confiana da disponibilidade. Nesse trabalho, considera-se o intervalo de
confiana de 95%.
Tabela 4.5: Parmetros de Entrada para o Mtodo de Keese.
Parmetros
Tempo total de falha do Frontend
Tempo total de reparo do Frontend
Quantidade de Falhas e Reparos da Frontend
Tempo total de falha do Node
Tempo total de reparo do Node
Quantidade de Falhas e Reparos da Node
Tempo total de falha do Cliente
Tempo total de reparo do Cliente
Quantidade de Falhas e Reparos da Cliente
Tempo total de falha do LiveVideo
Tempo total de reparo do LiveVideo
Quantidade de Falhas e Reparos da LiveVideo
Valores
12885, 71s
9603, 35s
50
16208, 51s
8113, 50s
50
3270000, 28s
1072241, 22s
50
6940, 14s
16973, 71s
50
A fim de simplificar o processo, o modelo foi dividido em quatro partes: i) da cmera,

Streaming Transmitter e WiFi; ii) Frontend; iii) Node; iv) LiveVideo. A Tabela 4.6 mostra
a disponibilidade para as partes distintas avaliadas pelo modelo, seguida por um intervalo
de confiana obtida por meio dos experimentos. Os resultados de cada parte, bem como a
disponibilidade geral do sistema 0,03552, revela que tivemos seus resultados dentro dos seus
respectivos intervalos de confiana, (0,01422, 0,07987).
Tabela 4.6: Validao das disponibilidades
Componente
Cliente
FrontEnd
Node
LiveVideo
Disponibilidade geral
Disponibilidade do Modelo
0, 35622
0, 53889
0, 63857
0, 28982
0, 03552
95% C.I.
(0, 24150; 0, 42525)
(0, 47496; 0, 66553)
(0, 57389; 0, 74764)
(0, 21609; 0, 37747)
(0, 01422; 0, 07987)
Os baixos valores das disponibilidades nos resultados so creditados ao fator de reduo

de 400 que aplicado para acelerao das falhas. Portanto, o modelo proposto no tem evidncias para ser refutado como modelo que representa o comportamento do ambiente real, desta
forma, demonstra ser um modelo confivel para ser utilizado na avaliao de disponibilidade do
ambiente, bem como a proposio de novas arquiteturas.
4.2. MODELAGEM DAS ARQUITETURAS DO SISTEMA EMPRESARIAL
4.2
68
Modelagem das Arquiteturas do Sistema Empresarial
Nesta Seo, as diferenas na modelagem entre a arquitetura bsica do Sistema Domstico e Empresarial so detalhadas, alterando ou acrescentando novas restries do seu
funcionamento. Como ilustrado na Figura 4.8, este modelo o suficiente para encontrar a
disponibilidade de um dos andares e foi orientada por uma visita a um empresa de pequeno porte
da cidade de Caruaru que por motivos de privacidade ser chamada de Empresa X. Nele foi
realizada a juno dos componentes Cmera e LiveVideo, formando um componente k-out-of-n
denominado CLV. O subsistema LiveVideo, nesta segunda arquitetura modelado por RBD, no
mais por uma CTMC. Com nfase explicao da SPN, proposta para a poltica de manuteno
da cmera reserva com a redundncia cold-standby.
Figura 4.8: Modelo RBD da Arquitetura de VSaaS da Empresa X
Para a disponibilidade completa da arquitetura empresarial. Considera-se a multiplicao

da disponibilidade de todos os andares considerando as cmeras e o LiveVideo. Pela visita na
empresa, constatou-se a necessidade suficiente de um Streaming Transmitter e uma conexo
de rede (optada pela WiFi) para toda a estrutura da empresa. A sequncia continua com um
Frontend e um Node no ambiente da nuvem, o Node por sua condio de instanciar no mximo
10 cmeras ter sua disponibilidade potencializada ao cubo para comportar as 25 cmeras iniciais.
Conforme resumida na Equao 4.9, utilizando notaes e outras equaes da arquitetura bsica.
AArquiteturaEmpresa = (ACLV )5 AST AW F AF (AN )3

4.9
Na Figura 4.9 exibida a apresentao hierrquica heterognea do bloco CLV do modelo

RBD, da Figura 4.8, por meio da tcnica de modelagem SPN.
A modelagem composta por dois componentes, os servios LiveVideos e as Cmeras,
onde uma delas poder ser substituda. O modelo SPN constitudo de 31 lugares, sendo 10
69
Figura 4.9: Rede de Petri dos componentes Cmera e LiveVideo relacionados com
redundncia.
para o servio LiveVideo: LV1_OK, LV2_OK, LV3_OK, LV4_OK e LV5_OK que representam
os estados operacionais e LV1_OFF, LV2_OFF, LV3_OFF, LV4_OFF, LV5_OFF so os seus
estados falhos. Os atributos relacionados a cada transio do LiveVideo descrito neste trabalho
so apresentados na Tabela 4.7. Nas transies temporizadas LV1F, LV2F, LV3F, LV4F e
LV5F que ocasionam as falhas nos respectivos servios, deixando-os em lugares OFF, seguem
uma distribuio exponencial (exp), bem como as transies temporizadas de reparo LV1R,
70
LV2R, LV3R, LV4R e LV5R que retorno o token para os lugares OK. Sobre todas as transies
temporizadas modeladas nesta SPN utilizou-se a semntica single-server.
Tabela 4.7: Atributos das transies dos LiveVideos do modelo SPN cold-standby.
Transio
LV 1F
LV 1R
LV 2F
LV 2R
LV 3R
LV 3F
LV 4R
LV 4F
LV 5R
LV 5R
Tipo
exp
exp
exp
exp
exp
exp
exp
exp
exp
exp
Tempo ou peso
MT T F
MT T R
MT T F
MT T R
MT T R
MT T F
MT T R
MT T F
MT T R
MT T R
No componente cmera so 21 lugares na SPN, sendo cinco lugares que sinalizam as

cmeras em estado operacional, C1_OK, C2_OK, C3_OK, C4_OK e C5_OK. H outros cinco
lugares que assumem que o estado operacional de uma cmera, ao substitu-la em uma das salas
ou do corredor, alcanando os lugares CSpare1_OK, CSpare2_OK, CSpare3_OK, CSpare4_OK
e CSpare5_OK, a partir do disparo de uma das transies de falha da cmera, entre elas: C1F,
C2F, C3F, C4F e C5F. Todas as transies inerentes ao processo de falha ou reparo das cmeras
reservas e principais so exibidas na Tabela 4.8. Estes lugares continuam em processo de
substituio at que um token continue nos lugares falhos das cmeras principais, C1_OFF,
C2_OFF, C3_OFF, C4_OFF e C5_OFF, porque com os disparos das transies de reparo das
cmeras principais, C1R, C2R, C3R, C4R e C5R passaro para os lugares operacionais.
Porm, considerando os lugares das cmeras reservas estando ativos, isso no garante
que eles sejam livres de falhas, ao disparo de qualquer transio de falha, C1FS, C2FS, C3FS,
C4FS e C5FS. Isso resultar na indisponibilidade destas cmeras e os lugares CSpare1_OFF,
CSpare2_OFF, CSpare3_OFF, CSpare4_OFF e CSpare5_OFF, podero ser alcanados, que por
sua vez, conseguiro retornar aos lugares em OK, por meio do disparo de alguma das transies
de reparo, C1RS, C2RS, C3RS, C4RS e C5RS. Todas essas transies temporizadas tambm so
exponencialmente distribudas, alternando entre MTTF e MTTR das cmeras.
O lugar Wait_Spare possui a quantidade de recursos disponveis, cmeras reservas.
Este lugar o centro do mecanismo de redundncia cold-standby. Ele responsvel pela
substituio das cmeras principais que, por ventura, falhar. O Wait_Spare pode ser acionado com
o disparo de cinco transies temporizadas (com tempo de um hora), Active_C1, Active_Spare2,
Active_Spare3, Active_Spare4 e Active_Spare5, apresentadas na Tabela 4.9. So essas transies
71
Tabela 4.8: Atributos das transies das cmeras do modelo SPN cold-standby.
Transio
C1F e C1FS
C1R e C1RS
C2F e C2FS
C2R e C2RS
C3F e C3FS
C3R e C3RS
C4F e C4FS
C4R e C4RS
C5F e C5FS
C5R e C5RS
Tipo
exp
exp
exp
exp
exp
exp
exp
exp
exp
exp
Tempo ou peso
MT T F
MT T R
MT T F
MT T R
MT T F
MT T R
MT T F
MT T R
MT T F
MT T R
que indicam qual cmera principal est falha e permitir sua substituio, com a condio que
haja recurso disponvel (representado graficamente pelo nmero de tokens no lugar Wait_Spare).
Essas transies esto interligadas com os lugares das cmeras em funcionamento por meio
de um arco inibidor que no permite que essas transies sejam disparadas com tokens nesses
lugares.
Supondo que a cmera 1 falhe e o disparo da transio Active_Spare1 seja concretizado
por haver um token disponvel no lugar Wait_Spare, desta forma a cmera reserva acionada e
representada com um token no lugar CSpare1_OK. Na hiptese da cmera dois tambm falhar
neste momento ela no ser substituda pela ausncia de token disponvel no lugar Wait_Spare.
Outra cmera em falha s ser substituda novamente depois que seja realizado o disparo
da transio de reparo da cmera principal. Quando isso ocorrer uma das transies, Desactive_Spare1, Desactive_Spare2, Desactive_Spare3, Desactive_Spare4 e Desactive_Spare5 ter
de ser disparada instantaneamente, por ela ser uma transio imediata. Estas transies so
interligadas com respectivos lugares de cmera principal em OFF por meio de um arco inibidor,
sendo habilitada com a ausncia de token nesses lugares e com a existncia do token nos lugares
CSpare_OK. Com isso ela estar devolvendo o token para o lugar Wait_Spare e permitindo a
substituio de outras cmeras falhas. Para aumentar o nmero de cmeras reservas na SPN
dever ser aumentado o nmero de tokens no lugar Wait_Spare.
A primeira obrigatoriedade para a SPN estar disponvel, considerar a dependncia entre
LiveVideo e cmera, por exemplo, se a cmera 1 estiver ativa, representada pelo estado C1_OK,
com o servio LiveVideo 1 tambm ativo, representado por LV1_OK. Com a ressalva de quando
a cmera principal falha, o servio da mesma forma poder ser relacionado com a cmera reserva
CSpare1_OK. Esta obrigatoriedade aplicada em todas as outras cmeras com seus respectivos
servios.
72
Tabela 4.9: Atributos das transies de disparo da Cmera Reserva do modelo SPN
cold-standby.
Transio
Active_Spare1
Desactive_Spare1
Active_Spare2
Desactive_Spare2
Active_Spare3
Desactive_Spare3
Active_Spare4
Desactive_Spare4
Active_Spare5
Desactive_Spare5
Tipo
exp
im
exp
im
exp
im
exp
im
exp
im
Tempo ou peso
1 hora
1
1 hora
1
1 hora
1
1 hora
1
1 hora
1
A seguir apresentada a Expresso Probabilstica utilizada para obter a disponibilidade

da SPN, considerando a obrigatoriedade explicada no pargrafo anterior. A estratgia de
disponibilidade adotada que ser explicada no Captulo 5, na Seo 5.2. Esta determina que para
o andar estar disponvel, quatro das cinco cmeras devero estar funcionando:
P{(((#C1_OK=1 OR #CSpare1_OK=1) AND #LV1_OK=1) AND ((#C2_OK=1 OR #CSpare2_OK=1) AND #LV2_OK=1) AND ((#C3_OK=1 OR #CSpare3_OK=1) AND #LV3_OK=1)
AND ((#C4_OK=1 OR #CSpare4_OK=1) AND #LV4_OK=1)) OR (((#C5_OK=1 OR #CSpare5_OK=1) AND #LV5_OK=1) AND ((#C2_OK=1 OR #CSpare2_OK=1) AND #LV2_OK=1)
AND ((#C3_OK=1 OR #CSpare3_OK=1) AND #LV3_OK=1) AND ((#C4_OK=1 OR #CSpare4_OK=1) AND #LV4_OK=1)) OR (((#C1_OK=1 OR #CSpare1_OK=1) AND #LV1_OK=1)
AND ((#C5_OK=1 OR #CSpare5_OK=1) AND #LV5_OK=1)AND ((#C3_OK=1 OR #CSpare3_OK=1) AND #LV3_OK=1) AND ((#C4_OK=1 OR #CSpare4_OK=1) AND #LV4_OK=1))
OR (((#C1_OK=1 OR #CSpare1_OK=1) AND #LV1_OK=1) AND ((#C2_OK=1 OR #CSpare2_OK=1) AND #LV2_OK=1) AND ((#C5_OK=1 OR #CSpare5_OK=1) AND #LV5_OK=1)
AND ((#C4_OK=1 OR #CSpare4_OK=1) AND #LV4_OK=1)) OR (((#C1_OK=1 OR #CSpare1_OK=1) AND #LV1_OK=1) AND ((#C2_OK=1 OR #CSpare2_OK=1) AND #LV2_OK=1)
AND ((#C3_OK=1 OR #CSpare3_OK=1) AND #LV3_OK=1) AND ((#C5_OK=1 OR #CSpare5_OK=1) AND #LV5_OK=1)) OR (((#C1_OK=1 OR #CSpare1_OK=1) AND #LV1_OK=1)
AND ((#C2_OK=1 OR #CSpare2_OK=1) AND #LV2_OK=1) AND ((#C3_OK=1 OR #CSpare3_OK=1) AND #LV3_OK=1) AND ((#C4_OK=1 OR #CSpare4_OK=1) AND #LV4_OK=1)
AND((#C5_OK=1 OR #CSpare5_OK=1) AND #LV5_OK=1))}
Portanto, esse Captulo apresentou os modelos e as frmulas para obteno da disponibilidade, estas sendo umas das principais contribuies desta Dissertao. Foi apresentado o
73
processo de validao que aumentou a credibilidade do modelo e possibilita a utilizao dos

scripts e da metodologia em outros modelos com ou sem o contexto de VSaaS.
74
5
Estudos de casos
A nossa maior glria no reside no fato de nunca cairmos, mas sim em
levantarmo-nos sempre depois de cada queda.
CONFCIO
Neste captulo, os resultados das mtricas de disponibilidade e downtime so apresentados

em dois estudos de casos oriundos das arquiteturas dos dois sistemas. Alm desses resultados,
os estudos de casos tem por objetivo utilizar tcnicas que apoiem a deciso dos administradores
de nuvens pblicas ou privadas, com necessidade de alta disponibilidade na plataforma VSaaS.
5.1
Estudo de Caso 1 - Sistema Domstico
Este primeiro estudo de caso compara a disponibilidade e o downtime anual entre as trs
arquiteturas VSaaS, propostos no Captulo 3, na Seo 3.2.1. Cujos modelos analticos RBDs
so representados pelas Figuras 4.1, 4.2 e 4.3. A particularidade comportamental do subsistemas
LiveVideo que foram modelados em CTMCs esto nas Figuras 4.4 e 4.5. Por fim, foi realizada
uma anlise de sensibilidade paramtrica no modelo da Figura 4.3 com objetivo de encontrar
pontos crticos com maior impacto na disponibilidade.
Espera-se que os resultados sejam subsdios aos administradores na utilizao de mecanismos de redundncia para o aumento da disponibilidade dos servios ofertado em suas
empresas. Colaborando para o estabelecimento e cumprimento de SLAs, manuteno ou elevao da confiabilidade perante os clientes, evitar prejuzos financeiros enquanto o sistema estar
indisponvel ou pelas multas contratuais.
No decorrer da pesquisa, houve a necessidade de estabelecer algumas restries, pois
elas determinam de que forma as anlises desse estudo de caso foram realizadas. As trs polticas
5.1. ESTUDO DE CASO 1 - SISTEMA DOMSTICO
75
restritivas foram:
As cmeras foram reparadas ou substitudas no prazo de 24 horas;
O mecanismo de redundncia empregado aos componentes foi o warm-standby, isto , eram
ativados automaticamente aps a deteco da falha, exceto as cmeras;
A arquitetura estava disponvel, se pelo menos duas das trs cmeras estivessem funcionando.
A arquitetura 1 (Figura 4.1) foi extrada de um sistema com os seus requisitos mnimos
para estar em funcionamento (ou seja, sem componentes paralelos e ausncia de redundncia). Na
arquitetura 2 (Figura 4.2), semelhante arquitetura 1, porm com a redundncia dos componentes
da Cmera, da conexo de rede e do servio LiveVideo. A arquitetura 3 consistiu de um modelo
RBD representado pela Figura 4.3 que, em relao arquitetura 2, teve a incluso da redundncia
no componente Node. Ressalte-se no componente LiveVideo, presente nas arquiteturas 2 e 3,
houve a modelagem da redundncia Warm-Standby por CTMC, exibido na Figura 4.5.
Todos os valores dos parmetros foram baseados em artigos pesquisados e na documentao dos fabricantes. No houve necessidade de obter esses parmetros de entrada pelo mtodo
da medio. Os parmetros do componente Cmera foram obtidos a partir das especificaes
da cmera AXIS. Contudo, nela no havia explicitamente o MTTF e MTTR, havendo somente
MTBF (tempo mdio entre falhas). Considerou-se ento o MTBF como o MTTF da cmera. A
restrio determina que a cmera fosse reparada em 24 horas e foi justamente criada para suprir
a ausncia deste informao, o MTTR. O reparo correspondeu a substituio da cmera e no
conserta-la.
A Tabela 5.1, fornece tanto os parmetros da Cmera, bem como todos os parmetros
utilizados neste estudo, os componentes Streaming Transmitter, Node, Frontend e LiveVideo,
extrados de (MATOS et al., 2012), (KIM; MACHIDA; TRIVEDI, 2009) e (DANTAS, 2012).
Os parmetros de entrada para as redes de comunicao, Wi-Fi e 3G foram provenientes de
(D-LINK, 2012) (COOPER; FARRELL, 2007), respectivamente. A Equao 2.4 foi adotada a
para a anlise de disponibilidade e para a transformao dos MTTF e MTTR em taxa, notao
usual de e de cada um dos componentes, na devida ordem.
Diante dos valores obtidos, foi possvel realizar a anlise de disponibilidade das trs
arquiteturas do sistema domstico do servio VSaaS. Os resultados dessa primeira anlise do
Estudo de Caso I, em termos de disponibilidade e downtime anual em horas, so apresentados na
Tabela 5.2. Para ampliar e facilitar o entendimento, esses resultados so ilustrados nas Figuras
5.1 e 5.2, por meio de grficos.
Como resultado, a disponibilidade encontrada para a arquitetura 1, sem redundncia,
foi de 99,503712%, correspondente a um downtime de 43,47482113 horas. Em seguida, a
76
Tabela 5.1: Parmetros da Cmera, WiFi, conexo 3G, Streaming Transmitter, Node,
Frontend e LiveVideo.
Parmetros
HW S, F, N
HW S, F, N
SO S, F, N
SO S, F, N
T
T
MT
MT
KV M
KV M
A
A
F
F
V
V
W F
W F
3G
3G
C
C
ActiveS pare1,2,3,4,5
Valores (h1 )
0, 000114155
0, 6
0, 000694444
1
0, 005714286
60
0, 001268392
1
0, 000347222
1
0, 005714286
60
0, 005714286
60
0, 000345661
1, 875
0, 00001
0, 6
0, 000012019
0, 083333333
0, 00001
0, 04167
1
Tabela 5.2: Resultados da comparao entre os modelos.
Arquiteturas
1
2
3
Disponibilidade
99, 503712%
99, 564588%
99, 686835%
Downtime h/ano
43, 474821
38, 142043
27, 433189
arquitetura 2, a primeira com redundncia, aumentou sua disponibilidade para 99,564588% e

reduziu o downtime para 38,142043 horas. Na comparao entre essas arquiteturas (1 e 2) houve
uma diferena de 5,3 horas. Ou seja, o perodo de aproximadamente dois dias que o servio
ficou sem funcionar na arquitetura 1 foi reduzido para um dia e meio na arquitetura 2. No caso, a
arquitetura 2 reduziu o downtime em 12,26% em relao primeira arquitetura.
Por fim, a arquitetura 3 obteve a maior disponibilidade e menor downtime, 99,686835%
e 27,433189 horas, respectivamente. medida que se compara a arquitetura 2 com a arquitetura
3 encontra-se a diminuio de 10,7 horas de interrupes, gerando um impacto na reduo do
77
Figura 5.1: Disponibilidade das arquiteturas
Figura 5.2: downtime das arquiteturas
downtime em percentagem de 28,07%. Estas arquiteturas diferenciam apenas com a redundncia

aplicada no componente Node da arquitetura 3. Por conseguinte, verificou-se a diferena de
16 horas de inatividade, mais que a metade de um dia, na comparao entre a arquitetura 3 e
a arquitetura inicial. Esta diferena equivale a 36,89% de reduo do downtime e significa o
servio indisponvel em um dia e 3 horas.
Nos trabalhos pesquisados e nas empresas que ofertam o servio de VSaaS, h poucas
informaes sobre o custo referente ao downtime desse servio. Justificado por ser um valor
complexo de ser estimado e genericamente utilizado para todas as reas, pela particularidade do
contedo ter um valor e/ou um significado diferente para cada cliente. Como forma de representar
e compreender os prejuzos financeiros deste downtime nas 27,43 horas, considerou-se outro
servio de vdeo, o pay-per-view, segundo a (INTRANSA, 2010). A Equao 5.1 mostra como
foi realizado o clculo, as horas de interrupo o custo por hora (pay-per-view $ 150.000,00
dlares), resultando um prejuzo de $ 4.114.500,00 dlares. Esse valor pode ser considerado
exagerado, entretanto, imagine o servio ofertado a um Museu com famosas obras de artes de
78
Pablo Picasso ou Leonardo da Vinci, certamente constar altssimas clusulas financeiras no

contrato.
CustoDowntimeAnual payperview = 27, 43 $150.000, 00 = $4.114.500, 00

5.1
Embora os valores de downtime observados para os modelos que continham redundncia

demonstrarem melhorias significativas em relao a uma arquitetura inicial, os resultados tambm
indicaram que h oportunidades de melhoria, j que o valor para a melhor arquitetura ainda
corresponde a mais de um dia de interrupo durante o perodo de um ano.
5.1.1
A partir do resultado encontrado na arquitetura 3, de aproximadamente um dia de

interrupo, optou-se por investigar possveis melhorias sobre essa arquitetura. Considerando
uma empresa de VSaaS com sua infraestrutura montada e com existncia de redundncia em
algum componente (por exemplo, o Frontend na estrutura da nuvem e esta escolhida de maneiro
intuitiva e/ou orientaes de outros profissionais de TI). Todavia, a empresa pretende aumentar a
disponibilidade da arquitetura atual fundamentada em alguma tcnica matemtica, por exemplo,
uma anlise de sensibilidade.
Como mencionado na Seo 2.5 do Captulo 2, o mtodo direto, baseado em derivadas
parciais a espinha dorsal de muitas tcnicas de anlise de sensibilidade. Usou-se tal tcnica
para comear a explorar os parmetros do modelo, com o objetivo de identificar aqueles com
impacto significativo sobre os resultados. O ranking de sensibilidade obtido atravs do clculo
de derivadas parciais tambm permite ignorar parmetros, justificadamente, que tm menos
impacto sobre as mtricas de interesse.
Nesse caso, a anlise de sensibilidade tornou-se uma das alternativas viveis para a
deteco de gargalos ou componentes chaves que aumentam a disponibilidade e, assim, incorporar novas melhorias. Todos os clculos desta anlise foram realizados com o suporte da
ferramenta Mathematica. Por uma questo de conciso, as prprias expresses derivadas no
foram apresentadas aqui pelo grande tamanho das expresses, sendo apresentado apenas os
valores obtidos para os ndices de sensibilidade.
Na Tabela 5.3, encontra-se o ranking de sensibilidade para os parmetros considerados
nesta anlise. Foram computados pelas derivadas parciais das expresses da Equao 4.3, indicada na Seo 4.1, do Captulo 4. O ranking de sensibilidade usou um ndice escalado para
remover as influncias indesejveis das unidades, porque parmetros com ordens de magnitude
79
muito diferentes foram utilizados neste modelo. Os parmetros tiveram seus ndices modulados
e organizados em ordem decrescente, conforme o parmetro de maior impacto sobre a disponibilidade do VSaaS. Aqueles que possuem um sinal de menos (-) indica apenas uma relao inversa
entre o parmetro e a disponibilidade.
Tabela 5.3: Ranking de Sensibilidade.
Parmetro
OSN
OSN
KV M
KV M
HW N
HW N
MT
MT
OSF
OSS
OSF
OSS
HW S
HW F
HW S
HW F
T
T
C
C
A
F
F
A
W F
W F
3G
3G
VAF
V
S (A)
5, 596 101
5, 596 101
2, 799 101
2, 799 101
1, 534 101
1, 534 101
1, 266 103
1, 266 103
6, 939 104
6, 939 104
6, 939 104
6, 939 104
1, 902 104
1, 902 104
1, 902 104
1, 902 104
9, 522 105
9, 522 105
3, 452 107
3, 452 107
1, 087 107
1, 087 107
1, 087 107
1, 087 107
2, 403 109
2, 403 109
2, 403 109
2, 403 109
7, 764 1011
7, 639 1011
Verificou-se que os seis parmetros com maior impacto foram associados com o componente do Node: sistema operacional (OSN e OSN ), hypervisor (KV M e KV M ) e hardware
(HW N e HW N ). Um gerente de TI que precisa melhorar a sua disponibilidade do sistema,
quando estiver operando um servio semelhante a esta arquitetura, deve concentrar seus esforos
80
nesses parmetros ou no componente inteiro.

Na sequncia, os parmetros que tambm apresentam relevncia esto relacionados aos
componentes do Frontend e do Streaming Transmitter, com resultados numricos similares, na
seguinte ordem: MT , MT , OSF , OSS , OSF , OSS , HW S , HW F , HW S , HW F , T e T . Pela
semelhana dos resultados, aps o melhoramento do componente Node, qualquer um dos dois
componentes (Frontend ou Streaming Transmitter) transformaram-se em bons componentes a
serem melhorados.
A possibilidade de trabalhar e analisar parmetro por parmetro uma das vantagens
da abordagem de anlise de sensibilidade utilizada neste estudo de caso. Que considerou nos
clculos os parmetro at ltimo nvel dos componentes que compe a arquitetura no processo de
modelagem. Havendo possibilidade em uma viso mais detalhada, de no realizar a redundncia
em todo o componente, por exemplo, priorizando somente o sistema de gerenciamento da
nuvem ou a mudana para um sistema operacional mais confivel, no caso com um MTTF
maior ou MTTR menor. Existem outras abordagens menos custosas que verificam o impacto do
componente inteiro, sem os seus respectivos detalhamentos.
Em outros resultados da anlise, observou-se baixo impacto da disponibilidade na taxa
de falha e de reparo da cmera. Devido restrio do tempo de reparo ser de 24 horas e
pela aplicao da estratgia 2-out-of-3, nesse componente. Os aplicativos que compreendem
o subsistema LiveVideo (VM, Apache, FFmpeg) tambm possuem a estratgia redundncia
2-out-of-3 e outra estratgia de redundncia realizada por meio de uma CTMC, tornando-os
com pouca relevncia na disponibilidade, bem como os componentes das conexes de redes
(WiFi e 3G). Por conta dessas redundncias, os administradores no devem considerar esses
componentes como prioritrios na poltica aplicada para aumentar a disponibilidade.
As Figuras 5.3 e 5.4 enfatizam os resultados da anlise de sensibilidade paramtrica,
usando a variao de um parmetro no tempo. importante observar que os grficos so organizados de acordo com a ordem do ranking de derivadas parciais. Os valores dos parmetros foram
mudados em passos mdios de 10% e manteve-se com uma linha tracejada a disponibilidade
estacionria da arquitetura 3.
A Figura 5.3, apresenta os parmetros com maior impacto. Por exemplo, MTTR do
sistema operacional do Node, visualmente, compreendido no seu distanciamento do valor
original de 1 hora, o que causou um impacto maior da disponibilidade, tanto no aumento mximo,
considerando o tempo de 30 minutos, como na reduo mnima com valor de 1 hora e 30 minutos.
Comportamento visual semelhante ao MTTF do sistema operacional, desse mesmo componente.
No caso do MTTR e MTTF do KVM, percebe-se uma reduo mediana em comparao ao
impacto dos componentes anteriores, mesmo sabendo que eles so o terceiro e quarto no ranking
81
(a) MTTR do SO - Node (horas).
(b) MTTF do SO - Node (horas).
(c) MTTR do KVM (horas).
(d) MTTF do KVM (horas).
(e) MTTR do HW - Node (horas).
(f) MTTF do HW - Node (horas).
Figura 5.3: Anlise de Sensibilidade - Grfico com parmetros de maior impacto
de sensibilidade. Observa-se o intrigante comportamento em relao aos MTTF e MTTR do

hardware no Node que suas curvaturas no grfico aproximam-se dos parmetros de menor
impacto.
Na Figura 5.4 apresenta os parmetros com menor impacto. Fenmeno contrrio do
ocorrido no pargrafo anterior, entre os parmetro com menor impacto, sobressai o MTTR do
3G, o MTTR e MTTF da cmera. Eles tiveram suas curvaturas praticamente iguais ou muito
prximas da linha tracejada da disponibilidade.
Nesta seo, foi proposta atravs da anlise de sensibilidade, algumas melhorias na
arquitetura 3. Dependendo das necessidades e dos recursos financeiros disponveis que o
5.2. ESTUDO DE CASO 2 - SISTEMA EMPRESARIAL
(a) MTTF da cmera (horas)
82
(b) MTTR da cmera (horas)
(c) MTTR do 3G (horas)
Figura 5.4: Anlise de Sensibilidade - Grfico com parmetros de menor impacto
administrador ou gestor de TI escolher as mudanas. Com isso, finaliza-se o primeiro estudo de

caso.
5.2
Estudo de Caso 2 - Sistema Empresarial
Os resultados desse segundo estudo de caso refere-se arquitetura empresarial do servio

de VSaaS, exposta na Figura 3.6, cujos modelos analticos RBDs so representados pela Figura
4.8. Para representar o subsistema da poltica de manuteno da cmera e o servio LiveVideo
foi modelado com SPN e exibido na Figura 4.9. Para a proposio das novas arquiteturas com
redundncia nesse estudo, utilizou-se a tcnica de Availability Importance. Para em seguida
realizar a anlise de disponibilidade em todas as arquiteturas. Em paralelo uma anlise de custo
foi aplicada as arquiteturas com o objetivo de comparar o downtime e o custo de cada arquitetura.
Esta comparao foi guiada por uma tcnica de cluster, a distncia euclidiana, para encontrar uma
arquitetura eficaz que combinem justamente o custo com o tempo que este ficar indisponvel no
ano.
Um dos principais problemas para obter altas disponibilidades em sistemas em nuvem
esto na escassez de recursos computacionais e na limitao dos recursos financeiros. Por
83
isso, a importncia de utilizar tcnicas que contribuiro para decises coerentes em relao
redundncia, que estas permitam o estreitamento do nmero de arquiteturas possveis e sugesto
de boas arquiteturas baseados na prioridade traada. Este estudo de caso, pontualmente, destinase a colaborar para essas decises.
Os clculos para avaliao destes modelos foram baseados na Equao 4.9. Com o
acrscimo dos resultados gerados pela rede de Petri 4.9. Inicialmente houve a definio de
estratgia abordada para a disponibilidade do servio LiveVideo com a cmera. Explicadas a
seguir:
Primeira estratgia um andar estava disponvel se pelo menos quatro das cinco cmeras
estivessem funcionando com seus respectivos servios de LiveVideo;
Segunda estratgia um andar estava disponvel se pelo menos trs das cinco cmeras
estivessem funcionando com seus respectivos servios de LiveVideo;
Terceira estratgia um andar estava disponvel se pelo menos duas das cinco cmeras
estivessem funcionando com seus respectivos servios de LiveVideo.
Figura 5.5: Disponibilidade do RBD da Cmera com o servio LiveVideo
Para obter os resultados de disponibilidade dessas estratgias que envolve estes dois
componentes (cmera e LiveVideo), modelou-se um bloco em RBD com a estrutura k-out-of-n,
chamado de CLV, conforme a Figura 4.8, do Captulo 4. Esses resultados so exibidos na Figura
5.5 e percebeu-se uma aproximao dos 100% de disponibilidade entre as estratgias. A primeira
estratgia atingiu 99,993356%, a segunda 99,999982% e a terceira 99,999999%. Para ampliar a
compreenso em um contexto geral, calculou-se as mtricas de disponibilidades e downtime do
modelo da Empresa X respeitando justamente essas estratgias e s ento foi escolhida a mais
adequada.
84
Tabela 5.4: Estratgias adotadas
Estratgia
4/5 Cmeras
3/5 Cmeras
2/5 Cmeras
Disponibilidade
99, 270138%
99, 303036%
99, 303122%
Downtime h/ano
63, 935857
61, 053977
61, 046509
Atravs da Tabela 5.4 e nas Figuras 5.6 e 5.7, para disponibilidade e downtime, respectivamente. Os resultados observados da disponibilidade na primeira estratgia foi de 99,270138%,
enquanto na segunda 99,303036% e na ltima 99,303122%. O perodo de interrupo anual
aproximou-se das 60 horas em todas as estratgias. Percebeu-se na primeira estratgia algo em
torno de 64 horas que comparada com as outras duas estratgias houve um pequena diferena de
3 horas, porque os downtimes foram de 61 horas.
Porm, como explicado na Seo 3.2.2, na apresentao da arquitetura da empresa, a
primeira estratgia possui maior segurana em relao as demais. Esse estudo adotou a primeira
estratgia para continuar a anlise de disponibilidade do modelo. Pela convenincia dessa
estratgia ser mais rgida e segura que as demais. Essa rigidez pelo fato que o andar composto
de quatro salas e um corredor, com cmeras em todos os compartimentos. Existe a concepo
que mesmo com a falha da cmera do corredor, todas os documentos e materiais das salas estaro
sendo monitorados. Caso a falha ocorra em uma das salas possvel identificar as pessoas que
tiveram acesso a elas, por meio da cmera instalada no corredor.
Figura 5.6: Disponibilidade das estratgias analisadas
5.2.1
Nesta subseo, usou-se anlise de sensibilidade Availability Importance (explicada na

Seo 2.6, do Captulo 2) para determinar quais componentes seriam replicados e auxiliar na
85
Figura 5.7: downtime das estratgias analisadas
gerao das arquiteturas. Diferentemente da anlise de sensibilidade paramtrica realizada no

estudo de caso anterior, esta abordagem considera apenas os componentes do modelo RBD. Essa
anlise foi auxiliada pela ferramenta Mercury conforme o modelo da Figura 4.8. Esses resultados
esto apresentados na Figura 5.8 e na Tabela 5.5. Com ndice 1 na CameraLiveVideo, do
Frontend 0,999564, do Node 0,998644, do Streaming Transmitter 0,998393 e da WiFi 0,997432.
Figura 5.8: Resultado da Availability Importance
Tabela 5.5: Resultado da Availability Importance
CameraLiveVideo
1
Frontend
0,999564
Node
0,998644
Streaming Transmitter 0,998393
WiFi
0,997432
86
Notou-se que os trs primeiros componentes com maior impacto na disponibilidade

foram CameraLiveVideo, Frontend e Node. Desta forma, as arquitetura criadas a partir desta
receberam redundncia nestes componentes, comparados na prxima seo.
5.2.2
Custo versus Downtime
Uma das contribuies desse estudo de caso a anlise de custo relacionado com o
downtime. Para isto, as arquiteturas e os valores dos componentes so apresentado. Para depois
os resultados serem analisados, considerando a disponibilidade, o downtime e o custo. Com
propsito de determinar arquiteturas eficientes tcnicas de distncia euclidiana foi utilizada sobre
as arquiteturas geradas.
Na Tabela 5.6, cada arquitetura foi descrita e definida a quantidade de vezes que os
componentes foram replicados, do total de 18 arquiteturas. Iniciando-se com a arquitetura A1
que ausente de redundncia. Na arquitetura A8 temos redundncia nica nos componentes
Node e Frontend. No caso da arquitetura A10 com redundncia na Node e a disponibilizao de
uma cmera reserva. Houve dez arquiteturas que foram adicionados redundncia no Frontend
(A2, A3, A8, A9, A11, A12, A13, A15, A17 e A18), dez no Node (A4, A5, A8, A10, A11, A13,
A14, A15, A16 e A18) e por final, dez arquiteturas com redundncia na cmera (A6, A7, A9,
A10, A11, A12, A14, A16, A17 e A18). A arquitetura com o mximo de redundncia o A18
com trs componentes de Node e de Frontend e duas cmeras reservas, logicamente, tendo o
maior custo e disponibilidade. Porm, nem sempre a empresa est com recursos financeiros
disponveis e procura qual o melhor custo benefcio.
A segunda etapa definiu os valores de cada componente. Sendo uma etapa crucial no
processo de avaliao, porque a eficincia e confiabilidade dos resultados esto relacionados
a esses dados de entrada. Ento, quanto mais prximo dos valores do mercado mais esta
comparao faz sentido. Os valores encontrados esto postados na Tabela 5.7. Os preos dos
componentes foram pesquisados nos sites dos fabricantes e serviu para obteno do custo final de
cada arquitetura. O componente com maior custo o computador que foi Frontend e Node, por
R$ 2.529,00 e seguido pelo custo da cmera de R$ 879,51. O terceiro maior valor foi R$ 848,00,
referente ao computador com configurao simples que foi usado para o Streaming Transmitter.
Por fim, o equipamento de conexo da internet custou R$ 189,05. No houve gastos com os
softwares utilizados nesta pesquisa por serem open source.
Depois da obteno dos custos e a escolha das arquiteturas comeou a fase de calcular as
mtricas de disponibilidade e o downtime anual. Estes resultados esto expressos na Tabela 5.8 e
para uma melhor compreenso, foram gerados os grficos para estas duas mtricas, Figuras 5.9,
5.10 e 5.11 para os custos. As arquiteturas encontradas com maior disponibilidade foram A8
87
Tabela 5.6: Apresentao das Arquiteturas
Arquiteturas
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
Descrio da redundncia
Sem redundncia
2 Frontend
3 Frontend
2 Node
3 Node
1 Cmera reserva
2 Cmeras reservas
2 Frontend e 2 Node
2 Frontend e 1 Cmera reserva
2 Node e 1 Cmera reserva
2 Frontend, 2 Node e 1 Cmera reserva
3 Frontend e 1 Cmera reserva
3 Frontend e 2 Node
3 Node e 1 Cmera reserva
3 Node e 2 Frontend
2 Cmeras reservas e 2 Node
2 Cmeras reservas e 2 Frontend
3 Frontend, 3 Node e 2 Cmeras reservas
Tabela 5.7: Descrio e valor dos componentes
Marca/Modelo
DELL - PowerEdge T110II
Custo(R$)
PC Lenovo
Custo(R$)
Cmera AXIS
Custo(R$)
Roteador Wireless Intelbras
Custo(R$)
Componente
HD
Memria
CPU
HD
Memria
CPU
M1011
Descrio
500 GB
4 GB
Intel Xeron - 3.10 GHz
2.529,00
500 GB
2 GB
Intel Celeron - 2.6 GHz
848,00
45s VGA (640 x 480 pixels)
878,51
300Mbps
189,05
(99,851341%), A15 (99,851794%), A13 (99,851802%), A11 (99,883969%) e A18 (99,884936%),

essa ltima era esperada porque possui mais componentes replicados. Caso a empresa busque
apenas maior disponibilidade, esses resultados seriam subsdios para a tomada de deciso dos
gestores.
No contexto do downtime, as arquiteturas com perodos de interrupo maiores foram
88
Figura 5.9: Disponibilidade das arquiteturas da empresa X
selecionados com valor acima de 40 horas, entre elas: A12 (42,353915), A17 (42,389451), A9
(42,394115), A3 (45,201584), A2 (45,241771), A7 (61,08), A6 (61,089656) e A1 (63,935857).
Elas possuem uma interrupo entre dois dias at dois dias e meio. Porm, a diferena de horas
entre essas arquiteturas com o menor downtime foi considervel. Por exemplo, comparando a
arquitetura A18 (10,7 horas) com o A1, chega a 53,86 horas, o que significa dois dias e 5 horas
de interrupes a mais. Foram arquiteturas extremas, todavia, comparando a arquitetura A18
com A12, esta diferena foi de 32 horas (um dia e 8 horas). Salientando, que a arquitetura A12
no est contida na lista de arquiteturas de custo mais elevado, apresentadas a seguir. Ento,
analisando superficialmente, a arquitetura A12 tem sua participao na reduo do downtime,
com um custo menor. As vezes a arquitetura no aparenta ter um downtime alto, porm, o
custo no compensa em relao a disponibilidade. Aconteceu com a arquitetura A5 que possui
disponibilidade razovel com um custo elevado, de forma tal que ao ser comparada com a
arquitetura A8 tem custo inferior. Apresentando downtime menor de 18 horas de diferena de 18
horas em relao A5 e R$ 5.058,00 de investimento a menos.
Na Tabela 5.8, os custos de cada arquitetura foram calculados, a Figura 5.11 as ilustram,
entre as de custo elevado esto: A11 (R$ 47.624,35), A5(R$ 48.289,80), A16(R$ 49.487,9),
A15(R$ 50.818,80), A14(R$ 52.682,35) e A18(R$ 62.132,90). Realizando um comparativo
entre o percentual de aumento do custo com base na arquitetura inicial (A1 = R$ 33.115,80),
tem-se um aumento de investimento na arquitetura A11 de 43,81% para a reduo do downtime
de 84,10%, na arquitetura A5 o aumento de 45,82% para reduo de 50,35%, na A16 esse
elevao do custo de 49,43% para uma diminuio de 54,76% do downtime, na arquitetura
A15 aumentando 53,45% do custo obtm reduo de 79,69%, na arquitetura A14 ao aumentar
89
Figura 5.10: downtime das arquiteturas da empresa X
59,08% para a reduo de 54,80% e por fim, a arquitetura A18 houve um investimento de 87,62%
(equivale a R$ 29.017,10 a mais em relao arquitetura A1) para reduzir 84,24% do tempo de
inatividade.
Figura 5.11: Custos das arquiteturas da empresa X
Aps a anlise dos dados no pargrafo anterior, a arquitetura A5 novamente apresentou-se

em desvantagem em relao s demais. Porm, ela acompanhada pelas arquiteturas A16 e A14,
como opes inviveis, considerando custo e downtime. Contudo, a arquitetura A11 destacou-se
por quase equiparar o downtime da melhor arquitetura (A18) com o investindo R$ 14.508,55 a
menos.
90
Visualmente complexo determinar a arquitetura mais eficiente ao comparar custo e

downtime. Por isso, a distncia euclidiana foi utilizada para determinar a arquitetura que ter um
custo benefcio aceitvel. Os clculos dessa distncia so referenciados ao ponto de origem (0).
Entretanto, pelas duas mtricas possurem magnitudes diferentes. Realizou-se a normatizao do
custo e do downtime de cada uma das arquiteturas, a fim de igualar as escalas. As normatizaes
so obtidas pela Equao 5.2 e os resultados exibidos na Tabela 5.9:
NormatizarXY =
NumX
MaxNumX MinNumX

5.2
Onde,
X = {Custo, downtime}
Y = {Arquiteturas: A1 .. A18}
MinNumX = {Menor valor das arquiteturas}
MaxNumX = {Maior valor das arquiteturas}
Por exemplo, a normatizao do downtime (N.D.) da arquitetura A1 resultante da
operao de 63,935857 horas (downtime de A1) divido pela subtrao de 63,935857 (valor
mximo) por 10,079587 (valor mnimo), totalizando 1,187157. A normatizao do custo (N.C.)
da A1 realizada igualmente, sendo a diviso de R$ 33.115,80 (custo de A1) pela subtrao de
R$ 33.115,80 por R$ 62,132,90, resultando 1,141251. Aps a normatizao dos dados, a etapa
seguinte foi calcular a distncia de cada uma das arquiteturas em relao origem (0), atravs da
distncia euclidiana, expressa na Equao 5.3.
DistanciaZ =
p
NC2 + ND2

5.3
Onde,
Z = {Arquitetura: A1 .. A18}
NC = {Normatizao do custo}
ND = {Normatizao do downtime}
No caso, o resultado 1,646753 da distncia de A1 foi obtido pela raiz quadrada da soma
entre 1, 1412512 (NC) e 1, 1871572 (ND), ambos elevados ao quadrado.
Com o resultado das distncias de todas as arquiteturas realizou-se a ordenao decrescente que visualizada na Tabela 5.10. A arquitetura A2 foi apontada como eficiente, destacada
em vermelho na Figura 5.12. Ao ser relacionada com a arquitetura inicial percebeu-se uma
reduo de 30% do downtime, mediante um aumento no custo de 7%. Ela apresenta o melhor
custo benefcio considerando pesos iguais de importncia entre Custo e Downtime.
Caso a arquitetura A2 no for apreciada pelo administrador. Deve-se retirar a arquitetura
91
Tabela 5.8: Apresentao do resultados da disponibilidade, downtime e custo das

Arquiteturas
Arquiteturas
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
Disponibilidade
99, 270139%
99, 483541%
99, 484000%
99, 637149%
99, 637602%
99, 302576%
99, 302630%
99, 851341%
99, 516049%
99, 669707%
99, 883969%
99, 516508%
99, 851802%
99, 670159%
99, 851794%
99, 669760%
99, 516102%
99, 884936%
Downtime
63, 935857
45, 241770
45, 201583
31, 785720
31, 746099
61, 094309
61, 089655
13, 022520
42, 394114
28, 933667
10, 164336
42, 353914
12, 982184
28, 894033
12, 982814
28, 928996
42, 389450
10, 079587
Custo (R$)
33.115, 80
35.644, 80
38.173, 80
40.702, 80
48.289, 80
37.508, 35
41.900, 90
43.231, 80
40.037, 35
45.095, 35
47.624, 35
42.566, 35
45.760, 80
52.682, 35
50.818, 80
49.487, 90
44.429, 90
62.132, 90
A2 e repetir o processo das Equaes 5.2 e 5.3, desta forma, encontrar outra arquitetura ideal.
Deve-se destacar que esta tcnica ir considerar como ideal somente o resultado com o menor
caminho em relao origem.
Figura 5.12: Apresentao das arquiteturas com prioridades iguais
Havendo a definio de prioridade por parte da empresa em garantir um downtime

Tabela 5.9: Normatizao e distncia euclidiana nas arquiteturas
Arquiteturas
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
N. D.
1, 187157
0, 840046
0, 839300
0, 590195
0, 589460
1, 134395
1, 134309
0, 241801
0, 787171
0, 537239
0, 188731
0, 786425
0, 241052
0, 536503
0, 241064
0, 537152
0, 787085
0, 187157
N. C.
1, 141251
1, 228407
1, 315562
1, 402718
1, 664184
1, 292629
1, 444007
1, 489873
1, 379785
1, 554096
1, 641251
1, 466940
1, 577029
1, 815562
1, 751340
1, 705474
1, 531163
2, 141251
Distncia Euclidiana
1, 646753
1, 488174
1, 56049
1, 521824
1, 765495
1, 719809
1, 83625
1, 509367
1, 588535
1, 644335
1, 652067
1, 664445
1, 595345
1, 893172
1, 767853
1, 788064
1, 721616
2, 149415
Tabela 5.10: Ranking das Arquiteturas
Arquitetura
A2
A8
A4
A3
A9
A13
A10
A1
A11
A12
A6
A17
A5
A15
A16
A7
A14
A18
Distncia em relao a origem

1,488174
1,509367
1,521824
1,56049
1,588535
1,595345
1,644335
1,646753
1,652067
1,664445
1,719809
1,721616
1,765495
1,767853
1,788063
1,83625
1,893172
2,149415
92
93
menor ou investir pouco. possvel adequar a Equao 5.3, da distncia com a multiplicao
das variveis NC e ND, por exemplo, ao multiplicar o NC0,7 e ND0,3 significar que o
administrador definiu a prioridade do custo com 70% e 30% de prioridade no downtime. Tal
como o oposto seria NC0,3 e ND0,7, agora sendo o custo com 30% de prioridade contra
70% downtime.
Com a delimitao de pesos na prioridade entre custo e downtime, considerando um percentual, na Tabela 5.11, esto os resultados do ranking dos cinco menores caminhos respeitando
a poltica estabelecida no pargrafo anterior. Na primeira aplicando peso de 70% para downtime
e 30% para custo foi apontado a arquitetura A8 como eficiente e seja replicado os componente
Frontend e Nodes. Este arquitetura possuiu um dos menores downtime entre todas as arquiteturas
e com um custo razovel, significa que para reduzir o downtime em 80% necessrio investir
30%, diferena de R$ 10.116,00.
70% Downtime / 30% Custo
A8
0,840740
A13
0,887006
A11
0,912713
A4
0,913300
A10
0,962602
A2
A8
A4
A3
A9
Igual
1,488174
1,509367
1,521824
1,560490
1,588535
30% Downtime / 70% Custo

A2
1,126051
A1
1,155215
A3
1,192820
A4
1,217305
A9
1,232297
Tabela 5.11: Comparao das arquiteturas considerando prioridades
Para a segunda poltica de prioridade, desta vez invertendo os pesos, a arquitetura

apontada foi a mesma do resultado com prioridades iguais, a arquitetura A2. O fato ocorre pelo
custo ter maior relevncia, sendo a arquitetura A2 o de menor custo e com reduo de downtime
interessante.
Portanto, este segundo estudo apresentou diversos resultados envolvendo uma arquitetura
um pouco mais robusta que o sistema domstico. Nesse estudo, utilizou-se outras duas tcnicas
(Availability Importance e distncia euclidiana) que foram capazes de apresentar resultados que
apoiam a deciso de gestores ou administradores, quando o objetivo aumentar a disponibilidade
do Video Surveillance as a Service.
94
6
Concluses e Trabalhos Futuros
Se hoje fosse o ltimo dia da minha vida, queria fazer o que vou fazer hoje?
E se a resposta fosse no muitos dias seguidos, sabia que precisava mudar
algo.
STEVE JOBS
Os vdeos de vigilncia esto contribuindo para crescimento dos big datas, apresentando
uma fatia importante no universo digital. O servio VSaaS foi recentemente introduzido como
uma alternativa para o desenvolvimento e a gesto de sistemas de vigilncia (XIONG et al.,
2014). O modelo VSaaS permite maior escalabilidade dos recursos a um baixo custo, pela
concentrao dos recursos computacionais na nuvem. Esta infraestrutura permite atender a mais
de um cliente e oferece mais qualidade e confiabilidade.
Para entender a grandeza desse servio, uma pesquisa da International Data Corporation
(IDC, 2013), evidencia que esperado em 2015 o percentual de 65% de todos os materiais
importantes a serem analisados no mundo digital sejam de vdeos de vigilncia. Pelo diagnstico
publicado em (MARKETSANDMARKETS, 2012), espera-se uma taxa composta de crescimento
anual do mercado de VSaaS de 31,5% de 2012 at 2017 resultando em $2.390,90 milhes em
2017.
Neste contexto, o presente trabalho trouxe um estudo sobre avaliao de disponibilidade
em ambientes de VSaaS. Investigou dois sistemas: domstico e empresarial. Destes, mais de
20 arquiteturas foram geradas com a premissa de aumentar a disponibilidade. Para avaliar as
arquiteturas, criaram-se dois modelos hierrquicos utilizando RBD com CTMC no primeiro
sistema e RBD com SPN no segundo. As redundncias de componentes foram baseadas em
anlises e conceitos publicados. No sistema empresarial foi discutida a relao do custo das
arquiteturas e o downtime.
95
Inicialmente, o primeiro estudo de caso apresentou uma arquitetura bsica, sem redundncia, com a finalidade foi apresentar os modelos analticos que representasse o comportamento
dessa arquitetura e obter o resultado de disponibilidade total desse servio, atravs dos parmetros de falha e reparo de cada um dos componentes que formam essa arquitetura sem redundncia.
Essa teve o seu modelo validado por meio de experimentos de injeo de falhas, guiados pelo
mtodo de KEESEE (1965). Constatou-se que o resultado do modelo est contido no intervalo
de confiana de 95%, adotado no estudo. Portanto, no modelo proposto no tem evidncias
para ser refutado como modelo que representa o comportamento do ambiente real, pois ambos
esto consistentes entre si. Por coerncia, os mesmos valores de tempo de falha foram reduzidos.
Os mesmos parmetros de entrada (tempos de falhas e reparos) usados durante o experimento
na injeo de falhas serviram como insumo para os parmetros dos modelos avaliados neste
trabalho.
Este estudo de caso foi composto por trs arquiteturas: a primeira sem redundncia
(arquitetura 1) e as outras duas houve a incluso de redundncia (arquiteturas 2 e 3). Os
resultados mostraram um aumento significativo na disponibilidade de 99,50% da arquitetura
1 para 99,68% da arquitetura 3 quando a redundncia foi atribuda s Cmeras, rede de
comunicao, ao Node, ao Frontend e ao servio LiveVideo. Comparado com a mtrica de
downtime, houve reduo de 36,89% entre as arquiteturas 1 e 3, uma diferena de 16 horas
(significa a metade de um dia com o servio interrompido). Considerando essa interrupo para
servios crticos, tais como transportadoras de valores, bancos, museus, poderiam ocasionar
prejuzos financeiros severos.
Para a realizao da anlise de sensibilidade paramtrica, adotou-se a arquitetura 3 do
modelo analtico do sistema domstico. Os resultados mostraram que os parmetros de falha
e reparo do Node tm o maior impacto na disponibilidade, sendo uma boa opo indicada
para receber melhorias e consequentemente aumentar a disponibilidade. Outros componentes
relevantes que contribuem na disponibilidade so o Frontend e o Streaming Transmitter. Porm,
os componentes do subsistema LiveVideo registraram pequeno impacto, este justificado pela redundncia warm-standby aplicada. Os componentes cmera, 3G e WiFi tiveram comportamentos
semelhantes.
No segundo estudo de caso, o empresarial, mais robusta que as arquiteturas do sistema
domstico. Nesse estudo, iniciou-se pela a definio da estratgia de disponibilidade mais coesa,
optando-se por quatro das cinco cmeras funcionarem por andar. A escolha foi motivada por ela
proporcionar maior sensao de segurana e a existncia de uma diferena de downtime pequena
em relao s outras estratgias, no ultrapassando as trs horas anuais.
Aps a definio dessa estratgia, aplicou-se a tcnica de Availability Importance para en-
96
contrar os componentes de maior impacto na disponibilidade. Usado com a finalidade semelhante
a da anlise de sensibilidade, na deteco de gargalos e pontos crticos. Entre os componentes
avaliados e apontados a serem replicados foram a CameraLiveVideo, o Node e o Frontend.
Com esta orientao foram geradas 18 arquiteturas com dois nveis a mais de redundncia para
os trs primeiros componentes do ranking do Availability Importance. Visualmente, algumas
arquiteturas destacam-se como boas escolhas conforme a mtrica de disponibilidade (A8, A11,
A13, A15 e A18) e de downtime as arquiteturas descartadas (A1, A5 e A6).
Para determinar uma arquitetura eficaz, entre todas, foi aplicada a tcnica de distncia
euclidiana, considerando a relao custo e downtime. Desse modo, houve necessidade de
transformar os valores em grandeza proporcionalmente iguais, por meio da normatizados dos
dados. O resultado indicou a arquitetura A2 como a de maior aumento na disponibilidade em
relao ao menor investimento. Com o investimento 7%, obteve-se 30% na reduo do downtime
anual. Somente a replicao do componente Frontend alcanou um resultado satisfatrio.
Contudo, isso no significa ser o melhor, porque depender das pretenses da empresa ao
considerar o capital de investimento disponvel e o nvel exigido de tolerncia a falha do sistema.
Para auxiliar a deciso dos gestores, dois pesos de prioridade foram determinados:
primeiro priorizando 70% na reduo do downtime e o outro 70% no baixo custo. O primeiro
peso apontou a arquitetura A8, que por meio da replicao do Frontend e do Node reduziu 80%
do downtime com R$ 10.116,00 a mais que a arquitetura bsica, em torno de 30%. No segundo
peso, a arquitetura A2 foi indicada como vivel financeiramente, inclusive a mesma indicada
no resultado com prioridades iguais para custo e downtime.
Portanto, os resultados obtidos e a abordagem utilizada durante esta pesquisa podem
auxiliar outros sistemas de vigilncia em nuvem, porm as concluses dependero do nvel de
disponibilidade desejado e os recursos financeiros destinados poltica de redundncia aplicada
aos componentes. Ressalta-se quanto maior o nmero de componentes replicados da arquitetura,
maior ser o custo e a disponibilidade.
Alm das concluses obtidas dos estudos, podem-se destacar algumas contribuies
especficas desse trabalho. Essas so listadas a seguir:
Desenvolvimento de uma metodologia para auxiliar o processo de avaliao do modelo
de disponibilidade de VSaaS, com modelos CTMC, SPN e RBD. Com a realizao de
experimentos de injeo de falhas para validao de modelos;
Modelos de arquiteturas de sistemas domsticos e empresariais para a plataforma de VSaaS,
considerando os componentes presentes no cliente e na infraestrutura da nuvem;
Utilizao da anlise de sensibilidade paramtrica e o Availability Importance em arquiteturas
de VSaaS, para detectar pontos crticos e indicar os componentes a serem replicados;
97
Aplicao do conceito de distncia euclidiana na discutir o trade-off entre custo versus
downtime.
Ao trmino dessa pesquisa, verificou-se que a mesma possui extenses para atividades
futuras. Dentre as quais, podem-se destacar:
Estender a modelagem das arquiteturas incluindo a entrega do servio ao usurio final, verificando as disponibilidades dos dispositivos (notebook, tablets e smartphones) e os softwares
de navegao, bem como, modelar o servio de armazenamento ocorrendo na nuvem,
localmente ou de maneira hbrida;
Verificar se h aumento de disponibilidade com o uso de cmeras com deteco de movimento,
considerando a viabilizao do custo;
Considerar balanceamento de carga e mecanismos de auto scaling nas VM do hosts, a fim de
avaliar o seu impacto sobre a disponibilidade do VSaaS;
Implementar um mecanismo de aviso automtico quando o sistema estiver indisponvel e
realizar uma anlise confiabilidade;
Utilizar um middleware no cliente com o objetivo de detectar falha no provedor de nuvem e
direcionar o processamento do servio para um provedor ativo.
98
Referncias
ABDALLAH, H.; HAMZA, M. On the sensitivity analysis of the expected accumulated reward.
Performance Evaluation, [S.l.], v.47, n.2, p.163179, 2002.
AJMONE MARSAN, M.; CONTE, G.; BALBO, G. A Class of Generalized Stochastic Petri
Nets for the Performance Evaluation of Multiprocessor Systems. ACM Trans. Comput. Syst.,
New York, NY, USA, v.2, p.93122, May 1984.
ARAUJO, C. J. M. Avaliaoo e modelagem de desempenho para planejamento de
capacidade do sistema de transferncia eletrnica de fundos utilizando trfego em rajada.
2009. Tese (Doutorado em Cincia da Computao) Dissertao, Universidade Federal de
Pernambuco, Centro de Informtica.
ARAUJO, J. et al. Software rejuvenation in eucalyptus cloud computing infrastructure: a
method based on time series forecasting and multiple thresholds. [S.l.]: IEEE, 2011. 3843p.
ARLAT, J. et al. Fault Injection and Dependability Evaluation of Fault-Tolerant Systems.
Computers, IEEE Transactions on, [S.l.], v.42, n.8, p.913923, 1993.
AVIZIENIS, A. et al. Fundamental Concepts of Dependability. [S.l.]: University of
Newcastle upon Tyne, Computing Science, 2001.
AVIZIENIS, A. et al. Basic Concepts and Taxonomy of Dependable and Secure Computing.
Dependable and Secure Computing, IEEE Transactions on, [S.l.], v.1, n.1, p.1133, 2004.
BAIER, C. et al. Model-checking algorithms for continuous-time Markov chains. Software
Engineering, IEEE Transactions on, [S.l.], v.29, n.6, p.524541, 2003.
BAKSHI, K. Cisco Cloud Computing-Data Center Strategy, Architecture, and Solutions. DOI=
http://www. cisco. com/web/strategy/docs/gov/CiscoCloudComputing_WP. pdf, [S.l.],
2009.
BALBO, G. Introduction to Stochastic Petri Nets. In: Lectures on Formal Methods and
PerformanceAnalysis. [S.l.]: Springer, 2001. p.84155.
BASSANEZI, R. C. Ensino-aprendizagem com modelagem matemtica: uma nova
estratgia. [S.l.]: Editora Contexto, 2002.
BLAKE, J. T.; REIBMAN, A. L.; TRIVEDI, K. S. Sensitivity analysis of reliability and
performability measures for multiprocessor systems. [S.l.]: ACM, 1988. 177186p. v.16,
n.1.
BOLCH, G. et al. Queuing Networks and Markov Chains: modeling and performance
evaluation with computer science applications. [S.l.]: John Wiley & Sons, 2006.
REFERNCIAS
99
BUYYA, R.; YEO, C. S.; VENUGOPAL, S. Market-Oriented Cloud Computing: vision,

hype, and reality for delivering it services as computing utilities. [S.l.]: Ieee, 2008. 6p.
CALHEIROS, R. N. et al. CLOUDSIM: a toolkit for modeling and simulation of cloud
computing environments and evaluation of resource provisioning algorithms. Software:
Practice and Experience, [S.l.], v.41, n.1, p.2350, 2011.
CALLOU, G. et al. Estimating Sustainability Impact of High Dependable Data Centers: a
comparative study between brazilian and us energy mixes. [S.l.: s.n.], 2013. 11371170p. v.95,
n.12.
CARVALHO, L. S. de. Modelagem e simulao: poderosa ferramenta para a otimizao de
operaes logsticas. [S.l.: s.n.], 2003.
CHAN, H. A. Accelerated Stress Testing for Both Hardware and Software. [S.l.]: IEEE,
2004. 346351p.
CHANG, S.-F.; VETRO, A. Video Adaptation: concepts, technologies, and open issues.
Proceedings of the IEEE, [S.l.], v.93, n.1, p.148158, 2005.
CHEN, X. et al. Understanding, Modelling, and Improving the Performance of Web
Applications in Multicore Virtualised Environments. [S.l.]: ACM, 2014. 197207p.
CIARDO, G. Petri Nets with Marking-Dependent Arc Cardinality: properties and analysis. In:
Application and Theory of Petri Nets 1994. [S.l.]: Springer, 1994. p.179198.
COOPER, T.; FARRELL, R. Value-Chain Engineering of a Tower-Top Cellular Base
Station System. [S.l.]: IEEE, 2007. 31843188p.
D-LINK. D-link Wireless N150 Router. [S.l.: s.n.], 2012.
DANTAS, J. et al. Models for Dependability Analysis of Cloud Computing Architectures for
Eucalyptus Platform. International Transactions on Systems Science and Applications,
[S.l.], v.8, p.1325, 2012.
DANTAS, J. R. Modelos para Anlise de Dependabilidade de Arquiteturas de
Computao em Nuvem. 2012. Dissertao (Mestrado em Cincia da Computao)
Universidade Federal de Pernambuco, Recife, PE.
DAS, O. Performance and Dependability Analysis of Fault-Tolerant Layered Distributed
Systems. 1998. Tese (Doutorado em Cincia da Computao) Carleton University Ottawa.
FIGUEIRDO, J. Jair Cavalcante de; ROMERO MARTINS MACIEL, P. O. Anlise de
dependabilidade de sistemas data center baseada em ndices de importncia. [S.l.: s.n.],
2011.
FRANK, P. M. Introduction to System Sensitivity Theory. [S.l.]: Academic press New York,
1978. v.11.
REFERNCIAS
100
GERMAN, R. Performance Analysis of Communication Systems with Non-Markovian

Stochastic Petri Nets. [S.l.]: John Wiley & Sons, Inc., 2000.
GOEL, A. L. Software Reliability Models: assumptions, limitations, and applicability. Software
Engineering, IEEE Transactions on, [S.l.], n.12, p.14111423, 1985.
GOMES, C. N. Estudo do Paradigma Computao em Nuvem. 2012. Tese (Doutorado em
Cincia da Computao) INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA.
HAGEN, S.; SEIBOLD, M.; KEMPER, A. Efficient Verification of it Change Operations or:
how we could have prevented amazons cloud outage. [S.l.]: IEEE, 2012. 368376p.
HAMBY, D. A Review of Techniques for Parameter Sensitivity Analysis of Environmental
Models. Environmental Monitoring and Assessment, [S.l.], v.32, n.2, p.135154, 1994.
HAVERKORT, B. R. Performance of Computer Communication Systems: a model-based
approach. [S.l.]: Wiley, 1998.
HERBERT, L.; ERICKSON, J. The ROI of Cloud Apps. A Total Economic Impact
Analysis Uncovers Long-Term Value In Cloud Apps, Forrester, [S.l.], 2011.
IDC. The Digital Universe in 2020: big data, bigger digital shadows, and biggest growth in the
far east. [S.l.: s.n.], 2013. IDC.
INTRANSA. High Availability Concepts for Video Surveillance. [S.l.: s.n.], 2010.
INTRANSA.
KARIMAA, A. Video Surveillance in the Cloud: dependability analysis. [S.l.: s.n.], 2011.
9295p.
KARTSON, D. et al. Modeling with Generalized Stochastic Petri Nets. [S.l.]: John Wiley &
Sons, Inc., 1994.
KEESEE, W. A Method of Determining a Confidence Interval for Availability. [S.l.]: DTIC
Document, 1965.
KIM, D. S.; GHOSH, R.; TRIVEDI, K. S. A Hierarchical Model for Reliability Analysis of
Sensor Networks. [S.l.]: IEEE, 2010. 247248p.
KIM, D. S.; MACHIDA, F.; TRIVEDI, K. S. Availability Modeling and Analysis of a
Virtualized System. [S.l.]: IEEE, 2009. 365371p.
KLEINROCK, L. Queueing systems, volume I: theory. , [S.l.], 1975.
KUO, W.; ZUO, M. J. Optimal Reliability Modeling: principles and applications. [S.l.]: Wiley.
com, 2003.
LAVENBERG, S. Computer Performance Modeling Handbook. [S.l.]: Elsevier, 1983. v.4.
LAWTON, G. Users take a close look at visual analytics. Computer, [S.l.], n.2, p.1922, 2009.
REFERNCIAS
101
M, R. Users take a close look at visual analytics. Smartvue White Paper, [S.l.], p.13, 2012.
MACIEL, P. R. et al. Dependability Modeling. Performance and Dependability in Service
Computing: Concepts, Techniques and Research Directions, [S.l.], v.1, p.5397, 2011.
MACIEL, P. R. et al. Dependability Modeling. Performance and Dependability in Service
Computing: Concepts, Techniques and Research Directions, [S.l.], p.5397, 2012.
MACIEL, P. R.; LINS, R. D.; CUNHA, P. R. Introduo s Redes de Petri e Aplicaes.
[S.l.]: UNICAMP-Instituto de Computacao, 1996.
MALHOTRA, M.; TRIVEDI, K. S. A Methodology for Formal Expression of Hierarchy in
Model Solution. [S.l.]: IEEE, 1993. 258267p.
MARKETSANDMARKETS. Global Video Surveillance as a Service Market worth
$2,390.9 Million by 2017. [S.l.: s.n.], 2012. MarketsandMarkets.
MARRANGHELLO, N. Redes de Petri: conceitos e aplicaes. So Paulo:
DCCE/IBILCE/UNESP, [S.l.], 2005.
MARSAN, M. A.; BALBO, G.; CONTE, G. Performance Models of Multiprocessor
Systems. [S.l.: s.n.], 1986.
MARSAN, M. A. et al. Modelling with Generalized Stochastic Petri Nets. [S.l.]: John Wiley
& Sons, Inc., 1994.
MARSTON, S. et al. Cloud Computing - The Business Perspective. Decision Support Systems,
[S.l.], v.51, n.1, p.176189, 2011.
Matos Jnior, R. S. An Automated Approach for Systems Performance and Dependability
Improvement Through Sensitivity Analysis of Markov Chains. 2011. Dissertao
(Mestrado em Cincia da Computao) Universidade Federal de Pernambuco, Recife, Brazil.
MATOS, R. et al. Sensitivity Analysis of Server Virtualized System Availability. Reliability,
IEEE Transactions on, [S.l.], v.61, n.4, p.9941006, 2012.
MELL, P.; GRANCE, T. The NIST Definition of Cloud Computing. National Institute of
Standards and Technology Special Publication, [S.l.], p.800145, 2014.
MELO, M. D. Modelos de Disponibilidade para Nuvens Privadas: rejuvenescimento de
software habilitado por agendamento de migrao de vms. 2014. Dissertao (Mestrado em
Cincia da Computao) Universidade Federal de Pernambuco, Recife, PE.
MELO, M. et al. Availability study on cloud computing environments: live migration as a
rejuvenation mechanism. [S.l.]: IEEE, 2013. 16p.
MENASCE, D. A. et al. Performance by design: computer capacity planning by example.
[S.l.]: Prentice Hall Professional, 2004.
REFERNCIAS
102
MILLER, M. Cloud Computing: web-based applications that change the way you work and
collaborate online. [S.l.]: Que publishing, 2008.
MURATA, T. Petri Nets: properties, analysis and applications. Proceedings of the IEEE, [S.l.],
v.77, n.4, p.541580, 1989.
NEAL, D.; RAHMAN, S. Video Surveillance in the Cloud? The International Journal of
Cryptography and Information Security (IJCIS), [S.l.], v.2, n.3, 2012.
PEARSON, S. Taking Account of Privacy When Designing Cloud Computing Services.
[S.l.]: IEEE Computer Society, 2009. 4452p.
PETRI, C. A. Kommunikation mit automaten. [S.l.: s.n.], 1962.
PICCONI, F.; MASSOULI, L. Is There a Future for Mesh-Based Live Video Streaming?
[S.l.]: IEEE, 2008. 289298p.
PRADO, G. Desertesejo: um projeto de ambiente virtual de multiusurio na web. Catlogo da
Electronic Art Exhibition, SIBGRAPI, [S.l.], 2000.
SABAHI, F. Cloud Computing Security Threats and Responses. [S.l.]: IEEE, 2011.
245249p.
SALEH, N. A.; MAHMOUD, M. A.; ABDEL-SALAM, A.-S. G. The Performance of the
Adaptive Exponentially Weighted Moving Average Control Chart with Estimated Parameters.
Quality and Reliability Engineering International, [S.l.], v.29, n.4, p.595606, 2013.
SALES, A. H. C. de. Um Estudo sobre Redes de Petri Estocsticas Generalizadas.
[S.l.: s.n.], 2002.
SARANYA, S. M.; VIJAYALAKSHMI, M. Interactive Mobile Live Video Learning System
in Cloud Environment. [S.l.]: IEEE, 2011. 673677p.
SCHROEDER, B.; GIBSON, G. A. Disk Failures in the Real World: what does an mttf of 1,
000, 000 hours mean to you? [S.l.: s.n.], 2007. 116p. v.7.
SHARMA, C. M.; KUMAR, H. Architectural framework for implementing visual
surveillance as a service. [S.l.]: IEEE, 2014. 296301p.
SIA. Mercado Formal de Segurana Eletrnica no Brasil Deve Crescer 20,6% at 2017.
[S.l.: s.n.], 2014. SIA.
SILVA, B. et al. ASTRO: an integrated environment for dependability and sustainability
evaluation. Sustainable Computing: Informatics and Systems, [S.l.], 2012.
SONG, B.; TIAN, Y.; ZHOU, B. Design and Evaluation of Remote Video Surveillance
System on Private Cloud. [S.l.]: IEEE, 2014. 256262p.
REFERNCIAS
103
SOUSA, E. d. Avaliao do impacto de uma poltica de manuteno na performabilidade

de sistemas de transferncia eletrnica de fundos. 2009. Tese (Doutorado em Cincia da
Computao) Dissertao, Universidade Federal de Pernambuco, Centro de Informtica.
SOUSA, E. et al. Evaluating Eucalyptus Virtual Machine Instance Types: a study
considering distinct workload demand. [S.l.: s.n.], 2012. 130135p.
SOUZA, D. et al. A Tool for Automatic Dependability Test in Eucalyptus Cloud Computing
Infrastructures. Computer and Information Science, [S.l.], v.6, n.3, p.5767, 2013.
STEWART, W. J. Introduction to the Numerical Solutions of Markov Chains. [S.l.]:
Princeton Univ. Press, 1994.
SUBRAMANIAN, K. Hybrid Clouds. Access from http://emea. trendmicro.
com/imperia/md/content/uk/cloud-security/wp01_hybridcloud-krish_110624us. pdf,
[S.l.], 2011.
SUN, D. et al. A Dependability Model to Enhance Security of Cloud Environment Using
System-Level Virtualization Techniques. [S.l.]: IEEE, 2010. 305310p.
SUTOR, S. et al. Large-Scale Video Surveillance Systems: new performance parameters and
metrics. [S.l.]: IEEE, 2008. 2330p.
SUVONVORN, N. A Video Analysis Framework for Surveillance System. [S.l.]: IEEE,
2008. 867871p.
TERRY, D. Acm Tech Pack on Cloud Computing. ACM Tech Pack Committee on Cloud
Computing, [S.l.], 2011.
TRIVEDI, K. S. Probability and Statistics with Reliability, Queueing and Computer
Science Applications. [S.l.]: John Wiley & Sons, 2002.
TRIVEDI, K. S. et al. Reliability Analysis Techniques Explored Through a
Communication Network Example. [S.l.: s.n.], 1996.
TRIVEDI, K. S. et al. Modeling High Availability. [S.l.]: IEEE, 2006. 154164p.
VACARO, J. C.; WEBER, T. S. Injeo de Falhas na Fase de Teste de Aplicaes
Distribudas. [S.l.: s.n.], 2006.
VAQUERO, L. M. et al. A Break in the Clouds: towards a cloud definition. ACM SIGCOMM
Computer Communication Review, [S.l.], v.39, n.1, p.5055, 2008.
WEBER, T. S. Tolerncia a Falhas: conceitos e exemplos. Apostila do Programa de
Ps-GraduaoInstituto de Informtica-UFRGS. Porto Alegre, [S.l.], 2003.
XIONG, Y.-H. et al. Design and Implementation of a Prototype Cloud Video Surveillance
System. Journal ref: Journal of Advanced Computational Intelligence and Intelligent
Informatics, [S.l.], v.18, n.1, p.4047, 2014.
REFERNCIAS
ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud Computing: state-of-the-art and research
challenges. Journal of internet services and applications, [S.l.], v.1, n.1, p.718, 2010.
104
Apndice
106
A
Scripts de Injeo de falha do Cliente
1
2
3
4
5
6
7
8
9
10
11
12
#!/bin/bash
echo "Fault injection Cliente...."
echo "# Event GT Date" >> ClienteFault.log
C1=0
while [ $C1 -le 49 ] ;

do
C1=$(($C1+1))
TIME=$(Rscript expFailCliente.r | awk {print $2})
sleep $TIME
sshpass -p "livevideo" ssh magno/192.168.56.109 "sudo -S /etc
/init.d/rtsp stop"
13
echo "Fault injected"
14
echo $C1 "Fault" $TIME $(date | awk { print $2, $3, $4 })
>> ClienteFault.log
15
16
TIMER=$(Rscript expRepairCliente.r | awk {print $2})
17
sleep $TIMER
18
sshpass -p "livevideo" ssh magno/192.168.56.109 "sudo -S /etc
/init.d/rtsp start"
19
echo "Repair Injected"
20
echo $C1 "Repair" $TIMER $(date | awk { print $2, $3, $4 })
>> ClienteFault.log
21 done
22
23 echo "Finish Cliente"
107
B
Scripts de Injeo de falha do Frontend
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
echo "Fault injection Frontend...."
echo "# Event GT Date" >> FrontendFault.log
C1=0
while [ $C1 -le 49 ] ;
do
C1=$(($C1+1))
TIME=$(Rscript expFailFrontend.r | awk {print $2})
sleep $TIME
ssh matheus/192.168.56.1 "sudo -S shutdown -h 0 < ~/FILE.txt"
>> FrontendFault.log
TIMER=$(Rscript expRepairFrontend.r | awk {print $2})
sleep $TIMER
wakeonlan 192.168.56.1
>> FrontendFault.log
21 done
22
23 echo "Finish Frontend"
108
C
Scripts de Injeo de falha do Node
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
echo "Fault injection Node...."
echo "# Event GT Date" >> NodeFault.log
C1=0
while [ $C1 -le 49 ] ;
do
C1=$(($C1+1))
TIME=$(Rscript expFailNode.r | awk {print $2})
sleep $TIME
ssh matheus/192.168.56.2 "sudo -S shutdown -h 0 < ~/FILE.txt"
>> NodeFault.log
TIMER=$(Rscript expRepairNode.r | awk {print $2})
sleep $TIMER
wakeonlan 192.168.56.2
>> NodeFault.log
21 done
22
23 echo "Finish Node"
109
D
Scripts de Injeo de falha do LiveVideo
1
2
3
4
5
6
7
8
9
10
11
12
#!/bin/bash
echo "Fault injection LiveVideo...."
echo "# Event GT Date" >> LiveVideoFault.log
C1=0
while [ $C1 -le 49 ] ;

do
C1=$(($C1+1))
TIME=$(Rscript expFailLiveVideo.r | awk {print $2})
sleep $TIME
sshpass -p "opennebula" ssh matheus/192.168.56.117 "sudo -S /
etc/init.d/apache2 stop"
13
14
>> LiveVideoFault.log
15
16
TIMER=$(Rscript expRepairLiveVideo.r | awk {print $2})
17
sleep $TIMER
18
sshpass -p "opennebula" ssh matheus/192.168.56.117 "sudo -S /
etc/init.d/apache2 start"
19
20
>> LiveVideoFault.log
21 done
22
23 echo "Finish LiveVideo"
110
E
Scripts de Monitoramento do Cliente
1
2
3
4
5
#!/bin/bash
C=0
echo "Start" $(date | awk { print $2, $3, $4 }) >> "
TesteAvailCliente".txt
echo "# StatusCliente " >> "TesteAvailCliente".txt
6
7
8 while [ True ]
9 do
10
C=$(($C+1))
11
STATUS=$(nmap -p 554 192.168.56.109 | grep 554/tcp | awk {
print $2})
12
if [ "$STATUSS" == "UNKNOWN"] ; then
13
echo $C "Cliente" "down" $(date | awk {
print $2, $3, $4 }) >> "TesteAvailCliente
".txt
14
else
15
echo $C "Cliente" "up" $(date | awk { print $2, $3,
$4 }) >> "TesteAvailCliente".txt
16
fi
17
sleep 1
18 done
19
20 echo "End" $(date | awk { print $2, $3, $4 }) > "TesteAvailCliente"
.txt
111
F
Scripts de Monitoramento do Frontend
1
2
3
4
5
#!/bin/bash
C=0
TesteAvailFrontend".txt
echo "# StatusFrontend" >> "TesteAvailFrontend".txt
6
7
8 while [ True ]
9 do
10
C=$(($C+1))
11
if [ping -c 5 192.168.56.1 > /dev/null] ; then
12
echo $C "up" $(date | awk { print $2, $3, $4 }) >>
"TesteAvailFrontend".txt
13
else
14
echo $C "down" $(date | awk { print $2, $3, $4 })
>> "TesteAvailFrontend".txt
15
fi
16
sleep 1
17 done
18 echo "End" $(date | awk { print $2, $3, $4 }) > "TesteAvailFrontend
".txt
112
G
Scripts de Monitoramento do Node
1
2
3
4
5
#!/bin/bash
C=0
echo "Start" $(date | awk { print $2, $3, $4 }) >> "TesteAvailNode"
.txt
echo "# StatusNode" >> "TesteAvailNode".txt
6
7
8 while [ True ]
9 do
10
C=$(($C+1))
11
if [ping -c 5 192.168.56.2 > /dev/null] ; then
12
echo $C "up" $(date | awk { print $2, $3, $4 }) >>
"TesteAvailNode".txt
13
else
14
echo $C "down" $(date | awk { print $2, $3, $4 })
>> "TesteAvailNode".txt
15
fi
16
sleep 1
17 done
18
19 echo "End" $(date | awk { print $2, $3, $4 }) > "TesteAvailNode".
txt
113
H
Scripts de Monitoramento do LiveVideo
1
2
3
4
5
#!/bin/bash
C=0
TesteAvailLiveVideo".txt
echo "# StatusLiveVideo " >> "TesteAvailLiveVideo".txt
6
7
8 while [ True ]
9 do
10
C=$(($C+1))
11
STATUS=$(nmap -p 80 192.168.56.118 | grep 80/tcp | awk {
print $2})
12
if [ "$STATUSS" == "(1" ] ; then
13
echo $C $STATUS "up" $(date | awk { print $2
, $3, $4 }) >> "TesteAvailLiveVideo".txt
14
else
15
echo $C "LiveVideo" "down" $(date | awk { print $2,
$3, $4 }) >> "TesteAvailLiveVideo".txt
16
fi
17
sleep 1
18 done
19
20 echo "End" $(date | awk { print $2, $3, $4 }) > "TesteAvailApache".
txt

Avaliação Da Disponibilidade de Video Surveillance As A Service (Vsaas) - Carlosmagno - Vfinal

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Avaliação Da Disponibilidade de Video Surveillance As A Service (Vsaas) - Carlosmagno - Vfinal

Uploaded by

Copyright:

Available Formats

Carlos Mgno

AVALIAO DA DISPONIBILIDADE DE VIDEO SURVEILLANCE AS

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

AVALIAO DA DISPONIBILIDADE DE VIDEO SURVEILLANCE AS

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Prof. Dr. Paulo Romero Martins Maciel

M198a Mgno, Carlos

1. Computao nas nuvens. 2. Dependabilidade. 3. Avaliao

CDD (23. ed.)

UFPE- MEI 2015-179

Dissertao de Mestrado apresentada por Carlos Mgno Ps-Graduao em Cincia da

Visto e permitida a impresso.

Dedico esta dissertao ao Senhor Deus, por mostrar a luz

"Sem crise no h desafios, sem desafios, a vida uma rotina."

Modelos de negcio de Computao em Nuvem . . . . . . . .

Modelo RBD da arquitetura 1. . . . . . . . . . . . . . . . . . . . . . . . . . .

Disponibilidade das arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . .

Anlise de Sensibilidade - Grfico com parmetros de maior impacto .

Relao entre a proposta desta dissertao e outros trabalhos relacionados . . .

Estados do subsistema LiveVideo sem redundncia. . . . . . . . . . . . . . . .

Compound Annual Gowth Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Continuous-Time Markov Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Discrete-Time Markov Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Infraestrutura como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

International Data Corporation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Mean Time Between Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Mean Time To Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Mean Time To Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Plataforma como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Reliability Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Software como Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Stochastic Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Video Surveillance as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Cobertura da Qualidade Visual de Vigilncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Security Industry Association Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Symbolic Hierarchical Automated Reliability and Performance Evaluator . . . . 46

A Scripts de Injeo de falha do Cliente

B Scripts de Injeo de falha do Frontend

C Scripts de Injeo de falha do Node

D Scripts de Injeo de falha do LiveVideo

E Scripts de Monitoramento do Cliente

F Scripts de Monitoramento do Frontend

G Scripts de Monitoramento do Node

H Scripts de Monitoramento do LiveVideo

Os vdeos de vigilncia, esto contribuindo para crescimento de big datas, apresentando

um servio possibilita os benefcios aumentando a flexibilidade na alternncia de parmetros ou

1.2. MOTIVAO E JUSTIFICATIVA

2002) e Redes de Petri Estocsticas (Stochastic Petri Net (SPN)).

Avaliaao de disponibilidade em ambientes VSaaS tem sido tema de pesquisas que

1.4. TRABALHOS RELACIONADOS

1.4. TRABALHOS RELACIONADOS

Principais contribuies da dissertao

avaliao de disponibilidade na plataforma de computao em nuvem privada OpenNebula.

1.5. ESTRUTURA DA DISSERTAO

Este Captulo contextualizou o tema da pesquisa ao tratar da relevncia em avaliar a

H conhecimentos bsicos para esta Dissertao ser compreendida. Ressaltam-se neste

Computao em nuvem um paradigma em contnuo desenvolvimento que foi originado

2.1. COMPUTAO EM NUVEM

Em BAKSHI (2009), a computao em nuvem definida como recursos de TI e servios

2.1. COMPUTAO EM NUVEM

pela utilizao eficiente dos recursos, empregando virtualizao, monitoramento de recursos e