Tese FlavioRubens

Universidade Federal do Cear a Centro de Ci encias Departamento de Computa c ao Mestrado e Doutorado em Ci encia da Computa c ao
ELASTICA REPLIC: REPLICAC AO DE BANCO DE DADOS MULTI-INQUILINO EM NUVEM COM QUALIDADE DE SERVIC O Fl avio Rubens de Carvalho Sousa TESE DE DOUTORADO
Fortaleza Janeiro - 2013
Universidade Federal do Cear a Centro de Ci encias Departamento de Computa c ao
Fl avio Rubens de Carvalho Sousa ELASTICA REPLIC: REPLICAC AO DE BANCO DE DADOS MULTI-INQUILINO EM NUVEM COM QUALIDADE DE SERVIC O
Tese
submetida
` a
Coordena c ao
do
Curso
de
P os-
Gradua c ao em Ci encia da Computa c ao da Universidade Federal do Cear a como requisito parcial para o grau de Doutor em Ci encia da Computa c ao.
Orientador: Prof. Javam de Castro Machado, DSc
Fortaleza Janeiro - 2013
Aos Meus Pais.
AGRADECIMENTOS
A Deus, por estar sempre ao meu lado, dando-me coragem para enfrentar todos os obst aculos da vida. Ao meu orientador Prof. Javam Machado. Por sempre ter acreditado no meu potencial e compartilhar seu conhecimento e experi encia, fundamentais ao bom desenvolvimento desta tese. Obrigado pela conan ca e paci encia nos momentos mais delicados. A Equipe do OLTPBenchmark, especialmente a ` Carlo Curino (Microsoft Research), pela colabora ca o e aten ca o dedicada a esta tese. Aos Professores Sherif Sakr (National ICT Australia - NICTA), Carlos Fisch (UFC) e Wladimir Tavares (UFC), pela colabora c ao no desenvolvimento desta tese. Ao Grupo UFC Cloud, em especial ao prof. Leonardo Moreira e Gustavo Campos, pela ajuda constante na implementa c ao e revis ao desta tese. Aos Profs. Marta Mattoso, Carmem Hara, Neuman Souza e Jos e Ant onio de Macedo pelas valiosas sugest oes no aprimoramento desta disserta c ao. A Heraldo Carneiro pelo desenvolvimento do RepliX e revis ao dos artigos elaborados durante esta tese. A Amazon Web Services in Education pela bolsa de pesquisa concedida sem a qual esse trabalho n ao teria sido poss vel. Aos meus pais, Francisco de Sousa Izid orio e Maria Edileusa de C. O. Sousa, que jamais pouparam esfor cos na aben coada tarefa de me fazer feliz. A minha namorada, Kaluce Sousa, a cujo amor e dedica c ao, devo alto percentual de minhas realiza co es. Aos meus amigos da UFC Quixad a, por compartilharem comigo seus conhecimentos, experi encias e alegrias. A todos aqueles que me apoiaram durante esse per odo. Obrigado a todos que, de alguma forma ou de outra, deixaram algo em mim.
If I have seen further it is by standing on the shoulders of Giants ISAAC NEWTON
RESUMO
Fatores econ omicos est ao levando ao aumento das infraestruturas e instala co es de fornecimento de computa c ao como um servi co, conhecido como Cloud Computing ou Computa ca o em Nuvem, onde empresas e indiv duos podem alugar capacidade de computa c ao e armazenamento, em vez de fazerem grandes investimentos de capital necess arios para a constru ca o e instala ca o de equipamentos de computa ca o em larga escala. Na nuvem, o usu ario do servi co tem algumas garantias, tais como desempenho e disponibilidade. Essas garantias de qualidade de servi co (QoS) s ao denidas entre o provedor do servi co e o usu ario e expressas por meio de um acordo de n vel de servi co (SLA). Este acordo consiste de contratos que especicam um n vel de qualidade que deve ser atendido e penalidades em caso de falha. Muitas empresas dependem de um SLA e estas esperam que os provedores de nuvem forne cam servi cos baseados em caracter sticas de desempenho. Contudo, em geral, os provedores baseiam seus SLAs apenas na disponibilidade dos servi cos oferecidos. Sistemas de gerenciamento de banco de dados (SGBDs) para computa ca o em nuvem devem tratar uma grande quantidade de aplica c oes, tenants ou inquilinos. Abordagens multi-inquilino t em sido utilizadas para hospedar v arios inquilinos dentro de um u nico SGBD, favorecendo o compartilhamento ecaz de recursos, al em de gerenciar uma grande quantidade de inquilinos com padr oes de carga de trabalho irregulares. Por outro lado, os provedores em nuvem devem reduzir os custos operacionais garantindo a qualidade. Neste contexto, uma caracter stica chave e a replica c ao de banco de dados, que melhora a disponibilidade, desempenho e, consequentemente, a qualidade do servi co. T ecnicas de replica ca o de dados t em sido usadas para melhorar a disponibilidade, o desempenho e a escalabilidade em diversos ambientes. Contudo, a maior parte das estrat egias de replica ca o de banco de dados t em se concentrado em aspectos de escalabilidade e consist encia do sistema com um n umero est atico de r eplicas. Aspectos relacionados a ` elasticidade para banco de dados multi-inquilino t em recebido pouca aten ca o. Estas quest oes s ao importantes em ambientes em nuvem, pois os provedores precisam adicionar r eplicas de acordo com a carga de trabalho para evitar viola ca o do SLA e eles precisam vii
RESUMO
viii
remover r eplicas quando a carga de trabalho diminui, al em de consolidar os inquilinos. Visando solucionar este problema, este trabalho apresenta RepliC, uma abordagem para a replica ca o de banco de dados em nuvem com foco na qualidade do servi co, elasticidade e utiliza c ao eciente dos recursos por meio de t ecnicas multi-inquilino. RepliC utiliza informa c oes dos SGBDs e do provedor para provisionar recursos de forma din amica. Com o objetivo de avaliar RepliC, experimentos que medem a qualidade de servi co e elasticidade s ao apresentados. Os resultados destes experimentos conrmam que RepliC melhora a qualidade com uma pequena quantidade de viola c ao do SLA enquanto utiliza os recursos de forma eciente. Palavras-chave: plica ca o. Computa ca o em nuvem, gerenciamento de dados, elasticidade, re-
ABSTRACT
Economic factors are causing a signicant infrastructure growth for providing computing as a service, a concept known as cloud computing, in which companies and individuals are able to rent processing and storage capacity, instead of making big investments to build and provision a large scale computing platform. These services are typically hosted in data centers, using shared hardware for processing and storage. In the cloud, the service user has some guarantees, such as performance and availability. Quality of Service (QoS) is dened between the service provider and customer and expressed through a service level agreement (SLA), which species a level of performance and availability that must be met and penalties in case of failure. Many companies rely on SLA and they expect cloud providers to guarantee of QoS based on performance aspects. Nevertheless, in general, providers base their SLAs only on the availability of services. Database systems serving cloud platforms must handle a large number of applications or tenants. Multi-tenancy database has been prevalent for hosting multiple tenants within a single DBMS while enabling eective resource sharing and also to allow you to manage a large amount of tenants with irregular patterns of workload. Providing such performance goals is challenging for providers as they must balance the performance that they can deliver to tenants and the operating costs. In such database systems, a key functionality for service providers is database replication, which is useful for availability, performance, and quality of service. Database replication techniques have been used to improve availability, performance and scalability in dierent environments. Solutions for database replication have focused on aspects of scalability and consistency of the system with a static number of replicas. Aspects related to elasticity and multi-tenant database have received little attention. These issues are important in cloud environments, because providers need to add replicas according to the workload to avoid SLA violation, to remove replicas when the workload decreases and also consolidate tenants.
ix
ABSTRACT
To solve this problem, this thesis presents RepliC, an approach to database replication in the cloud with quality of service, elasticity, and support to multi-tenancy. RepliC uses information from databases and providers infrastructure to providing resources dynamically. In order to evaluate RepliC, some experiments that measure the quality of service and elasticity are presented. Our experiment results conrm that RepliC improvements the quality of service with small SLA violations, while using resources eciently. Keywords: Cloud computing, data management, elasticity, replication.
SUMARIO
Cap tulo 1Introdu c ao 1.1 1.2 1.3 1.4 1.5 Motiva c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deni ca o do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribui c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 6 7 7 10 12 12 14 15 16 17 18 19 31 32 32
Cap tulo 2Gerenciamento de Dados em Nuvem 2.1 Computa c ao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 Caracter sticas Essenciais . . . . . . . . . . . . . . . . . . . . . .
Modelos de Servi cos . . . . . . . . . . . . . . . . . . . . . . . . . Modelos de Implanta ca o . . . . . . . . . . . . . . . . . . . . . . .
Gerenciamento de Dados em Nuvem . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 Requisitos do Gerenciamento de Dados em Nuvem . . . . . . . . . Caracter sticas do Gerenciamento de Dados em Nuvem . . . . . .
2.3
Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cap tulo 3Trabalhos Relacionados 3.1 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
SUMARIO
xii Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . An alise Comparativa entre os Trabalhos Relacionados . . . . . . . . . . . Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 46 48
3.2 3.3 3.4
Cap tulo 4Replica c ao El astica para Banco de Dados Multi-Inquilino com Qualidade do Servi co 49 4.1 4.2 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo de Banco de Dados Multi-Inquilino . . . . . . . . . . . . . . . . . 4.2.1 4.3 Interfer encia entre Inquilinos . . . . . . . . . . . . . . . . . . . . . 49 49 50 52 52 54 57 58 60 60 61 62 64 67 69 70 70
Modelo de Qualidade de Servi co para BD em Nuvem . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Especica c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento das m etricas do SLA . . . . . . . . . . . . . . . . Penalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Elasticidade na Replica ca o de Banco de Dados em Nuvem . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4 Adi c ao de R eplicas . . . . . . . . . . . . . . . . . . . . . . . . . . Remo c ao de R eplicas . . . . . . . . . . . . . . . . . . . . . . . . . Migra c ao de Dados entre as R eplicas . . . . . . . . . . . . . . . . Provisionamento de Banco de Dados em Nuvem . . . . . . . . . .
4.5
Algoritmos para Replica ca o de Banco de Dados em Nuvem . . . . . . . . 4.5.1 Exemplo de Execu ca o do RepliC . . . . . . . . . . . . . . . . . .
4.6
Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cap tulo 5Consist encia para Banco de Dados Multi-Inquilino 5.1 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SUMARIO
xiii Comunica c ao em Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocolo para Replica c ao . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 Grupo de Atualiza ca o . . . . . . . . . . . . . . . . . . . . . . . . Grupo de Leitura . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 74 75 77 77 78 81 83 84 84 84 87 88 90 91 92 100 101 101 102
5.2 5.3
5.4
Consist encia para Banco de Dados Multi-Inquilino . . . . . . . . . . . . . 5.4.1 Algoritmos para Consist encia . . . . . . . . . . . . . . . . . . . .
5.5 5.6
Toler ancia a Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cap tulo 6Avalia c ao Experimental 6.1 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.2 Arquitetura do QoSDBC . . . . . . . . . . . . . . . . . . . . . . . Implementa ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avalia c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cap tulo 7Conclus ao 7.1 7.2 Conclus oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE ABREVIATURAS
AWS - Amazon Web Services API - Application Programming Interface ACID - Atomicidade, Consist encia, Isolamento e Durabilidade CG - Comunica ca o em Grupo EC2 - Elastic Compute Cloud FIFO - First In First Out FSS - Fun ca o de Satisfa c ao do SLA IaaS - Infrastructure as a Service JDBC - Java Database Connectivity PaaS - Platform as a Service QoS - Qualidade de Servi co QoSDBC - Quality of Service for Database in the Cloud SaaS - Software as a Service SLA - Acordo de N vel de Servi co SLADB - Acordo de N vel de Servi co para Banco de Dados SLO - Objetivos de N vel de Servi co VM - M aquina Virtual XML - eXtensible Markup Language 2PC - Two-Phase Commit 2PL - Two-Phase Locking
xiv
LISTA DE FIGURAS
1.1 2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9
Cen ario do problema abordado neste trabalho. . . . . . . . . . . . . . . . Ambiente de computa ca o em nuvem . . . . . . . . . . . . . . . . . . . . . Arquitetura do sistema SQL Azure . . . . . . . . . . . . . . . . . . . . . Arquitetura da plataforma proposta por [Yang et al., 2009] . . . . . . . . Arquitetura do sistema Re: FRESHiT . . . . . . . . . . . . . . . . . . . Arquitetura do sistema SmartSLA . . . . . . . . . . . . . . . . . . . . . . Arquitetura do sistema Amazon RDS . . . . . . . . . . . . . . . . . . . . Arquitetura do sistema Relational Cloud . . . . . . . . . . . . . . . . . . Arquitetura da abordagem proposta por [Savinov and Daudjee, 2010] . . Arquitetura do sistema CloudDB AutoAdmin . . . . . . . . . . . . . . . Arquitetura do sistema Dolly . . . . . . . . . . . . . . . . . . . . . . . .
6 13 34 35 36 38 39 40 41 42 44 45 46 50 55 59 62
3.10 Arquitetura do sistema FlurryDB . . . . . . . . . . . . . . . . . . . . . . 3.11 Arquitetura do sistema RemusDB . . . . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 Modelo multi-inquilino utilizado pelo RepliC. . . . . . . . . . . . . . . .
Estados do SLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L ogica para adi ca o e remo c ao de r eplicas. . . . . . . . . . . . . . . . . . . Migra ca o dos dados entre as r eplicas. . . . . . . . . . . . . . . . . . . . . xv
LISTA DE FIGURAS 4.5 5.1 5.2 6.1 6.2 Estat egia incremental para armazenamento dos dados. . . . . . . . . . . Grupo de atualiza c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grupo de leitura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura do QoSDBC. . . . . . . . . . . . . . . . . . . . . . . . . . .
xvi 64 76 78 85
Aumento da taxa do servi co YCSB - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC . . . . . . . . . Aumento da taxa de todos os servi cos - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC . . . . . . Elasticidade do servi co YCSB - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC . . . . . . . . . . . Elasticidade para todos os servi cos - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC . . . . . . . . .
93
6.3
94
6.4
96
6.5
98
LISTA DE TABELAS
2.1 2.2 2.3 3.1 3.2 4.1 4.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7
Requisitos para banco de dados como um servi co . . . . . . . . . . . . . Caracter sticas do gerenciamento de dados em nuvem . . . . . . . . . . . Modelos de banco de dados multi-inquilino em nuvem . . . . . . . . . . . Requisitos para a replica c ao de banco de dados em nuvem . . . . . . . . An alise comparativa entre os trabalhos relacionados . . . . . . . . . . . . Conven co es de nota ca o para migra ca o de dados entre as r eplicas. . . . . . Nota ca o utiliza para descrever os recursos do sistema. . . . . . . . . . . . Aloca ca o das r eplicas durante o primeiro experimento de QoS. . . . . . . Aloca ca o das r eplicas durante o segundo experimento de QoS. . . . . . . Taxa de transa co es para o YCSB no primeiro experimento de elasticidade Aloca ca o das r eplicas durante o primeiro experimento de elasticidade. . .
18 19 21 32 47 62 65 94 95 96 97
Taxa de transa c oes para os servi cos no segundo experimento de elasticidade. 97 Aloca ca o das r eplicas durante o segundo experimento de elasticidade. . . Viola co es de SLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 99
xvii
CAP ITULO 1
INTRODUC AO
Esta tese apresenta RepliC, uma abordagem para a replica c ao de banco de dados em nuvem, cujo prop osito e garantir a qualidade do servi co de dados por meio da elasticidade do servi co em ambientes multi-inquilino. Esta abordagem permite a adi c ao e remo ca o de r eplicas de forma din amica para manter a qualidade do servi co. Neste cap tulo s ao apresentadas a justicativa e a motiva c ao para o desenvolvimento deste trabalho, uma descri c ao do problema tratado, assim como os objetivos e as contribui c oes. Ao nal do cap tulo, e descrito como est a organizado o restante desta tese. MOTIVAC AO
1.1
Com o avan co da sociedade humana moderna, servi cos b asicos e essenciais s ao quase todos entregues de uma forma transparente. Servi cos de utilidade p ublica como a gua, g as, eletricidade e telefone tornaram-se fundamentais para nossa vida di aria e s ao explorados por meio de um modelo de pagamento baseado no uso [Vecchiola et al., 2009]. As infraestruturas existentes permitem entregar tais servi cos em qualquer lugar e a qualquer hora, de forma que possamos simplesmente acender a luz, abrir a torneira ou usar o fog ao. O uso desses servi cos e, ent ao, cobrado de acordo com as diferentes pol ticas de tarifa ca o para o usu ario nal. Recentemente, a mesma ideia de utilidade tem sido aplicada no contexto da inform atica e uma mudan ca consistente vem sendo realizada com a dissemina c ao de Cloud Computing ou Computa ca o em Nuvem [Armbrust et al., 2009]. Computa ca o em nuvem e uma tend encia recente de tecnologia cujo objetivo e proporcionar servi cos de Tecnologia da Informa ca o (TI) sob demanda com pagamento baseado no uso. Tend encias anteriores ` a computa ca o em nuvem foram limitadas a uma determinada classe de usu arios ou focadas em tornar dispon vel uma demanda espec ca de recursos de TI, principalmente de inform atica [Buyya et al., 2009]. Computa ca o em nuvem pretende ser global e prover servi cos para as massas que v ao desde o usu ario nal que hospeda seus documentos pessoais na Internet at e empresas que terceirizam toda 1
1.1. Motiva c ao
infraestrutura de TI para outras empresas. Nunca uma abordagem para a utiliza c ao real foi t ao global e completa: n ao apenas recursos de processamento e armazenamento s ao entregues sob demanda, mas toda a pilha de computa ca o pode ser aproveitada na nuvem. Sistemas de gerenciamento de banco de dados (SGBDs)1 s ao candidatos potenciais para a implanta ca o em nuvem. Isso ocorre porque, em geral, as instala c oes destes sistemas s ao complexas e envolvem uma grande quantidade de dados, ocasionando um custo elevado, tanto em hardware quanto em software. Para muitas empresas, especialmente para startups e m edias empresas, o pagamento baseado no uso do modelo de computa ca o em nuvem, juntamente com o suporte para manuten ca o do hardware e muito atraente [Abadi, 2009]. De forma geral, o gerenciamento de dados em nuvem pode ser organizado em duas classes de sistemas: (i) para apoiar aplica co es com muitas atualiza c oes em tempo real (OLTP) e (ii) para analises dos dados e suporte ` a decis ao (OLAP). Esta primeira classe pode ser dividida em duas subclasses: a primeira cujo objetivo do sistema e apoiar uma u nica aplica ca o, com grandes quantidades de dados e a segunda, onde o objetivo do sistema e apoiar um grande n umero de aplica c oes, cada uma com pequenas quantidades de dados (dezenas de MBs at e poucos GB) [Agrawal et al., 2010] [Das et al., 2011]. Estes sistemas devem dar suporte a requisitos n ao funcionais, por exemplo, desempenho e disponibilidade [Lehner and Sattler, 2010]. De forma a possibilitar a consolida ca o da computa ca o em nuvem e dos SGBDs neste ambiente, t ecnicas de virtualiza ca o tem se tornando populares para a implanta ca o destes sistemas e de outros sistemas de software [Soror et al., 2010]. A virtualiza ca o apoia a consolida ca o dos recursos nas empresas, pois permite que uma variedade de aplica co es que funcionam com recursos de computa c ao dedicados sejam movidos para um pool de recursos compartilhados, o que ajuda a melhorar a utiliza c ao dos recursos f sicos, simplicar a administra c ao e reduzir custos para as empresas [Minhas et al., 2011]. Associado a ` virtualiza c ao, o compartilhamento de infraestrutura entre inquilinos [Microsoft, 2006] no gerenciamento de dados possibilita uma utiliza ca o eciente dos recursos com baixo custo de opera ca o, al em de permitir aos SGBDs em nuvem gerenciar uma grande quantidade de inquilinos com padr oes de carga de trabalho irregulares [Agrawal et al., 2011a]. O conceito de multi-inquilino, uma t ecnica para consolidar aplica co es de m ultiplos usu arios em um u nico sistema e frequentemente utilizada para
1
SGBD refere-se um uma classe geral de armazenamento de dados, incluindo sistemas n ao-relacionais.
1.1. Motiva c ao
eliminar a necessidade de sistemas separados para cada inquilino [Schiller et al., 2011]. Por exemplo, um inquilino pode ser um usu ario utilizando uma aplica c ao que acessa um SGBD ou um SGBD instalado em uma infraestrutura. SGBD multi-inquilino tem sido utilizado para hospedar m ultiplos inquilinos dentro de um u nico sistema, permitindo o compartilhamento ecaz de recursos em diferentes n veis de abstra ca o e isolamento [Agrawal et al., 2011b]. Existem v arios modelos de multi-inquilino e estes podem compartilhar desde m aquinas at e tabelas. Por exemplo, a empresa Salesforce utiliza o modelo de tabela compartilhada [Weissman and Bobrowski, 2009] enquanto [Soror et al., 2010] utilizam o modelo de m aquina virtual compartilhada para melhorar a utiliza ca o dos recursos. Entretanto, a maioria dos SGBDs foi projetada para escalar para um ou para poucos bancos de dados grandes e n ao fornecem suporte multi-inquilino para v arias aplica c oes executadas em hardware compartilhado. Na nuvem, o usu ario do servi co tem algumas garantias, tais como desempenho e disponibilidade. Apesar das limita c oes de rede e seguran ca, as solu co es em nuvem devem fornecer desempenho elevado, al em de serem ex veis para se adaptar diante de uma determinada quantidade de requisi c oes. Como, em geral, os ambientes de computa c ao em nuvem possuem acesso p ublico, torna-se imprevis vel e vari avel a quantidade de requisi co es realizadas, dicultando fazer estimativas e fornecer garantias de qualidade do servi co [Ferretti et al., 2010]. Assim, estimar m etricas de qualidade e um desao nestes ambientes, pois os recursos gerenciados est ao frequentemente sendo expandidos ou realocados com o objetivo de melhorar o desempenho. Essas garantias de qualidade do servi co s ao denidas entre o provedor do servi co e o usu ario e expressas por meio de um acordo de n vel de servi co (SLA) [Cooper et al., 2009], que consiste de contratos que especicam um n vel de desempenho que deve ser atendido e penalidades em caso de falha. Quest oes de qualidade de servi co podem ser abordadas sob v arios pontos de vista, tais como prestar um servi co sujeito a restri co es de desempenho ou como descobrir e selecionar dinamicamente um servi co com requisitos de desempenho [Entrialgo et al., 2011]. Embora seja menos complexo controlar o SLA para um ou poucos bancos de dados pela adi ca o de recursos, isto se torna um problema complexo de gerenciamento quando se necessita cumprir SLAs para milhares de aplica co es que utilizam recursos compartilhados, visto que utilizar recursos dedicados n ao e uma op ca o economicamente vi avel devido a ` grande quantidade de aplica co es [Yang et al., 2009].
1.1. Motiva c ao
Muitas empresas precisam garantir QoS para as suas aplica co es, por exemplo, exibir uma p agina web dentro de um determinado intervalo de tempo. Essas empresas esperam que os provedores de nuvem garantam a qualidade do servi co utilizando SLAs com base em caracter sticas de desempenho. Contudo, em geral, os provedores baseiam seus SLAs apenas na disponibilidade dos servi cos oferecidos, ao passo que os servi cos em nuvem apresentam uma variabilidade de desempenho bastante elevada. Portanto, e importante que os provedores ofere cam SLAs baseados em desempenho para os usu arios [Schad et al., 2010]. Para muitos sistemas, a maior parte do tempo de execu ca o est a associada ao banco de dados (em vez do servidor web ou servidor de aplica ca o). Dessa forma, e essencial que a QoS seja aplicada no SGBD para controlar o tempo de processamento das requisi co es [Schroeder et al., 2006]. Grandes sistemas de armazenamento tais como BigTable, Dynamo, Cassandra e PNUTS foram constru dos para escalar diante de um grande n umero de requisi co es simult aneas usando infraestrutura compartilhada de milhares de servidores e fornecendo toler ancia a falhas. Embora bem sucedidos, estes sistemas utilizam modelos de dados simplicados e n ao possuem acessos baseados em atributos [Das et al., 2010], o que pode resultar em uma sobrecarga consider avel na reestrutura c ao de aplicativos legados que s ao predominantemente baseados em tecnologia de SGBDs relacionais [Elmore et al., 2011a] [Elmore et al., 2011b]. De acordo com [Vaquero et al., 2011], os provedores devem permitir o acesso a SGBDs relacionais com suporte a transa co es ACID. Trabalhos recentes mostram que os SGBDs relacionais, tais como o Azure SQL, apresentam bons resultados em diferentes cen arios [Kossmann et al., 2010]. Isso indica que SGBDs relacionais podem ser utilizados em nuvem e atender a uma quantidade consider avel de aplica co es ou podem ser combinados com estrat egias para melhorar a escalabilidade e o desempenho destes sistemas [Arnaut et al., 2011]. Al em disso, uma aplica ca o com exig encias menores de armazenamento n ao iria utilizar as vantagens de escala de grandes sistemas de armazenamento. Diferentemente das abordagens anteriores, nas quais se procurou evitar falhas por meio da utiliza ca o de hardware de custo elevado, a infraestrutura para nuvem e constru da em cima de hardware de baixo custo e com a suposi ca o de que m aquinas e redes podem falhar. Dessa forma, as solu co es desenvolvidas para a nuvem devem lidar com falhas, j a que estas ir ao ocorrer em algum momento e o tempo de interrup c ao do servi co deve ser minimizado [Abadi, 2009].
1.1. Motiva c ao
T ecnicas de replica c ao de dados t em sido usadas para melhorar a disponibilidade, o desempenho e a escalabilidade em diversos ambientes [Bernstein and Newcomer, 2009] [Charron-Bost et al., 2010] [Kemme and Alonso, 2010] [Ozsu and Valduriez, 2011]. Contudo, a maior parte destes trabalhos de replica c ao de banco de dados tem se concentrado em aspectos de desempenho, escalabilidade e consist encia do sistema com um n umero est atico de r eplicas. Aspectos referentes ao provisionamento da capacidade de forma din amica, tais como a adi ca o de r eplicas on-the-y, t em recebido pouca aten ca o. Este problema e importante em ambientes de nuvem, onde as mudan cas de carga de trabalho exigem que novas r eplicas do banco de dados possam ser inicializadas em prazos curtos de tempo [Cecchet et al., 2011] [Wada et al., 2011]. Para melhorar a qualidade do servi co, novas r eplicas podem ser criadas para distribuir a carga de trabalho, o que aumenta o custo e a complexidade do gerenciamento. De acordo com [Ozsu and Valduriez, 2011], o gerenciamento autom atico da replica ca o para lidar com mudan cas na carga de trabalho e um desao de pesquisa interessante. Um ponto importante consiste em gerenciar de forma autom atica os recursos dispon veis e a carga de trabalho do sistema para garantir a qualidade do servi co e melhorar a utiliza c ao destes recursos [Sousa et al., 2011a]. Neste contexto, a elasticidade e o ponto chave para desenvolver servi cos com QoS para nuvem, pois permite adicionar ou remover recursos, sem interrup c oes e em tempo de execu c ao para lidar com a varia ca o da carga [Agrawal et al., 2011a]. De acordo com [Kemme et al., 2010], um sistema e el astico se ele ajusta automaticamente o n umero de r eplicas para a carga de trabalho atual. Elasticidade e alcan cada por meio de auto provisionamento, que adiciona novas r eplicas se o sistema n ao consegue lidar com a carga de trabalho atual ou remove r eplicas desnecess arias. Existem diversas propostas para replica c ao de banco de dados em nuvem. Em [Elmore et al., 2011a] [Curino et al., 2011a] n ao e detalhada a estrat egia de replica ca o e os trabalhos propostos por [Yang et al., 2009] [Savinov and Daudjee, 2010] n ao implementam elasticidade, multi-inquilino ou QoS. Outras solu co es n ao tratam quest oes de desempenho com QoS [Azure, 2012], n ao abordam conceitos de banco de dados multi-inquilino [Minhas et al., 2011] [Cecchet et al., 2011] [Mior and de Lara, 2011] [Sakr et al., 2011] ou tratam apenas o modelo multi-inquilino de m aquina compartilhada [Xiong et al., 2011]. Contudo, estas propostas n ao tratam de diferentes aspectos para a replica c ao em nuvem, tais como elasticidade, QoS e abordagens multi-inquilino para banco de dados. Visando a solucionar este problema, esta tese apresenta RepliC, uma abordagem 5
1.2. Deni c ao do Problema
para a replica ca o de banco de dados em nuvem com foco na qualidade do servi co de dados e elasticidade para ambientes multi-inquilino. RepliC utiliza informa co es dos bancos de dados e do provedor de infraestrutura para provisionar recursos. O processo de gerenciamento dos dados e autom atico, visto que r eplicas dos bancos de dados s ao adicionadas ou removidas, auxiliando a gest ao e o compartilhamento de recursos. DO PROBLEMA DEFINIC AO
1.2
Em seu sentido mais amplo, este trabalho est a relacionado com o problema de replica ca o de banco de dados no ambiente de computa ca o em nuvem. Tal dom nio de problema, claramente extenso, e restringido a partir de um conjunto de caracter sticas. A Figura 1.1 mostra o cen ario do problema abordado neste trabalho.
Figura 1.1 Cen ario do problema abordado neste trabalho.
Um provedor fornece um conjunto de servi cos de banco de dados no ambiente de computa ca o em nuvem. O usu ario especica um SLA por servi co. Cada servi co e caracterizado por um SLA, composto por informa co es sobre as partes envolvidas, m etricas, objetivos e penalidades para as transa co es que excedam o objetivo denido no SLA. A carga de trabalho associada a cada servi co e denida por uma taxa de transa c oes vari avel ao longo do tempo enviada por clientes de cada servi co. 6
1.3. Objetivos
Para fornecer estes servi cos, o provedor utiliza uma infraestrutura com m aquinas virtuais e r eplicas de banco de dados para cada servi co de acordo com a carga de trabalho. As m aquinas s ao caracterizadas por CPU, mem oria, disco e um custo associado por hora de utiliza ca o. Cada r eplica e caracterizada por CPU, mem oria e disco utilizado. O principal problema desta tese consiste em: Como melhorar a qualidade para um conjunto de servi cos de banco de dados de acordo com a carga de trabalho corrente enquanto utiliza os recursos ecientemente com pequena viola ca o do SLA? Hip otese da tese: Replica c ao el astica de banco de dados multi-inquilino melhora a qualidade de servi co e a utiliza c ao de recursos em ambientes de nuvem.
1.3
OBJETIVOS
O objetivo geral deste trabalho e desenvolver uma abordagem para a replica ca o de dados em nuvem com foco em qualidade do servi co e elasticidade para um ambiente de banco de dados multi-inquilino. Este trabalho prop oe uma estrat egia que monitora continuamente a qualidade de servi co do SGBD e adiciona ou remove r eplicas destes bancos em fun ca o da varia ca o da carga de trabalho de forma autom atica. Para atingir este objetivo geral, foram denidos os seguintes objetivos espec cos:
1. Investigar a possibilidade de se utilizar t ecnicas de gerenciamento de dados em ambientes distribu dos para replica c ao de banco de dados em nuvem, em particular, apoiar um grande n umero de aplica co es, cada uma com pequenas quantidades de dados [Agrawal et al., 2010]. 2. Projetar uma abordagem para a replica ca o de dados em nuvem com foco em qualidade do servi co e elasticidade para um ambiente de banco de dados multi-inquilino. 3. Analisar a ec acia da solu c ao proposta por meio da realiza c ao de um experimento pr atico utilizando uma nuvem computacional. CONTRIBUIC OES
1.4
As principais contribui co es desta tese s ao: 7
1.4. Contribui c oes
1. Uma abordagem para a replica c ao de banco de dados em nuvem : Esta abordagem utiliza uma arquitetura para banco de dados multi-inquilino que prop oe a elasticidade por meio da adi ca o e remo ca o de r eplicas com base em informa co es coletadas sobre a carga de trabalho. Esta abordagem e independente do sistema de banco de dados e pode ser utilizada em qualquer infraestrutura de nuvem [Sousa and Machado, 2011] [Sousa and Machado, 2012]. 2. Uma estrat egia para a qualidade do servi co de dados em nuvem : Esta estrat egia dene conceitos de SLA para SGBDs e t ecnicas de monitoramento para garantir a qualidade do servi co por meio do gerenciamento de r eplicas. Com isso, a solu c ao proposta mant em o n vel do servi co dentro dos limites denidos [Sousa et al., 2011b] [Sousa et al., 2012]. 3. A implementa c ao de uma arquitetura para o gerenciamento de banco de dados baseada na abordagem de replica c ao e QoS : Este prot otipo fornece suporte a ` infraestrutura Amazon AWS e pode ser facilmente estendido para outras infraestruturas, uma vez que todas as informa c oes necess arias para sua utiliza ca o podem ser extra das dos SGBDs e das infraestruturas por meio de agentes de monitoramento [Sousa et al., 2011b] [Sousa et al., 2012]. 4. Um m etodo de avalia c ao de servi co de banco de dados multi-inquilino em nuvem : Este m etodo permite construir um ambiente multi-inquilino completo para avalia ca o e contempla diferentes aspectos, tais como qualidade do servi co e elasticidade [Sousa and Machado, 2012].
Publica co es Esta tese e baseada principalmente nas seguintes publica co es:

SOUSA, F. R. C. ; MACHADO, J. C. Towards Elastic Multi-Tenant Database Replication with
Quality of Service. In: 5th IEEE/ACM International Conference on Utility and Cloud Computing (UCC) 2012.
SOUSA, F. R. C. ; MOREIRA, L. O. ; SANTOS, G. A C.; MACHADO, J. C. Quality of Service

for Database in the Cloud. In: 2st International Conference on Cloud Computing and Services Science (CLOSER), 2012.
1.4. Contribui c oes
SOUSA, F. R. C. ; MACHADO, J. C. An Approach to Database Replication in the Cloud. In:

26th Brazilian Symposium on Databases (SBBD), 2011.
SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. SLADB: Acordo de N vel de Servi co

para Banco de Dados em Nuvem. In: 26th Brazilian Symposium on Databases (SBBD), 2011.
SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. Computa c ao em Nuvem Aut onoma:

Oportunidades e Desaos. In: 1st Workshop on Autonomic Distributed Systems (WoSiDA), SBRC, 2011.
SOUSA, F. R. C. ; MOREIRA, L. O. ; MACEDO, J. A. F,; MACHADO, J. C. Gerenciamento de

Dados em Nuvem: Conceitos, Sistemas e Desaos. In: 25th Brazilian Symposium on Databases (SBBD), 2010.
SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. Computa c ao em Nuvem: Conceitos,

Tecnologias, Aplica c oes e Desaos. In: III Escola Regional de Computa c ao Cear a, Maranh ao, Piau (ERCEMAPI), 2009.
SOUSA, F. R. C.; MOREIRA, L. O.; MACHADO, J. C. Um Middleware para o Gerenciamento

de Dados XML Persistentes em Ambientes Distribu dos. In: 24th Brazilian Symposium on Databases (SBBD), 2009.
Embora as publica c oes abaixo n ao estejam diretamente relacionadas a esta tese, v arios conceitos de arquitetura e melhores pr aticas para aplica co es distribu das foram desenvolvidas e utilizadas nesta tese:
SILVA, T. L. C. ; NASCIMENTO, M. A. ; MACEDO, J. A. F. ; SOUSA, F. R. C. ; MACHADO,
J. C. Towards Non-Intrusive Elastic Query Processing in the Cloud. In: 4th International Workshop on Cloud Data Management (CloudDB), 2012.
MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C. Analisando o Desempenho de Banco de

Dados Multi-Inquilino em Nuvem. In: 27th Brazilian Symposium on Databases (SBBD), 2012.
REGO, P. A. L. ; COUTINHO, E. F. ; SOUSA, F. R. C. ; SOUZA, J. N. Alocac ao Auton omica

de Recursos para M aquinas Virtuais Baseada em Caracter sticas de Processamento. In: 2st Workshop on Autonomic Distributed Systems (WoSiDA), SBRC, 2012.
MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C. A Distributed Concurrency Control

Mechanism for XML Data. In: Journal of Computer and System Sciences (JCSS), 2011.
1.5. Estrutura da Tese
10
MOREIRA, E. J. R. ; SOUSA, F. R. C. ; MACHADO, J. C. RepliXP: Replica c ao Parcial de

Dados XML. In: 23th Brazilian Symposium on Databases (SBBD), 2008. (Best Poster).
Publica co es aceitas, submetidas ou em prepara ca o desenvolvidas em conjunto com esta tese:

COUTINHO, E. F. ; SOUSA, F. R. C. ; GOMES, D. G. ; SOUZA, J. N. Elasticidade em Computa c ao na Nuvem: Uma Abordagem Sistem atica. In: 31st Brazilian Symposium on Computer Networks and Distributed Systems (SBRC), 2013. (Aceito para Publica c ao).
SANTOS, G. A C. ; MAIA, G. J. R. ; MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C.

Scale-Space Filtering for Workload Analysis and Forecast. (Submetido para Publica c ao).
SILVA, T. L. C. ; NASCIMENTO, M. A. ; MACEDO, J. A. F. ; SOUSA, F. R. C. ; MACHADO,

J. C. Non-Intrusive Elastic Query Processing in the Cloud. (Submetido para Publica c ao).
SOUSA, F. R. C. ; MACHADO, J. C. RepliC: Elastic Multi-Tenant Database Replication with

Quality of Service. (Em Prepara c ao).
SOUSA, F. R. C. ; MACHADO, J. C. Strong Consistency for Muti-Tenant Database in the

Cloud. (Em Prepara c ao).
1.5
ESTRUTURA DA TESE
O restante desta tese est a organizado em seis cap tulos. As se co es seguintes apresentam um sum ario de cada um deles. Cap tulo 2: Gerenciamento de Dados em Nuvem O Cap tulo 2 introduz a computa ca o em nuvem e descreve o gerenciamento de dados neste ambiente, destacando diversos aspectos, tais como armazenamento, processamento de consultas, transa c oes e replica ca o. Cap tulo 3: Trabalhos Relacionados O Cap tulo 3 apresenta trabalhos que tratam da replica ca o de dados em nuvem. S ao 10
1.5. Estrutura da Tese
11
apresentados os requisitos para a replica ca o no contexto de computa c ao em nuvem, assim como uma an alise comparativa entre os trabalhos relacionados. Cap tulo 4: Replica c ao El astica para Banco de Dados Multi-Inquilino com Qualidade do Servi co O Cap tulo 4 apresenta RepliC, uma abordagem para a replica c ao de dados em nuvem, destacando uma camada de software para replicar dados. RepliC utiliza t ecnicas de elasticidade e migra c ao para garantir a qualidade do servi co em ambientes multi-inquilino. Tamb em e apresentada uma solu ca o desenvolvida para monitorar os servi cos de gerenciamento de dados em nuvem. Cap tulo 5: Consist encia para Banco de Dados Multi-Inquilino O Cap tulo 5 apresenta a estrat egia para a consist encia de banco de dados multi-inquilino utilizada pelo RepliC. S ao abordados diferentes algoritmos para tratar a sincroniza ca o entre as r eplicas em ambientes virtualizados e para o tratamento de falhas. Cap tulo 6: Avalia c ao Experimental Este cap tulo mostra detalhes sobre a implementa ca o e os experimentos realizados com a solu ca o proposta nos Cap tulos 4 e 5 em uma nuvem computacional real. Tamb em apresenta uma an alise dos resultados obtidos com o uso desta abordagem para replicar banco de dados em aplica co es submetidas para execu ca o na nuvem. Cap tulo 7: Conclus oes Por m, este cap tulo encerra o trabalho com uma an alise dos resultados obtidos e com uma discuss ao sobre dire co es para poss veis trabalhos futuros.
11
CAP ITULO 2
GERENCIAMENTO DE DADOS EM NUVEM
Este cap tulo descreve as caracter sticas do gerenciamento de dados em nuvem. Inicialmente, e apresentada uma introdu ca o sobre computa c ao em nuvem. Em seguida, s ao apresentados os requisitos do gerenciamento de dados e, por m, s ao detalhados os principais aspectos neste contexto. EM NUVEM COMPUTAC AO
2.1
A computa c ao em nuvem est a se tornando uma das palavras chaves da ind ustria de TI. A nuvem e uma met afora para a Internet ou infraestrutura de comunica ca o entre os componentes arquiteturais, baseada em uma abstra c ao que oculta ` a complexidade da infraestrutura. Cada parte desta infraestrutura e provida como um servi co e, estes s ao normalmente alocados em centros de dados, utilizando hardware compartilhado para computa ca o e armazenamento [Buyya et al., 2009]. Com isso, os usu arios est ao movendo seus dados e aplica co es para a nuvem e assim acess a-los de forma simples e de qualquer local. Isso e novamente um caso de utiliza c ao de processamento centralizado. Cen ario semelhante ocorreu h a aproximadamente 50 anos: um servidor de tempo compartilhado acessado por v arios usu arios. Contudo, nas u ltimas d ecadas, quando os computadores pessoais surgiram, os dados e as aplica co es come caram a ser utilizados localmente [Sousa et al., 2009]. Certamente o paradigma de computa c ao em nuvem n ao e uma repeti ca o da hist oria. H a 50 anos, os servidores de tempo compartilhado foram adaptados por quest oes de limita c ao de recursos. J a a computa ca o em nuvem surge da necessidade de construir infraestruturas de TI complexas, onde os usu arios t em que realizar instala ca o, congura ca o e atualiza c ao de sistemas de software. Al em disso, recursos de computa ca o cam obsoletos rapidamente. Assim, a utiliza ca o de plataformas computacionais de terceiros e uma solu ca o inteligente para os usu arios lidarem com infraestrutura de TI. Na computa c ao em nuvem os recursos de TI s ao fornecidos como um servi co, permitindo que os usu arios 12
2.1. Computa c ao em Nuvem
13
o acessem sem a necessidade de conhecimento sobre a tecnologia de base utilizada. Assim, usu arios e empresas passaram a acessar os servi cos sob demanda e independente de localiza ca o, o que aumentou a quantidade de servi cos dispon veis [Buyya et al., 2009]. A infraestrutura do ambiente de computa ca o em nuvem normalmente e composta por um grande n umero, centenas ou milhares de m aquinas f sicas ou n os f sicos de baixo custo, conectadas por meio de uma rede como ilustra a Figura 2.1. Cada m aquina f sica tem as mesmas congura c oes de software, mas pode ter varia c ao na capacidade de hardware em termos de CPU, mem oria e armazenamento em disco [Soror et al., 2010]. Dentro de cada m aquina f sica existe um n umero vari avel de m aquinas virtuais (VM) ou n os virtuais em execu ca o, de acordo com a capacidade do hardware dispon vel na m aquina f sica. Os dados s ao persistidos, geralmente, em sistemas de armazenamento distribu dos.
Figura 2.1 Ambiente de computa c ao em nuvem
A computa ca o em nuvem e uma evolu ca o dos servi cos e produtos de tecnologia da informa ca o sob demanda, tamb em chamada de Utility Computing [Brantner et al., 2008]. O objetivo da Utility Computing e fornecer componentes b asicos como armazenamento, processamento e largura de banda de uma rede como uma mercadoria atrav es de provedores especializados com um baixo custo por unidade utilizada. Usu arios de servi cos baseados em Utility Computing n ao precisam se preocupar com escalabilidade, pois a capacidade de armazenamento fornecida e praticamente innita. A Utility Computing prop oe fornecer disponibilidade total, isto e, os usu arios podem ler e gravar dados a qualquer tempo, sem nunca serem bloqueados; os tempos de resposta s ao quase constantes e n ao dependem do n umero de usu arios simult aneos, do tamanho do banco de dados ou de qualquer par ametro do sistema. Os usu arios n ao precisam se preocupar com backups, pois se os componentes falharem, o provedor e respons avel por substitu -los e tornar os 13
14
dados dispon veis em tempo h abil por meio de r eplicas [Brantner et al., 2008]. Uma raz ao importante para a constru c ao de novos servi cos baseados em Utility Computing e que provedores de servi cos que utilizam servi cos de terceiros pagam apenas pelos recursos que recebem, ou seja, pagam pelo uso. N ao s ao necess arios investimentos iniciais em TI e o custo cresce de forma linear e previs vel com o uso. Dependendo do modelo do neg ocio, e poss vel que o provedor de servi cos repasse o custo de armazenagem, computa ca o e de rede para os usu arios nais, j a que e realizada a contabiliza c ao do uso [Binnig et al., 2009]. Existem diversas propostas para denir o paradigma da computa ca o em nuvem [Vaquero et al., 2009]. O National Institute of Standards and Technology (NIST) argumenta que a computa ca o em nuvem e um paradigma em evolu c ao e apresenta a seguinte deni ca o: Computa c ao em nuvem e um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos computacionais congur aveis (por exemplo, redes, servidores, armazenamento, aplica c oes e servi cos) que podem ser rapidamente adquiridos e liberados com m nimo esfor co gerencial ou intera c ao com o provedor de servi cos [Mell and Grance, 2011]. O NIST descreve que a computa c ao em nuvem e composta por cinco caracter sticas essenciais, tr es modelos de servi co e quatro modelos de implanta c ao, detalhados a seguir. Informa co es sobre os principais sistemas de computa ca o em nuvem podem ser encontradas em [Sousa et al., 2009].
2.1.1
Caracter sticas Essenciais
As caracter sticas essenciais s ao vantagens que as solu co es de computa c ao em nuvem oferecem. Algumas destas caracter sticas, em conjunto, denem exclusivamente a computa c ao em nuvem e fazem a distin ca o com outros paradigmas. Por exemplo, a elasticidade r apida de recursos, amplo acesso e a medi ca o de servi co s ao caracter sticas b asicas para compor uma solu ca o de computa ca o em nuvem.
Self-service sob demanda : O usu ario pode adquirir unilateralmente recurso compu-
tacional, como tempo de processamento no servidor ou armazenamento na rede, na medida em que necessite e sem precisar de intera ca o humana com os provedores de cada servi co.
Amplo acesso : Recursos s ao disponibilizados por meio da rede e acessados atrav es
de mecanismos padronizados que possibilitam o uso por plataformas do tipo thin, 14
15
tais como celulares, laptops e PDAs.

Pooling de recursos : Os recursos computacionais do provedor s ao organizados em
um pool para servir m ultiplos usu arios usando um modelo multi-tenant ou multiinquilino, com diferentes recursos f sicos e virtuais, dinamicamente atribu dos e ajustados de acordo com a demanda dos usu arios. Estes usu arios n ao precisam ter conhecimento da localiza c ao f sica dos recursos computacionais, podendo somente especicar a localiza c ao em um n vel mais alto de abstra ca o, tais como o pa s, estado ou centro de dados.
Elasticidade r apida : Recursos podem ser adquiridos de forma r apida e el astica, em
alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e liberados, na retra c ao dessa demanda. Para os usu arios, os recursos dispon veis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento.
Servi co medido : Sistemas em nuvem automaticamente controlam e otimizam o uso
de recursos por meio de uma capacidade de medi c ao. A automa ca o e realizada em algum n vel de abstra c ao apropriado para o tipo de servi co, tais como armazenamento, processamento, largura de banda e contas de usu ario ativas. O uso de recursos pode ser monitorado e controlado, possibilitando transpar encia para o provedor e o usu ario do servi co utilizado.
2.1.2
Modelos de Servi cos
O ambiente de computa ca o em nuvem e composto de tr es modelos de servi cos. Estes modelos s ao importantes, pois eles denem um padr ao arquitetural para solu co es de computa ca o em nuvem.
Software como um Servi co (SaaS) : O modelo de SaaS proporciona sistemas de soft-
ware com prop ositos espec cos que s ao dispon veis para os usu arios por meio da Internet e acess veis a partir de v arios dispositivos do usu ario por meio de uma interface thin client como um navegador Web. No SaaS, o usu ario n ao administra ou controla a infraestrutura subjacente, incluindo rede, servidores, sistema operacional, armazenamento ou mesmo as caracter sticas individuais da aplica c ao, exceto congura co es espec cas. Como exemplos de SaaS podemos destacar os servi cos de Customer Relationship Management (CRM) da Salesforce e o Google Docs. 15
16
Plataforma como um Servi co (PaaS) : O modelo de PaaS fornece sistema operacio-
nal, linguagens de programa ca o e ambientes de desenvolvimento para as aplica co es, auxiliando a implementa c ao de sistemas de software. Assim como no SaaS, o usu ario n ao administra ou controla a infraestrutura subjacente, mas tem controle sobre as aplica co es implantadas e, possivelmente, as congura co es de aplica co es hospedadas nesta infraestrutura. Google App Engine [Ciurana, 2009] e Microsoft Azure [Azure, 2012] s ao exemplos de PaaS.
Infraestrutura como um Servi co (IaaS) : A IaaS torna mais f acil e acess vel o forneci-
mento de recursos, tais como servidores, rede, armazenamento e outros recursos de computa ca o fundamentais para construir um ambiente de aplica ca o sob demanda, que podem incluir sistemas operacionais e aplicativos. Em geral, o usu ario n ao administra ou controla a infraestrutura da nuvem, mas tem controle sobre os sistemas operacionais, armazenamento, aplicativos implantados e, eventualmente, seleciona componentes de rede, tais como rewalls. O Amazon Elastic Cloud Computing (EC2) [Robinson, 2008] e o Eucalyptus [Liu et al., 2007] s ao exemplos de IaaS.
2.1.3
Modelos de Implanta c ao
Quanto ao acesso e a disponibilidade, h a diferentes tipos de modelos de implanta ca o para os ambientes de computa c ao em nuvem. A restri ca o ou abertura de acesso depende do processo de neg ocios, do tipo de informa c ao e do n vel de vis ao desejado.
Nuvem privada : a infraestrutura de nuvem e utilizada exclusivamente por uma
organiza ca o, sendo esta nuvem local ou remota e administrada pela pr opria empresa ou por terceiros.
Nuvem p ublica : a infraestrutura de nuvem e disponibilizada para o p ublico em
geral, sendo acessado por qualquer usu ario que conhe ca a localiza ca o do servi co.
Nuvem comunidade : fornece uma infraestrutura compartilhada por uma comuni-
dade de organiza c oes com interesses em comum.

Nuvem h brida : a infraestrutura e uma composi c ao de duas ou mais nuvens, que
podem ser do tipo privada, p ublica ou comunidade e que continuam a ser entidades u nicas, mas conectadas por meio de tecnologia propriet aria ou padronizada que permite a portabilidade de dados e aplica co es. 16
2.2. Gerenciamento de Dados em Nuvem
17
2.2
GERENCIAMENTO DE DADOS EM NUVEM
SGBDs em nuvem est ao come cando a ser utilizados e t em o potencial de atrair clientes de diversos setores do mercado, desde pequenas empresas com o objetivo de reduzir o custo total, por meio da utiliza c ao de infraestrutura e sistemas de terceiros, at e grandes empresas que buscam solu co es para gerenciar milhares de m aquinas e atender um aumento inesperado de tr afego [Abadi, 2009]. A infraestrutura de SGBDs em nuvem possui v arias vantagens para os usu arios: (i) previsibilidade e custos mais baixos, proporcional ` a qualidade do servi co (QoS) e cargas de trabalho reais, (ii) complexidade t ecnica reduzida, gra cas a interfaces de acesso unicado e a delega ca o de tuning e administra ca o de SGBDs e (iii) elasticidade e escalabilidade, proporcionando a percep ca o de recursos quase innitos. Por outro lado, o provedor tem que garantir (i) ilus ao de recursos innitos, sob cargas de trabalho din amicas e (ii) minimizar os custos operacionais associados a cada usu ario [Curino et al., 2010a]. Diversos sistemas e arquiteturas est ao sendo desenvolvidos para suprir as novas demandas de aplica co es com diferentes requisitos de processamento e armazenamento [Abouzeid et al., 2009] [Dash et al., 2009]. Estes novos sistemas tentam fornecer uma vis ao de armazenamento e escalabilidade innitos, mas tem que tratar o problema de provisionar recursos. Este problema, que em SGBDs tradicionais consiste em determinar quais recursos s ao alocados para um u nico banco de dados, no ambiente em nuvem tornase um problema de otimiza c ao, onde se tem uma grande quantidade de usu arios, m ultiplos SGBDs em nuvem e grandes centros de dados. Isso fornece uma oportunidade sem precedentes para explorar a economia em escala, balanceamento de carga din amico e gerenciamento de energia. Esse aumento no n umero de abordagens dispon veis de SGBDs em nuvem agrava o problema da escolha, implanta c ao e solu co es de administra ca o para a gest ao de dados. Com isso, os SGBDs em nuvem est ao sendo disponibilizados como servi cos, que encapsulam a complexidade do gerenciamento por meio de formas de acesso simples e garantias de qualidade do servi co.
17
18
2.2.1
Requisitos do Gerenciamento de Dados em Nuvem
A deni ca o dos requisitos e fundamental no gerenciamento de dados como um servi co. [Curino et al., 2010a] apresentam uma lista de requisitos de um SGBD como um servi co da perspectiva do usu ario, do provedor e requisitos adicionais relacionados a ` nuvem p ublica conforme apresenta a Tabela 2.1.
Requisitos do Usu ario API simples com pouca congura c ao e administra c ao (ex. sem tuning) Alto desempenho (ex. vaz ao, escalabilidade) Alta disponibilidade e conan ca (ex. hot stand-by, backup) Acesso f acil ` a caracter sticas avan cadas (ex. snapshot, evolu c ao de esquema, minera c ao de dados) Requisitos do Provedor Atender o SLA do usu ario (ex. potencialmente sob carga de trabalho din amica) Limitar hardware e custo de energia (ex. multiplexa c ao intensiva) Limitar custo de administra c ao (ex. custo com pessoal) Requisitos extra de Nuvem P ublica Esquema de pre co: barato, previs vel e proporcional ao uso (elasticidade) Garantias de seguran ca e privacidade Baixa lat encia (relevante para OLTP e aplica c oes Web)
U1 U2 U3 U4
P1 P2 P3 P1 P2 P3
Tabela 2.1 Requisitos para SGBD como um Servi co [Curino et al., 2010a]
Da perspectiva do usu ario, a principal necessidade e um servi co de banco de dados com uma interface simples que n ao necessite de ajuste ou administra ca o. Trata-se de uma melhoria em rela ca o a `s solu c oes tradicionais que requerem t ecnicas para provisionar recursos, sele c ao de SGBDs em nuvem, instala c ao, congura ca o e administra ca o. O usu ario quer um desempenho satisfat orio, expresso em termos de lat encia e vaz ao, independente do tamanho da base de dados e das altera co es da carga de trabalho. Atualmente, esta e uma tarefa dif cil que exige uma ampla an alise do pessoal de TI, software caro e atualiza c oes de hardware. Alta disponibilidade e outro requisito fundamental, que normalmente e oferecido pelos SGBDs tradicionais, mas exige cuidados de congura c ao e manuten ca o. Finalmente, as caracter sticas avan cadas de gerenciamento do banco de dados, tais como snapshot, evolu ca o de esquema e minera ca o de dados devem estar prontamente dispon veis e simples de utilizar. Da perspectiva do provedor, e necess ario atender aos acordos de n vel de servi co, apesar da quantidade de dados e altera c oes na carga de trabalho. O sistema deve ser 18
19
eciente na utiliza ca o dos recursos de hardware. O modelo de servi co proporciona a oportunidade de fazer isso, por multiplexa ca o de cargas de trabalho e ajuste din amico da aloca ca o de recursos. Finalmente, a quantidade de tarefas de administra ca o deve ser minimizada. Para tanto, ferramentas sosticadas de an alise de carga de trabalho e centraliza c ao do gerenciamento de muitos bancos de dados devem ser utilizadas. Para provedores de servi cos em nuvem p ublica, existem requisitos adicionais, tais como esquema de pre co, seguran ca, privacidade e lat encia. Entretanto, estas quest oes n ao s ao espec cas de bancos de dados e podem ser abordadas com t ecnicas em desenvolvimento pela comunidade de computa c ao em nuvem.
2.2.2
Caracter sticas do Gerenciamento de Dados em Nuvem
Alguns trabalhos destacam caracter sticas espec cas do gerenciamento de dados em nuvem. Segundo [Voicu and Schuldt, 2009], no ambiente em nuvem, os dados s ao gerenciados em poucos centros de dados, utilizando recursos homog eneos e, mais recentemente, recursos heterog eneos. Estes dados s ao acessados por meio de APIs simples, SQL ou varia co es. Os SGBDs em nuvem devem dar suporte a atualiza co es concorrentes e transa c oes ACID ou varia co es. Em rela ca o a ` replica c ao, esta deve ser transparente para os usu arios e fornecer garantias de qualidade de servi co, obtidas pela cria c ao de r eplicas dos dados em um mesmo centro de dados ou em centros de dados diferentes, al em de permitir granulosidade na dos dados. Na distribui ca o de dados, os SGBDs em nuvem podem apresentar um controle global central ou distribu do, devem fornecer escalabilidade e suportar cargas de trabalho inesperadas. A Tabela 2.2 resume estas caracter sticas. Distribui c ao Ambiente Opera c oes para acesso aos dados Atualiza c ao Transa c oes Replica c ao Granulosidade da Replica c ao Controle Global Altera c oes Din amicas
Poucos centros de dados Recursos homog eneos em centros de dados API simples, SQL ou varia c oes Suporte ` as atualiza c oes concorrentes ACID ou varia c oes Garantia de QoS e transpar encia Fina Central ou Distribu do Escalabilidade e suporte para cargas de trabalho inesperadas
Tabela 2.2 Caracter sticas do Gerenciamento de Dados em Nuvem [Voicu and Schuldt, 2009]
Uma caracter stica essencial no ambiente de nuvem e o gerenciamento aut onomo 19
20
[Paton et al., 2009]. A computa ca o aut onoma e inspirada em sistemas biol ogicos para lidar com desaos de complexidade, dinamismo e heterogeneidade [Kephart and Chess, 2003], caracter sticas presentes nos ambientes de computa c ao em nuvem e, assim, fornece uma abordagem promissora neste contexto. Embora a computa c ao em nuvem apresente certas caracter sticas aut onomas como o provisionamento autom atico de recursos, seu objetivo e reduzir o custo dos recursos ao inv es de reduzir a complexidade do sistema [Sousa et al., 2011a]. Hardware e software dentro de nuvens podem ser automaticamente recongurados, orquestrados e estas modica co es s ao apresentadas ao usu ario como uma imagem poss u nica. E vel identicar tr es diferen cas em compara c ao com os sistemas tradicionais: interven c ao humana limitada, alta altern ancia na carga de trabalho e uma variedade de infraestruturas compartilhadas [Agrawal et al., 2008]. Na maioria dos casos, n ao haver a administradores de SGBDs em nuvem ou de sistemas para ajudar os desenvolvedores que acessam um banco de dados em nuvem, fazendo com que a solu c ao seja automatizada ao m aximo. Os usu arios podem variar a carga de trabalho habitual, necessitando de uma infraestrutura ecaz, pois esta ser a compartilhada por v arios usu arios ou inquilinos. De forma a possibilitar a consolida ca o da computa ca o em nuvem e dos SGBDs em nuvem, t ecnicas de virtualiza ca o tem se tornando populares para a implanta ca o destes sistemas e de outros sistemas de software [Soror et al., 2010]. A virtualiza ca o apoia a consolida ca o dos recursos nas empresas, pois permite que uma variedade de aplica c oes que funcionam com recursos de computa ca o dedicados sejam movidos para um pool de recursos compartilhados, o que ajuda a melhorar a utiliza ca o dos recursos f sicos, simplicar a administra ca o e reduzir custos para a empresa. Em [Soror et al., 2010] e apresentado um estudo sobre a sobrecarga de executar SGBDs em ambientes com m aquinas virtuais. De acordo com o estudo, a execu ca o n ao traz um alto custo de desempenho, visto que a virtualiza ca o introduz pouca sobrecarga para chamadas de sistema, tratamento de falta de p aginas e opera ca o de E/S no disco e isto n ao e traduzido em alta sobrecarga no tempo de execu c ao da consulta. Chamadas de sistema e falta de p aginas representam uma pequena fra c ao no tempo de execu ca o de uma consulta. Opera co es de E/S no disco correspondem a uma fra ca o signicativa do tempo, mas o retardo n ao e muito. Os resultados apresentados mostram que a sobrecarga m edia e menor do que 10%. Multi-Inquilino 20
21
Associado a ` virtualiza ca o, o compartilhamento de infraestruturas entre inquilinos no gerenciamento de dados possibilita uma utiliza ca o eciente dos recursos com baixo custo de opera ca o, al em de permitir que os SGBDs em nuvem possam gerenciar uma grande quantidade de inquilinos com padr oes de carga de trabalho irregulares [Elmore et al., 2011a]. O conceito de multi-inquilino, uma t ecnica para consolidar aplica co es de m ultiplos inquilinos em um u nico sistema e frequentemente utilizada para eliminar a necessidade de sistemas separados para cada inquilino. Um inquilino e denido de acordo com o contexto onde se encontra inserido; por exemplo, um inquilino pode ser usu ario de uma aplica ca o ou pode ser um banco de dados em rela ca o ao SGBD. SGBDs multi-inquilino tem sido utilizado para hospedar m ultiplos inquilinos dentro de um u nico sistema, permitindo o compartilhamento ecaz de recursos em diferentes n veis de abstra ca o e isolamento. Algumas caracter sticas do gerenciamento de dados em nuvem aumentam a relev ancia de outros modelos de SGBDs multi-inquilino. Para melhorar a compreens ao destes modelos, [Elmore et al., 2011a] prop oem uma nova classica ca o, como mostra a Tabela 2.3.
Modo de Compartilhamento 1. Hardware 2. M aquina Virtual 3. Sistema Operacional 4. Inst ancia 5. Banco de Dados 6. Tabela Isolamento VM Usu ario SO Inst ancia do BD BD Esquema Linha IaaS PaaS SaaS
x x x x x x
Tabela 2.3 Modelos de banco de dados multi-inquilino e correspond encia com a computa c ao em nuvem [Reinwald, 2010] [Elmore et al., 2011a]
Os modelos correspondentes ` as linhas 1-3 compartilham recursos nos n veis das mesmas m aquinas f sicas com diferentes n veis de abstra c ao; por exemplo, m ultiplas VMs, contas de SO de usu arios diferentes e diversas inst ancias dos SGBDs. Neste caso, n ao existe compartilhamento de recursos de banco de dados e as inst ancias dos SGBDs se mant em independentes. As linhas 4-6 envolvem o compartilhamento de processos de banco de dados em v arios n veis de isolamento, tais como: diferentes bancos de dados, esquema ou tablespace e tupla. Nos diferentes modelos, os dados dos inquilinos s ao armazenados de v arias formas. O modelo de hardware compartilhado utiliza a virtualiza ca o para chavear v arias VMs na mesma m aquina. Cada VM possui apenas um processo de 21
22
banco de dados, e uma VM inteira em geral corresponde a um inquilino. J a o modelo de tabela compartilhada armazena dados de v arios inquilinos em uma mesma tabela; e algumas tuplas de uma tabela correspondem a um inquilino. Os modelos das linhas 4-6 s ao os mais amplamente utilizados, pois permitem um melhor compartilhamento de recursos. Por outro lado, estes tr es modelos apresentam maior interfer encia entre os inquilinos do sistema, o que pode interferir no desempenho do sistema. No modelo da linha 4, um inquilino e um banco de dados separado, que melhora o isolamento. Contudo, o modelo 4 est a limitado ao n umero de estruturas que o SGBD pode manipular. Os modelos 5-6 utilizam um n umero menor de recursos dentre todos os modelos. Entretanto, estes modelos apresentam algumas desvantagens; por exemplo, o modelo 6 necessita de indexa ca o e otimiza c ao, j a que os inquilinos compartilham as mesmas tabelas, por em apresentam requisitos diferentes. Tamb em n ao existem estudos detalhados referentes aspectos de isolamento do banco de dados e seguran ca deste modelo. Armazenamento e Processamento de Consultas O armazenamento e processamento de consultas s ao pontos cr ticos no contexto da gest ao de dados em nuvem [Armbrust et al., 2009] [Silva et al., 2012]. Existem diversas abordagens para gerenciar dados em nuvem e cada sistema utiliza uma abordagem espec ca para persistir os dados. Dentre estas abordagens, podemos destacar novos sistemas de arquivos, frameworks e propostas para o armazenamento e processamento de dados. Google File System (GFS) e um sistema de arquivos distribu dos propriet ario desenvolvido pelo Google e projetado especialmente para fornecer acesso eciente e con avel aos dados usando grandes clusters de servidores [Ghemawat et al., 2003]. Em compara c ao com os sistemas de arquivos tradicionais, o GFS foi projetado e otimizado para ser executado em centros de dados e fornecer elevada vaz ao, baixa lat encia e toler ancia a falhas individual de servidores. Inspirado pelo GFS, o projeto de c odigo livre Hadoop File System (HDFS) [Hadoop, 2012] armazena grandes arquivos em v arias servidores e obt em a conabilidade por meio da replica ca o de dados. Similar ao GFS, os dados s ao armazenados em n os geogracamente distribu dos. Diferentemente de outras abordagens de sistemas de arquivos distribu dos, o armazenamento e processamento do HDFS s ao realizados em cada n o do sistema. Para apoiar o processamento distribu do de grandes conjuntos de dados em clusters foi introduzido pelo Google o framework MapReduce [Dean and Ghemawat, 2004]. 22
23
No modelo MapReduce cada opera c ao e composta por duas fun c oes: Map e Reduce. A fun ca o Map recebe uma por ca o do arquivo de entrada e, de acordo com a especica c ao do usu ario, emite um conjunto de tuplas intermedi arias no formato chave-valor. A fun c ao Reduce recebe um conjunto de valores associados a cada chave, chamados de blocos. O processamento, denido pelo usu ario, e realizado sobre cada bloco. Por m, cada fun c ao Reduce emite um conjunto de tuplas que s ao armazenadas em arquivos de sa da. O MapReduce gerencia o processamento atrav es de um processo master, cuja fun ca o e de orquestrar o processamento, gerenciar o processo de agrupamento de registros e distribuir os blocos de forma equilibrada. As tarefas de paralelismo, toler ancia a falhas, distribui ca o dos dados e balanceamento de carga s ao tratadas pelo MapReduce, que tamb em oferece transpar encia de replica c ao, distribui ca o e sincroniza ca o. Existem algumas implementa c oes de c odigo livre, dentre as quais se destaca o Hadoop MapReduce. O Hadoop possui v arios subprojetos, tais como o HBase, um sistema de banco de dados distribu do e o Pig, uma linguagem de uxo de dados e execu c ao para computa ca o paralela [Olston et al., 2008] [Thusoo et al., 2010]. Algumas propostas para o armazenamento e processamento utilizam a estrutura chave-valor em uma Distributed Hash Table (DHT) [DeCandia et al., 2007]. Este valor e a chave associada s ao armazenados de forma n ao normalizada, o que facilita a distribui c ao dos dados entre os n os do sistema, onde cada um destes n os possui parte dos dados. As APIs b asicas de acesso s ao simples com opera c oes tais como get(key) e put(key, value). APIs mais sosticadas permitem a execu ca o de fun co es denidas pelo usu ario no ambiente do servidor tais como execute(key, operation, parameters) ou mapreduce(keyList, mapFunc, reduceFunc). Para acessar ou modicar qualquer dado e necess ario fornecer poss uma chave, j a que a busca e realizada utilizando a igualdade. E vel realizar pesquisas com outros crit erios, tais como maior ou menor ou express oes booleanas. Neste caso, s ao utilizadas t ecnicas de busca exaustiva e a rvores B+ distribu das. Outra abordagem para armazenar e processar dados em nuvem consiste em utilizar uma estrutura de colunas ou arrays multidimensionais [Chang et al., 2006]. Os dados s ao organizados em tabelas e estas possuem diversas colunas. Cada coluna armazena um valor, acessado por meio de uma chave. Nesta abordagem, todos os valores de uma coluna s ao serializados em conjunto, os valores da coluna seguinte tamb em, e assim por diante. Com isso, os dados semelhantes, de mesmo formato, podem ser agrupados, auxiliando no armazenamento e na recupera ca o de informa ca o. Al em disso, diversas t ecnicas tais como a fragmenta c ao de dados e o processamento OLAP tornam-se mais ecientes para dados 23
24
gerenciados com esta abordagem. Outras abordagens para o armazenamento e processamento de consultas gerenciam os dados de tal sorte a reetir a estrutura de um documento ou tratam os dados na forma de grafos. Na abordagem orientada a documento, as t ecnicas s ao desenvolvidas para o armazenamento, modelagem, consulta e apresenta c ao de dados de forma a reetir a estrutura de um documento, que, em geral, n ao possui um esquema pr e-denido. Neste contexto, o formato JavaScript Object Notation (JSON) tem sido bastante utilizado, j a que e simples criar e manipular dados neste formato, facilitando a utiliza c ao desta abordagem. Na abordagem baseada em grafo [Rodriguez and Neubauer, 2010], os dados s ao gerenciados da seguinte forma: (i) n o (v ertice) : possui o mesmo conceito de uma inst ancia de um objeto com identicador u nico; (ii) relacionamento (arestas) : fornece uma liga c ao entre dois n os, sendo que estes n os possuem uma dire ca o e um tipo de relacionamento e (iii) propriedade (atributo) : s ao pares de strings chave-valor do objeto que podem existir tanto em um n o quanto em um relacionamento. Esta abordagem auxilia na modelagem de estruturas complexas e por meio da representa c ao utilizando grafos, a navega ca o entre os n os e os relacionamentos apresenta bons resultados de desempenho. Com o aumento no volume de dados e dos requisitos para extrair valores a partir destes dados, empresas necessitam gerenciar e analisar uma grande quantidade de dados e fornecer alto desempenho. Al em disso, os dados s ao gerenciados em v arias parti co es, o que diculta garantias transacionais, tais como atomicidade e isolamento. Para tratar estes problemas, diferentes solu c oes tem sido desenvolvidas combinando tecnologias como o MapReduce ou SGBDs paralelos [Abouzeid et al., 2009] [Olston et al., 2008]. O framework MapReduce e suas diversas implementa c oes como o Hadoop e o Drayd foram projetados para o processamento distribu do de tarefas e geralmente utilizam sistemas de arquivos como o GFS e o HDFS. Estes sistemas de arquivos s ao diferentes dos sistemas de arquivos distribu dos tradicionais em sua estrutura de armazenamento, padr ao de acesso e interface de programa c ao. Em particular, eles n ao implementam a interface padr ao POSIX, e, portanto, apresentam problemas de compatibilidade com aplica co es e sistemas de arquivos legados [Zhang et al., 2010]. Em rela c ao ao acesso aos servi cos de dados em nuvem, os provedores fornecem linguagens com restri co es, APIs simples e estas apresentam muitas limita co es, tais como a aus encia de consultas com jun co es, permitem apenas consultas por uma chave e n ao 24
25
suportam m ultiplas chaves. Considerando a grande quantidade de servi cos de dados em nuvem, os desenvolvedores necessitam utilizar APIs diferentes para cada servi co. Isso exige mais esfor co dos desenvolvedores e aumenta a complexidade na camada de aplica ca o [Cooper et al., 2009] [Agrawal et al., 2008]. Transa c oes Os conceitos de processamento de transa c oes s ao de extrema import ancia em ambientes centralizados e distribu dos, sendo que nestes u ltimos e comum haver dados replicados e alocados em locais geogracamente distantes. Estes conceitos denem o n vel de consist encia e integridade dos dados nestes ambientes. A utiliza ca o de transa c oes distribu das dene o controle do processamento de dados em todo ambiente de computa c ao em nuvem e tem a responsabilidade de garantir as propriedades ACID ou varia co es destas no ambiente. Neste sentido, necessita-se utilizar protocolos de replica c ao de dados, termina ca o distribu da e sincroniza ca o de acesso devido ` a natureza compartilhada dos recursos. Um ponto fundamental na constru c ao de sistemas distribu dos e considerado por todos os sistemas em nuvem e o teorema Consistency, Availability, Partition Tolerance (CAP) [Brewer, 2000] [Gilbert and Lynch, 2002]. Este teorema mostra que os sistemas distribu dos n ao podem assegurar as seguintes propriedades simultaneamente:
Consist encia : todos os n os tem a mesma vis ao dos dados ao mesmo tempo. Disponibilidade : falhas em n os n ao impedem os demais n os de continuar a operar. Toler ancia a parti c oes : o sistema continua a operar mesmo com a perda arbitr aria
de mensagens. Um sistema distribu do pode suportar apenas duas dessas tr es propriedades ao mesmo tempo. Como uma forma simples de entender um assunto complexo, o teorema CAP tornou-se um modelo popular para compreender aspectos de sistemas distribu dos. No entanto, esta simplicidade pode conduzir a interpreta co es incorretas do teorema. Estas propriedades n ao devem ser interpretadas no sentido de que o sistema e dispon vel ou consistente, mas que quando ocorre uma falha de rede, e necess ario escolher qual propriedade torna-se mais importante para o sistema. Em decorr encia deste teorema, algumas abordagens para o gerenciamento de dados em nuvem t em utilizado diferentes formas de consist encia. Uma alternativa e utilizar a 25
26
abordagem Basically Available, Soft state, Eventually consistent (BASE) [Pritchett, 2008], que e caracterizada pelo sistema ser basicamente dispon vel, pois este parece estar em funcionamento todo o tempo; em estado leve, j a que o sistema n ao precisa estar sempre consistente; e eventualmente consistente, que dene que o sistema torna-se consistente em um determinado momento. De acordo com [Vogels, 2009], existem duas formas de caracterizar a consist encia: do ponto de vista do programador/cliente - como os dados s ao observados e atualizados e do ponto de vista do servidor - como e processado o uxo das atualiza c oes por meio do sistema e que garantias este pode fornecer, no que diz respeito ` as atualiza co es. Por exemplo, podem-se denir alguns tipos de consist encia. A consist encia forte garante que ap os uma atualiza c ao ser conclu da, qualquer acesso subsequente fornecer a o valor atualizado. Por outro lado, na consist encia fraca, o sistema n ao garante que os acessos subsequentes ir ao retornar o valor atualizado. O per odo entre uma atualiza ca o e o momento no qual e garantido ao observador que este ir a sempre visualizar o valor atualizado e denominado janela de inconsist encia. A consist encia eventual e uma forma espec ca de consist encia fraca, na qual o sistema garante que, se nenhuma atualiza ca o for feita ao dado, todos os acessos ir ao devolver o u ltimo valor atualizado. Se n ao ocorrer nenhum erro, o tamanho m aximo da janela de inconsist encia pode ser determinado com base em fatores tais como os atrasos de comunica c ao, a carga do sistema e o n umero de r eplicas envolvidas do esquema de replica ca o. O sistema mais popular que implementa consist encia eventual e o Domain Name System (DNS). O modelo de consist encia eventual apresenta um n umero de varia co es tais como consist encia causal, consist encia leitura/escrita, consist encia de sess ao, consist encia de leitura/escrita mon otona. Estas varia c oes podem ser combinadas com o objetivo de tornar mais simples a constru ca o de aplica co es e permitir aos sistemas melhorarem a consist encia e fornecer maior disponibilidade. Sob o ponto de vista do servidor, o n vel de consist encia depende de como as atualiza co es s ao propagadas entre as r eplicas dos dados. Isto permite melhorar a taxa de transfer encia e fornecer escalabilidade. Contudo, o desenvolvedor deve estar consciente sobre quais garantias de consist encia s ao fornecidas pelo sistema na constru ca o de aplica co es. As solu co es em nuvem, em geral, oferecem consist encia fraca de dados, por exemplo, consist encia eventual. Este tipo de consist encia n ao permite a constru c ao de uma 26
27
ampla gama de aplica co es, tais como servi cos de pagamento e leil oes online, que n ao podem trabalhar com dados inconsistentes [Wei et al., 2009]. Neste contexto, aspectos de armazenamento de dados, processamento de consultas e controle transacional t em sido exibilizados por algumas abordagens para garantir a escalabilidade [Abadi, 2009]. Em [Wei et al., 2009] e apresentado uma solu c ao com suporte ` as transa c oes ACID e sem comprometer a escalabilidade mesmo na presen ca de falhas. Contudo, esta solu ca o necessita utilizar t ecnicas para remover a normaliza c ao dos esquemas, o que pode dicultar sua utiliza ca o. [Yang et al., 2009] prop oem uma plataforma para o gerenciamento de dados que pode escalar para uma grande quantidade de pequenas aplica co es e fornecer consist encia forte. Escalabilidade A nuvem e composta por uma enorme rede de m aquinas que necessita ser escal avel. A escalabilidade deve ser transparente para os usu arios, podendo estes armazenar seus dados na nuvem sem a necessidade de saber a localiza c ao dos dados ou a forma de acesso. Na nuvem, os desenvolvedores disp oem de ambientes escal aveis, mas eles t em que aceitar algumas restri co es sobre o tipo de software que se pode desenvolver, desde limita c oes que o ambiente imp oe na concep c ao das aplica c oes at e a utiliza c ao de SGBDs em nuvem do tipo chave-valor, ao inv es de SGBDs relacionais [Sousa et al., 2010]. De forma geral, e poss vel identicar duas dimens oes de escalabilidade: vertical e horizontal. Na escalabilidade vertical melhora-se a capacidade do hardware, incrementando individualmente os n os existentes, como por exemplo, por meio da disponibiliza c ao de um servidor com mais mem oria f sica ou da melhoria da largura de banda que conecta dois n os. Isto funciona razoavelmente bem para os dados, mas tem v arias limita co es tais como a aquisi c ao constante de hardware de maior capacidade, o que pode criar depend encia de fornecedores, aumentando os custos. A escalabilidade horizontal consiste em adicionar mais m aquinas ` a solu c ao atual de tal modo que seja poss vel distribuir as requisi co es entre estas m aquinas. No caso dos dados, pode-se agrup a-los por fun c oes e distribu -los por v arios SGBDs. Dessa forma, ocorre a fragmenta c ao dos dados em SGBDs em nuvem e cada um destes sistemas pode ser dimensionado de forma independente. Este tipo de escalabilidade oferece maior exibilidade, mas necessita de um planejamento espec co. A escalabilidade envolvendo dados e uma tarefa complexa, j a que a maioria dos
27
28
SGBDs em nuvem utiliza arquiteturas n ao compartilhadas, tornando a disposi ca o dos dados um ponto chave. Pode-se pensar que adicionar dinamicamente um novo servidor de banco de dados e t ao simples como dividir os dados em mais um servidor. Por exemplo, se h a dois servidores, cada um com 50% do total dos dados e se adiciona um terceiro servidor, poder-se-ia colocar um ter co dos dados em cada servidor, fazendo com que cada um dos tr es servidores casse com 33% dos dados. Entretanto, n ao e t ao simples assim, pois as consultas dos usu arios envolvem dados relacionados em diferentes servidores, o que exige o transporte dos dados, diminuindo o desempenho do sistema. Algumas solu co es em nuvem utilizam estruturas que auxiliam na distribui ca o dos dados, tais como DHT, que facilita a fragmenta ca o dos dados. De forma geral, a distribui ca o dos dados deve ser feita de forma a minimizar o transporte de dados, o qual adiciona um custo relevante ao processamento [Curino et al., 2010b]. Replica c ao de Dados Diferentemente das abordagens anteriores, onde se procurou evitar falhas por meio da utiliza ca o de hardware de custo elevado, as infraestruturas para nuvem s ao constru das em cima de hardware de baixo custo e com a suposi ca o de que m aquinas e redes podem falhar. Dessa forma, as solu c oes desenvolvidas devem lidar com falhas, j a que estas ir ao ocorrer em algum momento [Abadi, 2009]. A replica ca o de dados e a chave para tratar as falhas e melhorar o desempenho dos sistemas. Embora replica c ao seja um conceito intuitivo, sua implementa ca o requer t ecnicas sosticadas. Isso ocorre pela diculdade de manuten c ao da consist encia de r eplicas: quando um dado e alterado, suas r eplicas tamb em precisam ser atualizadas para manter um estado distribu do consistente [Saito and Shapiro, 2005]. Para manter a consist encia das r eplicas, s ao necess arios protocolos espec cos ou protocolos de replica ca o. [Gray et al., 1996] classicaram os protocolos de replica c ao de bancos de dados usando dois par ametros. O primeiro par ametro estabelece a forma de propaga c ao das modica co es, que pode ser de forma s ncrona ou ass ncrona. O segundo par ametro indica quem pode propagar as atualiza co es: uma r eplica espec ca, chamada de r eplica ou c opia prim aria ou qualquer uma das r eplicas, onde cada uma destas e denominada r eplica ativa. No protocolo de c opia prim aria, uma das r eplicas e escolhida como c opia ou r eplica prim aria e as outras c opias s ao r eplicas secund arias. Essa c opia prim aria gerencia as demais e envia a resposta da opera ca o para o cliente. Este protocolo apresenta um
28
29
baixo poder de processamento, j a que apenas a c opia prim aria realiza o processamento das atualiza co es. Al em disso, possui algumas desvantagens como a necessidade de escolha de uma nova c opia prim aria, no caso de falha, e tempos de respostas inaceit aveis, quando a prim aria torna-se um gargalo, pois ela centraliza todas as opera c oes de atualiza ca o, afetando a escalabilidade [Ozsu and Valduriez, 2011]. No protocolo de r eplicas ativas, qualquer uma das r eplicas pode executar opera co es de atualiza ca o. Essas opera c oes s ao executadas na mesma sequ encia por todas as r eplicas, produzindo resultados id enticos. N ao h a uma r eplica centralizadora, como no protocolo de c opia prim aria. Esse protocolo apresenta a vantagem de ser tolerante a falhas, j a que n ao existe uma c opia prim aria, e de apresentar melhor desempenho, pois v arias r eplicas podem ser acessadas de forma concorrente. A principal desvantagem desse protocolo e a necessidade de um mecanismo que assegure a consist encia entre as r eplicas quando atualiza co es s ao executadas [Kemme et al., 2010]. V arias estrat egias de propaga ca o de atualiza c ao entre as r eplicas podem ser adotadas. A escolha da melhor estrat egia depende da disponibilidade de comunica ca o, do grau de atualiza ca o e do volume das informa co es requisitadas pelos usu arios. As principais formas de propaga ca o s ao a s ncrona e a ass ncrona. Na forma s ncrona, quando uma r eplica e alterada, essa altera ca o e imediatamente aplicada a `s demais r eplicas dentro de uma transa ca o. Nesse caso, as r eplicas cooperam usando estrat egias para manter a consist encia das r eplicas. Sistemas de banco de dados s ncronos tradicionalmente utilizam o protocolo de two-phase commit (2PC). Neste protocolo, uma r eplica e encarregada de coordenar (fase 1) e conrmar (fase 2) a difus ao das modica co es para as demais r eplicas. Esse tipo de consist encia e muito dispendioso, principalmente quando o n umero de participantes e grande, pois o grau de comunica c ao na rede e alto, e todos os participantes devem estar conectados. Em [Gray et al., 1996] foi provado que o protocolo 2PC e impratic avel quando a quantidade de r eplicas e grande, pois o n umero de aborts, deadlocks e mensagens trocadas cresce de maneira exponencialmente proporcional ao n umero de r eplicas. Na forma ass ncrona, a altera c ao de uma r eplica n ao e propagada imediatamente, sendo realizada em um momento posterior, dentro de uma transa c ao separada [Bernstein and Newcomer, 2009]. A propaga c ao das atualiza c oes pode ser realizada de forma linear ou constante. A primeira consiste em enviar as atualiza c oes a cada transa ca o. A segunda consiste em denir intervalos de tempo congur aveis para o envio das atualiza co es. Geralmente, esse tipo de controle de consist encia e usado quando n ao h a 29
30
necessidade de se obter os dados totalmente atualizados. A replica ca o apresenta um conjunto de vantagens. Estas vantagens dependem dos padr oes de acesso, do sistema em quest ao e do estado da rede, dos dados replicados e do esquema de replica ca o utilizada. Um esquema de replica c ao descreve como um determinado item de dados e replicado, ou seja: n umero de r eplicas, onde essas r eplicas est ao alocadas e a escolha da t ecnica de propaga ca o de atualiza c ao que rege a consist encia. Existem duas t ecnicas para o desenvolvimento e aplica ca o destes esquemas de replica c ao: replica ca o est atica e replica ca o din amica [Doherty and Hurley, 2007]. Replica ca o est atica e o termo usado para descrever a replica ca o em sistemas onde os esquemas de replica c ao s ao desenvolvidos e aplicados em tempo de projeto e permanece praticamente inalterado at e que um administrador realize uma interven ca o manual. Em um sistema onde os atributos de tr afego e da rede s ao conhecidos e imut aveis, esquemas est aticos s ao adequados. Para sistemas em nuvem, que s ao altamente din amicos, uma administra ca o manual da replica ca o e complexa, pois esta envolve uma grande quantidade de recursos. A replica c ao din amica utiliza informa c oes do tr afego do usu ario para adaptar o esquema de replica ca o baseada no estado atual da rede, comportamento do usu ario e m etricas relacionadas ao desempenho. Um sistema que emprega a replica ca o din amica monitora seu ambiente para determinar como e quando alterar esquemas de replica ca o, e como essas altera co es afetam o sistema. Desta forma, os esquemas de replica c ao s ao desenvolvidos, ajustados e aplicados de modo a maximizar algum objetivo, por exemplo, o desempenho. A replica ca o din amica permite modicar os esquemas de replica c ao para lidar com a carga de trabalho e cada r eplica que comp oe o sistema pode receber parte desta carga. Al em do esquema de replica c ao din amica, utiliza-se uma pol tica, que e denida como um conjunto de regras de alto n vel para administrar, gerenciar e controlar a replica c ao din amica e o acesso aos recursos. As pol ticas s ao denidas por um administrador e fornecem informa c oes para cada n o do sistema em termos de recursos de processamento e armazenamento e par ametros de desempenho, por exemplo, capacidades m aximas de CPU, mem oria, armazenamento, limites superiores e inferiores de tempo de reposta e protocolos de replica ca o. Na nuvem, os administradores podem utilizar SLAs para especicar estas regras. Em rela ca o ao processo de replica c ao em nuvem, pode-se criar e iniciar novas 30
2.3. Conclus ao
31
r eplicas rapidamente por meio de m aquinas virtuais [Soror et al., 2010]. Isso permite manter muitas r eplicas por m aquina, o que reduz a quantidade total de armazenamento e, portanto, os custos associados. Dentre os protocolos utilizados na replica c ao de dados em nuvem pode-se destacar o de c opia prim aria, r eplica ativa, qu orum baseado em 2PC, Paxos [Chang et al., 2006] e o Gossip [DeCandia et al., 2007]. Por outro lado, como o uso de m aquinas virtuais auxilia a provisionar recursos [Rogers et al., 2010], pode-se explorar a possibilidade de escalar SGBDs para tratar com cargas de trabalho inesperadas por meio da utiliza ca o de novas r eplicas em m aquinas virtuais rec em-provisionadas [Soror et al., 2010]. Com isso, e necess ario garantir o acesso consistente ao SGBD durante e ap os o processo de replica ca o, coordenar solicita co es de roteamento para as m aquinas virtuais antigas e novas, desenvolver pol ticas para a provis ao de novas r eplicas e modelos mais abrangentes para o planejamento da capacidade necess aria para a nuvem [Aboulnaga et al., 2009]. CONCLUSAO
2.3
Este cap tulo apresentou uma introdu c ao a ` computa ca o em nuvem e as principais caracter sticas relacionadas ao gerenciamento de dados em nuvem. Tamb em foram apresentados os requisitos da gest ao de dados em nuvem. A compreens ao destas caracter sticas e extremamente importante e possibilita fazer escolhas adequadas no desenvolvimento de solu c oes para a computa ca o em nuvem. Al em disso, acredita-se que a combina ca o entre caracter sticas de diferentes abordagens pode conduzir ao surgimento de solu co es mais ecazes no gerenciamento de dados. O pr oximo cap tulo apresentado os trabalhos relacionados a esta tese.
31
CAP ITULO 3
TRABALHOS RELACIONADOS
Este cap tulo apresenta os trabalhos que tratam da replica c ao de banco de dados relacional em nuvem. Inicialmente, s ao apresentados os requisitos para a replica ca o de banco de dados no contexto de computa ca o em nuvem. Em seguida, descreve-se cada um desses trabalhos considerando os requisitos apresentados. Por m, um estudo comparativo e apresentado, destacando as limita c oes destes trabalhos. INTRODUC AO
3.1
Para compreender melhor as caracter sticas necess arias para uma solu ca o de replica c ao de banco de dados em nuvem foram identicados os requisitos referentes ` as aplica co es e aos usu arios, conforme mostra a Tabela 3.1. Estes requisitos consideram as caracter sticas da computa c ao em nuvem e do gerenciamento de dados para apoiar diferentes aplica c oes compartilhando os mesmos recursos.
Elasticidade Qualidade do Servi co Multi-inquilino Consist encia Adicionar e remover r eplicas Atender o SLA do usu ario Compartilhar recursos Garantir consist encia forte
Tabela 3.1 Requisitos para a replica c ao de banco de dados em nuvem
O provedor deve fornecer elasticidade por meio da adi c ao e remo ca o de r eplicas de acordo com a carga de trabalho. O provedor tamb em deve garantir a qualidade de servi co, denida por meio de um SLA com o usu ario, mesmo com altera c oes na carga de trabalho. Para tanto, deve-se fazer uso do gerenciamento autom atico, j a que os sistemas em nuvem utilizam e compartilham uma grande quantidade de recursos. Neste caso, os provedores de IaaS utilizam t ecnicas de virtualiza c ao para auxiliar o gerenciamento dos recursos e melhorar a exibilidade do sistema.
32
3.2. Trabalhos Relacionados
33
Para melhorar a utiliza c ao dos recursos, deve-se implementar o conceito de multiinquilino em algum n vel de compartilhamento, tais como SGBD, banco de dados ou tabela. Assim, o provedor reduz os custos, pois utiliza os recursos de forma eciente. Por m, as aplica c oes possuem requisitos de consist encia forte, pois muitas destas aplica co es est ao sendo migradas para a nuvem e foram desenvolvidas considerando este tipo de consist encia.
3.2
TRABALHOS RELACIONADOS
Existem muitas solu co es para a replica c ao de banco de dados em nuvem. A seguir, s ao apresentadas as solu c oes que est ao diretamente relacionadas a esta tese, ou seja, gerenciamento de dados para apoiar diferentes aplica co es, cada uma com pequenas quantidades de dados e que utilizam o modelo de dados relacional. SQL Azure [Mukerjee et al., 2011] O Microsoft SQL Azure e composto por um conjunto de servi cos para o armazenamento e processamento de dados em nuvem [Mukerjee et al., 2011] [Bernstein et al., 2011] [Azure, 2012]. O SQL Azure Database (SAD) e o principal componente do SQL Azure e foi constru do com base na tecnologia do SGBD relacional SQL Server [Bernstein et al., 2011]. Para permitir uma integra ca o transparente de aplica co es com o SQL Azure, o SAD suporta os principais comandos da linguagem Transact-SQL (T-SQL). Esta linguagem possui diversas caracter sticas, tais como manipula ca o de tabelas, ndices, fun co es, procedimentos e gatilhos. O SQL Azure implementa alta disponibilidade, toler ancia a falhas e o conceito de multi-inquilino no n vel de m aquina virtual. Cada banco de dados e implementado como uma parti ca o de dados replicados em m ultiplas m aquinas em um SQL Azure Datacenter. Com esse tipo de abordagem, SQL Azure fornece um gerenciamento autom atico de falhas e balanceamento de carga de trabalho. A Figura 3.1 mostra a arquitetura do SQL Azure. As m aquinas s ao organizadas em um anel l ogico, de modo que cada m aquina tem dois vizinhos e, assim, e poss vel detectar falhas de hardware. Um componente para detec ca o de falhas verica quando a r eplica prim aria ou secund aria torna-se indispon vel. O agente de recongura ca o gerencia o restabelecimento de r eplicas ap os uma falha de um n o. A estrat egia de replica ca o utiliza c opias dos itens de dados para fornecer a dis33
34
Figura 3.1 Arquitetura do sistema SQL Azure [Azure, 2012]
ponibilidade e implementa consist encia forte. No SQL Azure Database, um banco de dados individual possui um tamanho limitado de 50 GB. Para criar solu co es que armazenem banco de dados maiores do que este tamanho deve-se particionar os dados entre m ultiplos bancos de dados e utilizar consultas em paralelo para acess a-los. Entretanto, o particionamento dos dados e realizado de forma manual. O SQL Azure utiliza o protocolo de c opia prim aria [Kossmann et al., 2010]. Cada banco de dados possui tr es r eplicas: uma prim aria e duas secund arias. As opera c oes de escritas s ao enviadas para a r eplica prim aria e as altera c oes s ao propagadas para as r eplicas secund arias de forma ass ncrona. O SQL Azure utiliza uma estrat egia de qu orum, onde a r eplica prim aria e pelo menos uma das r eplicas secund arias devem conrmar a escrita no log antes que uma transa c ao seja considerada consolidada.
Plataforma Proposta por [Yang et al., 2009] Em [Yang et al., 2009] e apresentada uma plataforma para o gerenciamento de dados que implementa qualidade de servi co para diferentes aplica co es. Esta plataforma prop oe uma solu ca o completa de gerenciamento com o objetivo de melhorar a vaz ao e garantir alta disponibilidade. Para tanto, esta plataforma utiliza diversas t ecnicas, tais como replica ca o, migra ca o e consist encia. A Figura 3.2 mostra a arquitetura da plataforma. 34
35
Figura 3.2 Arquitetura da plataforma proposta por [Yang et al., 2009]
O sistema consiste de m aquinas em m ultiplos colos (similar ` as zonas de disponibilidade utilizadas em computa ca o em nuvem) geogracamente distribu dos. O banco de dados e replicado em v arios colos para prover recupera ca o de desastres. Os colos s ao coordenados por um controlador do sistema tolerante a ` falhas, que encaminha as requisi co es dos clientes para o colo apropriado, baseado em diferentes aspectos, tais como a congura c ao da replica c ao do banco de dados, a carga de trabalho, o estado do colo e a proximidade geogr aca entre o cliente e o colo. O controlador de colo gerencia um poll de m aquinas f sicas dispon veis e adiciona estas m aquinas para o aglomerado quando a qualidade denida n ao e atendida. Cada colo cont em um ou mais aglomerados de m aquinas. Cada aglomerado cont em uma pequena quantidade de m aquinas, tipicamente em um mesmo rack. Cada m aquina executa uma inst ancia de um SGBD e cada banco de dados e mapeado em duas ou mais m aquinas no aglomerado. As m aquinas do aglomerado s ao coordenadas por um controlador de aglomerados tolerante a ` falhas, que executa tr es tarefas: (a) gerenciar as conex oes e garantir que as m ultiplas r eplicas de cada banco de dados no aglomerado estejam sempre sincronizadas, (b) gerenciar falhas e (c) garantir que o SLA para cada banco de dados individual seja satisfeito. Neste trabalho tamb em s ao propostas deni c oes de SLA para banco de dados considerando vaz ao e disponibilidade. Estas deni co es tem o objetivo de alocar bancos de dados com o n umero m nimo de m aquinas de tal forma que os SLAs sejam satisfeitos. Em rela c ao a ` replica c ao de dados, esta plataforma utiliza protocolos tradicionais, tais 35
36
como o protocolo baseado em duas fases (2PC), o que pode comprometer o desempenho no ambiente de nuvem.
Re: FRESHiT [Voicu et al., 2010] Em [Voicu et al., 2010] e apresentado o Re: FRESHiT, um protocolo para a replica ca o de dados em nuvem. O FRESHiT e baseado no Re:GRIDiT [Voicu and Schuldt, 2009], um protocolo para o gerenciamento de dados em grades computacionais com acesso simult aneo aos dados replicados em diferentes locais, sem um componente global e com controle din amico de r eplicas. O Re:FRESHiT permite o acesso a dados atualizados e tamb em com diferentes n veis de consist encia. Dependendo do tipo de acesso, os s tios s ao divididos em s tios de atualiza ca o e leitura. As atualiza co es s ao propagadas dos s tios de atualiza ca o para os de leitura. Os s tios s ao organizados em estruturas de a rvores virtuais de acordo com o n vel de consist encia. Essas a rvores s ao automaticamente reorganizadas para melhorar o desempenho. Um mecanismo de roteamento e utilizado para garantir o acesso baseado no n vel de consist encia denido pelo usu ario e na carga de trabalho dos s tios. A Figura 3.3 mostra a arquitetura do Re: FRESHiT.
Figura 3.3 Arquitetura do sistema Re: FRESHiT [Voicu et al., 2010]
O primeiro n vel cont em os s tios de atualiza c ao e utiliza o protocolo de c opia prim aria com propaga ca o s ncrona. Este n vel possui um rel ogio de sincroniza ca o, necess ario para calcular o n vel de consist encia. No segundo n vel, os s tios de leitura mant em os dados atualizados na medida do poss vel. Existe um relacionamento 1-para-n entre o primeiro e o segundo n vel, assim como entre o segundo e o terceiro n vel. 36
37
No terceiro n vel, os s tios de leitura n ao s ao atualizados com frequ encia. Este u ltimo n vel e opcional, mas pode auxiliar na distribui c ao da carga de trabalho, principalmente se a quantidade de s tios de leitura no sistema e relativamente maior que a quantidade de s tios de atualiza c ao. O terceiro n vel pode ser organizado em uma estrutura hier arquica, formando uma estrutura de a rvore em profundidade. Para calcular o n vel de consist encia e utilizada uma fun c ao, onde este n vel e decrescente em rela c ao a `a rvore, da raiz para as folhas. Os s tios de leitura s ao capazes de determinar o n vel de consist encia com base no conhecimento local, ou seja, se a vers ao corrente dos dados pode ser usada para atender uma requisi ca o do usu ario ou se esta requisi ca o precisa ser roteada para um s tio predecessor na a rvore. Para tanto, o Re:FRESHiT possui quatro estruturas: (a) um cat alogo de r eplicas e usado para determinar as r eplicas dispon veis na rede (b) um reposit orio de r eplicas e usando para coletar o n vel de consist encia dos dados de forma peri odica ou sob demanda (c) um reposit orio de carga de trabalho e usado para determinar informa c oes sobre a carga aproximada e (d) las de propaga c ao s ao utilizadas para enleirar as altera c oes a serem aplicadas nos s tios inferiores das arvores.
SmartSLA [Xiong et al., 2011] Em [Xiong et al., 2011] e apresentado o SmartSLA, um sistema inteligente para o gerenciamento de recursos, que considera a carga de trabalho e o custo da infraestrutura. Este trabalho aborda o problema do gerenciamento de recursos virtuais em ambientes de computa ca o em nuvem e utiliza t ecnicas de aprendizagem de m aquina. Estas t ecnicas s ao utilizadas para descrever um modelo de desempenho do sistema por meio de uma abordagem orientada a dados. Um modelo preditivo e utilizado para a aloca c ao de recursos de hardware, tais como CPU e mem oria, assim como para denir o n umero de r eplicas do sistema. O SmartSLA assume que existem dois tipos de clientes, por exemplo, um ouro e um prata, que compartilham recursos de hardware. Como a demanda de carga de trabalho destes clientes mudam, SmartSLA adiciona ou remove r eplicas do banco de dados de forma a atender os requisitos dos clientes. O sistema e monitorado continuamente e os recursos alocados podem mudar periodicamente em cada intervalo de tempo. A Figura 3.4 mostra a arquitetura do SmartSLA. 37
38
Figura 3.4 Arquitetura do sistema SmartSLA [Xiong et al., 2011]
O SmartSLA consiste de dois componentes principais: m odulo de modelagem do sistema e m odulo de decis ao para aloca c ao de recursos. Os clientes fornecem informa co es sobre o custo e o desempenho para o SmartSLA. O m odulo de modelagem coleta dados sobre o estado dos bancos de dados e o m odulo de decis ao emite comandos para controlar os recursos. O m odulo de modelagem utiliza t ecnicas de aprendizagem de m aquina para construir um modelo que descreva o potencial de margem de lucro para cada cliente com diferentes aloca co es de recursos. Este m odulo utiliza um modelo baseado no relacionamento entre os recursos alocados e o custo esperado para cada cliente. O m odulo de decis ao de aloca ca o ajusta dinamicamente os recursos para maximizar os lucros. Em rela ca o a ` replica ca o, esta e implementada com o protocolo de c opia prim aria de forma ass ncrona e o SmartSLA trata apenas da quest ao do n umero de r eplicas necess arias para garantir o SLA.
Amazon Relational Database Service (RDS) [Amazon, 2012] O Amazon Relational Database Service (RDS) [Amazon, 2012] e um sistema para a cria ca o e acesso a um SGBD relacional em nuvem. Com isso, os usu arios n ao precisam se preocupar em gerenciar a implanta c ao, patches, atualiza co es de software e backups. O Amazon RDS possui diferentes congura co es, de acordo com o tamanho de inst ancia denida. A Figura 3.5 mostra a arquitetura do Amazon RDS.
38
39
Figura 3.5 Arquitetura do sistema Amazon RDS [Amazon, 2012]
O Amazon RDS utiliza o protocolo de r eplica prim aria, onde uma r eplica recebe todas as atualiza c oes e as propaga para as r eplicas de leitura. Com isso, o Amazon RDS e capaz de tratar o aumento de atualiza c oes apenas pelo incremento da capacidade da r eplica prim aria. A replica ca o tamb em e utilizada entre os centros de dados da Amazon para aumentar a disponibilidade.
Relational Cloud [Curino et al., 2011a] O Relational Cloud e um SGBD como um servi co desenvolvido com o objetivo de consolidar as funcionalidades de gerenciamento de dados em nuvem [Curino et al., 2011a]. O Relational Cloud foca nos conceitos de multi-inquilino, escalabilidade e privacidade dos dados. Para tanto, utiliza uma abordagem orientada a carga de trabalho para tratar a aloca ca o de inquilinos, algoritmos de particionamento dos dados baseados em grafos e um esquema de seguran ca ajust avel para permitir que consultas SQL sejam executadas sobre dados criptografados. O Relational Cloud fornece disponibilidade por meio de replica c ao transparente, particionamento de dados autom atico e migra c ao de dados em tempo de execu ca o, al em de oferecer transa c oes distribu das serializ aveis. A Figura 3.6 mostra a arquitetura do Relational Cloud. A comunica c ao entre as aplica co es e o Relational Cloud e realizada por meio de interfaces padr ao ou protocolos
39
40
conhecidos, tais como a interface JDBC [Curino et al., 2010a]. As consultas SQL recebidas s ao enviadas para um roteador, respons avel por analisar e vericar os metadados do banco de dados e determinar o plano de execu c ao. Por m, o sistema de transa co es distribu das distribui a carga de trabalho, assegurando a serializabilidade e o tratamento de falhas.
Figura 3.6 Arquitetura do sistema Relational Cloud [Curino et al., 2011a]
Por meio do monitoramento do desempenho e da carga de trabalho, o Relational Cloud ajusta o particionamento dos dados e as op co es de localiza ca o em tempo de execu ca o [Curino et al., 2011b]. Falhas no sistema e altera c oes de carga de trabalho exigem a evolu ca o do esquema de particionamento e aloca c ao em tempo de execu ca o. Para tanto, utiliza-se a migra ca o dos dados baseada nas inst ancias do SGBD, o que melhora o desempenho do sistema. No Relational Cloud, cada m aquina executa v arias inst ancias de um SGBD. Cada banco de dados e dividido em parti co es l ogicas por meio de t ecnicas de particionamento. Estas parti co es s ao armazenadas em grupos de r eplicas com o objetivo de garantir a disponibilidade e toler ancia a falhas. Um grupo de r eplica consiste de v arias inst ancias do banco de dados sendo que cada uma armazena c opia dos dados de uma parti ca o l ogica. Em rela ca o ao particionamento, este sistema prop oe um novo algoritmo com o objetivo de minimizar a probabilidade de uma determinada opera c ao ter que acessar m ultiplos s tios para responder uma requisi ca o. O Relational Cloud n ao detalha a estrat egia de replica ca o adotada, apenas destaca sua utiliza ca o em conjunto com o particionamento de dados [Curino et al., 2010b].
40
41
Trabalho Proposto por [Savinov and Daudjee, 2010] Em [Savinov and Daudjee, 2010] e apresentado um estudo sobre a replica ca o de dados em ambientes virtualizados com foco no provisionamento quando a c opia prim aria est a sobrecarregada ou falha. Este trabalho utiliza um balanceador de cargas, uma c opia prim aria e v arias c opias secund arias. A Figura 3.7 mostra a arquitetura do trabalho, destacando a estrutura e o relacionamento entre os componentes. Linhas s olidas mostram a transfer encia de consultas e seus respectivos resultados, enquanto linhas tracejadas representam o caminho para as atualiza co es.
Figura 3.7 Arquitetura da abordagem proposta por [Savinov and Daudjee, 2010]
Transa co es submetidas pelos clientes para o sistema s ao recebidas pelo balanceador de cargas. Se a transa ca o e de atualiza c ao, esta e encaminhada para a c opia prim aria, que processa todas as atualiza co es do sistema. Se a transa ca o e de leitura, esta e encaminhada para as c opias secund arias. Um processo de propaga ca o na c opia prim aria coleta um lote de atualiza c oes periodicamente dos arquivos de log e envia este lote para as c opias secund arias. Transa co es de atualiza co es s ao mantidas em um arquivo de log com identicador u nico e incrementado monotonicaamente, representando a ordem na qual as atualiza co es foram aplicadas na c opia prim aria. O balanceador de cargas mantem uma c opia das u ltimas transa co es submetidas ao sistema para tratar os casos de falhas da c opia prim aria. As r eplicas s ao adicionadas no sistema a qualquer momento. Um dump e usado para recuperar as informa co es da c opia prim aria e atualizar as c opias secund arias. Para distribuir a carga de trabalho, o balanceador considera o tempo de resposta das requisi co es. No caso de falha na c opia prim aria, o balanceador de cargas seleciona a r eplica mais atualizada e aplica todas as transa c oes contidas na la, mantidas pelo balanceador, 41
42
enquanto a c opia prim aria n ao est a operacional.
CloudDB AutoAdmin [Sakr et al., 2011] CloudDB AutoAdmin e um framework para o gerenciamento autom atico da camada de banco de dados [Sakr et al., 2011] [Sakr and Liu, 2012]. Este framework permite ajustar e adaptar dinamicamente os recursos para garantir a qualidade do servi co. A Figura 3.8 mostra a arquitetura do CloudDB AutoAdmin. O m odulo do controle recebe as congura co es de m etricas de SLA denidas para a aplica c ao. Estas congura c oes s ao especicadas na linguagem XML e permitem denir as condi c oes para satisfazer o SLA, tais como tempo de resposta e vaz ao. Este m odulo verica continuamente o SLA de acordo com as informa c oes dos bancos de dados. O m odulo de monitoramento coleta informa co es sobre a execu c ao dos bancos de dados e envia informa c oes para o m odulo de controle. O m odulo de a ca o executa as a c oes para garantir as regras denidas no SLA. Estas a c oes incluem o balanceamento da carga de trabalho e a adi c ao/remo c ao de r eplicas.
Figura 3.8 Arquitetura do sistema CloudDB AutoAdmin [Sakr et al., 2011]
Em rela c ao a ` replica ca o, o CloudDB AutoAdmin utiliza a estrat egia de c opia prim aria com a replica ca o total do banco de dados [Zhao et al., 2012]. Apesar de permitir a elasticidade pela adi c ao e remo c ao de r eplicas, os experimentos realizados consideram apenas cen arios com a adi c ao de r eplicas [Liang Zhao and Liu, 2012]. Por m, o CloudDB AutoAdmin n ao utiliza nenhum modelo multi-inquilino, fundamental para compartilhar 42
43
recursos e reduzir os custos.
Dolly [Cecchet et al., 2011] Em [Cecchet et al., 2011] e apresentado Dolly, um sistema para provisionamento din amico de r eplicas de banco de dados em nuvem. Este sistema foca na virtualiza ca o e tem como base utilizar clonagem e snapshots de m aquinas virtuais de forma inteligente. Neste sistema, cada r eplica do banco de dados e executada em uma m aquina virtual isolada. Em vez de utilizar mecanismos tradicionais de banco de dados para criar novas r eplicas, e clonada toda a m aquina virtual de uma r eplica existente, incluindo o ambiente operacional, o SGBD com todas as suas congura c oes, ajustes e o pr oprio banco de dados. A m aquina virtual e iniciada em um novo servidor, resultando em uma nova r eplica, que sincroniza o estado com outras r eplicas antes de processar solicita co es do usu ario. Este trabalho se concentra na camada de banco de dados e aborda o problema do provisionamento como duas tarefas: (i) quando alterar a capacidade baseada na carga de trabalho corrente e tend encias futuras e (ii) como iniciar e remover as r eplicas. Para tratar estas tarefas, Dolly estima o tempo de lat encia para iniciar uma nova r eplica de banco de dados e usa este tempo para realizar o provisionamento de forma antecipada. utilizado um algoritmo inteligente que considera as fun E co es de custo especicadas pelo usu ario para otimizar a sobrecarga de adicionar ou remover r eplicas. A Figura 3.9 mostra a arquitetura do sistema Dolly. Sistemas de predi c ao observam o comportamento do sistema e auxiliam na demanda de capacidade futura. Dolly possui quatro componentes principais: provisionamento de capacidade, escalonador de snapshot, escalonador geral e desalocador de recursos. Para calcular a capacidade por um determinado prazo, e necess ario executar a c oes de provisionamento que considerem o tempo necess ario para replicar o estado do banco de dados. Como as r eplicas t em de ser geradas a partir de um snapshot do banco, o escalonador decide quando novos snapshots do banco devem ser obtidos. Alguns recursos, tais como backups podem se tornar obsoletos com o tempo e s ao desalocados. O escalonador orquestra e executa as requisi co es dos outros componentes. O processo de execu ca o do sistema consiste em um conjunto de etapas. Primeiro, um comando para adicionar uma nova r eplica e emitido a partir do console de gerenciamento para a camada de replica ca o. Um ponto de controle e criado no log transacional 43
44
Figura 3.9 Arquitetura do sistema Dolly [Cecchet et al., 2011]
e uma r eplica e removida temporariamente do aglomerado de banco de dados para realizar um snapshot do banco de dados. Assim que o snapshot e realizado, esta r eplica e sincronizada novamente, reexecutando as opera co es de escrita no log transacional desde o ponto de controle e adicionada ao aglomerado de banco de dados. Uma nova r eplica e iniciada em uma m aquina separada e um snapshot e aplicado a esta nova r eplica usando uma opera ca o de restaura ca o. Por m, as atualiza c oes que ocorreram desde que o snapshot foi realizado s ao reexecutados a partir do log transacional para sincronizar a nova r eplica e torn a-la atualizada em rela c ao as demais r eplicas do sistema. Dolly utiliza a estrat egia de c opia prim aria e trata a elasticidade, mas n ao aborda a quest ao multi-inquilino.
FlurryDB [Mior and de Lara, 2011] FlurryDB e uma abordagem para replica c ao de banco de dados baseada em t ecnicas de clonagem de m aquinas virtuais [Mior and de Lara, 2011]. Esta abordagem cria uma c opia da m aquina virtual e utiliza um roteador para replicar as opera c oes do banco de dados executadas durante a clonagem da m aquina com o objetivo de manter a consist encia do banco de dados. Os clientes se conectam a um roteador que realiza o balanceamento
44
45
da carga de trabalho e o gerenciamento das opera co es do banco de dados. Estas opera co es s ao envidas para um proxy presente em cada m aquina. Para replicar uma m aquina, o FlurryDB cria um clone da m aquina prim aria e aplica as opera c oes realizadas durante a clonagem. A Figura 3.10 mostra a arquitetura do FlurryDB.
Figura 3.10 Arquitetura do sistema FlurryDB [Mior and de Lara, 2011]
FlurryDB utiliza a estrat egia de c opia prim aria para replicar a m aquina. Apesar de replicar o banco de dados rapidamente, esta abordagem requer um hypervisor ou monitor de m aquina virtual espec co para tratar do processo de clonagem, o que diculta sua utiliza ca o. Al em disso, o FlurryDB n ao trata quest oes de elasticidade e multi-inquilino.
RemusDB [Minhas et al., 2011] RemusDB e um sistema para fornecer alta disponibilidade para SGBDs em ambientes virtualizados [Minhas et al., 2011]. RemusDB utiliza pontos de verica c ao (checkpoint ) para enviar as altera co es do servidor prim ario para o servidor de backup. A Figura 3.11 mostra a arquitetura do RemusDB. O servidor ativo trata todas as requisi co es dos clientes durante a opera ca o normal. Pontos de verica c ao da m aquina, incluindo mem oria, disco e conex oes de rede ativas s ao continuamente salvos no servidor em espera. As requisi co es s ao executadas e consolidadas no servidor ativo antes do envio para o servidor em espera. Para concluir o processo de replica c ao, estes pontos s ao executados no servidor em espera. Em caso de falha do servidor ativo, o servidor em espera recebe as requisi co es. 45
3.3. An alise Comparativa entre os Trabalhos Relacionados
46
Figura 3.11 Arquitetura do sistema RemusDB [Minhas et al., 2011]
Este processo utiliza t ecnicas de failover para garantir as mesmas congura co es de rede e e transparente para o usu ario. Al em disso, o RemusDB garante a consist encia, pois transfere o estado completo da m aquina, incluindo o estado do banco de dados e o estado interno do SGBD, que cont em informa co es de buer e bloqueios. Esta estrat egia garante que o servidor em espera possui exatamente o mesmo estado do servidor ativo, n ao afetando as conex oes dos clientes. RemusDB utiliza a estrat egia de c opia prim aria para a replica ca o e fornece alta disponibilidade para SGBDs, o que melhora a qualidade do servi co. Contudo, esta abordagem requer modica c ao no hypervisor da m aquina virtual para suportar a replica ca o do SGBD. Em rela ca o a ` elasticidade e t ecnicas multi-inquilino, o RemusDB n ao aborda estes aspectos. ANALISE COMPARATIVA ENTRE OS TRABALHOS RELACIONADOS
3.3
Esta an alise comparativa considerou os requisitos denidos para a replica ca o de banco de dados em nuvem. Os sistemas SQL Azure, Dolly e Amazon RDS implementam as caracter sticas de elasticidade completamente, pois adicionam e removem r eplicas de acordo com a carga de trabalho. J a os sistemas Relational Cloud, Flurry e CloudDB AutoAdmin tratam apenas da adi ca o de novas r eplicas. A plataforma proposta por [Yang et al., 2009] compartilha recursos, mas n ao especica o modelo multi-inquilino utilizado. O Relational Cloud implementa diferentes
46
3.3. An alise Comparativa entre os Trabalhos Relacionados
47
inst ancias de SGBD, mas as t ecnicas desenvolvidas por este sistema consideram apenas m aquinas f sicas, o que inviabiliza sua utiliza ca o em ambientes virtualizados. J a o SQL Azure compartilha recursos apenas por meio de parti c ao de dados. O smartSLA trabalha com um n vel de multi-inquilino de m aquina virtual, o que n ao contribui para uma utiliza ca o eciente de recursos, aumentando os custos. Nenhum dos trabalhos considera a replica ca o utilizando o modelo multi-inquilino no n vel de banco de dados. Alguns trabalhos, tais como Dolly, smartSLA e CloudDB AutoAdmin implementam qualidade de servi co considerando caracter sticas de desempenho, tais como tempo de resposta e vaz ao. O SQL Azure e Amazon RDS abordam parcialmente a qualidade de servi co, pois contemplam somente a disponibilidade. Os sistemas Dolly, RemusDB e FlurryDB apresentam estrat egias ecientes para replicar o banco de dados, pois utilizam t ecnicas para clonar as VMs juntamente com o SGBD. Contudo, estes sistemas n ao podem ser usados em provedores p ublicos, como o da Amazon, pois necessitam de altera c oes no ambiente de virtualiza ca o. Estes trabalhos implementam consist encia forte, mas utilizam protocolos de replica ca o tradicionais, como o de r eplica prim aria e o 2PC, o que pode comprometer a disponibilidade e o desempenho. Nenhum dos trabalhos relacionados estudados atende totalmente os requisitos denidos neste trabalho no que se refere ` a replica ca o de dados, requisitos estes contemplados pelo RepliC. A Tabela 3.2 apresenta um resumo deste comparativo. Requisitos Trabalhos
[Yang et al., 2009] Re: FRESHiT [Voicu et al., 2010] [Savinov and Daudjee, 2010] SQL Azure [Mukerjee et al., 2011] Dolly [Cecchet et al., 2011] smartSLA [Xiong et al., 2011] Rel. Cloud [Curino et al., 2011a] Flurrydb [Mior and de Lara, 2011] CloudDB [Sakr et al., 2011] RemusDB [Minhas et al., 2011] AmazonRDS [Amazon, 2012]
Elasticidade Multiinquilino Qualidade de Servi co Consist encia
VM
sim
sim sim apenas apenas apenas apenas sim
VM adi c ao adi c ao adi c ao adi c ao VM sim
apenas disp. sim sim
sim apenas disp.
sim sim sim sim sim sim sim sim sim sim sim
Tabela 3.2 An alise comparativa entre os trabalhos relacionados
47
3.4. Conclus ao
48
3.4
CONCLUSAO
Neste cap tulo foram discutidas as principais abordagens encontradas na literatura para a replica c ao de banco de dados relacional em nuvem. Foram destacados os requisitos para a replica ca o neste ambiente e uma an alise comparativa detalhada destas abordagens tamb em foi apresentada. Apesar da grande quantidade de trabalhos relacionados, nenhum destes contempla os diversos aspectos da replica ca o de dados em nuvem, pontos estes previsto neste trabalho. O pr oximo cap tulo apresenta a abordagem RepliC e s ao explanadas suas caracter sticas, sua especica c ao e os algoritmos desenvolvidos.
48
CAP ITULO 4
ELASTICA REPLICAC AO PARA BANCO DE DADOS MULTI-INQUILINO COM QUALIDADE DO SERVIC O
Este cap tulo descreve RepliC, uma abordagem para a replica c ao de banco de dados multiinquilino em nuvem, cujo prop osito e garantir a qualidade de servi co com a utiliza ca o eciente de recursos por meio da adi ca o e remo c ao de r eplicas. Tamb em s ao apresentados o modelo multi-inquilino utilizado neste trabalho, um modelo para qualidade de servi co de banco de dados e os algoritmos para replica c ao que tratam da elasticidade. INTRODUC AO
4.1
RepliC e uma abordagem para a replica ca o de dados em nuvem com foco na garantia da qualidade de servi co, elasticidade e na utiliza c ao eciente dos recursos sob uma carga de trabalho vari avel. Baseado em t ecnicas de monitoramento, RepliC modica o estado do sistema e s ao realizadas modica co es na estrat egia de replica c ao quando o desempenho do sistema n ao est a de acordo com o SLA denido. A elasticidade permite ajustar dinamicamente a capacidade do sistema pela adi ca o e remo c ao de r eplicas de acordo com a carga de trabalho. Para melhorar a utiliza c ao dos recursos, RepliC utiliza o modelo multi-inquilino de inst ancia. O gerenciamento da infraestrutura e autom atico, auxiliando na gest ao da estrat egia de replica ca o. Esta abordagem implementa consist encia forte, pois muitas aplica c oes trabalham com esse tipo de consist encia. O modelo de dados relacional e utilizado pelo RepliC, visto que este modelo e amplamente utilizado em diferentes aplica c oes em nuvem [Kossmann et al., 2010].
4.2
MODELO DE BANCO DE DADOS MULTI-INQUILINO
Existem diversos modelos de banco de dados multi-inquilino, cada um com vantagens e desvantagens, conforme apresentado no Cap tulo 2. Nesta tese, optou-se por utilizar o modelo multi-inquilino de inst ancia, pois e o mais utilizado e apresenta a melhor rela ca o 49
4.2. Modelo de Banco de Dados Multi-Inquilino
50
entre a utiliza c ao de recursos, desempenho e seguran ca [Barker et al., 2012]. De acordo com o modelo utilizado, um banco de dados corresponde a um inquilino no sistema, conforme mostra a Figura 4.1. Neste modelo, cada VM possui uma inst ancia de um SGBD. Por sua vez, cada SGBD cont em uma quantidade vari avel de inquilinos, de acordo com a capacidade dos recursos na VM e da carga de trabalho. Por exemplo, o SGBD da V M4 possui os inquilinos T1 , T4 e T6 . Neste trabalho, um inquilino e representado por uma r eplica do banco de dados no sistema.
Figura 4.1 Modelo multi-inquilino utilizado pelo RepliC.
4.2.1
Interfer encia entre Inquilinos
O modelo multi-inquilino utilizado no RepliC pode apresentar interfer encia entre os inquilinos, conforme apresentado em nosso estudo [Moreira et al., 2012]. Uma interfer encia ocorre quando o aumento na carga de trabalho de um inquilino altera o desempenho de outros inquilinos que est ao sendo executados no mesmo SGBD. Com isso, a escolha do SGBD ajuda a diminuir as interfer encias. Al em disso, para diminuir tais interfer encias, e necess ario identicar o n vel de intera ca o entre os inquilinos e, consequentemente, melhorar a aloca c ao dos inquilinos de acordo com suas interfer encias. Para tanto, e necess aria uma an alise do perl do inquilino. Tamb em e importante isolar inquilinos suscet veis a este problema. Alguns trabalhos utilizam um modelo anal tico ou executam experimentos reais para avaliar a aloca ca o de recursos e diminuir as interfer encias [Ahmad and Bowman, 2011] [Lang et al., 2012]. Contudo, estas abordagens ocasionam uma sobrecarga signicativa com a altera ca o da carga de trabalho. Nestas abordagens, faz-se necess ario recalibrar e revalidar o modelo ou executar um novo conjunto de experimentos para selecionar uma nova aloca ca o de recursos. Durante o per odo de adapta ca o, o sistema pode ser executado 50
4.2. Modelo de Banco de Dados Multi-Inquilino
51
com uma congura c ao ineciente e n ao garantir a qualidade [Vasi c et al., 2012]. Al em disso, estas abordagens consideram o conhecimento pr evio de informa co es sobre a carga de trabalho, componentes de hardware, software e as intera co es entre todos estes componentes [Tsakalozos et al., 2011]. Contudo, o ambiente de computa ca o em nuvem e din amico e estas informa co es s ao obtidas apenas em tempo de execu ca o. Para tratar este problema, RepliC utiliza uma estrat egia baseada em DejaVu [Vasi c et al., 2012], um framework para a aprendizagem e reutiliza c ao de aloca ca o de recursos. Este framework coleta informa c oes sobre o estado do sistema durante a execu ca o e reutiliza estas informa co es para garantir uma aloca c ao aproximada para futuras cargas de trabalho semelhantes a `s cargas anteriores. Esta estrat egia e independente de componentes de hardware, software e pode ser utilizada por qualquer infraestrutura. RepliC monitora os recursos e armazena informa co es sobre os inquilinos, suas cargas de trabalho e os limites dentro dos quais eles podem ser executados sem viola c ao do SLA. A interfer encia entre inquilinos e ocasionada pela viola ca o do SLA de qualquer um destes inquilinos. Essa interfer encia entre os inquilinos e modelada por um conjunto de regras. Uma regra de interfer encia entre dois inquilinos P e Q, denotada por P Q, dene a carga de trabalho limite dentro da qual a viola c ao do SLA n ao ocorre, como mostra a seguinte regra:
P Q if carga atualP,Q > carga SLAP,Q
(4.1)
Esta deni c ao pode ser aplicada para k inquilinos, por exemplo, P Q, R, k . No caso de viola c ao do SLA, uma nova regra com o valor anterior a ` viola c ao e armazenada pelo RepliC. Quando ocorrem altera co es na carga de trabalho, RepliC verica estas regras e limita as requisi co es enviadas para os inquilinos que apresentaram interfer encia. Para garantir a qualidade de servi co, a carga de trabalho excedente e enviada para um inquilino do sistema com os recursos dispon veis. Caso contr ario, uma nova r eplica e inicializada para lidar com esse aumento da carga. Estas regras s ao reutilizadas com o objetivo de evitar viola co es do SLA similares a `s execu c oes anteriores. Para ilustrar a interfer encia, considere o seguinte exemplo. Suponha que os inquilinos P e Q executem as cargas de trabalho atuais cargaP = 800, cargaQ = 1000 e que com estes valores o SLA para cada inquilino seja satisfeito. Agora considere que a cargaP continua constante e a cargaQ foi alterada para 1200, mas o SLA n ao foi violado. Estes 51
4.3. Modelo de Qualidade de Servi co para BD em Nuvem
52
valores cargaP = 800 e cargaQ = 1200 representam a nova cargaSLA e s ao armazenados, pois indicam que estes inquilinos podem ser executados com estas cargas sem violar o SLA. Por m, suponha que a carga do inquilino Q foi incrementada para cargaQ = 1700, aumentando o tempo de resposta dos dois inquilinos e ocasionando viola ca o do SLA, ou seja, interfer encia entre os mesmos. RepliC armazena e reutiliza estes valores em futuras execu co es para garantir a qualidade.
4.3
MODELO DE QUALIDADE DE SERVIC O PARA BD EM NUVEM
Existem muitos modelos para SLA e qualidade de servi co em nuvem [Fito et al., 2010], [Malkowski et al., 2010] [Schnjakin et al., 2010]. Entretanto, estes modelos s ao muito gerais e n ao tratam caracter sticas do gerenciamento de dados em nuvem. Modelos para SLAs e qualidade espec cos para servi cos de banco de dados s ao descritos em [Yang et al., 2009] [Xiong et al., 2011] [Chi et al., 2011] [LSCR, 2012]. Contudo, estes modelos n ao contemplam alguns aspectos do gerenciamento de dados em nuvem, tais como m etricas espec cas para servi cos de banco de dados em nuvem e prop oem apenas parte de uma solu c ao para qualidade, por exemplo, a deni ca o de um SLA ou abordagens para penalidades. Al em disso, estes trabalhos n ao utilizam t ecnicas ecazes de monitoramento espec cas para SGBDs, fundamentais para tratar a elasticidade do ambiente de computa ca o em nuvem. RepliC utiliza o Service-level Agreement for Database (SLADB), um modelo de qualidade proposto em nossos trabalhos anteriores [Sousa et al., 2011b] [Sousa et al., 2012]. Este modelo dene uma solu c ao para auxiliar a qualidade de servi co, pois aborda diferentes quest oes, tais como deni ca o do SLA, t ecnicas de monitoramento e penalidades. Ele combina diferentes t ecnicas de monitoramento, permitindo a melhoria dos servi cos de banco de dados em nuvem e contempla aspectos do gerenciamento de dados, tais como tempo de resposta, vaz ao, disponibilidade e consist encia.
4.3.1
Especica c ao
Um SLA cont em informa c oes sobre o modelo de receita do provedor de servi co em nuvem, a determina c ao do valor recebido pelo provedor para cumprir o SLA, bem como penalidades ou multas em caso de falhas. A deni c ao de um SLA e uma tarefa n ao trivial, pois estes acordos devem reetir o valor econ omico, bem como as exig encias de servi co ao 52
53
usu ario. Adicionalmente, SLAs t em que descrever as condi c oes comuns de neg ocios, tais como par ametros de desempenho e disponibilidade, m etricas de avalia c ao, contabilidade e quest oes jur dicas, bem como prazos de contrato [Malkowski et al., 2010]. Esta tese aborda apenas aspectos t ecnicos relacionados aos par ametros de desempenho e m etricas de avalia c ao. As propostas para SLAs apresentam muitas diferen cas, mas e poss vel identicar uma estrutura geral comum: informa co es sobre as partes envolvidas, par ametros do SLA, m etricas utilizadas para calcular os par ametros do SLA, algoritmo para calcular os par ametros do SLA, objetivo de n vel de servi co (SLO) e a c oes a serem realizadas em caso de viola c ao do acordo [Schnjakin et al., 2010]. O modelo SLADB utiliza a seguinte deni ca o: Deni c ao 1.1: Um SLA para Servi co de Banco de Dados em Nuvem e composto por informa c oes das partes envolvidas, m etricas do SLA, SLOs, algoritmos para calcular as m etricas do SLA e penalidades. Informa co es sobre as partes envolvidas referem-se ao contrato entre o provedor e o cliente. As m etricas do SLA est ao relacionadas aos itens a serem monitorados (ex. tempo de resposta e vaz ao) e o SLO cont em os limites pr e-denidos para o par ametro (ex. tempo de reposta menor do que 5 ms). Para cada par ametro e denido uma forma de calcul a-lo (ex. tempo m edio) e penalidades referentes ` as a c oes em caso de n ao conformidade dos SLOs (ex. multa). De acordo com [Chi et al., 2011], as m etricas de SLA para banco de dados em nuvem devem otimizar o sistema, tratar aspectos relevantes para o gerenciamento de dados e contemplar as caracter sticas do modelo de computa c ao em nuvem. O SLADB utiliza as m etricas de tempo de resposta, vaz ao, disponibilidade e consist encia1 e as considera fundamentais para o gerenciamento de servi cos de banco de dados em nuvem. Entretanto, e importante ressaltar que o provedor de servi co pode optar por fornecer apenas algumas destas m etricas no seu SLA, visto que existem m etricas relacionadas, por exemplo, tempo de resposta e vaz ao. Um SLO e associado para cada m etrica, conforme destacado a seguir:
Tempo de reposta : o tempo de resposta m aximo, em segundos, para cada transa ca o,
durante um per odo de tempo t.

Est a m etrica e importante para servi cos de banco de dados em nuvem, mas n ao se aplica a todos os servi cos. Assim, esta m etrica e opcional.
1
53
54
Vaz ao : o rendimento m nimo, em transa c oes por segundo, durante um per odo de
tempo t.
Disponibilidade : a fra ca o m axima de transa co es rejeitadas ao longo de um per odo
de tempo t.
Consist encia : o acesso a dados atualizados de acordo com o tipo de consist encia:
forte ou fraca.
4.3.2
Monitoramento das m etricas do SLA
Do ponto de vista do usu ario, um servi co de banco de dados executa bem se os requisitos de desempenho e disponibilidade que o usu ario contrata s ao cumpridos. Um primeiro ponto e traduzir os requisitos de desempenho denidos pelo usu ario em um conjunto comum de m etricas que podem ser obtidos por meio do monitoramento. Exemplos de tais m etricas incluem o tempo de resposta e vaz ao. O tempo de resposta m edio e uma das formas mais comuns para vericar a qualidade do servi co. Em diferentes contextos, e importante estabelecer metas mais gerais para o QoS [Schroeder et al., 2006], tais como o percentil, onde x% dos tempos de resposta s ao inferiores a um valor y. O percentil e solicitado pelos usu arios como componente de um SLA, por exemplo, para garantir que pelo menos 90% das transa c oes dos clientes tenha um tempo de resposta abaixo de um limite especicado [Entrialgo et al., 2011]. Para cada m etrica do SLA, pode-se utilizar um algoritmo para calcular as m etricas do SLA. O SLADB utiliza a seguinte estrat egia:
Tempo de reposta : percentil x% dos tempos de resposta inferiores a um valor y
durante um per odo de tempo t.

Vaz ao : percentil z% de vaz ao maiores a um valor k durante um per odo de tempo
t.
Disponibilidade : fun ca o atendido/n ao-atendido Consist encia : fun ca o atendido/n ao-atendido.
O SLADB utiliza o intervalo de tempo de uma hora para vericar as penalidades do SLA, visto que este valor e utilizado pela maioria dos provedores para a tarifa ca o 54
55
de recursos. Para denir os limites de monitoramento, adotou-se estados para o SLA, conforme mostra a Figura 4.2. Utilizou-se uma escala para o tempo de resposta/vaz ao e estados atendido e n ao atendido para a disponibilidade e consist encia.
Figura 4.2 Estados do SLA.
Baixo : O SLA e menor do que o denido para a aplica c ao. Neste estado, recursos
podem ser removidos do sistema.

Denido : O n vel denido e dividido em ideal e toler avel. Na faixa ideal, o SLA
e mantido dentro um intervalo aceit avel (valor de 80%), mas pode-se congurar outros valores de acordo com os requisitos da aplica ca o. Na faixa toler avel, o SLADB intensica o monitoramento do sistema de forma a preparar a adi ca o de recursos.
Falha : Neste n vel, ocorreu uma falha em rela ca o ao SLA. Neste caso, o provedor
e penalizado de acordo com a quantidade de consultas no n vel de falha e novos recursos devem ser adicionadas rapidamente para retornar ao n vel denido. A disponibilidade de um sistema pode ser obtida a partir de indicadores de falhas de seus componentes, tais como o Mean Time Between Failures (MTBF) e Mean Time To Repair (MTTR). Dene-se MTBF como o tempo m edio (normalmente medido em horas) entre duas falhas consecutivas de um componente ou servi co. O MTTR representa o tempo m edio para se reparar uma falha identicada. Esta medida inclui o per odo de tempo para detectar o problema, diagnosticar e solucionar o mesmo. Assim, a disponibilidade de um sistema e dada pela f ormula MTBF/(MTBF + MTTR) [Tanenbaum and Steen, 2006]. 55
56
A consist encia da aplica ca o pode ser vericada por meio de t ecnicas propostas por [Zellag and Kemme, 2012], que permitem detectar anomalias de consist encia para aplica co es e n ao requerem nenhum conhecimento sobre a l ogica das aplica c oes. A detec ca o de anomalias consiste na constru c ao e verica ca o de gr aco de depend encia durante a execu ca o, permitindo identicar os itens de dados que est ao inconsistentes. Devido a ` sua representatividade, o tempo de resposta e a vaz ao s ao m etricas de desempenho de alto n vel que precisam ser obtidas e analisadas. Os valores dessas m etricas s ao dependentes do estado do SGBD. Quando ele n ao est a sobrecarregado, os valores s ao quase constantes. Entretanto, quando o sistema de banco de dados est a sobrecarregado, os valores crescem linearmente e depois, exponencialmente. Assim sendo, e necess ario ter mecanismos ecazes para detectar a aumento ou diminui ca o destes valores [Malkowski et al., 2010]. Existem v arios m etodos para avaliar o desempenho de servi cos em nuvem. Contudo, a natureza aleat oria da demanda do usu ario e as mudan cas constantes na carga de trabalho ao longo do tempo tornam complexo o planejamento de capacidade em um curto per odo de tempo. Isso ocasiona alguns problemas: (i) a carga de trabalho muda constantemente, implicando em uma atualiza c ao cont nua da congura ca o do sistema e este pode car sobrecarregado devido a ` execu ca o dos procedimentos de adi c ao e remo ca o de recursos; (ii) a quantidade e a precis ao de dados coletados deve reetir o estado atual do sistema. O tempo de resposta e vaz ao do servi co podem variar muito em curtos per odos de tempo e e necess ario ltrar essa variabilidade para obter um padr ao regular e evitar adi ca o ou remo c ao de recursos. O SLADB utiliza uma estrat egia similar a [Fito et al., 2010] para calcular os dados coletados. A coleta e realizada seis vezes com o intervalo de 10 segundos. Para cada coleta, o SLADB calcula a mediana e desvio-padr ao do tempo de resposta. As duas medianas com menor desvio s ao selecionadas para obter os valores nais a serem armazenados. Com os valores de tempo de resposta coletados, aplica-se uma m edia ponderada exponencial Xt = Xt + (1 - ) Xt1 , onde e o fator de pondera c ao (0 1). Nesta m edia, os valores mais recentes t em maior peso, com o peso declinando exponencialmente a ` medida que esses valores se tornam ultrapassados. O fator de pondera ca o pode ser determinado experimentalmente, utilizando uma combina c ao de benchmarks com cargas articiais e aplica co es com cargas reais. Esta t ecnica de monitoramento e semelhante a ` 56
57
adapta ca o de sobrecarga de servi cos de internet [Welsh and Culler, 2003]. As m etricas do SLA s ao calculadas diretamente no provedor de servi co, pois e complexo realizar medi c oes no cliente em virtude das varia co es na qualidade da conex ao. Contudo, muitos provedores de Internet fornecem solu co es para melhorar a qualidade da conex ao, por exemplo, Virtual Private Network (VPN), que podem ajudar na qualidade geral do sistema [Pierre and Stratan, 2012].
4.3.3
Penalidades
Como o custo e importante no ambiente de computa ca o em nuvem, um modelo para representar SLA para banco de dados em nuvem deve contempl a-lo. Da perspectiva do provedor de servi co, o lucro e o objetivo nal. Assim, um SLA orientado ao lucro e caracterizado por duas partes: receita e custo operacional. A receita e o valor pago pelos clientes ao provedor do servi co de acordo com o SLA. A receita n ao e xa e pode mudar com uma potencial redu ca o do pagamento ou mesmo penalidades, dependendo da qualidade de servi co. Custo operacional e o custo dos recursos usados para executar o servi co, por exemplo, pagamento da infraestrutura [Malkowski et al., 2010]. SLADB utiliza uma estrat egia de SLA orientado ao lucro. Este tipo de SLA apresenta um funcionamento con avel dos sistemas, pois o provedor est a motivado a prestar o servi co com uma qualidade elevada. Nos casos onde o provedor n ao e capaz de atender o SLA, ele e incentivado a continuar a prestar o servi co at e obter o lucro. A receita e o valor pago pelo cliente ao provedor para cumprir um SLA Si e o custo operacional e o gasto do provedor para a execu ca o de um servi co com um SLA Si especicado. Dessa forma, o lucro consiste na receita subtra da do custo operacional e das penalidades, conforme mostra a f ormula a seguir.
Lucro = Receita (Custo + P enalidades)
(4.2)
A penalidade ou multa e um valor que o provedor deve pagar ao cliente, se o SLA Si n ao e cumprido. Por exemplo, no Google AppEngine2 ou Amazon S33 , se a disponibilidade car abaixo de 99,9%, em seguida, os clientes recebem um cr edito no
2 3
http://code.google.com/appengine/sla.html http://aws.amazon.com/s3-sla/
57
4.4. Elasticidade na Replica c ao de Banco de Dados em Nuvem
58
servi co de acordo com a qualidade de servi co e proporcional a receita. Da mesma forma, o tempo de resposta e fundamental para garantir a qualidade de servi co e pode incorrer em penalidades em alguns modelos de servi cos [Xiong et al., 2011]. No SLADB, o custo de penalidade e denido pela raz ao entre a soma de todas as consultas violadas pelo total de consultas multiplicado pela receita do sistema, de acordo com a f ormula abaixo. consultas violadas Receita consulta
CP =
(4.3)
Com isso, pode-se denir uma fun c ao de satisfa c ao para o SLA, conforme apresentado a seguir. A fun ca o e atendida, caso o SLA Si seja satisfeito, ou seja, todos os SLOs do SLA Si sejam satisfeitos e, n ao e atendida, caso contr ario.
F SS (Si) =
1 se SLA Si e satisfeito 0 se SLA Si e violado
(4.4)
4.4
DE BANCO DE DADOS EM NUVEM ELASTICIDADE NA REPLICAC AO
Elasticidade e a capacidade de aumentar e diminuir o n umero de r eplicas para se adaptar a ` carga de trabalho [Perez-Sorrosal et al., 2011]. Um sistema el astico para replica c ao de dados deve realizar os seguintes passos: adi ca o, remo c ao e migra ca o dos dados para uma nova r eplica. De acordo com [Soundararajan and Amza, 2006], a adi c ao de uma nova r eplica consiste de duas fases: migra c ao de dados e estabiliza c ao do sistema. A migra c ao e o processo de mover os dados e executar as transa co es pendentes para tornar uma r eplica atualizada. A estabiliza ca o envolve o gerenciamento durante a adi ca o de uma r eplica ao sistema. Como a varia ca o no n umero de r eplicas altera os valores monitorados, deve-se garantir a estabilidade e o desempenho do sistema durante a adi c ao de novas r eplicas. RepliC utiliza um processo de decis ao para adi c ao e remo c ao de r eplicas baseado na fun c ao de satisfa c ao do SLA (FSS), descrita na se ca o anterior. RepliC monitora o sistema e executa a decis ao para modicar o estado de acordo com as m etricas coletadas. A Figura 4.3 mostra a l ogica para a adi c ao e remo ca o de r eplicas e as condi c oes sob as quais uma r eplica do banco de dados e adicionada ou removida. No estado est avel, isto e, onde o SLA est a sendo atendido (ideal ou toler avel), RepliC monitora o SLA constantemente durante um intervalo de tempo por meio da 58
59
Figura 4.3 L ogica para adi c ao e remo c ao de r eplicas.
fun ca o FSS. Caso ocorra uma varia ca o no tempo de resposta (1), o sistema passa para um novo estado. Se o SLA denido n ao for atendido, RepliC inicia o processo de adi c ao de uma nova r eplica (2). Em seguida, a migra c ao dos dados e realizada para atualizar a r eplica (3), conduzindo o sistema para um novo estado com a nova r eplica. No novo estado, RepliC verica o resultado das altera co es realizadas e compara os valores coletados com o objetivo de determinar quanto a nova r eplica agregou ao desempenho do sistema. Caso o SLA ainda n ao seja atendido (4), RepliC executa novamente os passos (2) e (3). Caso contr ario, o sistema encontra-se no estado est avel (8). Se a fun c ao FSS for atendida por um determinado intervalo de tempo (tempo abaixo do ideal), uma r eplica pode ser removida (5), conduzindo o sistema para um novo estado (6). Se a fun c ao FSS continuar sendo atendida (7), outra r eplica pode ser removida. Se o SLA torna-se ideal, o sistema e conduzido para o estado est avel (8). Para melhorar o processo de adi ca o, pode-se utilizar informa co es sobre as r eplicas rec em-adicionadas como uma heur stica para determinar a contribui ca o agregada por uma nova r eplica, visto que a estabiliza c ao pode demorar e comprometer o desempenho do sistema. Para tanto, o processo de adi ca o e remo c ao deve monitorar a varia ca o do SLA e modicar a quantidade de recursos somente se o sistema apresentar altera co es constantes
59
60
no aumento ou diminui c ao da carga de trabalho. A estrat egia adotada na fun ca o FSS, que utiliza a m edia ponderada exponencial para o processo de monitoramento, evita a adi ca o ou remo ca o de r eplicas desnecess arias, principalmente quando ocorrem altera co es pontuais da carga de trabalho.
4.4.1
Adi c ao de R eplicas
Para realizar a adi c ao de uma nova r eplica, RepliC verica a possibilidade de adicionar uma nova r eplica do banco de dados em uma das VMs em execu ca o, observando os recursos de CPU, mem oria e disco dispon veis. Caso a adi c ao seja poss vel, a primeira VM com recursos dispon veis e selecionada. Caso n ao exista uma VM com recursos dispon veis, uma nova VM e iniciada. Em seguida, a migra ca o de dados para a nova r eplica e realizada. Por m, a r eplica recebe as transa co es executadas desde o in cio do processo de migra ca o. Durante o processo de adi ca o, RepliC suspende as decis oes de adi c ao at e que o processo seja conclu do. Ap os a conclus ao, o SLA e monitorado considerando a nova r eplica.
4.4.2
Remo c ao de R eplicas
Com a diminui ca o da carga de trabalho de um determinado banco de dados e, consequentemente, a satisfa c ao da fun c ao FSS, pode-se realizar a remo ca o de uma quantidade de r eplicas associadas a este banco de dados, desde que a qualidade do servi co seja mantida. Quando uma r eplica precisa ser removida do sistema, RepliC seleciona a r eplica com menor carga de trabalho e esta r eplica n ao recebe novas requisi co es. Quando todos os clientes atuais da r eplica forem desconectados, ela e removida. Se a remo ca o precisa ser r apida, os clientes s ao redirecionados para outra r eplica deste banco de dados em execu ca o. Com a remo ca o de r eplicas dos bancos de dados, muitas VMs podem car com poucas r eplicas, implicando em recursos ociosos. Para tratar este problema, podem-se reorganizar as r eplicas de tal forma a reduzir a quantidade de VMs em uso. Este processo de reorganizar consiste na adi ca o de uma nova r eplica na VM de destino e a remo c ao da r eplica na VM atual ou VM de origem. Esta reorganiza ca o n ao deve interferir no SLA dos bancos de dados e deve ser realizada de forma supervisionada por meio t ecnicas que permitam aos desenvolvedores acompanharem o processo para garantir a qualidade de 60
61
servi co. Este processo de reorganiza ca o n ao e abordado neste trabalho, mas pode ser adaptado ` a partir das a c oes de adicionar e remover r eplicas presentes no RepliC.
4.4.3
Migra c ao de Dados entre as R eplicas
A migra ca o de dados trata da atualiza c ao de uma r eplica nova. Durante o processo de adi ca o, a nova r eplica recupera os dados persistidos no servi co de armazenamento, tais como snapshot e logs, visto que as inst ancias dos SGBDs est ao sendo executados em um ambiente virtualizado. Associado a estes dados, as transa co es executadas nas outras r eplicas durante a adi c ao da nova r eplica s ao recuperadas. Este passo e realizado armazenando as transa c oes executadas e, em seguida, enviando-as para a nova r eplica. A migra ca o dos dados deve minimizar as interrup co es e sobrecarga no processamento das transa co es. Para auxiliar este processo, RepliC armazena e gerencia as transa co es a serem executadas. Isso melhora o desempenho deste processo, pois diminui a sobrecarga sobre as r eplicas em execu c ao. De forma similar a [Savinov and Daudjee, 2010], RepliC mant em logs das transa c oes de atualiza c oes. Os logs s ao armazenados at e que as transa co es sejam efetivadas ou abortadas pelas r eplicas e s ao reexecutados durante a migra ca o de dados para atualizar uma nova r eplica. Para detectar o conjunto de atualiza c oes que ainda n ao foram aplicados, utiliza-se um identicador para cada transa ca o. Para melhorar o desempenho na execu c ao das transa co es em uma nova r eplica, estas transa co es s ao executadas em bloco. Quando os blocos s ao executados, as r eplicas tornam-se atualizadas e podem receber requisi co es enviadas ao sistema. A migra ca o dos dados deve conduzir o sistema entre estados consistentes. Para detalhar o processo de migra c ao, utiliza-se a nota c ao da Tabela 4.1, que mostra os componentes utilizados na migra ca o e envolve um conjunto de fases. A Figura 4.4 apresenta as fases realizadas durante a migra ca o dos dados entre as r eplicas. Fase de Prepara c ao: Nesta fase, um ponto de controle e criado e uma r eplica atualizada RAtl e selecionada do sistema. Em seguida, uma imagem (snapshot) ISnap do banco de dados da r eplica RAtl e armazenado no servi co de armazenamento SArm . A partir deste ponto, o servi co de escalonamento SEsc salva o log das transa co es conrmadas. Fase de Transfer encia: O processo de atualiza ca o da r eplica RN ova e iniciada nesta fase. A imagem ISnap e recuperada do SArm e restaurada na r eplica RN ova . 61
62
Par ametro RAtl RN ova SEsc SArm ISnap
Valor R eplica atualizada R eplica nova Servi co de escalonamento Servi co de armazenamento Imagem (snapshot) do banco de dados
Tabela 4.1 Conven c oes de nota c ao para migra c ao de dados entre as r eplicas.
Fase de Conclus ao: Nesta fase, o log armazenado pelo SEsc e enviado e executado na r eplica RN ova . Assim, a RN ova torna-se atualizada em rela ca o as outras r eplicas e come ca a receber as transa c oes enviadas ao sistema.
Figura 4.4 Migra c ao dos dados entre as r eplicas.
4.4.4
Provisionamento de Banco de Dados em Nuvem
O provisionamento no ambiente de nuvem e fundamental para garantir a qualidade do servi co. As estrat egias podem ser reativas ou proativas. Estrat egias de provisionamento reativas s ao mais adequadas para a camada web, visto que nesta camada pode-se adicionar maior capacidade sempre que necess ario e a lat encia refere-se apenas a ` inicializa c ao da m aquina virtual. Diferentemente, o provisionamento de uma nova r eplica de banco de dados envolve os seguintes passos: (i) extrair o conte udo do banco de dados de uma r eplica existente, se este ainda n ao estiver dispon vel e (ii) restaurar esse conte udo em uma nova r eplica. Estas opera co es podem demorar, dependendo do tamanho do banco de dados, congura c oes do sistema de armazenamento e ferramentas de backup /restaura ca o [Cecchet et al., 2011]. Dessa forma, para a camada de gerenciamento de dados, deve-se utilizar estrat egias proativas. Uma estrat egia para provisionamento deve considerar o tempo para replicar o 62
63
estado do banco de dados e a sobrecarga de sincroniza c ao. Caso estes pontos n ao sejam considerados, a nova r eplica pode demorar um intervalo grande de tempo para estar operacional e n ao poder a lidar com um aumento da carga de trabalho em tempo h abil. Assim, e necess ario estimar o tempo necess ario para replicar os dados. Contudo, n ao e trivial estimar o tempo exato necess ario para gerar uma nova r eplica. Modelos de determina ca o de capacidade podem ajudar a predizer a carga de trabalho futura e t ecnicas de provisionamento podem ser utilizadas para estimar o n umero de r eplicas necess arias para atender o servi co. A t ecnica de provisionamento do RepliC e simples e ela dene apenas quando uma nova r eplica deve ser adicionada de acordo com a carga de trabalho. RepliC n ao implementa t ecnicas espec cas de predi c ao e provisionamento de recursos, pois estas s ao caracter sticas ortogonais ao processo de replica ca o. Aspectos relativos ` a predi c ao e provisionamento s ao abordados em nosso trabalho [Santos et al., 2012] e podem ser adicionados ao RepliC com pequenos ajustes. Em geral, existe um equil brio entre o tempo para realizar um snapshot do banco de dados, o tamanho do log transacional e a quantidade de opera co es de atualiza ca o na carga de trabalho [Cecchet et al., 2011]. Por exemplo, uma nova r eplica pode ser iniciada com um snapshot antigo, que evita a sobrecarga da fase de backup. Entretanto, a utiliza ca o de um snapshot antigo for ca o sistema a manter um log transacional grande e aumenta o tempo para reexecutar as atualiza co es deste log durante a nova execu ca o. Por outro lado, utilizar um novo snapshot para cada nova r eplica pode incorrer em sobrecargas signicativas durante a fase de backup, especialmente se o banco de dados e grande. Como este trabalho considera o contexto de aplica c oes que manipulam pequenas quantidades de dados, esta quest ao do tamanho do banco de dados n ao se apresenta como um desao consider avel. No ambiente virtualizado, onde os sistemas de bancos de dados est ao sendo executados, os dados s ao persistidos por meio de servi cos de armazenamento, visto que as m aquinas virtuais possuem apenas armazenamento em mem oria principal. Dessa forma, RepliC utiliza uma estrat egia incremental para armazenar os dados, conforme apresenta a Figura 4.5. Quando um novo banco de dados e adicionado ao sistema, e realizada uma c opia inicial completa deste banco no servi co de armazenamento. Com o processamento das transa co es, estas transa co es s ao organizadas em blocos de dados com um identicador u nico. Estes blocos s ao persistidos por meio do servi co de armazenamento ` a medida 63
4.5. Algoritmos para Replica c ao de Banco de Dados em Nuvem
64
que s ao preenchidos com um conjunto de transa co es. Quando a quantidade de blocos aumenta, RepliC salva uma c opia atual completa do banco de dados e a estrat egia e reiniciada.
Figura 4.5 Estat egia incremental para armazenamento dos dados.
Os logs persistidos pelo RepliC s ao removidos por meio de um processo de coleta de lixo quando se tornam obsoletos, isto e, quando um novo snapshot do banco de dados e persistido. Para minimizar o tempo de reintegra ca o, por exemplo, ap os uma falha, e para facilitar a coleta de lixo peri odica do log, utilizam-se pontos de verica ca o em intervalos de tempo regulares. DE BANCO DE DADOS EM NUVEM ALGORITMOS PARA REPLICAC AO
4.5
Esta se ca o descreve os principais algoritmos do RepliC referentes a elasticidade. Estes algoritmos tratam do monitoramento, adi ca o/remo ca o de r eplicas e a migra c ao de dados entre as r eplicas. A Tabela 4.2 mostra a nota c ao utilizada para descrever os recursos do sistema. Com o objetivo de melhorar a disponibilidade e desempenho, este trabalho considera as seguintes restri c oes: a) cada banco de dados possui pelo menos duas r eplicas; b) as r eplicas de um servi co n ao est ao alocadas em uma mesma m aquina virtual; c) o somat orio dos recursos das r eplicas deve ser menor do que os recursos da m aquina. O Algoritmo 1 refere-se ao monitoramento do SLA. Este procedimento e executado continuamente (linha 2) e verica o SLA monitorado para cada banco de dados (linhas 3 e 4). Caso o SLA denido n ao seja atendido pela fun c ao FSS (linha 5), uma nova r eplica deste banco de dados e criada (linha 6). Em seguida, a migra c ao de dados e realizada para copiar os dados para a nova r eplica (linha 7) e a mesma e adicionada ao sistema, recebendo as requisi c oes (linha 7). Por m, o sistema e estabilizado para reetir o estado atual considerando a nova r eplica. Caso o SLA seja atendido, uma r eplica e removida do sistema. Neste caso, as 64
65
Par ametro VM VME vm BD bd cap res
Valor Conjunto de m m aquinas virtuais Conjunto de m aquinas virtuais em execu c ao M aquina virtual Conjunto de k banco de dados Banco de dados - representa um inquilino/r eplica Quantidade de recursos Recurso residual - representa os recursos dispon veis
Tabela 4.2 Nota c ao utiliza para descrever os recursos do sistema.
requisi co es s ao redirecionadas para um conjunto de r eplicas de tal forma que a r eplica com menor carga de trabalho n ao receba requisi c oes (linha 10). A r eplica e removida (linha 11) e o sistema e estabilizado para reetir o estado atual. Algoritmo 1 - Procedimento de Monitoramento do SLA
1: procedure M onitoramento(SLA) 2: loop 3: for bd BD do 4: for i range(SLA(bd)).length) do 5: if F SS (SLA(bd)) = f alse then 6: CriarReplica(bdi ); 7: M igrarDados(bdi ); 8: AdicionarSistema(bdi ); 9: else 10: RedirecionarRequisicoes(); 11: RemoverSistema(bdi ); 12: end if 13: end for 14: end for 15: end loop 16: end procedure
O Algoritmo 2 descreve a fun ca o de busca utilizada durante a adi ca o de uma r eplica. Esta fun ca o recebe como entrada um banco de dados (linha 1) e verica se e poss vel adicionar uma r eplica deste banco em uma m aquina virtual em execu ca o. Inicialmente, as m aquinas virtuais s ao ordenadas de acordo com sua capacidade residual (linha 2), isto e, a capacidade de recursos dispon vel. Em seguida, as m aquinas s ao percorridas para vericar se a r eplica do banco de dados pode ser adicionada (linhas 3 e 5 ). Se a quantidade de recursos necess arios para o banco de dados for maior do que os recursos dispon veis nas m aquinas (linha 6), a fun c ao e abortada e uma nova m aquina e 65
66
retornada (linha 17). Se existir uma m aquina com recursos para comportar a r eplica do banco de dados, esta fun ca o verica se j a existe uma r eplica deste banco de dados nesta m aquina (linha 12), visto que esta e uma restri c ao do problema abordado neste trabalho. Caso n ao exista, esta m aquina e retornada (linha 13). Caso contr ario, uma nova m aquina e retornada (linha 17). Algoritmo 2 - Fun ca o para Buscar um Banco de Dados
1: function Busca(bd ) 2: Ordenar VME por capacidade residual res; 3: for vm V M E do 4: f lag = true; 5: for i range(res.length) do 6: if capi (bd) > resi (vm) then 7: f lag = f alse; 8: break; 9: end if 10: end for 11: if (f lag = true) then 12: if (bd / V M E (vm)) then 13: return vm; 14: end if 15: end if 16: end for 17: return N ew(vm); 18: end function
O Algoritmo 3 mostra o procedimento para adicionar uma nova r eplica ao sistema. Este procedimento consiste em realizar uma busca utilizando a fun c ao denida anteriormente (linha 2), que retorna uma m aquina na qual a r eplica ser a adicionada. Ap os a adi ca o (linha 3), a capacidade da m aquina virtual e decrementada (linha 5) e a r eplica e adicionada ao conjunto m aquinas em execu ca o (linha 7). Este procedimento e executado duas vezes quando um novo banco de dados e adicionado a ` infraestrutura, visto que, considera-se que cada banco possui duas r eplicas em m aquinas virtuais diferentes. O Algoritmo 4 remove uma r eplica de banco de dados do sistema. Este procedimento consiste em selecionar a r eplica com a menor carga de trabalho (linha 2) baseada em uma varia c ao da fun ca o descrita para adicionar novas r eplicas. Em seguida, a r eplica e removida (linha 3), liberando os recursos na m aquina onde a mesma estava sendo executada (linha 5). Ap os a remo c ao, as VMs que n ao possu rem r eplicas tamb em podem ser removidas do sistema. 66
67
Algoritmo 3 - Procedimento para Adicionar uma Nova R eplica

1: procedure Adiciona(bd) 2: vm = Busca(bd); 3: vm.Adiciona(bd); 4: for i range(cap.length) do 5: capi (vm) = capi (vm) capi (bd); 6: end for 7: V M E (vm) = V M E (vm) + bd; 8: end procedure
Algoritmo 4 - Procedimento para Remover uma R eplica

1: procedure Remove(bd) 2: vm = BuscaM enorCarga(bd); 3: vm.Remove(bd); 4: for i range(cap.length) do 5: capi (vm) = capi (vm) + capi (bd); 6: end for 7: V M E (vm) = V M E (vm) bd; 8: end procedure
O Algoritmo 5 mostra o procedimento para migrar dados para uma r eplica. Primeiramente, um snapshot ou imagem da r eplica e persistido no servi co de armazenamento (linha 2). O servi co de escalonamento persiste um log com as opera c oes de atualiza c ao executadas pelas demais r eplicas (linha 3). Em seguida, a imagem persistida e recuperada na nova r eplica (linha 4) e as opera co es de atualiza co es pendentes em uma la s ao executadas (linha 5). Finalmente, a r eplica e adicionada ao sistema (linha 6). Algoritmo 5 - Procedimento para Migra ca o de Dados para uma R eplica
1: procedure M igra 2: ServicoArmazenamento(imagem); 3: ServicoEscalonamento(log ); 4: Restore(imagem); 5: Execute(log ); 6: AdicionaSistema(bd); 7: end procedure
4.5.1
Exemplo de Execu c ao do RepliC
Para ilustrar a execu c ao do RepliC, considere tr es servi cos de banco de dados, Y CSB , W iki e T witter, que representam bancos de dados do Yahoo! Cloud Serving Benchmark (YCSB), Wikipedia e Twitter, respectivamente. Cada servi co recebe uma carga 67
68
de trabalho/taxa de transa co es vari avel ao longo do tempo. Estes servi cos possuem os seguintes SLAs de tempo de resposta Y CSBSLA = 0.1s, W ikiSLA = 0.2s, T witterSLA = 0.5s. A penalidade e denida pela soma das transa c oes que n ao atenderam ao SLA, com valor de $ 0.001 por transa ca o n ao atendida. Considere a infraestrutura da Amazon com m aquinas do tipo small, com custo de $ 0.08. A aloca ca o inicial considera que duas r eplicas de cada banco de dados s ao utilizadas, com a seguinte aloca ca o V M1 ={Y CSB , W iki, T witter}, V M2 ={Y CSB , W iki, T witter}. Para simplicar o exemplo, suponha que n ao ocorre interfer encia entre as r eplicas ou inquilinos. Suponha, no momento inicial de execu ca o dos servi cos, as seguintes taxas de transa co es para os servi cos Y CSBtaxa = 4t/s, W ikitaxa = 1t/s, T wittertaxa = 3t/s. Neste cen ario, os tempos de respostas (TR) calculados s ao Y CSBT R = 0.03s, W ikiT R = 0.09s, T witterT R = 0.23s e os SLAs est ao sendo atendidos para os tr es servi cos. No T empocrono = 3hs, suponha que a taxa de transa c oes do T witter aumentou para T wittertaxa = 12t/s e o T witterT R = 1.2s. Isso implica em viola c ao do T witterSLA . Para tratar isso, RepliC adiciona uma nova m aquina e uma r eplica do T witter, visto que as m aquinas em uso j a possuem uma r eplica do T witter. Assim sendo, a V M3 ={T witter} e adicionada. Ap os a adi ca o, que demorou 35s desde a viola ca o, o sistema e monitorado e verica-se T witterT R = 0.34s. No T empocrono = 4hs, suponha que a taxa de transa co es do W iki foi alterada para W ikitaxa = 6t/s e o W ikiT R = 0.32s. O sistema verica a disponibilidade de recursos nas m aquinas em uso para alocar uma r eplica do W iki. A V M3 n ao possui recursos. As V M1 e V M2 possuem recursos, mas j a possuem uma r eplica do W iki. Dessa forma, uma nova m aquina e uma r eplica s ao adicionadas V M4 ={W iki}, levando 42s para estar em execu ca o desde a viola ca o e tornando W ikiT R = 0.13s. Considere que o T witter encontra-se com T witterT R = 0.35s ap os o T empocrono = 6hs e a carga de trabalho n ao apresenta altera co es, tornando a fun c ao de satisfa ca o do SLA verdadeira. Neste caso, o sistema redireciona a carga de trabalho da V M3 ={T witter} para a V M1 = {Y CSB , W iki, T witter}, alterando T witterT R = 0.42s, mas n ao viola o SLA, que e T witterSLA = 0.5s. Com isso, a r eplica do T witter da V M3 e removida do sistema. Como a V M3 continha apenas a r eplica removida, essa m aquina tamb em e removida do sistema, dimi68
4.6. Conclus ao
69
nuindo os custos. Neste exemplo, os servi cos foram encerrados no T empocrono = 7 hs. O custo do provedor com as VMs e calculado pela quantidade de VMs em cada intervalo de tempo: (1-3hs x 2 V M ) + (3-4hs x 3 V M ) + (4-6hs x 4 V M ) + (6-7hs x 3 V M ), totalizando $ 1.12. Durante a execu ca o, ocorreu viola c ao do SLA com o T witter e W iki. Para calcular o total de transa co es que n ao atenderam o SLA, multiplica-se a taxa de transa c oes no momento da viola ca o pelo tempo decorrido desde a viola ca o at e a adi ca o da nova r eplica. Para o T witter tem-se 12t/s x s = 420 transa c oes e para o W iki 6t/s x 42s = 252 transa co es, totalizando 672 transa c oes. Como o custo por transa ca o violada e$ 0.001, o valor nal da penalidade paga pelo provedor e $ 0.672. O custo total do provedor e calculado pela soma do custo com as VMs $ 1.12 e as penalidades $ 0.672, totalizando $ 1.792. Embora este exemplo seja simples, pode-se observar a execu ca o da abordagem proposta. RepliC melhora a utiliza ca o dos recursos por meio do modelo multi-inquilino adotado, reduzindo as penalidades e melhorando a qualidade por meio da elasticidade. CONCLUSAO
4.6
Este cap tulo apresentou RepliC, uma abordagem para a replica ca o de banco de dados em nuvem, cujo prop osito e garantir a qualidade de servi co com a utiliza ca o eciente dos recursos. Foram elencados quais os pressupostos considerados pelo RepliC e um modelo de qualidade de servi co foi descrito. Os algoritmos desenvolvidos referentes a ` elasticidade tamb em foram apresentados, assim como um exemplo de execu ca o. O modelo multiinquilino utilizado pelo RepliC permite compartilhar os recursos de forma eciente. A estrat egia de elasticidade associada ` as caracter sticas da infraestrutura em nuvem garante a qualidade do servi co por meio da adi ca o e remo c ao de r eplicas. O pr oximo cap tulo trata de quest oes relativas a ` consist encia dos dados e toler ancia a falhas implementadas pelo RepliC.
69
CAP ITULO 5
CONSISTENCIA PARA BANCO DE DADOS MULTI-INQUILINO
Este cap tulo descreve a estrat egia para consist encia de banco de dados multi-inquilino utilizada pelo RepliC. Inicialmente, s ao destacados aspectos relevantes ` a consist encia de dados em nuvem. Em seguida, s ao abordados algoritmos para tratar a sincroniza c ao entre as r eplicas em ambientes virtualizados de tal forma a garantir a consist encia. Finalmente, s ao apresentadas estrat egias para tratar falhas neste ambiente. INTRODUC AO
5.1
As solu co es em nuvem focam em escalabilidade e, em geral, oferecem consist encia fraca de dados, por exemplo, consist encia eventual. Este tipo de consist encia n ao permite a constru ca o de uma ampla gama de aplica co es, tais como servi cos de pagamento e leil oes online, que n ao podem trabalhar com dados inconsistentes [Wei et al., 2009] [Baker et al., 2011]. Devido a ` grande quantidade de aplica co es que utilizam consist encia forte, RepliC implementa este tipo de consist encia, onde as aplica c oes sempre acessam dados atualizados. Aspectos Relevantes Para melhorar o desempenho, o processo de replica ca o deve estar completamente sintonizada com a aplica ca o e a carga de trabalho. Al em disso, altera c oes no padr ao de acesso podem conduzir a mudan cas nas estrat egias de replica c ao, o que torna a concep ca o de uma estrat egia ideal muito complexa [Sivasubramanian et al., 2005]. Uma quest ao importante em qualquer sistema replicado e a consist encia. O gerenciamento das r eplicas tem dois aspectos principais: a propaga ca o de atualiza co es e controle de concorr encia [Kemme et al., 2010]. As estrat egias de propaga ca o de atualiza co es podem ser classicadas em push e pull. Estrat egias de atualiza ca o de dados baseadas em push asseguram a consist encia das r eplicas de forma s ncrona, pois todas as atualiza co es s ao enviadas para as r eplicas imediatamente. Estrat egias baseadas em 70
5.2. Comunica c ao em Grupos
71
pull propagam as atualiza c oes de forma ass ncrona e s ao mais apropriadas para evitar atualiza co es desnecess arias quando n ao ocorre acesso de dados entre duas transa co es de atualiza co es subsequentes. A propaga c ao de atualiza c oes n ao e suciente para manter a consist encia dos dados, pois deve-se ter mecanismos para sincroniza c ao entre as diferentes r eplicas. O sistema deve lidar com atualiza co es simult aneas dos dados em v arias r eplicas. Solu co es tradicionais como o protocolo de duas fases (2PC) s ao muitas limitadas, pois exigem bloqueio global de todas as r eplicas, reduzindo assim as melhorias de desempenho proporcionadas pela replica c ao [Ozsu and Valduriez, 2011]. Outro ponto importante refere-se a ` aloca c ao das m aquinas virtuais pelos provedores de infraestrutura. Os provedores criam as m aquinas virtuais de forma autom atica com o objetivo de melhorar a utiliza ca o dos recursos, minimizando os custos. Com isso, as m aquinas virtuais correspondentes a uma mesma aplica ca o ou banco de dados podem estar em estruturas f sicas diferentes, por exemplo, racks diferentes, o que pode aumentar a lat encia [Wada et al., 2011]. RepliC utiliza o modelo de replica ca o transparente combinando as estrat egias push e pull, onde o cliente da aplica ca o que acessa o banco de dados n ao precisa se preocupar com problemas de replica c ao e pode se concentrar apenas nos requisitos funcionais da aplica ca o. Em rela c ao a aloca ca o das m aquinas virtuais na infraestrutura, RepliC n ao interfere ou modica esta aloca ca o. O ajuste na quantidade de r eplicas e realizado de acordo com o monitoramento do ambiente, vericando par ametros de desempenho. Dentre v arios tipos de protocolos de replica ca o, a abstra ca o de comunica ca o em grupo (CG) e uma tecnologia eciente para implementar estes protocolos, pois prov e garantias de conabilidade que simplicam a aplica ca o de t ecnicas de toler ancia a falhas [Birman, 2012]. Estas primitivas de comunica ca o em grupo t em sido aplicadas com eci encia nesses protocolos, tanto em abordagens s ncronas como ass ncronas. Dessa forma, comunica c ao em grupos e uma solu c ao vi avel para implementar protocolos de replica ca o. EM GRUPOS COMUNICAC AO
5.2
A abstra ca o de grupos [Birman, 2012] tem provado ser um mecanismo eciente para implementar protocolos de consist encia de r eplicas, facilitando o desenvolvimento de 71
72
aplica co es distribu das con aveis. Essa abstra ca o tem por objetivo resolver problemas b asicos de inconsist encias na comunica ca o entre processos distribu dos que cooperam para a execu c ao de uma tarefa. Nesse sentido, um grupo e apenas um conjunto de processos que cooperam. Na forma mais geral de comunica c ao em grupos, um determinado processo pode pertencer a diferentes grupos, ou seja, os grupos podem se sobrepor. A exist encia de m ultiplos membros em um grupo e invis vel para o cliente. Um cliente que deseja se comunicar com um grupo, ao inv es de enviar uma mensagem individual para cada membro, envia apenas uma mensagem para o endere co do grupo. A abstra ca o de grupos evita que um processo externo tenha que conhecer individualmente cada um dos membros. O servi co baseado em grupos e composto de duas partes: group membership e group communication [Birman, 2012]. O servi co de membership prov e aos processos a composi ca o do grupo. Tal composi ca o evolui de acordo com o interesse dos processos de se unirem (join ) ou sairem (leave ) do grupo e com a verica c ao da ocorr encia de falhas, sejam de processos pertencentes ao grupo ou de canais de comunica ca o. Esse servi co abstrai os eventos que provocam mudan cas na composi c ao do grupo, atrav es da entrega a cada membro de uma vis ao, ou seja, a composi c ao do grupo em um determinado instante, atualizada e composta por todos os processos considerados ativos. Essas vis oes s ao atualizadas de forma coerente de tal maneira que os processos que as instalam concordam com a sua composi c ao. O objetivo do servi co de communication e prover aos processos primitivas de comunica c ao necess arias ` a troca eciente de mensagens [Tanenbaum and Steen, 2006]. A principal primitiva oferecida por esse servi co e a de multicast ou difus ao. Quando uma entidade externa invoca essa opera ca o a um grupo, essa primitiva garante a entrega da mensagens a todos os membros do grupo. Uma mensagem enviada pode ser con avel ou n ao-con avel. Quando o envio e con avel, garante-se que a mensagem ser a recebida por todos os processos n ao-falhos ou por nenhum deles, garantindo a propriedade da atomicidade. Com essa propriedade, o processo que envia a mensagem para um grupo ir a receber uma mensagem de erro se um ou mais integrantes do grupo tiver problema no recebimento. J a quando o envio e n ao-con avel, o servi co de CG n ao garante a atomicidade. O servi co de grupos tamb em devem garantir alguma forma de integra c ao entre a entrega de invoca co es regulares (multicast ) e a entrega de eventos de mudan ca de vis ao. 72
73
Dessa forma, tais servi cos fazem uso do paradigma de View Synchronous Communication [Birman, 2012]. Esse paradigma garante que as mensagens de multicast sejam entregues na mesma ordem para todos os processos do grupo. Classica c ao Grupos podem ser classicados segundo suas caracter sticas. A principal classica ca o e quanto ` a facilidade em reetir ou n ao as altera co es do sistema distribu do [Birman, 2012]. Em grupos est aticos, n ao ocorre qualquer altera c ao na quantidade de membros durante a vida u til do sistema, n ao sendo necess ario um servi co para controlar a entrada e sa da de membros. Grupos din amicos sofrem altera c oes, reetindo entradas e sa das de membros, ou seja, qualquer altera ca o no n umero de membros de um grupo e indicada na vis ao do grupo. Os grupos tamb em podem ser classicados quanto ` a forma na qual o multicast e implementado [Birman, 2012]. Se todos os membros est ao aptos a fazer o multicast, sem necessitar de um membro coordenador, o grupo e n ao-hier arquico ou sim etrico. Quando o grupo precisa de um membro coordenador para realizar o sequenciamento de mensagens, o grupo e assim etrico ou hier arquico. Neste caso, apenas o coordenador precisa estar apto a fazer o multicast. Os demais membros que desejam realizar um multicast enviam uma mensagem ponto-a-ponto para o coordenador. Al em dessas classica c oes, os grupos podem ser fechados, onde os membros recebem somente mensagens de outros membros, ou abertos, no qual os membros recebem mensagens de qualquer processo. Ordena c ao de Mensagens Uma mensagem recebida por um membro do grupo que est a funcionando corretamente passa por um processo de entrega que eventualmente precisa ser controlado para que a sequ encia de entrega seja a mesma sequ encia de envio. Os tipos de ordena ca o que normalmente est ao implementadas nos sistemas de CG s ao:
FIFO: mensagens enviadas a partir de um u nico membro s ao entregues na ordem
em que s ao enviadas a todos os membros do grupo. Por exemplo, para todas as mensagens M1 e M2 e todos os processos Pi e Pj , se Pi envia M1 antes de enviar M2 , ent ao M2 n ao e recebida em Pj antes que M1 seja recebida.
Causal: mensagens enviadas a partir de m ultiplos membros que possuam uma
73
5.3. Protocolo para Replica c ao
74
rela ca o de causalidade s ao entregues a todos os membros do grupo respeitando sua ordem de causalidade. Duas mensagens possuem rela ca o de causalidade caso uma delas tenha sido gerada depois do recebimento da outra. Pode ser necess ario preservar essa ordem em todos os participantes, j a que o conte udo da segunda mensagem pode ser afetado pelo processamento da primeira.
Total: todas as mensagens enviadas ao grupo s ao entregues a todos os membros na
mesma ordem. Por exemplo, para todas as mensagens M1 e M2 e todos os processos Pi e Pj , se M1 e recebida em Pi antes que M 2 seja, ent ao M2 n ao e recebida em Pj antes que M1 seja. PROTOCOLO PARA REPLICAC AO
5.3
RepliC combina protocolos s ncronos, ass ncronos e primitivas de comunica c ao em grupo, visando obter uma estrutura eciente para a replica ca o de banco de dados em nuvem. O crit erio one-copy serializability e usado neste trabalho como modelo de corretude [Bernstein and Newcomer, 2009]. Esse modelo garante que a execu c ao de transa c oes concorrentes produza resultados equivalentes a uma execu c ao sequencial do mesmo conjunto de transa co es em uma inst ancia do banco de dados. Isso signica que clientes de um sistema replicado o enxergam como um banco de dados com apenas uma inst ancia e que opera co es submetidas sempre obt em dados atualizados. Como no ambiente de computa c ao em nuvem os recursos s ao compartilhados, dicultando o gerenciamento, este trabalho realiza uma estrat egia baseada nos trabalhos propostos por [Vo et al., 2010] [Cao et al., 2011], que consiste em ter diferentes camadas ou grupos virtuais de replica c ao. Tamb em foi estendido a estrat egia proposta em nosso trabalho anterior [Sousa et al., 2007] para contemplar os seguintes aspectos:
1. Execu c ao em ambientes virtualizados: permite a execu ca o em m aquina virtual e utiliza ca o de servi cos de armazenamento em nuvem. 2. Modelo multi-inquilino: possui suporte ao modelo multi-inquilino de inst ancia de banco de dados. 3. Modelo relacional: permite o gerenciamento de sistemas que utilizam o modelo de dados relacional.
74
75
Para auxiliar o gerenciamento das r eplicas, RepliC utiliza grupos virtuais. Cada grupo virtual corrresponde a um conjunto de r eplicas de banco de dados de uma determinada aplica c ao e estes grupos podem ser de dois tipos: grupo de atualiza c ao e grupo de leitura, que tratam transa c oes de atualiza ca o e transa co es de leitura, respectivamente. As r eplicas de cada banco de dados da aplica ca o e suas respectivas transa co es possuem um identicador u nico que permite gerenci a-las. RepliC realiza a distin ca o entre as transa co es, classicando-as de acordo com o conte udo de suas opera co es. Transa co es que contenham apenas opera co es de leitura s ao consideradas de leitura. Caso a transa ca o contenha pelo menos uma opera ca o de modica c ao (inser ca o, atualiza c ao ou remo ca o), ela e classicada como de atualiza ca o. Para reduzir os custos, apenas a quantidade m nima de r eplicas e alocada para cada banco de dados. RepliC utiliza duas r eplicas de cada banco de dados da aplica ca o, sendo que uma r eplica est a contida no grupo de atualiza c ao e outra no grupo de leitura. Contudo, pode-se congurar RepliC para iniciar com uma quantidade maior de r eplicas. Estes grupos s ao alterados pela adi ca o e remo c ao de r eplicas de acordo com a carga de trabalho e a satisfa ca o do SLA. A estrat egia de utilizar grupos tem como objetivo melhorar o desempenho do sistema, visto que a carga de trabalho pode ser distribu da e apenas uma parte das r eplicas necessita ser atualizada a cada modica ca o, diminuindo conitos durante as opera co es de atualiza ca o. RepliC implementa replica c ao total, pois esta tese considera o contexto de inquilinos com requisito de gerenciamento de pequenas quantidades de dados.
5.3.1
Grupo de Atualiza c ao
A r eplica do grupo de atualiza c ao que recebe uma transa ca o de atualiza c ao e denominada de r eplica prim aria. Esta r eplica e respons avel por vericar os conitos com as demais r eplicas deste grupo, denominadas de r eplicas secund arias em rela c ao a r eplica prim aria, por meio do protocolo proposto por [Sousa et al., 2007]. Em seguida, os dados s ao persistidos no servi co de armazenamento da nuvem, que utiliza m ultiplas c opias dos dados persistidos, garantindo a alta disponibilidade dos dados. Os servi cos de armazenamento em nuvem disponibilizados pelos provedores utilizam uma estrutura de replica c ao em n vel de arquivos, por exemplo, Amazon EBS e S3. Com isso, quando uma das r eplicas do grupo de atualiza ca o executa e salva os dados, 75
76
estes servi cos garantem a durabilidade dos mesmos. As demais r eplicas do grupo de atualiza ca o executam as transa co es e conrmam a execu c ao, mas n ao e necess ario que elas persistam os dados no servi co de armazenamento, apenas localmente, para a conclus ao de uma transa ca o. Em caso de falha em algumas r eplicas, os dados podem ser recuperados por meio destes servi cos. As modica co es do grupo de atualiza ca o s ao serializadas e enviadas continuamente pela r eplica prim aria para cada r eplica do grupo de leitura, denominada slaves por meio de um multicast com a propriedade de ordena c ao FIFO. Essas modica c oes s ao adicionadas em las locais de cada r eplica do grupo de leitura e executadas na mesma sequ encia do grupo de atualiza c ao. A Figura 5.1 mostra um exemplo do grupo de atualiza c ao. Na V M1 , a r eplica do banco de dados BD1 e a r eplica prim aria em rela ca o ao cliente cx e a r eplica do banco de dados BD1 na V M2 e V MM s ao r eplicas secund arias. Por outro lado, a r eplica do banco de dados BD1 na V M2 e a r eplica prim aria para o cliente cy e as outras r eplicas deste banco de dados s ao secund arias. Neste exemplo, o banco de dados BD1 na m aquina V MM e sempre uma r eplica secund aria.
Figura 5.1 Grupo de atualiza c ao
76
5.4. Consist encia para Banco de Dados Multi-Inquilino
77
5.3.2
Grupo de Leitura
O grupo de leitura utiliza m ultiplas las para gerenciar os dados enviados pelo grupo de atualiza ca o, onde cada r eplica da m aquina virtual possui uma la respons avel por gerenciar as transa c oes desta r eplica. Para cada r eplica, e criada uma la persistente com as transa co es correspondentes. Cada m aquina virtual possui um conjunto de banco de dados e para cada um destes existe uma la associada. Estas las cont em as transa co es referentes a `s modica co es enviadas pelo grupo de atualiza ca o. Para garantir a consist encia, as transa co es contidas nas las s ao aplicadas as r eplicas. O grupo de leitura executa dois tipos de transa co es: propaga ca o e refresh. Transa co es de propaga c ao s ao executadas durante o tempo ocioso de uma r eplica, ou seja, quando n ao est ao sendo executadas transa c oes de leitura ou transa c oes de refresh, com o objetivo de efetivar as atualiza co es. Transa c oes de refresh s ao aplicadas para adicionar as transa co es contidas na la local a uma r eplica do grupo de leitura. Durante a execu c ao das transa co es de leitura em uma determinada r eplica, RepliC gerencia as r eplicas por meio da execu ca o de transa co es de propaga c ao e de refresh. Caso novas modica c oes sejam adicionadas na la local, RepliC continua a execu c ao da consulta nesta r eplica e posteriormente executa uma transa ca o de propaga ca o, adicionando o conte udo da la ao banco de dados local. Quando uma nova transa ca o e direcionada para esta r eplica, RepliC realiza as seguintes verica co es: (i) se a nova transa ca o requisita dados que foram atualizados, uma transa ca o de refresh e executada, (ii) caso contr ario, a transa ca o e executada sem a necessidade de transa co es de refresh ou propaga ca o. A Figura 5.2 apresenta um exemplo do grupo de leitura. Cada replica slave possui uma la com transa c oes a serem executadas. Replicas prim arias e secund arias est ao alocadas na mesma VM, por exemplo, a r eplica prim aria BD1 e a secund aria BD2 na V M1 . O banco de dados BD2 j a executou as transa co es da la e est a completamente atualizado. Os bancos de dados BD3 e BD11 precisam executar as transa co es de refresh para se tornarem atualizados. CONSISTENCIA PARA BANCO DE DADOS MULTI-INQUILINO
5.4
RepliC implementa um protocolo para consist encia forte que permite a execu ca o de diferentes cargas de trabalho. Quando se utiliza apenas uma r eplica no grupo de atualiza ca o, 77
78
Figura 5.2 Grupo de leitura
este protocolo comporta-se de forma similar ao protocolo de c opia prim aria, mas com melhor desempenho, pois combina estrat egias s ncronas e ass ncronas.
5.4.1
Algoritmos para Consist encia
No RepliC, as atualiza co es s ao executadas de forma s ncrona, primeiramente, na r eplica prim aria do grupo de atualiza ca o, e, caso exista, nas demais r eplicas deste grupo. Em seguida, as atualiza c oes s ao enviadas de forma ass ncrona para os grupos de leitura. O Algoritmo 6 descreve as opera co es realizadas pela r eplica prim aria. Esta r eplica recebe continuamente as mensagens enviadas pelos clientes e pelo sistema de comunica ca o em grupo. Se a mensagem indica a exist encia de uma nova vis ao (linha 3), esta e prontamente instalada, substituindo a vers ao anterior (linha 4). Essa mensagem e proveniente do sistema de CG, enquanto as mensagens de begin e commit de transa co es s ao originadas pelos clientes da r eplica prim aria. Caso a mensagem seja um begin (linha 5), a transa ca o e iniciada no banco de dados local (linha 6), sendo executadas suas opera co es e os resultados retornados ao cliente (linha 7). Quando o cliente requisita o commit da transa ca o (linha 8), as opera c oes de atualiza ca o (write set ) da transa ca o s ao enviados para as outras r eplicas do grupo de atualiza ca o (r eplicas secund arias ) utilizando uma primitiva de ordena ca o total (linha 9). Em seguida, a r eplica prim aria aguarda as conrma co es do teste de certica c ao executado nas r eplicas secund arias da vis ao atual (linha 10). Se ocorrerem conitos no teste de certica c ao (linha 12), a r eplica prim aria envia um multicast com a mensagem 78
79
Algoritmo 6 - Procedimento executado pela R eplica Prim aria

1: loop 2: msg replica primaria.recebe mensagem(); 3: if msn.tipo=nova visao then 4: replica primaria.instala nova visao; 5: else if msn.tipo=begin then 6: replica primaria.begin; 7: resultados replica primaria.execute(msg.transacao, msg.operacoes); 8: else if msn.tipo=commit then 9: replica primaria.multicast(grupo atualizacao, msg.transacao, write set); 10: replica primaria.espera conf irmacao certif icacao; 11: if encontrou conito nas certicacoes then 12: replica primaria.multicast(grupo atualizacao, msg.transacao, abort); 13: else 14: replica primaria.multicast(grupo atualizacao, msg.transacao, commit); 15: end if 16: end if 17: replica primaria.commit; 18: servico armazenamento nuvem(msg.operacoes); 19: replica primaria.multicast(grupo leitura, msg.transacao, write set); 20: end loop
de abort para as r eplicas secund arias (linha 12). Caso n ao ocorram conitos, e feito um multicast para as r eplicas secund arias para que estas realizem o commit da transa ca o nos bancos de dados locais (linha 14). Na sequ encia, a r eplica prim aria faz o commit localmente (linha 17), persiste as opera c oes no servi co de armazenamento em nuvem (linha 18) e envia o write set da transa c ao as r eplicas do grupo de leitura (linha 19). Posteriormente, as r eplicas slave efetivaram essas modica co es em seus bancos de dados locais. O Algoritmo 7 descreve o comportamento das r eplicas secund arias. Ao receber uma mensagem enviada pela r eplica prim aria (linha 2), caso a mensagem contenha um write set (linha 4), e executado um teste de certica c ao (linha 4) para vericar se as atualiza co es conitam com alguma transa c ao em execu c ao e, em caso negativo, e enviada uma mensagem de conrma ca o a ` r eplica prim aria (linha 5). As r eplicas que n ao responderem, por motivos de falha na r eplica ou de comunica ca o s ao exclu das do grupo por meio de uma nova vis ao. Essas r eplicas podem ser reintegradas posteriormente ao grupo. Se a mensagem recebida for um commit (linha 6), uma transa ca o e iniciada no banco de dados local, e as opera c oes do write set recebidas anteriormente s ao executadas (linha 8). Em seguida, o commit da transa c ao e realizado (linha 9). Se a mensagem recebida for um abort, a r eplica secund aria aborta a transa c ao (linha 11). O Algoritmo 8 mostra o teste de certica c ao utilizado na r eplica secund aria. Esse 79
80
Algoritmo 7 - Procedimento executado pelas R eplicas Secund arias

1: loop 2: msg replica secundaria.recebe mensagem(); 3: if msg.tipo =write set then 4: resultado replica secundario.teste de certif icao(msg.operacoes); 5: return resultado; 6: else if msg =commit then 7: replica secundaria.begin; 8: replica secundaria.execute(msg.transacao, msg.write set); 9: replica secundaria.commit; 10: else if msg =abort then 11: replica secundaria.abort(msg.transacao); 12: end if 13: end loop
teste verica conitos entre as transa c oes, comparando seus read sets e write sets (linhas 2 a 4). Depois do teste de certica c ao, a transa ca o e conrmada, abortando transa co es locais (nas r eplicas secund arias ) em execu ca o que est ao em conito com a transa ca o enviada pela r eplica prim aria. Algoritmo 8 - Procedimento do Teste de Certica ca o
1: 2: 3: 4: 5: 6: 7: for transacoes em replica secundaria do if (operacoes.read set= transacoes.operacoes.write set) or (operacoes.write set= transacoes.operacoes.read set) or (operacoes.write set= transacoes.operacoes.write set) then return f also; end if end for
O Algoritmo 9 descreve o comportamento das r eplicas slaves. Cada r eplica slave recebe mensagens de clientes ou do grupo de atualiza ca o (linha 2). Ao receber mensagens de begin (linha 3), provenientes de clientes, a la e inspecionada, vericando se existem modica co es pendentes recebidas do grupo de atualiza ca o a serem efetivadas (linha 4). Em caso positivo, os itens de dados da r eplica a serem atualizados s ao bloqueados (linha 5), ou seja, estes itens de dados n ao podem ser acessados por outras transa c oes at e que sejam desbloqueados, para a execu c ao de uma transa ca o de refresh (linha 6) com as atualiza co es presentes na la. Este passo e denominado bloqueio de refresh. Ao nal da execu c ao, os dados da r eplica s ao desbloqueados (linha 7). Em seguida, a transa c ao e iniciada no banco de dados local, suas opera co es s ao executadas dentro da transa c ao iniciada (linha 10) e os resultados retornados ao cliente (linha 11). Caso a mensagem seja de atualiza ca o (linha 12), originada por uma das r eplicas do grupo de atualiza ca o, o write set recebido e colocado no nal da la da r eplica slave (linha 13) para, 80
5.5. Toler ancia a Falhas
81
posteriormente, ser efetivado por meio de uma transa c ao de refresh ou de propaga c ao. Nos momentos em que a r eplica est a ociosa (linha 15), isto e, n ao est a executando nenhuma transa c ao, e vericado se existem atualiza co es pendentes na la (linha 16). Caso existam, os itens de dados a serem atualizados s ao bloqueados (linha 17), e uma transa ca o de propaga ca o com as altera co es contidas na la e executada (linha 18). Os itens de dados s ao bloqueados (linha 17) para impedir que novas transa co es sejam executadas antes da transa ca o de propaga ca o terminar, impedindo que aquelas vejam dados desatualizados. Ao nal da execu ca o, os itens de dados da r eplica s ao desbloqueados (linha 19) e este ca dispon vel para executar as transa c oes pendentes. Algoritmo 9 - Procedimento executado pelas R eplicas Slave
1: loop 2: msg replica leitura.recebe mensagem; 3: if msg.tipo=begin then 4: if la.vazia()=false then 5: replica leitura.bloquear(msg.item de dados); 6: replica leitura.executa transacao ref resh(f ila); 7: replica leitura.desbloquear(msg.item de dados); 8: end if 9: replica leitura.begin; 10: resultado replica leitura.execute(msg.operacoes); 11: return resultados; 12: else if msg.tipo=atualizacao then 13: f ila.mensagem.(msg.write set); 14: end if 15: while replica leitura.ocioso()=true do 16: if la.vazio=false then 17: replica leitura.bloquear(msg.item de dados); 18: replica leitura.executar(transacao propagacao f ila); 19: replica leitura.desbloquear(msg.item de dados); 20: end if 21: end while 22: end loop
importante ressaltar que todas as r E eplicas s ao executadas em m aquinas virtuais, ou seja, os dados est ao em mem oria principal. Na nossa estrat egia, as r eplicas do grupo de atualiza ca o persistem os dados por meio do servi co de armazenamento em nuvem. TOLERANCIA A FALHAS
5.5
Existem diferentes tipos de falhas, dentre as quais podem ser destacadas falhas de hardware, rede, armazenamento, sistema operacional e inst ancia do SGBD. Os provedores de 81
5.5. Toler ancia a Falhas
82
IaaS tratam a maioria destas falhas, principalmente pela utiliza ca o de hardware redundante, que manter a disponibilidade da infraestrutura em 99%. Entretanto, o desenvolvedor deve ser capaz de manter o sistema funcionando corretamente durante estas falhas da perspectiva do cliente. O intervalo de indisponibilidade do servi co deve ser minimizado, pois isso viola a regra do SLA, resultando em uma penalidade. Por exemplo, no Google AppEngine, se a disponibilidade ca abaixo de 99,9%, em seguida, os inquilinos recebem um cr edito no servi co. Da mesma forma, o tempo de resposta e fundamental para garantir a qualidade do servi co e pode incorrer em penalidades em alguns modelos de servi cos [Xiong et al., 2011]. Assim, t ecnicas para replica c ao em nuvem devem gerar um impacto m nimo sobre os SLAs denidos para os inquilinos. Em geral, estes provedores permitem apenas que as m aquinas virtuais de uma determinada aplica ca o sejam criadas em estruturas f sicas diferentes ou em diferentes zonas de disponibilidade, onde cada uma destas zonas descreve o local f sico dos recursos [Bonvin et al., 2009]. Cada zona de disponibilidade e projetada para estar isolada das falhas das demais zonas de disponibilidade. Dentro de uma mesma zona de disponibilidade a lat encia e baixa, mas podem apresentar varia co es de acordo com a disposi c ao dos recursos. Este ponto e relevante para sistemas replicados, visto que estes sistemas trocam uma quantidade elevada de mensagens. Para melhorar a disponibilidade, cada servi co possui pelo menos duas r eplicas e as r eplicas de um determinado servi co n ao est ao alocadas em uma mesma m aquina, por exemplo, duas r eplicas do banco de dados Wiki n ao s ao alocados na mesma VM. RepliC gerencia as r eplicas dos bancos de dados de tal forma que as falhas n ao sejam percebidas para o cliente. RepliC implementa um agente para vericar o estado da VM e do SGBD com o objetivo de detectar falhas. As m aquinas virtuais s ao organizadas para comportar as r eplicas dos grupos de atualiza c ao e leitura. As r eplicas de cada grupo s ao organizadas logicamente em uma topologia em anel. Com isso, as falhas podem ser detectadas pelas r eplicas adjacentes. A persist encia dos dados e realizada por meio de um servi co de armazenamento em nuvem, por exemplo, Amazon S3. Assim, quando uma transa c ao e conrmada e persistida, pode-se garantir que na presen ca de falhas, os dados podem ser recuperados por meio deste servi co. Para as transa co es de atualiza c ao, durante o processo de consolida ca o, o log e os registros consolidados s ao armazenados em um servi co de armazenamento 82
5.6. Conclus ao
83
distribu do para garantir a durabilidade. Similar a [Savinov and Daudjee, 2010], se a r eplica prim aria falhar, a transa ca o pode ser recuperada por meio de uma arquivo de log que armazena as transa c oes a serem executadas. No caso de falha em uma r eplica secund aria ou slave, novas transa co es n ao s ao enviadas transa co es para estas r eplicas e as mesmas s ao removidas do sistema. Caso esta r eplica se torne novamente operacional, um processo para vericar o estado da r eplica e executado e a adi ca o da r eplica e realizada. Caso contr ario, uma nova r eplica secund aria ou slave e criada. Neste trabalho, o processo de recupera ca o das r eplicas n ao e abordado. Contudo, o processo de recupera c ao proposto por [Perez-Sorrosal et al., 2011] pode ser utilizado com pequenos ajustes. CONCLUSAO
5.6
Este cap tulo apresentou a estrat egia para consist encia de banco de dados multi-inquilino utilizada pelo RepliC. Esta estrat egia n ao possui os problemas dos protocolos tradicionais, tais como c opia prim aria e r eplica ativa. A especica ca o e os algoritmos desenvolvidos tamb em foram apresentados. Por m, foram discutidos quest oes de toler ancia a falhas. A abordagem para tratar falhas utilizada pelo RepliC n ao apresenta um ponto de falha u nico, melhorando a disponibilidade. O pr oximo cap tulo apresenta os experimentos realizados e uma an alise dos resultados obtidos com o uso do RepliC.
83
CAP ITULO 6
EXPERIMENTAL AVALIAC AO
Este cap tulo descreve a implementa ca o do RepliC e a avalia c ao experimental realizada. S ao apresentadas as diferen cas no processo de avalia c ao de servi cos de dados em nuvem e, ao nal, os resultados obtidos considerando diversas caracter sticas de um ambiente de banco de dados replicado em nuvem. INTRODUC AO
6.1
A abordagem RepliC foi desenvolvida em conjunto com nossa camada de software Quality of Service for Database in the Cloud (QoSDBC) [Sousa et al., 2012]. O QoSDBC implementa o modelo de qualidade descrito nesta tese e simplica a utiliza c ao de SGBDs em nuvem. Esta camada e desenvolvida como uma PaaS e pode ser facilmente integrada a `s diferentes infraestruturas existentes.
6.1.1
Arquitetura do QoSDBC
A arquitetura do QoSDBC e dividida em tr es partes: QoSDBCDriver, QoSDBCCoordinator e Agente. O QosDBCDriver e o componente que fornece acesso ao sistema. Este driver substitui o driver JDBC espec co do banco de dados, mas oferece a mesma interface sem a necessidade de modica c oes no SGBD. O QoSDBCCoordinator consiste de um conjunto de servi cos que tratam do gerenciamento das r eplicas. O Agente e o componente adicionado em cada VM, sendo respons avel por coletar, monitorar e interagir com a VM e o SGBD, bem como vericar o estado dos itens monitorados, por exemplo, se os mesmos est ao operacionais ou indispon veis. Uma vis ao geral da arquitetura do QoSDBC pode ser observada na Figura 6.1. O Servi co de Monitoramento e respons avel por gerenciar as informa c oes coletadas pelo Agente sobre o estado das VMs e dos SGBDs. Um cat alogo armazena as informa c oes coletadas e as restri c oes sobre os recursos necess arios para a execu c ao. O Servi co de SLA 84
6.1. Introdu c ao
85
Figura 6.1 Arquitetura do QoSDBC.
gerencia o acordo de n vel de servi co acertado entre o usu ario e o provedor do servi co. O Servi co de Balanceamento realiza a distribui c ao das requisi co es entre as r eplicas. O Servi co de Provisionamento utiliza as informa co es dos demais m odulos para denir os recursos necess arios de forma a garantir a qualidade do servi co e o gerenciamento das r eplicas. Por m, o Servi co de Escalonamento enumera e seleciona os recursos a serem utilizados para a execu c ao das requisi co es e o log armazena as transa c oes a serem executadas. Servi co de Monitoramento O Servi co de Monitoramento gerencia as informa c oes coletadas pelo Agente. Este servi co monitora informa c oes sobre cada VM e SGBD, estat sticas da carga de trabalho, consulta informa co es sobre os recursos necess arios para os SGBDs e sobre os recursos dispon veis na infraestrutura. Essas informa c oes s ao utilizadas para denir a adi c ao ou remo ca o dos SGBDs das VM e provisionar recursos de forma a garantir a qualidade do servi co. As informa c oes s ao armazenadas no cat alogo e continuamente atualizadas para
85
6.1. Introdu c ao
86
ajustar os outros servi cos. As seguintes informa c oes s ao monitoradas para cada VM: estado da VM, recursos de CPU, mem oria e disco. Para cada SGBD s ao monitoradas as informa co es sobre os recursos de CPU, mem oria e tamanho das bases de dados utilizadas, assim como as m etricas denidas no SLA. Servi co de SLA O Servi co de SLA cont em informa c oes sobre o acordo de n vel de servi co acertado entre o usu ario e o provedor do servi co. Estas informa c oes est ao relacionadas a `s deni co es do SLA, tais como o tempo de resposta, vaz ao, disponibilidade e consist encia. Este servi co fornece par ametros para o Servi co de Monitoramento vericar os valores denidos e ajustar os demais servi cos. Servi co de Balanceamento O Servi co de Balanceamento de carga recebe as transa co es enviadas ao sistema e as direciona para as r eplicas de acordo com uma estrat egia de la circular ou baseada na utiliza ca o de recursos. Este servi co evita que as VMs e r eplicas tornem-se sobrecarregadas enquanto outras est ao subutilizadas. O equil brio de carga e realizado direcionando as transa co es por meio do QoSDBCDriver. Servi co de Provisionamento O Servi co de Provisionamento utiliza informa co es dos outros servi cos para provisionar os recursos. RepliC dene como e quando uma r eplica deve ser adicionada ou removida. A carga de trabalho e distribu da entre as r eplicas com recursos sucientes para execut a-las de forma que o SLA seja satisfeito. Este servi co tamb em decide como os recursos devem ser compartilhados entre os v arios inquilinos. A infraestrutura em nuvem permite um r apido provisionamento de recursos por meio de t ecnicas de virtualiza ca o, o que melhora o impacto de cargas de trabalho com grandes varia co es. Servi co de Escalonamento Este servi co enumera e seleciona os recursos provisionados. Para tanto, o escalonador gerencia as r eplicas, garantindo o acesso ao SGBD durante e ap os o processo de replica ca o. Este processo consiste em gerenciar as transa c oes e direcion a-las para os SGBDs 86
6.1. Introdu c ao
87
em execu c ao. As opera co es s ao analisadas e a transa ca o e direcionada a uma r eplica do grupo de atualiza ca o ou de leitura dependendo do seu conte udo. Este servi co mant em uma c opia das u ltimas transa co es submetidas para auxiliar na replica ca o. Cada SGBD e respons avel pelo processamento interno e otimiza c ao local.
6.1.2
Implementa c ao
A implementa c ao do RepliC baseou-se no nosso sistema anterior [Sousa et al., 2007], uma vez que este sistema possui uma solu ca o para a replica c ao de banco de dados. Por decis oes de projeto, optou-se por desenvolver RepliC servindo-se da linguagem Java. Caracter sticas como portabilidade, reusabilidade, processamento distribu do e multithreading s ao propriedades desta linguagem que favorecem um desenvolvimento con avel. Em rela ca o ao sistema de comunica ca o em grupo, que implementa as primitivas FIFO e de ordena ca o total, optou-se pela utiliza ca o do sistema Spread [Spread, 2012], que possui c odigo aberto, o que facilita seu uso principalmente no ambiente acad emico. A solu ca o desenvolvida foi implementada na infraestrutura da Amazon. O monitoramento dos recursos e realizado por meio de consultas utilizando a API do Amazon EC2 CloudWatch. Os dados monitorados s ao armazenados no sistema de banco de dados Amazon SimpleDB. Foi utilizada a API Java fornecida pela Amazon EC2 para iniciar, terminar ou recongurar as VMs. Uma Amazon Machine Image (AMI) contendo o SGBD e o agente foi criada, permitindo iniciar uma nova VM rapidamente. Para armazenar e compartilhar os snapshots do banco de dados foi utilizado o Amazon Elastic Block Store (EBS). Para o processo de migra ca o de dados, foi utilizada a ferramenta de backup Xtrabackup [Percona, 2012], que permite backup quente sem interromper o processamento de transa c oes [Barker et al., 2012]. RepliC aproveita a fun ca o de backup quente para obter uma c opia consistente do banco de dados e para iniciar uma nova r eplica. Foi utilizada a ferramenta Linux pv, que permite limitar a quantidade de dados enviados por meio do pipe Unix, para evitar a interfer encia entre o SGBD e o processo de backup/restore. Esta abordagem limita efetivamente o uso de recursos para a CPU e I/O. Em rela ca o a `s deni co es do QoS, existem algumas linguagens para denir SLA, principalmente para servi cos web, tais como WSLA, WSOL ou SLAang [Schnjakin et al., 2010]. Estas linguagens permitem o processamento e automa c ao de tal forma a expressar as 87
6.2. Avalia ca o
88
necessidades dos clientes e informa co es dos provedores. O RepliC utiliza uma vers ao simplicada da linguagem WSLA [Keller and Ludwig, 2003] para lidar com a gest ao dos SLAs. A linguagem WSLA consiste de uma linguagem extens vel baseado em XML Schema e permite a deni c ao de SLAs individuais e personalizados. Mais detalhes sobre a implementa ca o podem sem obtidos em [Sousa et al., 2007] [QoSDBC, 2012]. AVALIAC AO
6.2
A avalia c ao de SGBDs em nuvem apresenta diferen cas signicativas em rela c ao a ` avalia ca o dos SGBDs executados em infraestruturas convencionais. Estes SGBDs pressup oem a exist encia de congura co es xas de recursos, tratam exclusivamente da otimiza ca o de desempenho e tem como objetivo minimizar o tempo de resposta para cada requisi ca o. Essa vis ao n ao considera os custos operacionais do sistema. Entretanto, o modelo de pagamento baseado no uso da computa c ao em nuvem requer que os custos operacionais sejam considerados juntamente com o desempenho. No ambiente em nuvem, o objetivo e minimizar a quantidade de recursos necess arios para garantir uma meta de qualidade para cada requisi ca o e, com isso, o custo operacional e um par ametro importante [Florescu and Kossmann, 2009]. Existem muitos benchmarks para SGBDs relacionais executados em infraestruturas tradicionais, tais como os benckmarks do tipo TPC [TPC, 2012], que s ao amplamente utilizados para avaliar o desempenho de diferentes SGBDs. SGBDs em nuvem apresentam caracter sticas que n ao fazem parte dos par ametros avaliados pelos benchmarks TPC, tais como a elasticidade. Estes sistemas s ao el asticos e, sendo assim, t em a capacidade de melhorar a sua congura c ao durante a execu ca o da carga de trabalho. Al em disso, os benchmarks TPC consideram que o sistema a ser avaliado e baseado em transa c oes com as propriedades ACID, que n ao s ao utilizadas em muitos sistemas em nuvem. Estes pontos indicam que os atuais benchmarks padr ao para os SGBDs devem ser repensados [Florescu and Kossmann, 2009]. O problema de padroniza ca o de benchmarks para avaliar SGBDs em nuvem e um desao. Isso se deve principalmente a ` diversidade de SGBDs em nuvem e a forma como estes sistemas s ao constru dos, visto que as implementa co es variam em termos de modelo de dados, n veis de consist encia, expressividade da linguagem de acesso aos dados, entre outros [Sousa et al., 2010]. Devido a ` elasticidade e ao tamanho destes sistemas, que podem possuir centenas ou milhares de m aquinas, alguns problemas podem n ao ocorrer 88
6.2. Avalia ca o
89
at e que um determinado cen ario seja alcan cado. Com isso, o desenvolvimento de um benchmark que aborde todos os poss veis casos de uso do sistema e muito dif cil e invi avel. [Florescu and Kossmann, 2009] destacam que sistemas de benchmarks para o gerenciamento de dados devem tratar de aspectos de custo, tempo de resposta, vaz ao, escalabilidade, consist encia, exibilidade e discutem como estes aspectos podem impactar na arquitetura dos SGBDs. [Binnig et al., 2009] discutem por que benchmarks tradicionais n ao s ao sucientes para analisar os novos servi cos em nuvem e apresentam id eias para o desenvolvimento de um novo benchmark. Em [Cooper et al., 2010] e apresentado o Yahoo! Cloud Serving Benchmark (YCSB), framewok com o objetivo de facilitar a avalia ca o de diferentes SGBDs chave/valor em nuvem. Este framewok trata caracter sticas de desempenho e escalabilidade, mas ainda n ao aborda aspectos de disponibilidade e replica ca o. O trabalho [Folkerts et al., 2012] discute requisitos, tais como elasticidade e variabilidade da carga de trabalho que devem ser tratados na concep c ao de um novo benchmark para nuvem. [Huppler, 2011] discute que os benchmarks TPC n ao reetem os aspectos atuais de custo da ind ustria e prop oe sugest oes sobre custo, desempenho e disponibilidade que devem ser contemplados pelos novos benchmarks. Em [Sethuraman and Taheri, 2011] e proposto o TPC-V, um benchmark para avaliar o desempenho de SGBDs em ambientes virtualizados. [Kossmann et al., 2010] apresentam uma extens ao do benchmark TPC-W com m etricas que contemplam diferentes n veis de consist encia, escalabilidade, custo, carga de trabalho din amica e toler ancia a falhas. Essas novas m etricas permitem medir aspectos din amicos dos SGBDs em nuvem. Para ambientes multi-inquilino, e essencial utilizar um benchmark para avaliar SGBDs multi-inquilino. De acordo com [Hui et al., 2009], n ao existe um benchmark padr ao para esta tarefa e eles prop oem uma estrat egia para gerar um esquema de banco de dados TPC-C extens vel. Contudo, esta estrat egia foca no modelo multi-inquilino de tabela e n ao permite trabalhar com outros modelos. [Ahmad and Bowman, 2011] [Kiefer et al., 2012] utilizam m ultiplas inst ancias dos benchmarks TPC-C e TPC-H para simular um ambiente multi-inquilino. Essas estrat egias n ao modelam um ambiente multiinquilino completo, pois utilizam uma u nica aplica ca o.
89
6.2. Avalia ca o
90
6.2.1
Benchmark
Para fornecer um ambiente de banco de dados multi-inquilino completo para a avalia c ao do RepliC, este trabalho utilizou uma nova estrat egia com diferentes bancos de dados. Essa estrat egia modela um ambiente similar a um cen ario real de nuvem. Estes bancos s ao fornecidos pelo framework OLTPBenchmark [Curino et al., 2012]. O OLTPBenchmark e um framework para avaliar o desempenho de diferentes SGBDs relacionais diante de congura co es de cargas de trabalho OLTP. O framework possui diversos benchmarks que representam diferentes aplica c oes, tais como TPC-C, Twitter, YCSB, AuctionMark, Wikipedia. O OLTPBenchmark possibilita congurar a taxa de transa c oes, denir o percentual de cada tipo de transa c ao por tempo de experimento, obter informa c oes sobre vaz ao, m edia do tempo de resposta e informa co es sobre utiliza ca o dos recursos de SGBD e do sistema operacional. Este framework utiliza o padr ao JDBC para a conex ao com o SGBD. Ambiente de Avalia c ao A infraestrutura da Amazon foi utilizada neste trabalho. Esta infraestrutura oferece VMs nas quais pode-se instalar e executar os SGBDs. Assim, uma imagem de VM com um SGBD pr e-instalado e pr e-congurado est a dispon vel para a implanta c ao de forma simples e r apida [Aboulnaga et al., 2009]. As VMs s ao diferenciadas pelos recursos que elas oferecem, tais como CPU, mem oria e espa co em disco. Neste trabalho utilizou-se apenas inst ancias de VM do tipo small na mesma zona de disponibilidade (us-west-1c). Cada inst ancia possui um processador Xeon 2.4 GHz, 1.7 GB de mem oria, 160 GB de disco e utiliza o sistema operacional Ubuntu 12.04, SGBD MySQL 5.5 com engine InnoDB e 128 MB de buer. As IaaS fornecem servi cos de armazenamento e transfer encia de dados, por exemplo o Amazon EBS, normalmente com custos adicionais referentes a quantidade de dados armazenados e de requisi co es de E/S. Estes custos dos servi cos de armazenamento s ao relativamente menores do que os custos associados a `s VMs e alguns provedores n ao cobram por estes servi cos. RepliC utiliza os recursos de forma eciente por meio da adi c ao e remo c ao de r eplicas e do compartilhamento de recursos, o que auxilia na redu ca o dos custos operacionais e reete nos custos monet arios. Entretanto, neste trabalho, n ao s ao considerados os custos monet arios, visto que cada provedor utiliza uma estrat egia dife90
6.2. Avalia ca o
91
rente de tarifa ca o (apenas os valores relativos a `s m aquinas virtuais s ao contabilizados). Os SGBDs persistem os dados, que consistem de logs e snapshots, em um sistema de armazenamento distribu do ou em um Network-Attached Storage (NAS) [Das et al., 2011]. Por exemplo, um NAS oferece um armazenamento escal avel, altamente dispon vel e tolerante a ` falhas para persistir os dados dos clientes. Esta arquitetura e diferente de sistemas de disco compartilhado que utiliza um controle entre opera co es concorrentes [Bernstein and Newcomer, 2009]. Esta dissocia c ao da propriedade de armazenamento auxilia na migra ca o dos dados entre as r eplicas e e utilizada por sistemas como o Amazon EBS. Para estes experimentos, utilizou-se uma vers ao simplicada do modelo de qualidade proposto neste trabalho. Esta vers ao considerou a m etrica de tempo de reposta. Foram denidos tr es servi cos, onde cada um destes possui um banco de dados (r eplicas s ao adicionadas e removidas de acordo com a qualidade) e um SLA (tempo de resposta) associado a este servi co. De acordo com o OLTPBenchmark, os seguintes bancos de dados foram gerados: AuctionMark (450 MB), Wikipedia (600 MB) e YCSB (600 MB). Foram usadas todas as transa co es com os pesos padr oes denidos pelo OLTPBenchmark. Os seguintes valores de tempo de resposta foram denidos para cada servi co: AMSLA = 1s, W ikiSLA = 0.1s , Y CSBSLA = 0.2s e percentil de 95% em rela ca o ao tempo de resposta. Experimentos utilizando a vers ao completa do modelo de qualidade proposta neste trabalho podem ser encontrados em [Sousa et al., 2011b].
6.2.2
Experimentos
Elaborar e construir experimentos que representam aplica co es reais e complexo, assim como comparar diferentes abordagens para o gerenciamento de dados em nuvem. A compara ca o direta com os trabalhos relacionados e invi avel de ser realizada, visto que cada trabalho elenca um conjunto de pressupostos pr oprios. Dessa forma, n ao foram realizados experimentos diretos comparando RepliC e os trabalhos relacionados. Dessa forma, a avalia ca o deste trabalho buscou analisar as diversas caracter sticas contempladas pelo RepliC. Cada experimento explora um aspecto diferente de um SGBD replicado em nuvem, tais como elasticidade e qualidade do servi co, incluindo quest oes de penalidades. Estes experimentos foram baseados na avalia ca o dos trabalhos propostos por [Cecchet et al., 2011], [Xiong et al., 2011] e [Bonvin et al., 2011]. A varia ca o da taxa de 91
6.2. Avalia ca o
92
transa co es foi utilizada para avaliar a elasticidade e qualidade dos servi cos considerados. RepliC foi comparado com uma estrat egia de provisionamento reativo similar a um sistema de auto escalonamento, por exemplo, o Amazon Auto Scaling. Este tipo de sistema utiliza uma abordagem orientada a recursos e seu comportamento segue um conjunto de regras pr e-denidas. Uma regra neste sistema e formado por um par de informa co es contendo um antecedente e um consequente. Neste trabalho, a seguinte regra foi denida: uma VM e adicionada quando a m edia de utiliza c ao da CPU excede 80% por um per odo cont nuo de 2 minutos; uma VM e removida quando a utiliza c ao da CPU e menor do que 20% pelo mesmo per odo [Islam et al., 2012]. A estrat egia de provisionamento reativo implementa o protocolo de c opia prim aria. Para RepliC e para esta estrat egia, inicialmente, duas r eplicas foram utilizadas, cada uma destas em um dos grupos. Contudo, para atender um SLA mais restrito, uma quantidade maior de r eplicas pode ser inicializada. Na congura ca o de provisionamento reativo, todas as r eplicas prim arias de cada servi co foram alocadas em uma mesma VM, visto que seria complexo adaptar o protocolo de c opia prim aria para trabalhar com r eplicas prim arias em diferentes VMs. Na congura ca o do RepliC, a aloca ca o foi a seguinte: V M1 ={AMP rimario , W ikiSlave , Y CSBSlave } e V M2 ={AMSlave , W ikiP rimario , Y CSBP rimario }.
6.2.3
Resultados
Qualidade de servi co No primeiro experimento para avaliar a qualidade, a taxa de transa c oes do servi co YCSB foi incrementada e a taxa dos servi cos AM e Wiki foram xadas durante toda a avalia ca o. Este experimento consistiu em aumentar a taxa de transa c oes a cada 20 minutos. O intervalo para aumentar a taxa e similar ao trabalho proposto por [Cecchet et al., 2011]. Para os servi cos AuctionMark (AM) e Wiki, a taxa foi xada em 1000. Todos os servi cos foram executados com 100 clientes/terminais. A Figura 6.2 (a) mostra a varia c ao da m etrica de tempo de resposta do SLA com o provisionamento reativo/c opia prim aria quando a taxa do YCSB foi incrementada. Podese observar que o tempo de resposta do YCSB aumentou quando a taxa foi aumentada. A estrat egia reativa demora um longo per odo para identicar o aumento do tempo de 92
6.2. Avalia ca o
93
resposta. Isso ocorre porque esta estrat egia e orientada a recursos e o limite para tomar a decis ao para adicionar uma nova r eplica n ao foi atingido. Somente quando a taxa atingiu o valor de 3000, uma nova r eplica slave do YCSB foi adicionada ao sistema.
Figura 6.2 Aumento da taxa do servi co YCSB - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC
A Figura 6.2(b) apresenta o resultado com RepliC. Com o aumento da taxa do YCSB, a estrat egia de monitoramento do RepliC identicou a varia ca o do tempo de resposta decorrente do aumento da taxa de transa c oes e uma nova VM com uma r eplica prim aria do YCSB e adicionada. Neste experimento, n ao ocorreu interfer encia entre o YCSB e os servi cos. A Tabela 6.1 mostra a quantidade de VMs e a aloca ca o das r eplicas para o primeiro experimento. As r eplicas prim arias s ao destacadas, por exemplo, A, W e Y representam r eplicas prim arias dos servi cos AM, Wikipedia e YCSB, respectivamente. Neste experimentos, as duas estrat egias utilizaram a mesma quantidade de VMs, sendo que RepliC iniciou uma nova VM primeiramente, quando a taxa alcan cou o valor de 2000 e instanciou duas r eplicas prim arias do servi co YCSB. No segundo experimento de qualidade, as taxas de transa c oes de todos os servi cos foram aumentadas simultaneamente. A Figura 6.3(a) mostra a varia ca o da m etrica de tempo de resposta do SLA com o provisionamento reativo quando a taxa dos servi cos AM, Wiki e YCSB foram incrementados. Neste experimento, inicialmente, o tempo de resposta aumentou rapidamente para todos os servi cos. Duas VMs com r eplicas slave de todos os bancos de dados s ao adicionados quando a taxa aumenta para 2000. A c opia prim aria utilizada pelo provisionamento reativo tem um limite para gerenciar as transa c oes. Assim, o sistema tornou-se sobrecarregado e a 93
6.2. Avalia ca o
94
Taxa 1000 2000 3000 4000 5000 Taxa 1000 2000 3000 4000 5000
Provisionamento Reativo
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={Y} V M2 ={A,W,Y}, V M3 ={Y} V M2 ={A,W,Y}, V M3 ={Y} V M2 ={A,W,Y} V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y},
RepliC
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M3 ={Y} V M3 ={Y} V M3 ={Y} V M3 ={Y}
Tabela 6.1 Aloca c ao das r eplicas durante o primeiro experimento de QoS.
c opia prim aria teve problemas para processar e enviar as atualiza co es para as r eplicas slaves. Em adi ca o, ocorreram muitas interfer encias entre os bancos de dados executados na mesma VM, visto que esta cont em todas as c opias prim arias. Isso ocasiona um aumento no tempo de resposta e na viola ca o do SLA.
Figura 6.3 Aumento da taxa de todos os servi cos - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC
O resultado do RepliC e apresentado na Figura 6.3(b). O tempo de reposta aumentou, mas RepliC adicionou duas VMs com r eplicas prim arias e slaves para cada servi co. Com a estrat egia de monitoramento e a verica ca o das interfer encias entre as r eplicas, RepliC identicou a condi c ao em que as r eplicas podem ser executadas com menor viola ca o do SLA. RepliC melhorou o tempo de resposta distribuindo as transa c oes 94
6.2. Avalia ca o
95
de atualiza c ao entre as r eplicas prim arias. Em adi ca o, a aloca c ao eciente das r eplicas prim arias em diferentes VMs foi um ponto fundamental para melhorar o desempenho do sistema. Neste experimento, RepliC armazenou as regras sobre a interfer encia entre os bancos de dados, principalmente entre o AM e YCSB. Essas informa c oes podem ser utilizadas em execu c oes posteriores. A Tabela 6.2 mostra a quantidade de VMs e a aloca ca o das r eplicas para o segundo experimento de QoS. Neste experimento foram utilizadas a mesma quantidade de VMs. Contudo, e importante observar que RepliC inicializou primeiramente a V M3 quando a taxa atingiu o valor de 1500 e a r eplica do YCSB na V M4 e prim aria, contribuindo para a melhoria da qualidade.
Taxa 1000 1500 2000 2500 3000 Taxa 1000 1500 2000 2500 3000
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={A,W,Y}, V M4 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={A,W,Y}, V M4 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={A,W,Y}, V M4 ={A,W,Y} V M2 ={A,W,Y} V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y},
RepliC
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M3 ={A,W,Y}, V M3 ={A,W,Y}, V M3 ={A,W,Y}, V M3 ={A,W,Y}, V M4 ={A,W,Y} V M4 ={A,W,Y} V M4 ={A,W,Y} V M4 ={A,W,Y}
Tabela 6.2 Aloca c ao das r eplicas durante o segundo experimento de QoS.
Elasticidade Para analisar a elasticidade, um experimento foi realizado variando a taxa de transa co es ao longo do tempo. No primeiro experimento de elasticidade, a taxa de transa co es do servi co YCSB foi aumentada/decrementada de acordo com a sequencia apresentada na Tabela 6.3. Os servi cos AM e Wiki utilizam valores xos com as mesmas taxas do primeiro experimento de QoS. A Figura 6.4(a) mostra a varia c ao da m etrica de tempo de resposta do SLA para a estrat egia de provisionamento reativo. Com o aumento da taxa de transa co es do 95
6.2. Avalia ca o
96
Tempo 20 40 60 80 100
Taxa YCSB 1000 5000 1000 1000 3000
Tabela 6.3 Taxa de transa c oes para o servi co YCSB durante o primeiro experimento de elasticidade.
YCSB, uma nova VM com uma r eplica slave do YCSB foi adicionada, que recebeu parte das transa co es e o tempo de resposta do YCSB diminui. Contudo, no tempo 60, com a diminui c ao da carga de trabalho, o limite da CPU n ao e atingido (isto e, 20%) e a VM n ao foi removida. O provisionamento reativo utiliza uma estrat egia orientada a recursos e n ao existe uma rela ca o linear entre os recursos alocados e o SLA. Assim sendo, esta estrat egia n ao trabalha bem com a elasticidade para sistemas que mant em o estado, por exemplo, SGBDs.
Figura 6.4 Elasticidade do servi co YCSB - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC
O resultado do RepliC neste experimento e apresentado na Figura 6.4(b). Com o aumento na carga do YCSB, uma nova VM com uma r eplica slave do YCSB foi adicionada e o SLA foi garantido. Com a diminui ca o da carga de trabalho, a r eplica foi removida, mesmo com o SGBD mantendo os recursos atuais alocados, uma vez que o tempo de resposta melhorou. Por m, uma nova r eplica slave do YCSB e adicionada no tempo 100, quando a carga aumentou para 3000. Isso est a relacionado ` a estrat egia de monitoramento do RepliC, que identica a varia ca o da carga de trabalho e do tempo de resposta. Assim, 96
6.2. Avalia ca o
97
RepliC alterou a quantidade de r eplicas rapidamente. A Tabela 6.4 mostra a quantidade de VMs e a aloca ca o das r eplicas para o primeiro experimento de elasticidade. Neste experimento, RepliC utilizou uma quantidade menor de VMs, visto que uma r eplica do YCSB foi adicionada no instante de tempo 40 e removida no tempo 60. J a a estrat egia de provisionamento reativo mant em a quantidade de VMs constante ap os a adi ca o da r eplica do YCSB no tempo 40.
Tempo 20 40 60 80 100 Tempo 20 40 60 80 100
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M3 ={Y} V M3 ={Y} V M3 ={Y} V M3 ={Y}
RepliC
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={Y} V M2 ={A,W,Y} V M2 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={Y}
Tabela 6.4 Aloca c ao das r eplicas durante o primeiro experimento de elasticidade.
No segundo experimento de elasticidade, a taxa de transa co es foi alterada para todos os servi cos simultaneamente. A Tabela 6.5 mostra a taxa de cada servi co durante este experimento. Tempo 20 40 60 80 100 AM 1000 5000 5000 1000 1000 Taxa Wiki 1000 5000 1000 5000 1000 YCSB 1000 2000 1000 2000 1000
Tabela 6.5 Taxa de transa c oes para cada servi co durante o segundo experimento de elasticidade.
A Figura 6.5(a) mostra a varia c ao da m etrica do tempo de resposta com o provisionamento reativo de acordo com a Tabela 6.5. No tempo 40, com o aumento da taxa 97
6.2. Avalia ca o
98
Figura 6.5 Elasticidade para todos os servi cos - (a) Tempo de resposta com o Provisionamento Reativo - (b) Tempo de resposta com RepliC
dos servi cos AM e Wiki, o tempo de resposta aumentou para todos os servi cos. Assim, duas novas r eplica slave do banco de dados foram adicionadas. No tempo 60, com a diminui c ao da carga do Wiki, o tempo de resposta continuou elevado. O tempo de resposta melhorou no nal do experimento, quando a taxa de transa c oes de todos os servi cos diminuiu. Este comportamento est a relacionado com a diculdade de gerenciar o aumento e diminui c ao da carga de trabalho, principalmente devido a ` interfer encia entre os banco de dados executando na mesma VM e a sobrecarga da c opia prim aria. A Figura 6.5(b) apresenta o resultado com RepliC. Com o aumento da carga de trabalho, RepliC adicionou duas novas VMs com r eplicas prim arias e slaves dos servi cos AM e Wiki. Assim, o tempo de resposta diminuiu. No tempo 60, a carga de trabalho do Wiki diminuiu e RepliC removeu uma r eplica deste servi co. No tempo 80, RepliC adicionou uma nova r eplica slave do Wiki. RepliC reusou as regras armazenadas sobre a interfer encia entre o AM e o YCSB ocorrida durante o segundo experimento de QoS, reduzindo a viola c ao do SLA. No experimento de elasticidade, RepliC tamb em utilizou uma quantidade menor de VMs, j a que r eplicas dos servi cos Wiki e AM s ao adicionadas e removidas durante o experimento, conforme mostra a Tabela 6.6. Viola c ao do SLA A Tabela 6.7 mostra a viola ca o do SLA para os experimentos anteriores. No primeiro experimento de QoS, o provisionamento reativo apresentou 39% de viola c ao do SLA para o servi co YCSB. RepliC garante melhor qualidade com a mesma quantidade de recursos. 98
6.2. Avalia ca o
99
Tempo 20 40 60 80 100 Tempo 20 40 60 80 100
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M2 ={A,W,Y}, V M3 ={W, V M3 ={W, V M3 ={W, V M3 ={W, AM}, AM}, AM}, AM}, V M4 ={W, V M4 ={W, V M4 ={W, V M4 ={W, AM} AM} AM} AM}
RepliC
V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M1 ={A,W,Y}, V M2 ={A,W,Y} V M2 ={A,W,Y}, V M3 ={A, W}, V M4 ={A,W} V M2 ={A,W,Y}, V M3 ={A, W}, V M4 ={A} V M2 ={A,W,Y}, V M3 ={A, W}, V M4 ={A,W} V M2 ={A,W,Y}
Tabela 6.6 Aloca c ao das r eplicas durante o segundo experimento de elasticidade.
Uma raz ao para isso e que as transa c oes foram distribu das entre as r eplicas dos grupos de atualiza c ao e leitura, melhorando o processamento. No segundo experimento de QoS, a estrat egia reativa apresentou um resultado de desempenho inferior comparado com RepliC. Contudo, os valores de viola ca o do RepliC aumentaram consideralmente. Isto e devido ao fato de que mais mensagens foram enviadas do grupo de atualiza c ao para o grupo de leitura. Nesses experimentos, RepliC teve menor viola c ao do SLA do que a estrat egia reativa. Provisionamento Reativo AM Wiki YCSB 12% 7% 39% 20% 35% 47% 14% 16% 27% 26% 25% 51% RepliC AM Wiki 1% 3% 14% 10% 6% 5% 12% 14%
Experimento 1 Experimento 2 Experimento 1 Experimento 2 Experimento
QoS QoS Elastic Elastic
YCSB 14% 20% 15% 16%
Tabela 6.7 Viola c oes de SLA.
No primeiro experimento de elasticidade, RepliC apresentou menor viola ca o SLA, especialmente para o servi co YCSB, onde ocorreu a varia c ao na taxa de transa co es. Para o segundo experimento, a estrat egia reativa teve um alto valor de viola c ao para todos os servi cos. Por sua vez, RepliC gerenciou melhor a varia c ao da carga de trabalho e a interfer encia entre os bancos de dados.
99
6.3. Conclus ao
100
A estrat egia de sincroniza ca o do RepliC melhorou o desempenho, visto que esta estrat egia atualiza inicialmente somente as r eplicas do grupo de atualiza ca o e n ao possui apenas uma r eplica prim aria. A aloca c ao eciente da r eplica prim aria foi um ponto determinante para melhorar o tempo, pois estas r eplicas foram distribu das entre as VMs. Em adi ca o, a abordagem RepliC reduz a interfer encia entre as r eplicas slave e prim aria, sendo estas u ltimas respons aveis por enviar atualiza c oes para as r eplicas slaves. Durante a execu ca o destes experimentos, foi observada uma pequena quantidade de aborts (menos de 3%) no grupo de atualiza ca o, devido ao teste de certica ca o. A m edia do tempo de resposta para adicionar uma nova VM foi 55 segundos usando a AMI criada. De uma forma geral, RepliC utilizou a mesma quantidade de VMs em todos os experimentos, exceto no primeiro experimento de QoS e no segundo experimento de elasticidade. Contudo, nestes casos, RepliC utilizou apenas uma VM adicional, mas garantindo o QoS, que conrmaram que essa abordagem utilizou os recursos ecientemente. CONCLUSAO
6.3
Este cap tulo descreveu a implementa c ao e avalia ca o do RepliC. Foi justicada a escolha dos sistemas utilizados, os detalhes da implementa ca o foram descritos, al em do modelo e do ambiente de avalia ca o. Ao nal, foram apresentados os resultados obtidos na avalia ca o do RepliC. Os resultados demostraram que a abordagem RepliC garante a qualidade do servi co em diferentes cen arios com pequena viola ca o do SLA. Al em disso, RepliC utiliza os recursos de forma eciente por meio da estrat egia multi-inquiino utilizada. O cap tulo a seguir apresenta as conclus oes deste trabalho.
100
CAP ITULO 7
CONCLUSAO
Este cap tulo apresenta as conclus oes desta tese e uma discuss ao sobre dire co es para poss veis trabalhos futuros. CONCLUSOES
7.1
As principais conclus oes desta tese s ao:

A abordagem RepliC melhora a qualidade de servi co para banco de dados multi-
inquilino em nuvem. O modelo multi-inquilino adotado permite compartilhar os recursos de forma eciente. As estrat egias de replica c ao, elasticidade e migra ca o, associadas ` as caracter sticas da infraestrutura em nuvem garantem a qualidade de servi co por meio da adi ca o e remo ca o de r eplicas. O processo de gerenciamento dos dados e autom atico, melhorando a administra ca o das r eplicas e da infraestrutura.
O modelo de qualidade SLADB contempla os conceitos de SLA para banco de dados
em nuvem, tais como tempo de resposta, vaz ao, disponibilidade e consist encia. Este modelo e uma solu c ao para auxiliar a qualidade de servi co, pois aborda diferentes quest oes, como a deni c ao do SLA, t ecnicas de monitoramento e penalidades. As t ecnicas de monitoramento utilizadas pelo SLADB evitam que varia co es pontuais na carga de trabalho interram na qualidade de servi co.
A arquitetura QoSDBC e modular e ex vel, o que facilita sua integra c ao a qualquer
infraestrutura, uma vez que todas as informa co es necess arias para sua utiliza ca o s ao extra das dos SGBDs e das infraestruturas por meio de agentes de monitoramento. Al em disso, QoSDBC pode ser estendida, adicionando novas caracter sticas.
A estrat egia para consist encia dos dados baseada em uma extens ao do nosso traba-
lho anterior para a replica ca o de dados XML implementa consist encia forte e n ao possui os problemas dos protocolos tradicionais, tais como c opia prim aria e r eplica 101
7.2. Trabalhos Futuros
102
ativa. As extens oes introduzidas permitiram sua execu c ao em ambientes virtualizados com sistemas de banco de dados multi-inquilinos, melhorando o desempenho e a disponibilidade.
O m etodo de avalia c ao de servi co de banco de dados multi-inquilino proposto nesta
tese modela um ambiente similar a um cen ario real de nuvem. Para isso, foi utilizado o OLTPBenchmark, que permite construir um ambiente de banco de dados multiinquilino e variar a carga de trabalho em fun ca o do tempo para implementar a elasticidade.
Os resultados dos experimentos realizados conrmaram que RepliC garantiu a qua-
lidade com uma pequena quantidade de viola c ao do SLA, enquanto utiliza os recursos de forma eciente, mesmo em cen arios com diferentes varia c oes da carga de trabalho. Estes resultados comprovam a nossa hip otese de que replica c ao el astica de banco de dados multi-inquilino melhora a qualidade de servi co e utiliza c ao de recursos em ambientes de nuvem.
7.2
TRABALHOS FUTUROS
Os trabalhos propostos como atividades a serem feitas posteriormente para dar continuidade a este trabalho s ao os seguintes: 1. Diferentes N veis de Consist encia RepliC foi desenvolvido para trabalhar com consist encia forte. Por outro lado, existe uma grande quantidade de aplica co es que n ao necessita de consist encia forte. De acordo com [Kraska et al., 2009], consist encia e custo est ao relacionados e devem ser considerados no desenvolvimento de solu co es em nuvem. Consist encia forte implica em alto custo por transa ca o e, em algumas situa co es, reduz a disponibilidade. Consist encia fraca apresenta menor custo. Em [Kraska et al., 2009] e apresentado um novo paradigma que permite aos desenvolvedores denir garantias de consist encia e o chaveamento autom atico destas garantias em tempo de execu ca o com o objetivo de minimizar os custos. Para garantir a disponibilidade e a toler ancia ` a falhas, os servi cos de dados em nuvem devem fornecem diferentes garantias de consist encia.
102
103
Devido a ` diversidade de aplica co es, pretende-se estender RepliC para implementar diferentes n veis, tais como consist encia fraca ou consist encia eventual. De acordo com os requisitos da aplica ca o em rela ca o ` a consist encia, um n vel de consist encia para o banco de dados desta aplica ca o poderia ser utilizado, adequando o custo a ` consist encia utilizada. Outro direcionamento seria adaptar novos protocolos de replica ca o e consist encia, tais como Paxos e Gossip ao RepliC, melhorando ainda mais o desempenho e disponibilidade. 2. Novos Modelos Multi-Inquilinos RepliC utiliza o modelo multi-inquilino de inst ancia, que permite um bom compartilhamento de recursos. Por outro lado, este modelo apresenta interfer encias entre os inquilinos. Nosso estudo [Moreira et al., 2012] apresenta uma an alise de um conjunto de experimentos para medir a varia ca o do desempenho de SGBDs multi-inquilino em nuvem. Esta an alise apresenta em detalhes as interfer encias e as suas poss veis causas, tais como a carga de trabalho e o tipo de SGBD utilizado. Neste contexto, as solu co es em nuvem devem alocar inquilinos com pouca interfer encia entre si. Para tanto, e necess aria uma an alise do perl do inquilino para identicar o n vel de interfer encia. Tamb em e importante isolar inquilinos suscet veis a ` interfer encia. Neste caso, outros modelos multi-inquilino podem ser utilizados, por exemplo, SGBD privado para inquilinos suscet veis a ` interfer encia. Al em disso, para diminuir tais interfer encias, e necess ario identicar o n vel de intera c ao entre os inquilinos e, consequentemente, melhorar a aloca ca o dos inquilinos de acordo com suas interfer encias. Em trabalhos futuros, pretende-se realizar experimentos com outros modelos multi-inquilinos n ao contemplados neste trabalho, assim como vericar o n vel de interfer encias em outros SGBDs e os recursos utilizados por cada inquilino. Outro aspecto importante e desenvolver t ecnicas para migrar inquilinos com muita interfer encia, melhorando o desempenho do sistema. Pretende-se tamb em realizar um estudo para elaborar uma estrat egia de aloca c ao para inquilinos na nuvem, visando diminuir as interfer encias. 3. Novos Experimentos de QoS Os experimentos realizados neste trabalho abordaram aspectos espec cos de elasticidade e QoS do sistema avaliado. Pretende-se realizar experimentos com cargas de trabalho
103
104
maiores e com varia co es em um menor intervalo de tempo. Tais experimentos permitir ao avaliar o comportamento do RepliC nestes cen arios e, se for o caso, aprimorar seus algoritmos. Em rela ca o a experimentos para avaliar a disponibilidade, pretende-se desenvolver experimentos para validar a dependabilidade total do RepliC, englobando tamb em a conabilidade. Para tanto, e necess ario desenvolver experimentos detalhados com inje c ao de falhas. Tamb em e proposta a avalia c ao do RepliC em diferentes zonas de disponibilidade com o intuito de identicar a varia c ao no desempenho adicionado em decorr encia da lat encia da rede. Para tanto, s ao necess arios identicar par ametros e desenvolver cen arios que contemplem um ambiente mais geral do que o utilizado nos experimentos aqui apresentados. RepliC foi avaliado com a infraestrutura da Amazon. Entretanto, ele pode ser utilizado por qualquer infraestrutura. Em trabalhos futuros, poder-se-ia avali a-lo com outras infraestruturas, tais como OpenNebula, OpenStack e CloudStack, vericando a melhoria proporcionada ao servi cos executados em cada uma dessas infraestruturas. 4. Gerenciamento Aut onomo A nuvem e um sistema aut onomo onde hardware e software podem ser automaticamente recongurados, orquestrados e estas modica co es s ao apresentadas de forma transparente para os usu arios. Com isso, tem-se um ambiente din amico, el astico e distribu do, o que diculta o desenvolvimento de solu c oes para o gerenciamento destes ambientes [Sousa et al., 2011a]. Um sistema aut onomo para o gerenciamento de dados em nuvem deve monitorar o comportamento e desempenho do ambiente, tratar quest oes de toler ancia a falhas, elasticidade e balanceamento da carga de trabalho, modelar e prever o comportamento para as cargas de trabalho e realizar a co es para lidar com as varia c oes destas cargas. Baseados em uma estimativa de carga de trabalho esperada, os clientes/desenvolvedores podem monitorar e, consequentemente, ajustar a capacidade do sistema. O gerenciamento aut onomo pode permitir ao RepliC acompanhar a execu ca o e aplicar solu c oes a eventos, por exemplo, altera c oes na carga de trabalho ou falhas, assim como garantir a qualidade do servi co e evitar desperd cio de recursos. Para tanto, t ecnicas de aprendizagem de m aquina podem ser utilizadas para classicar a carga de tra104
105
balho e prever o custo de opera c oes, melhorando o provisionamento [Rogers et al., 2010] [Agrawal et al., 2011a]. 5. Processo de Tomada de Decis ao para Adic ao e Remo c ao de R eplicas RepliC utiliza uma heur stica baseada no tempo de resposta para determinar a adi ca o e remo ca o de r eplica. Apesar desta heur stica apresentar resultados satisfat orios, ela n ao combina as diferentes informa c oes do ambiente para o processo de decis ao, tais como carga de trabalho, quantidade de r eplicas e interfer encia entre inquilinos. De acordo com uma investiga c ao inicial, percebeu-se que o problema abordado pelo RepliC pode ser modelado como um problema de decis ao. RepliC monitora o estado do ambiente e executa a co es baseadas na qualidade do servi co e nas penalidades. Assim sendo, um direcionamento para trabalhos futuros e utilizar o Markov Decision Process (MDP) para adicionar e remover m aquinas e inquilinos do ambiente. 6. Modelo de Custo para SGBDs em Nuvem Os provedores de servi cos em nuvem devem tratar aspectos de custo baseados na utiliza ca o dos SGBDs. As IaaS fornecem servi cos de armazenamento e transfer encia de dados, normalmente com custos adicionais referentes a quantidade de dados armazenados e de requisi co es de E/S. No contexto deste trabalho, estes custos dos servi cos de armazenamento foram relativamente menores do que os custos associados a `s VM. Al em disso, cada provedor utiliza uma estrat egia diferente de tarifa c ao. Dessa forma, este trabalho considerou apenas os custos referentes a `s m aquinas virtuais. Trabalhos recentes tem propostos modelos de custo abordando diversos aspectos do gerenciamento de dados, tais como armazenamento, processamento e E/S aos dados [Viana et al., 2011] [Floratou et al., 2012] [Upadhyaya et al., 2012] [Nguyen et al., 2012]. Assim, outro direcionamento consiste em utilizar ou estender estes modelos de forma a permitir ao RepliC contabilizar todos os custos associados ao SGBD e, consequentemente, fornecer uma solu c ao com contabiliza ca o total dos custos para os usu arios.
105
REFERENCIAS BIBLIOGRAFICAS
[Abadi, 2009] Abadi, D. J. (2009). Data management in the cloud: Limitations and opportunities. IEEE Data Eng. Bull., 32:312. [Aboulnaga et al., 2009] Aboulnaga, A., Salem, K., Soror, A. A., Minhas, U. F., Kokosielis, P., and Kamath, S. (2009). Deploying database appliances in the cloud. IEEE Data Eng. Bull., 32(1):1320. [Abouzeid et al., 2009] Abouzeid, A., Bajda-Pawlikowski, K., Abadi, D. J., Rasin, A., and Silberschatz, A. (2009). Hadoopdb: An architectural hybrid of mapreduce and dbms technologies for analytical workloads. PVLDB, 2(1):922933. [Agrawal et al., 2011a] Agrawal, D., Abbadi, A. E., Das, S., and Elmore, A. J. (2011a). Database scalability, elasticity, and autonomy in the cloud - (extended abstract). In Database Systems for Advanced Applications - 16th International Conference, DASFAA 2011, pages 215. [Agrawal et al., 2010] Agrawal, D., Das, S., and Abbadi, A. E. (2010). Big data and cloud computing: New wine or just new bottles? PVLDB, 3(2):16471648. [Agrawal et al., 2011b] Agrawal, D., Das, S., and Abbadi, A. E. (2011b). Big data and cloud computing: Current state and future opportunities. In Proceedings of the 14th International Conference on Extending Database Technology, EDBT 11, New York, NY, USA. ACM. [Agrawal et al., 2008] Agrawal, R., Garcia-Molina, H., Gehrke, J., Gruenwald, L., Haas, L. M., Halevy, A. Y., Hellerstein, J. M., Ioannidis, Y. E., Korth, H. F., Kossmann, D., Madden, S., Ailamaki, A., Magoulas, R., Ooi, B. C., OReilly, T., Ramakrishnan, R., Sarawagi, S., Stonebraker, M., Szalay, A. S., Weikum, G., Bernstein, P. A., Brewer, E. A., Carey, M. J., Chaudhuri, S., Doan, A., Florescu, D., and Franklin, M. J. (2008). The claremont report on database research. ACM SIGMOD Record, 37:9. [Ahmad and Bowman, 2011] Ahmad, M. and Bowman, I. T. (2011). Predicting system performance for multi-tenant database workloads. In Proceedings of the Fourth International Workshop on Testing Database Systems, DBTest 11, pages 6:16:6, New York, NY, USA. ACM. [Amazon, 2012] Amazon (2012). Amazon Relational Database Service (Amazon RDS). http: //aws.amazon.com/rds/. [Armbrust et al., 2009] Armbrust, M., Fox, A., Grith, R., Joseph, A. D., Katz, R. H., Konwinski, A., Lee, G., Patterson, D. A., Rabkin, A., Stoica, I., and Zaharia, M. (2009). Above the clouds: A berkeley view of cloud computing. Technical report, EECS Department, University of California, Berkeley.
106
107
[Arnaut et al., 2011] Arnaut, D. E. M., Schroeder, R., and Hara, C. S. (2011). Phoenix: A relational storage component for the cloud. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing, CLOUD 11, pages 684691, Washington, DC, USA. IEEE Computer Society. [Azure, 2012] Azure (2012). Microsoft Azure. http://www.microsoft.com/azure/. [Baker et al., 2011] Baker, J., Bond, C., Corbett, J. C., Furman, J., Khorlin, A., Larson, J., L eon, J. M., Li, Y., Lloyd, A., and Yushprakh, V. (2011). Megastore: Providing scalable, highly available storage for interactive services. In CIDR 2011, Fifth Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, Online Proceedings, pages 223234. [Barker et al., 2012] Barker, S., Chi, Y., Moon, H. J., Hacig um u s, H., and Shenoy, P. (2012). cut me some slack: latency-aware live migration for databases. In Proceedings of the 15th International Conference on Extending Database Technology, EDBT 12, pages 432443, New York, NY, USA. ACM. [Bernstein and Newcomer, 2009] Bernstein, P. and Newcomer, E. (2009). Principles of transaction processing: for the systems professional. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, second edition. [Bernstein et al., 2011] Bernstein, P. A., Cseri, I., Dani, N., Ellis, N., Kalhan, A., Kakivaya, G., Lomet, D. B., Manne, R., Novik, L., and Talius, T. (2011). Adapting microsoft sql server for cloud computing. In Proceedings of the 27th International Conference on Data Engineering, ICDE 2011, pages 12551263. IEEE Computer Society. [Binnig et al., 2009] Binnig, C., Kossmann, D., Kraska, T., and Loesing, S. (2009). How is the weather tomorrow?: towards a benchmark for the cloud. In DBTest 09: Proceedings of the Second International Workshop on Testing Database Systems, pages 16, New York, NY, USA. ACM. [Birman, 2012] Birman, K. P. (2012). Guide to Reliable Distributed Systems: Building HighAssurance Applications and Cloud-Hosted Services. Springer. [Bonvin et al., 2009] Bonvin, N., Papaioannou, T. G., and Aberer, K. (2009). Dynamic costecient replication in data clouds. In ACDC 09: Proceedings of the 1st workshop on Automated control for datacenters and clouds, pages 4956, New York, NY, USA. ACM. [Bonvin et al., 2011] Bonvin, N., Papaioannou, T. G., and Aberer, K. (2011). Autonomic sladriven provisioning for cloud applications. In Proceedings of the 2011 11th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, CCGRID 11, pages 434443, Washington, DC, USA. IEEE Computer Society. [Brantner et al., 2008] Brantner, M., Florescu, D., Graf, D., Kossmann, D., and Kraska, T. (2008). Building a database on s3. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data - SIGMOD 08, page 251, New York. ACM Press. [Brewer, 2000] Brewer, E. A. (2000). Towards robust distributed systems (abstract). In PODC, page 7. ACM.
107
108
[Buyya et al., 2009] Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst., 25(6):599616. [Cao et al., 2011] Cao, Y., Chen, C., Guo, F., Jiang, D., Lin, Y., Ooi, B. C., Vo, H. T., Wu, S., and Xu, Q. (2011). Es2 : A cloud data storage system for supporting both oltp and olap. In Proceedings of the 27th International Conference on Data Engineering, ICDE 2011, pages 291302. IEEE Computer Society. [Cecchet et al., 2011] Cecchet, E., Singh, R., Sharma, U., and Shenoy, P. (2011). Dolly: virtualization-driven database provisioning for the cloud. In Proceedings of the 7th ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, VEE 11, pages 5162, New York, NY, USA. ACM. [Chang et al., 2006] Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. (2006). Bigtable: a distributed storage system for structured data. In OSDI 06: Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, pages 1515, Berkeley, CA, USA. USENIX Association. [Charron-Bost et al., 2010] Charron-Bost, B., Pedone, F., and Schiper, A., editors (2010). Replication: Theory and Practice, volume 5959 of Lecture Notes in Computer Science. Springer. [Chi et al., 2011] Chi, Y., Moon, H. J., Hacig um u s, H., and Tatemura, J. (2011). Sla-tree: a framework for eciently supporting sla-based decisions in cloud computing. In Proceedings of the 14th International Conference on Extending Database Technology, EDBT/ICDT 11, pages 129140, New York, NY, USA. ACM. [Ciurana, 2009] Ciurana, E. (2009). Developing with Google App Engine. Apress, Berkely, CA, USA. [Cooper et al., 2009] Cooper, B. F., Baldeschwieler, E., Fonseca, R., Kistler, J. J., Narayan, P. P. S., Neerdaels, C., Negrin, T., Ramakrishnan, R., Silberstein, A., Srivastava, U., and Stata, R. (2009). Building a cloud for yahoo! IEEE Data Eng. Bull., 32(1):3643. [Cooper et al., 2010] Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R., and Sears, R. (2010). Benchmarking cloud serving systems with ycsb. In SoCC 10: Proceedings of the 1st ACM symposium on Cloud computing, pages 143154, New York, NY, USA. ACM. [Curino et al., 2011a] Curino, C., Jones, E., Popa, R., Malviya, N., Wu, E., Madden, S., Balakrishnan, H., and Zeldovich, N. (2011a). Relational cloud: a database service for the cloud. In CIDR 2011, Fifth Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, Online Proceedings, pages 235240. [Curino et al., 2010a] Curino, C., Jones, E., Zhang, Y., Wu, E., and Madden, S. (2010a). Relational cloud: The case for a database service. Technical report, MIT-CSAIL-TR-2010-014. Computer Science and Articial Intelligence Laboratory, MIT, USA. [Curino et al., 2011b] Curino, C., Jones, E. P., Madden, S., and Balakrishnan, H. (2011b). Workload-aware database monitoring and consolidation. In Proceedings of the ACM SIGMOD International Conference on Management of Data, SIGMOD 11, pages 313324, New York, NY, USA. ACM.
108
109
[Curino et al., 2010b] Curino, C., Zhang, Y., Jones, E. P. C., and Madden, S. (2010b). Schism: a workload-driven approach to database replication and partitioning. PVLDB, 3(1):4857. [Curino et al., 2012] Curino, C. A., Difallah, D. E., Pavlo, A., and Cudre-Mauroux, P. (2012). Benchmarking oltp/web databases in the cloud: the oltp-bench framework. In Proceedings of the Fourth International Workshop on Cloud Data Management (CloudDB 12), pages 1720, New York, NY, USA. ACM. [Das et al., 2010] Das, S., Agrawal, D., and El Abbadi, A. (2010). G-store: a scalable data store for transactional multi key access in the cloud. In SoCC 10: Proceedings of the 1st ACM symposium on Cloud computing, pages 163174, New York, NY, USA. ACM. [Das et al., 2011] Das, S., Nishimura, S., Agrawal, D., and El Abbadi, A. (2011). Albatross: lightweight elasticity in shared storage databases for the cloud using live data migration. Proc. VLDB Endow., 4:494505. [Dash et al., 2009] Dash, D., Kantere, V., and Ailamaki, A. (2009). An economic model for self-tuned cloud caching. In Proceedings of the 2009 IEEE International Conference on Data Engineering, pages 16871693, Washington, DC, USA. IEEE Computer Society. [Dean and Ghemawat, 2004] Dean, J. and Ghemawat, S. (2004). Mapreduce: simplied data processing on large clusters. In OSDI04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation, pages 1010, Berkeley, CA, USA. USENIX Association. [DeCandia et al., 2007] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., and Vogels, W. (2007). Dynamo: amazons highly available key-value store. SIGOPS Oper. Syst. Rev., 41(6):205220. [Doherty and Hurley, 2007] Doherty, C. and Hurley, N. (2007). Autonomic distributed data management with update accesses. In Proceedings of the 1st international conference on Autonomic computing and communication systems, Autonomics 07, pages 10:110:8. ICST. [Elmore et al., 2011a] Elmore, A., Das, S., Agrawal, D., and Abbadi, A. E. (2011a). Towards an elastic and autonomic multitenant database. In NetDB 2011 - 6th International Workshop on Networking Meets Databases Co-located with SIGMOD 2011. [Elmore et al., 2011b] Elmore, A. J., Das, S., Agrawal, D., and El Abbadi, A. (2011b). Zephyr: live migration in shared nothing databases for elastic cloud platforms. In Proceedings of the ACM SIGMOD International Conference on Management of Data, SIGMOD 11, pages 301312, New York, NY, USA. ACM. [Entrialgo et al., 2011] Entrialgo, J., Garc a, D. F., Garc a, J., Garc a, M., Valledor, P., and Obaidat, M. S. (2011). Dynamic adaptation of response-time models for qos management in autonomic systems. J. Syst. Softw., 84:810820. [Ferretti et al., 2010] Ferretti, S., Ghini, V., Panzieri, F., Pellegrini, M., and Turrini, E. (2010). Qos-aware clouds. In Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, CLOUD 10, pages 321328, Washington, DC, USA. IEEE Computer Society.
109
110
[Fito et al., 2010] Fito, J. O., Presa, I. G., and Guitart, J. (2010). Sla-driven elastic cloud hosting provider. Parallel, Distributed, and Network-Based Processing, Euromicro Conference on, 0:111118. [Floratou et al., 2012] Floratou, A., Patel, J. M., Lang, W., and Halverson, A. (2012). When free is not really free: what does it cost to run a database workload in the cloud? In Proceedings of the Third TPC Technology conference on Topics in Performance Evaluation, Measurement and Characterization, TPCTC11, pages 163179, Berlin, Heidelberg. SpringerVerlag. [Florescu and Kossmann, 2009] Florescu, D. and Kossmann, D. (2009). Rethinking cost and performance of database systems. SIGMOD Rec., 38(1):4348. [Folkerts et al., 2012] Folkerts, E., Alexandrov, A., Sachs, K., Iosup, A., Markl, V., and Tosun, C. (2012). Benchmarking in the cloud: What it should, can, and cannot be. In TPC Technology Conference, TPCTC 2012. [Ghemawat et al., 2003] Ghemawat, S., Gobio, H., and Leung, S.-T. (2003). The google le system. SIGOPS Oper. Syst. Rev., 37(5):2943. [Gilbert and Lynch, 2002] Gilbert, S. and Lynch, N. (2002). Brewers conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News, 33(2):5159. [Gray et al., 1996] Gray, J., Helland, P., ONeil, P., and Shasha, D. (1996). The dangers of replication and a solution. In SIGMOD 96: Proceedings of the 1996 ACM SIGMOD international conference on Management of data, pages 173182, New York, NY, USA. ACM Press. [Hadoop, 2012] Hadoop (2012). Apache Hadoop. http://hadoop.apache.org. [Hui et al., 2009] Hui, M., Jiang, D., Li, G., and Zhou, Y. (2009). Supporting database applications as a service. In ICDE 09: Proceedings of the 2009 IEEE International Conference on Data Engineering, pages 832843, Washington, DC, USA. IEEE Computer Society. [Huppler, 2011] Huppler, K. (2011). Price and the tpc. In Proceedings of the Second TPC technology conference on Performance evaluation, measurement and characterization of complex systems, TPCTC10, pages 7384, Berlin, Heidelberg. Springer-Verlag. [Islam et al., 2012] Islam, S., Lee, K., Fekete, A., and Liu, A. (2012). How a consumer can measure elasticity for cloud platforms. In Proceedings of the third joint WOSP/SIPEW international conference on Performance Engineering, ICPE 12, pages 8596, New York, NY, USA. ACM. [Keller and Ludwig, 2003] Keller, A. and Ludwig, H. (2003). The wsla framework: Specifying and monitoring service level agreements for web services. J. Netw. Syst. Manage., 11:5781. [Kemme and Alonso, 2010] Kemme, B. and Alonso, G. (2010). Database replication: a tale of research across communities. PVLDB, 3(1):512. [Kemme et al., 2010] Kemme, B., Jim enez-Peris, R., and Pati no-Mart nez, M. (2010). Database Replication. Synthesis Lectures on Data Management. Morgan & Claypool Publishers.
110
111
[Kephart and Chess, 2003] Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. Computer, 36(1):4150. [Kiefer et al., 2012] Kiefer, T., Schlegel, B., and Lehner, W. (2012). Multe: A multi-tenancy database benchmark framework. In TPC Technology Conference, TPCTC 2012. [Kossmann et al., 2010] Kossmann, D., Kraska, T., and Loesing, S. (2010). An evaluation of alternative architectures for transaction processing in the cloud. In SIGMOD 10: Proceedings of the 2010 international conference on Management of data, pages 579590, New York, NY, USA. ACM. [Kraska et al., 2009] Kraska, T., Hentschel, M., Alonso, G., and Kossmann, D. (2009). Consistency rationing in the cloud: Pay only when it matters. PVLDB, 2(1):253264. [Lang et al., 2012] Lang, W., Shankar, S., Patel, J. M., and Kalhan, A. (2012). Towards multitenant performance slos. In Proceedings of the 2012 IEEE 28th International Conference on Data Engineering, ICDE 12, pages 702713, Washington, DC, USA. IEEE Computer Society. [Lehner and Sattler, 2010] Lehner, W. and Sattler, K.-U. (2010). Database as a service (dbaas). In Proceedings of the 26th International Conference on Data Engineering, ICDE 2010, pages 12161217, Long Beach, California, USA. IEEE. [Liang Zhao and Liu, 2012] Liang Zhao, S. S. and Liu, A. (2012). Application-managed replication controller for cloud-hosted databases. In IEEE CLOUD 2012 - Proceedings of the 5th IEEE International Conference on Cloud Computing, pages 922929. [Liu et al., 2007] Liu, S., Liang, Y., and Brooks, M. (2007). Eucalyptus: a web service-enabled e-infrastructure. In CASCON 07: Proceedings of the 2007 conference of the center for advanced studies on Collaborative research, pages 111, New York, NY, USA. ACM. [LSCR, 2012] LSCR (2012). SLA for database projects. http://lscr.berkeley.edu/rates/ sla/database.php. [Malkowski et al., 2010] Malkowski, S., Hedwig, M., Jayasinghe, D., Pu, C., and Neumann, D. (2010). Cloudxplor: a tool for conguration planning in clouds based on empirical data. In Proceedings of the 2010 ACM Symposium on Applied Computing, SAC 10, pages 391398, New York, NY, USA. ACM. [Mell and Grance, 2011] Mell, P. and Grance, T. (2011). NIST Working Denition of Cloud Computing (Draft). National Institute of Standards and Technology. http://csrc.nist. gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf. [Microsoft, 2006] Microsoft (2006). Architecture Strategies for Catching the Long Tail. http: //msdn.microsoft.com/en-us/library/aa479069.aspx. [Minhas et al., 2011] Minhas, U. F., Rajagopalan, S., Cully, B., Aboulnaga, A., Salem, K., and Wareld, A. (2011). Remusdb: Transparent high availability for database systems. PVLDB, 4(11):738748.
111
112
[Mior and de Lara, 2011] Mior, M. J. and de Lara, E. (2011). Flurrydb: a dynamically scalable relational database with virtual machine cloning. In Proceedings of the 4th Annual International Conference on Systems and Storage, SYSTOR 11, pages 1:11:9, New York, NY, USA. ACM. [Moreira et al., 2012] Moreira, L. O., Sousa, F. R. C., and Machado, J. C. (2012). Analisando o desempenho de banco de dados multi-inquilino em nuvem. In XXVII Simp osio Brasileiro de Banco de Dados, SBBD 2012, pages 161168. [Mukerjee et al., 2011] Mukerjee, K., Talius, T., Kalhan, A., Ellis, N., and Cunningham, C. (2011). Sql azure as a self-managing database service: Lessons learned and challenges ahead. IEEE Data Eng. Bull., 34(4):6170. [Nguyen et al., 2012] Nguyen, T.-V.-A., Bimonte, S., dOrazio, L., and Darmont, J. (2012). Cost models for view materialization in the cloud. In Proceedings of the 2012 Joint EDBT/ICDT Workshops, EDBT-ICDT 12, pages 4754, New York, NY, USA. ACM. [Olston et al., 2008] Olston, C., Reed, B., Srivastava, U., Kumar, R., and Tomkins, A. (2008). Pig latin: a not-so-foreign language for data processing. In SIGMOD 08: Proceedings of the 2008 ACM SIGMOD international conference on Management of data, pages 10991110, New York, NY, USA. ACM. [Ozsu and Valduriez, 2011] Ozsu, M. T. and Valduriez, P. (2011). Principles of Distributed Database Systems, 3rd Edition. Springer. [Paton et al., 2009] Paton, N. W., Arag ao, M. A. T., Lee, K., Fernandes, A. A. A., and Sakellariou, R. (2009). Optimizing utility in cloud computing through autonomic workload execution. IEEE Data Eng. Bull., 32(1):5158. [Percona, 2012] Percona (2012). percona-xtrabackup. XtraBackup. http://www.percona.com/software/
[Perez-Sorrosal et al., 2011] Perez-Sorrosal, F., Pati no-Martinez, M., Jimenez-Peris, R., and Kemme, B. (2011). Elastic si-cache: consistent and scalable caching in multi-tier architectures. The VLDB Journal, pages 125. [Pierre and Stratan, 2012] Pierre, G. and Stratan, C. (2012). Conpaas: A platform for hosting elastic cloud applications. IEEE Internet Computing, 16:8892. [Pritchett, 2008] Pritchett, D. (2008). Base: An acid alternative. Queue, 6(3):4855. [QoSDBC, 2012] QoSDBC (2012). QoSDBC. http://code.google.com/p/qosdbc/. [Reinwald, 2010] Reinwald, B. (2010). Database support for multi-tenant applications. In IEEE Workshop on Information and Software as Services (WISS). Co-located with ICDE. [Robinson, 2008] Robinson, D. (2008). Amazon Web Services Made Simple: Learn how Amazon EC2, S3, SimpleDB and SQS Web Services enables you to reach business goals faster. Emereo Pty Ltd, London, UK, UK. [Rodriguez and Neubauer, 2010] Rodriguez, M. A. and Neubauer, P. (2010). Constructions from dots and lines. Bulletin of the American Society for Information Science and Technology, 36(6):3541.
112
113
[Rogers et al., 2010] Rogers, J., Papaemmanouil, O., and Cetintemel, U. (2010). A generic auto-provisioning framework for cloud databases. In IEEE 26th International Conference on Data Engineering Workshops (ICDEW), pages 63 68. [Saito and Shapiro, 2005] Saito, Y. and Shapiro, M. (2005). Optimistic replication. ACM Comput. Surv., 37:4281. [Sakr and Liu, 2012] Sakr, S. and Liu, A. (2012). Sla-based and consumer-centric dynamic provisioning for cloud databases. 2012 IEEE Fifth International Conference on Cloud Computing, 0:360367. [Sakr et al., 2011] Sakr, S., Zhao, L., Wada, H., and Liu, A. (2011). Clouddb autoadmin: Towards a truly elastic cloud-based data store. In Proceedings of the 2011 IEEE International Conference on Web Services, ICWS 11, pages 732733, Washington, DC, USA. IEEE Computer Society. [Santos et al., 2012] Santos, G. A. C., Maia, J. G. R., Moreira, L. O., Sousa, F. R. C., and Machado, J. C. (2012). Scale-space ltering for workload analysis and forecast. In Submetido para Publica c ao. http: // replic. sf. net/ ccgrid2013. pdf . [Savinov and Daudjee, 2010] Savinov, S. and Daudjee, K. (2010). Dynamic database replica provisioning through virtualization. In Proceedings of the second international workshop on Cloud data management, CloudDB 10, pages 4146, New York, NY, USA. ACM. [Schad et al., 2010] Schad, J., Dittrich, J., and Quian e-Ruiz, J.-A. (2010). Runtime measurements in the cloud: Observing, analyzing, and reducing variance. PVLDB, 3(1):460471. [Schiller et al., 2011] Schiller, O., Schiller, B., Brodt, A., and Mitschang, B. (2011). Native support of multi-tenancy in rdbms for software as a service. In Proceedings of the 14th International Conference on Extending Database Technology, EDBT/ICDT 11, pages 117 128, New York, NY, USA. ACM. [Schnjakin et al., 2010] Schnjakin, M., Alnemr, R., and Meinel, C. (2010). Contract-based cloud architecture. In Proceedings of the second international workshop on Cloud data management, CloudDB 10, pages 3340, New York, NY, USA. ACM. [Schroeder et al., 2006] Schroeder, B., Harchol-Balter, M., Iyengar, A., and Nahum, E. (2006). Achieving class-based qos for transactional workloads. In Proceedings of the 22nd International Conference on Data Engineering, ICDE 06, pages 153, Washington, DC, USA. IEEE Computer Society. [Sethuraman and Taheri, 2011] Sethuraman, P. and Taheri, H. R. (2011). Tpc-v: a benchmark for evaluating the performance of database applications in virtual environments. In Proceedings of the Second TPC technology conference on Performance evaluation, measurement and characterization of complex systems, TPCTC10, pages 121135, Berlin, Heidelberg. Springer-Verlag. [Silva et al., 2012] Silva, T. L. C., Nascimento, M. A., Mac edo, J. A. F., Sousa, F. R. C., and Machado, J. C. (2012). Towards non-intrusive elastic query processing in the cloud. In Proceedings of the Fourth International Workshop on Cloud Data Management (CloudDB 12), pages 916, New York, NY, USA. ACM.
113
114
[Sivasubramanian et al., 2005] Sivasubramanian, S., Alonso, G., Pierre, G., and van Steen, M. (2005). Globedb: autonomic data replication for web applications. In Proceedings of the 14th international conference on World Wide Web, WWW 05, pages 3342, New York, NY, USA. ACM. [Soror et al., 2010] Soror, A. A., Minhas, U. F., Aboulnaga, A., Salem, K., Kokosielis, P., and Kamath, S. (2010). Automatic virtual machine conguration for database workloads. ACM Trans. Database Syst., 35(1):147. [Soundararajan and Amza, 2006] Soundararajan, G. and Amza, C. (2006). Reactive provisioning of backend databases in shared dynamic content server clusters. ACM Trans. Auton. Adapt. Syst., 1:151188. [Sousa et al., 2007] Sousa, F. R. C., Filho, H. J. A. C., and Machado, J. C. (2007). A new approach to replication of xml data. In Database and Expert Systems Applications, 18th International Conference, DEXA 2007, Regensburg, Germany, volume 4653 of Lecture Notes in Computer Science, pages 141150. Springer. [Sousa and Machado, 2011] Sousa, F. R. C. and Machado, J. C. (2011). An approach to database replication in the cloud. In XXVI Proceedings of Brazilian Symposium on Databases, SBBD 2011. [Sousa and Machado, 2012] Sousa, F. R. C. and Machado, J. C. (2012). Towards elastic multitenant database replication with quality of service. In Proceedings of the 5th IEEE/ACM International Conference on Utility and Cloud Computing (UCC 12). [Sousa et al., 2010] Sousa, F. R. C., Moreira, L. O., Mac edo, J. A. F., and Machado, J. C. (2010). Gerenciamento de Dados em Nuvem: Conceitos, Sistemas e Desaos, pages 101 130. In: PEREIRA, A. C. M.; PAPPA, G. L.; WINCKLER, M.; GOMES, R. L. (Org.). T opicos em Sistemas Colaborativos, Interativos, Multim dia, Web e Bancos de Dados, SIWB 2010, 1. ed. SBC, Belo Horizonte. [Sousa et al., 2009] Sousa, F. R. C., Moreira, L. O., and Machado, J. C. (2009). Computa c ao em Nuvem: Conceitos, Tecnologias, Aplica c oes e Desaos. In: MOURA, R. S. (Org.) ; SOUZA, F. V. (Org.) ; OLIVEIRA, A. C. (Org.). Escola Regional de Computa c ao (Cear a, Maranh ao e Piau , ERCEMAPI 2009, 1. ed. EDUFPI, Piau . [Sousa et al., 2011a] Sousa, F. R. C., Moreira, L. O., and Machado, J. C. (2011a). Computa c ao em nuvem aut onoma: Oportunidades e desaos. In Proceedings of the I Workshop on Autonomic Distributed Systems, WoSiDA 2011, collocated with SBRC 2011, Campo Grande, MS. [Sousa et al., 2011b] Sousa, F. R. C., Moreira, L. O., and Machado, J. C. (2011b). Sladb: Acordo de n vel de servi co para banco de dados em nuvem. In XXVI Simp osio Brasileiro de Banco de Dados, SBBD 2012, S ao Paulo. [Sousa et al., 2012] Sousa, F. R. C., Moreira, L. O., Santos, G. A. C., and Machado, J. C. (2012). Quality of service for database in the cloud. In Proceedings of the 2nd International Conference on Cloud Computing and Services Science - CLOSER 12, pages 595601. [Spread, 2012] Spread (2012). Spread. http://www.spread.org.
114
115
[Tanenbaum and Steen, 2006] Tanenbaum, A. S. and Steen, M. v. (2006). Distributed Systems: Principles and Paradigms (2nd Edition). Prentice-Hall, Inc., Upper Saddle River, NJ, USA. [Thusoo et al., 2010] Thusoo, A., Shao, Z., Anthony, S., Borthakur, D., Jain, N., Sen Sarma, J., Murthy, R., and Liu, H. (2010). Data warehousing and analytics infrastructure at facebook. In SIGMOD 10: Proceedings of the 2010 international conference on Management of data, pages 10131020, New York, NY, USA. ACM. [TPC, 2012] TPC (2012). Transaction Processing Performance Council. http://www.tpc. org/. [Tsakalozos et al., 2011] Tsakalozos, K., Kllapi, H., Sitaridi, E., Roussopoulos, M., Paparas, D., and Delis, A. (2011). Flexible use of cloud resources through prot maximization and price discrimination. In Proc. of the 27th IEEE Int. Conf. on Data Engineering (ICDE11), pages 7586. [Upadhyaya et al., 2012] Upadhyaya, P., Balazinska, M., and Suciu, D. (2012). How to price shared optimizations in the cloud. Proc. VLDB Endow., 5(6):562573. [Vaquero et al., 2011] Vaquero, L. M., Rodero-Merino, L., and Buyya, R. (2011). Dynamically scaling applications in the cloud. SIGCOMM Comput. Commun. Rev., 41:4552. [Vaquero et al., 2009] Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lindner, M. (2009). A break in the clouds: towards a cloud denition. SIGCOMM Comput. Commun. Rev., 39(1):5055. [Vasi c et al., 2012] Vasi c, N., Novakovi c, D., Miu cin, S., Kosti c, D., and Bianchini, R. (2012). Dejavu: accelerating resource allocation in virtualized environments. In Proceedings of the seventeenth international conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 12, pages 423436, New York, NY, USA. ACM. [Vecchiola et al., 2009] Vecchiola, C., Chu, X., and Buyya, R. (2009). Aneka: A Software Platform for .NET-based Cloud Computing, pages 267295. In: W. Gentzsch, L. Grandinetti, G. Joubert (Eds.). High Speed and Large Scale Scientic Computing. IOS Press, Amsterdam, Netherlands. [Viana et al., 2011] Viana, V., de Oliveira, D., and Mattoso, M. (2011). Towards a cost model for scheduling scientic workows activities in cloud environments. Services, IEEE Congress on, 0:216219. [Vo et al., 2010] Vo, H. T., Chen, C., and Ooi, B. C. (2010). Towards elastic transactional cloud storage with range query support. PVLDB, 3(1):506517. [Vogels, 2009] Vogels, W. (2009). Eventually consistent. Commun. ACM, 52(1):4044. [Voicu and Schuldt, 2009] Voicu, L. C. and Schuldt, H. (2009). How replicated data management in the cloud can benet from a data grid protocol: the re:gridit approach. In CloudDB 09: Proceedings of the First International Workshop on Cloud Data Management, pages 4548, New York, NY, USA. ACM.
115
116
[Voicu et al., 2010] Voicu, L. C., Schuldt, H., Breitbart, Y., and Schek, H.-J. (2010). Flexible data access in a cloud based on freshness requirements. In IEEE International Conference on Cloud Computing, pages 180187, Los Alamitos, CA, USA. IEEE Computer Society. [Wada et al., 2011] Wada, H., Fekete, A., Zhao, L., Lee, K., and Liu, A. (2011). Data consistency properties and the trade-os in commercial cloud storage: the consumers perspective. In CIDR 2011, Fifth Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, Online Proceedings, pages 134143. [Wei et al., 2009] Wei, Z., Pierre, G., and Chi, C.-H. (2009). Scalable transactions for web applications in the cloud. In Euro-Par, pages 442453. [Weissman and Bobrowski, 2009] Weissman, C. D. and Bobrowski, S. (2009). The design of the force.com multitenant internet application development platform. In SIGMOD 09: Proceedings of the 35th SIGMOD international conference on Management of data, pages 889896, New York, NY, USA. ACM. [Welsh and Culler, 2003] Welsh, M. and Culler, D. (2003). Adaptive overload control for busy internet servers. In Proceedings of the 4th conference on USENIX Symposium on Internet Technologies and Systems - Volume 4, USITS03, pages 44, Berkeley, CA, USA. USENIX Association. [Xiong et al., 2011] Xiong, P., Chi, Y., Zhu, S., Moon, H. J., Pu, C., and Hacig um us, H. (2011). Intelligent management of virtualized resources for database systems in cloud environment. In Proc. of the 27th IEEE Int. Conf. on Data Engineering (ICDE11), pages 8798. [Yang et al., 2009] Yang, F., Shanmugasundaram, J., and Yerneni, R. (2009). A scalable data platform for a large number of small applications. In CIDR 2009, Fourth Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, Online Proceedings, pages 110. [Zellag and Kemme, 2012] Zellag, K. and Kemme, B. (2012). How consistent is your cloud application? In Proceedings of the Third ACM Symposium on Cloud Computing, SoCC 12, pages 6:16:14, New York, NY, USA. ACM. [Zhang et al., 2010] Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud computing: stateof-the-art and research challenges. Journal of Internet Services and Applications, 1:718. [Zhao et al., 2012] Zhao, L., Sakr, S., Fekete, A., Wada, H., and Liu, A. (2012). Applicationmanaged database replication on virtualized cloud environments. In Data Management in the Cloud (DMC 12), ICDE Workshops, pages 127134, Los Alamitos, CA, USA. IEEE Computer Society.
116

Tese FlavioRubens

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tese FlavioRubens

Caricato da

Copyright:

Formati disponibili

Universidade Federal do Cear a Centro de Ci encias Departamento de Computa c ao Mestrado e Doutorado em Ci encia da Computa c ao

Fortaleza Janeiro - 2013

Universidade Federal do Cear a Centro de Ci encias Departamento de Computa c ao

Orientador: Prof. Javam de Castro Machado, DSc

Fortaleza Janeiro - 2013

Aos Meus Pais.

If I have seen further it is by standing on the shoulders of Giants ISAAC NEWTON

Modelos de Servi cos . . . . . . . . . . . . . . . . . . . . . . . . . Modelos de Implanta ca o . . . . . . . . . . . . . . . . . . . . . . .

Cap tulo 3Trabalhos Relacionados 3.1 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

xii Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . An alise Comparativa entre os Trabalhos Relacionados . . . . . . . . . . . Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 46 48

3.2 3.3 3.4

Toler ancia a Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cap tulo 7Conclus ao 7.1 7.2 Conclus oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Deni c ao do Problema

Figura 1.1 Cen ario do problema abordado neste trabalho.

As principais contribui co es desta tese s ao: 7

1.4. Contribui c oes

Publica co es Esta tese e baseada principalmente nas seguintes publica co es:

SOUSA, F. R. C. ; MOREIRA, L. O. ; SANTOS, G. A C.; MACHADO, J. C. Quality of Service

1.4. Contribui c oes

SOUSA, F. R. C. ; MACHADO, J. C. An Approach to Database Replication in the Cloud. In:

SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. SLADB: Acordo de N vel de Servi co

SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. Computa c ao em Nuvem Aut onoma:

SOUSA, F. R. C. ; MOREIRA, L. O. ; MACEDO, J. A. F,; MACHADO, J. C. Gerenciamento de

SOUSA, F. R. C. ; MOREIRA, L. O. ; MACHADO, J. C. Computa c ao em Nuvem: Conceitos,

SOUSA, F. R. C.; MOREIRA, L. O.; MACHADO, J. C. Um Middleware para o Gerenciamento

MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C. Analisando o Desempenho de Banco de

REGO, P. A. L. ; COUTINHO, E. F. ; SOUSA, F. R. C. ; SOUZA, J. N. Alocac ao Auton omica

MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C. A Distributed Concurrency Control

1.5. Estrutura da Tese

MOREIRA, E. J. R. ; SOUSA, F. R. C. ; MACHADO, J. C. RepliXP: Replica c ao Parcial de

Publica co es aceitas, submetidas ou em prepara ca o desenvolvidas em conjunto com esta tese:

SANTOS, G. A C. ; MAIA, G. J. R. ; MOREIRA, L. O. ; SOUSA, F. R. C. ; MACHADO, J. C.

SILVA, T. L. C. ; NASCIMENTO, M. A. ; MACEDO, J. A. F. ; SOUSA, F. R. C. ; MACHADO,

SOUSA, F. R. C. ; MACHADO, J. C. RepliC: Elastic Multi-Tenant Database Replication with

SOUSA, F. R. C. ; MACHADO, J. C. Strong Consistency for Muti-Tenant Database in the

1.5. Estrutura da Tese

GERENCIAMENTO DE DADOS EM NUVEM

2.1. Computa c ao em Nuvem

Figura 2.1 Ambiente de computa c ao em nuvem

2.1. Computa c ao em Nuvem

Caracter sticas Essenciais

de mecanismos padronizados que possibilitam o uso por plataformas do tipo thin, 14

2.1. Computa c ao em Nuvem

tais como celulares, laptops e PDAs.

Modelos de Servi cos

2.1. Computa c ao em Nuvem

Plataforma como um Servi co (PaaS) : O modelo de PaaS fornece sistema operacio-

dade de organiza c oes com interesses em comum.

2.2. Gerenciamento de Dados em Nuvem

GERENCIAMENTO DE DADOS EM NUVEM

2.2. Gerenciamento de Dados em Nuvem

Requisitos do Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

Caracter sticas do Gerenciamento de Dados em Nuvem

Uma caracter stica essencial no ambiente de nuvem e o gerenciamento aut onomo 19

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem

2.2. Gerenciamento de Dados em Nuvem