5.2 Um Exemplo Ilustrativo
5.2.3 Simula¸c˜ao Estoc´astica
A ferramenta OpenMADS foi usada para computar a disponibilidade dos modelos DSPN gerados pelo processo de mapeamento. Os valores default dos parˆametros usados na si- mula¸c˜ao s˜ao sumarizados na Tabela 5.2. Foram usados parˆametros de entrada arbitr´arios (por´em razo´aveis), visto que o prop´osito deste exemplo ´e mostrar a aplicabilidade da fer- ramenta. Note que todos esses parˆametros s˜ao definidos atrav´es das anota¸c˜oes de MARTE e das propriedades dos blocos. Neste exemplo, todas as transi¸c˜oes s˜ao exponenciais com exce¸c˜ao da transi¸c˜ao determin´ıstica Tclock. A Tabela 5.3 detalha a disponibilidade e o
downtime do sistema de aplica¸c˜ao Web e dos componentes que comp˜oem esse sistema. As disponibilidades s˜ao calculadas atrav´es das m´etricas definidas na Tabela 5.4. Note que a disponibilidade do sistema (Asys) n˜ao ´e igual ao produto da disponibilidade de cada
componente porque eles n˜ao s˜ao independentes. O resultado mostra que o Servidor Web possui a menor disponibilidade de todos os componentes do sistema, sendo, portanto, um dos gargalos da disponibilidade do ambiente modelado.
Tamb´em realizamos an´alise de sensibilidade dos models DSPN, em que o intervalo de monitoramento do servidor Web foi variado (Tclock). Como pode ser observado a
5.2 UM EXEMPLO ILUSTRATIVO 87
Tabela 5.1: Fun¸c˜oes de Guarda Geradas pelo Processo de Mapeamento.
A¸c˜ao Guarda Fun¸c˜ao Nos de decis˜ao Gout1 dec1 ]PDCup=1
Gout2 dec1 ]PDCup=0
Gout1 dec2 ]PW EBup>3
Gout2 dec2 ]PW EBup<3
Gout3 dec2 ]PW EBup=3
Sincroniza¸c˜ao Gin W EBF over ]pin F over=1
Gin F over ]Pin W EBF over=1
Gout W EBF over ]Pout F over=1
Gout F over ]Pin W EBF over=0
Gin W EBF back ]pin F back=1
Gin F back ]Pin W EBF back=1
Gout W EBF back ]Pout F back=1
Gout F back ]Pin W EBF back=0
Composi¸c˜ao dos Modelos GW EBdown (](’PDCdown=1
GDBdown ]PDCdown=1
GLBdown ]PDCdown=1
GW EBdet ]PDCup=1
GDBdet ]PDCup=1
GLBdet ]PDCup=1
Web s˜ao checados constantemente evitando o downtime e, assim, resulta numa maior disponibilidade do sistema. Por outro lado, a medida que intervalo de monitoramento aumente, a disponibilidade do sistema diminui, j´a que as interrup¸c˜oes nos servidores Web podem levar mais tempo para serem detectadas. O downtime anual aumenta de 12 horas para 15,5 horas, se modificarmos o intervalo de monitoramento de 5 minutos para 200 minutos. Esse ´e um exemplo de v´arias conclus˜oes importantes que podemos obter usando OpenMADS.
5.3 CONSIDERAC¸ ˜OES FINAIS 88
Tabela 5.2: Descri¸c˜ao dos Parˆametros de Entrada e seus Valores Default.
Parˆametro Transi¸c˜ao Valor [horas] Tempo M´edio at´e a Falha do Data Center TDCf ail 13149
Tempo de Reparo do Data Center TDCrec 3
Tempo de Detec¸c˜ao do Data Center TDCdet 0.08
Tempo M´edio at´e a Falha do Banco de Dados TDBf ail 4383
Tempo de Reparo do Banco de Dados TDBrec 2
Tempo de Detec¸c˜ao do Banco de Dados TDBdet 0.08
Tempo M´edio at´e a Falha do Balanceador de Cargas TLBf ail 8760
Tempo de Reparo do Balanceador de Cargas TLBrec 2
Tempo M´edio at´e a Falha do Servidor Web TW EBf ail 1461
Tempo de Reparo do Servidor Web TW EBrec 2
Tempo de Detec¸c˜ao do Servidor We TW EBdet 0.08
Tempo de Failover do Servidor Web TW EBf over 0.02
Tempo de Failback do Servidor Web TW EBf back 0.02
Tempo das Atividades TX 1.39 × 10−3
Intervalo de Monitoramento Tclock 0.42
Tabela 5.3: Disponibilidade em Estado Estacion´ario e Downtime.
Disponibilidade Downtime (horas por ano) Balanceador de Cargas 0,9998313 1,477812 Servidor Web 0,9989158 9,497242 Banco de Dados 0,9993347 5,828028 Data Center 0,9996610 2,969640 Sistema (Asys) 0,9986098 12,178152
Tabela 5.4: M´etricas para Calcular a Disponibilidade em Estado Estacion´ario.
M´etrica Fun¸c˜ao Balanceador de Carga (RLB) P{]PLBup=1}
Servidores Web (RW EB) P{]PW EBup>2}
Banco de Dados (RBD) P{]PDBup=1}
Data Center (RDC) P{]PDCup=1}
Sistema (Asys) P{((]PLBup=1) AND (]PDCup=1) AND
(]PDBup=1) AND (]PW EBup>2))}
5.3 CONSIDERAC¸ ˜OES FINAIS
O mapeamento das especifica¸c˜oes dos sistemas distribu´ıdos, incluindo os mecanismos de tratamento de interrup¸c˜oes pode ser complexo e propenso a erros. Isto ´e, para que ele seja
5.3 CONSIDERAC¸ ˜OES FINAIS 89
mais pratic´avel, o suporte de ferramentas pode ser necess´ario. Dessa forma, este cap´ıtulo introduziu a ferramenta OpenMADS que pode ser usada para auxiliar os projetistas na modelagem, no mapeamento e na an´alise das especifica¸c˜oes dos sistemas distribu´ıdos. O grande desafio do desenvolvimento desse ferramenta foi justamente em lidar com a complexidade da mesma, devido, principalmente, `as convers˜oes requeridas (Diagramas da SysML -> Redes de Petri), como tamb´em `a disponibiliza¸c˜ao de uma interface gr´afica online para os usu´arios.
0 0 1 0 2 0 3 0 4 0 5 0 6 0 5 25 50 100 150 200 A n á li se d e E st a d o E st a ci o n á ri o Intervalo de monitoramento[minutos]
CAP´ITULO 6
ESTUDO DE CASOS
Education is the most powerful weapon which you can use to change the world. —NELSON MANDELA
Os exemplos apresentados neste cap´ıtulo s˜ao mecanismos de tratamento de inter- rup¸c˜oes reais implantado nos sistemas distribu´ıdos. Neste sentido, procura-se demonstrar a aplicabilidade do framework que almeja auxiliar os projetistas, os quais n˜ao possuem (ou possuem pouca) expertise em modelagem estoc´astica a projetar e estudar as infra- estruturas dos sistemas distribu´ıdos e os mecanismos de tratamento de interrup¸c˜oes, a partir de especifica¸c˜oes descritas em SysML e MARTE. Trˆes estudos de casos s˜ao apresen- tados neste cap´ıtulo. O primeiro consiste do estudo da nuvem open-source Eucallyptus. Nesse estudo, s˜ao levados em conta os bugs de envelhecimento e seus respectivos meca- nismos de mitiga¸c˜ao de interrup¸c˜oes. Tamb´em foi utilizada uma abordagem hier´arquica para os modelos obtidos pelo processo de mapeamento, visto que os mesmos podem ser decompostos em submodelos hier´arquicos. O segundo consiste de uma nuvem no modelo p´ublico de infraestrutura como servi¸co (ex.: Amazon Web Services EC2), em que meca- nismos de tratamento de interrup¸c˜oes pr´oprios desse modelo s˜ao levados em considera¸c˜ao, tais como: zona de isolamento e mecanismo de auto scaling. Esses mecanismos s˜ao usa- dos para garantir alta disponibilidade e continuidade dos servi¸cos para os SD, mesmo diante de diferentes tipos de interrup¸c˜oes. O ´ultimo consiste no estudo de um sistema de recupera¸c˜ao de interrup¸c˜oes severas utilizando uma infraestrutura de nuvem privada. Nesse estudo de caso, um mecanismo de monitoramento de desastres ´e utilizado para detectar as ocorrˆencias de interrup¸c˜oes severas. Caso um desastre tenha sido detectado, o mecanismo de monitoramento realiza o failover do sistema hospedado na infraestru- tura prim´aria (data center ) para uma infraestrutura secund´aria (nuvem privada), a fim de garantir interoperabilidade e disponibilidade dos servi¸cos providos. Para esse estudo de caso, toda a infraestrutura real do sistema de recupera¸c˜ao de desastres foi montada e experimentos foram realizados para analisar a aplicabilidade do framework proposto.
6.1 INFRAESTRUTURA EUCALYPTUS
O Eucalyptus (Elastic Utility Computing Architecture Linking Your Programs To Use- ful Systems) ´e uma infraestrutura de software de c´odigo aberto que implementa estilos escal´aveis de IaaS de nuvens privadas e h´ıbridas [NWG+09]. A plataforma Eucalyptus
surgiu a partir de um projeto desenvolvido no departamento de ciˆencia da computa¸c˜ao da Universidade da Calif´ornia, Santa B´arbara, com o intuito de realizar pesquisas na
6.1 INFRAESTRUTURA EUCALYPTUS 91
´area de computa¸c˜ao em nuvem. Essa plataforma oferece servi¸cos como armazenamento, virtualiza¸c˜ao de sistemas operacionais, clusters, entre outros. O Eucalyptus ´e compat´ıvel com v´arias distribui¸c˜oes Linux, tais como: Ubuntu, Red Hat Enterprise Linux (RHEL), CentOS, SUSE Linux Enterprise Server (SLES), openSUSE, Debian e Fedora e com uma variedade de tecnologias de virtualiza¸c˜ao, i.e., VMware, Xen e KVM. H´a cinco compo- nentes de alto n´ıvel da arquitetura Eucalyptus: o Controlador da Nuvem (consiste da porta de entrada na nuvem para os administradores, desenvolvedores e usu´ario final), o Controlador do Cluster (respons´avel pelo gerenciamento de um ou mais controlador do n´o), o Controlador do N´o (gerencia o ciclo de vida das VMs em opera¸c˜ao no n´o), o Controlador de Armazenamento (fornece armazenamento permanente para ser usado por instˆancias de VMs), e o Walrus (consiste de um servi¸co de armazenamento compat´ıvel com o Amazon S3) [Dan13].
A Figura 6.1 apresenta a infraestrutura Eucalyptus adotada neste estudo de caso. Essa nuvem privada tem uma estrutura simples, composta por um FrontEnd, com um controlador de armazenamento e um controlador de n´o. Assim, considerou-se que o con- trolador da nuvem, o controlador do cluster e o walrus foram instalados numa mesma m´aquina f´ısica (FrontEnd ). J´a o controlador do n´o e o controlador de armazenamento foram, cada um, considerados em m´aquinas f´ısicas distintas, pois eles tˆem que gerenciar os recursos da m´aquina f´ısica para as respectivas VMs instaladas, bem como realizar o armazenamento pertencente as VMs. De acordo com os resultados preliminares apresen- tados em [AMM+11], o controlador do n´o pode demonstrar um desempenho degradado
e uma taxa de falha crescente em decorrˆencia da cria¸c˜ao e destrui¸c˜ao de VMs (bugs de envelhecimento). Dessa forma, visando impedir a ocorrˆencia de falhas devido esse compor- tamento de envelhecimento, os mecanismos de mitiga¸c˜ao, chamados de rejuvenescimento, s˜ao executados periodicamente sobre o controlador do n´o a fim de evitar o downtime da infraestrutura Eucalyptus. Este estudo de caso tem o objetivo de demonstrar que o re- juvenescimento baseado em tempo (mecanismo de mitiga¸c˜ao de bugs de envelhecimento) pode ser efetivo para garantir alta disponibilidade e continuidade dos servi¸cos providos pela a infraestrutura Eucalyptus. Ademais, uma abordagem hier´arquica para os modelos obtidos pelo processo de mapeamento ´e adotada, onde os submodelos independentes s˜ao separados e a disponibilidade de todo o sistema ´e calculada usando o RBD.
Front nd Controlador de Arma enamento Controlador do nfraestrutura ucal ptus Cliente Re para criar e destruir s Re para criar e destruir s
6.1 INFRAESTRUTURA EUCALYPTUS 92