Tese de mestrado, Engenharia Informática (Arquitetura, Sistemas e Redes de Computadores) Universidade de Lisboa, Faculdade de Ciências, 2016A fiabilidade dos sistemas informáticos é uma preocupação fundamental em qualquer organização que dependa das suas infraestruturas de tecnologias de informação. Particularmente, a ocorrência de desastres introduz sérios obstáculos à continuidade de negócio. Ao contrário das falhas individuais de componentes, os desastres tendem a afetar toda a infraestrutura que suporta o sistema [1]. Consequentemente, a aplicação de técnicas de recuperação de desastres (Disaster Recovery ou DR) é crucial para assegurar alta disponibilidade e proteção de dados em sistemas de informação. As estratégias tradicionais para recuperação de desastres baseiam-se na realização periódica de cópias de segurança utilizando dispositivos de armazenamento em fita, que são armazenados numa localização distante (de modo a não serem suscetíveis aos mesmos desastres que a infraestrutura do sistema). As abordagens mais recentes, por sua vez, passam por replicar os recursos computacionais que compõem o sistema numa infraestrutura remota que pode ser utilizada para dar continuidade ao serviço em caso de desastre. Mais uma vez, a distancia geográfica entre as infraestruturas deve ser tão grande quanto possível. Tendo em conta estes requisitos, as clouds publicas surgem como uma excelente oportunidade para a concretização de sistemas de recuperação de desastres [2]. A elasticidade da cloud elimina a necessidade da replicação completa do serviço na infraestrutura secundária, permitindo que apenas os serviços mínimos sejam executados na ausência de falhas, e que os custos operacionais do sistema sejam pagos apenas em caso de necessidade, i.e., aquando da ocorrência de desastres. Isto possibilita ganhos substanciais quando comparado com os custos fixos (e.g., hardware, gestão, energia, conectividade) de uma infraestrutura dedicada [3]. A criação de uma estratégia de recuperação de desastres na cloud requer a definição de um conjunto de instancias computacionais a executar os serviços sem estado que compõem o serviço (e.g., servidores web, middleboxes, servidores de aplicação) e um outro conjunto de instâncias a executar os componentes do sistema com estado persistente, normalmente composto por um sistema de gestão de bases de dados (SGBD). Nas soluções atuais para recuperação de desastres na cloud, os serviços sem estado permanecem inativos durante a operação normal, enquanto os serviços com estado são mantidos em execução, mas em modo passivo, apenas recebendo atualizações das suas cópias presentes na infraestrutura primária. Estas atualizações podem ser concretizadas através da replicação oferecida pelos próprios SGBDs ou por funcionalidades concretizadas ao nível do sistema operativo ou da camada de virtualização [4–6]. Neste trabalho propomos o GINJA, um sistema de recuperação de desastres que recorre exclusivamente a serviços de armazenamento na cloud para replicar uma importante classe de sistemas – os sistemas de gestão de bases de dados. O GINJA atinge três principais objetivos que tornam a proposta inovadora: reduzir os custos da recuperação de desastres; permitir um controlo preciso sobre os compromissos de custo, durabilidade e desempenho; e adicionar um overhead mínimo ao desempenho do SGBD. O principal fator que permite ao GINJA reduzir custos prende-se com o facto de este ser completamente centrado no uso de serviços de armazenamento da cloud (e.g., Amazon S3, Azure Blob Storage). Esta decisão elimina a necessidade de manter máquinas virtuais em execução na cloud para receber atualizações da infraestrutura primária, o que resultaria em elevados custos monetários e de manutenção. Deste modo, o GINJA define um modelo de dados (concebido especificamente com o intuito de reduzir custos monetários e permitir uma realização eficiente de backups), e sincroniza para a cloud os dados gerados pelo SGBD de acordo com esse modelo. Em caso de desastre, uma instancia computacional é executada em modo de recuperação com o fim de descarregar os dados armazenados na cloud e dar continuidade ao serviço. É de referir que o tempo de recuperação pode ser reduzido drasticamente se o processo de recuperação for executado em recursos computacionais presentes na infraestrutura utilizada para armazenar dados (e.g., Amazon EC2, Azure VM). A execução do GINJA é baseada na configuração de dois parâmetros fundamentais: B e S. B define o número de alterações nas bases de dados que são incluídas em cada sincronização com a cloud, pelo que tem efeitos diretos no custo monetário (dado que cada carregamento de dados para a cloud tem um custo associado). S define o número máximo de operações de escrita no SGBD que podem ser perdidas em caso de desastre. De modo a garantir que nunca são perdidas mais do que S operações nas bases de dados, o GINJA bloqueia o SGBD sempre que necessário. Por consequência, este parâmetro relaciona-se diretamente com o desempenho do sistema. Conjuntamente, os parâmetros B e S fornecem aos nossos clientes um controlo preciso relativamente ao custo e durabilidade do SGBD no qual o GINJA é integrado. O GINJA foi implementado sob a forma de um sistema de ficheiros ao nível do utilizador [7], que intercepta as chamadas ao sistema de ficheiros efetuadas pelo SGBD e realiza sincronizações com a cloud de acordo com os parâmetros B e S. Esta decisão torna o GINJA numa solução bastante portável, dado que não necessita que sejam efetuadas quaisquer alterações ao SGBD, e permite que sejam criadas extensões com o fim de suportar outros sistemas de gestão de bases de dados. Neste projeto realizamos também uma avaliação extensiva ao nosso sistema, que analisa tópicos como custos monetários, eficiência e utilização de recursos. Os resultados obtidos ilustram os compromissos fundamentais de custo, desempenho e limite de perda de dados (i.e., durabilidade em caso de desastre), e mostram que a utilização do GINJA leva a uma perda de desempenho negligenciável em configurações nas quais alguma perda de dados é aceitável. O trabalho desenvolvido neste projeto resultou na publicação: Joel Alcântara, Tiago Oliveira, Alysson Bessani; Ginja: Recuperação de Desastres de Baixo Custo para Sistemas de Gestão de Bases de Dados, no INForum 2016, na track “Computação Paralela, Distribuída e de Larga Escala” [8]. Além disso, o software desenvolvido será utilizado na demonstração do projeto H2020 SUPERCLOUD, juntamente com o sistema de gestão de análises clínicas da MAXDATA, a ser realizada na avaliação intermédia do projeto, em meados de Setembro.Disaster recovery is a crucial feature to ensure high availability and data protection in modern information systems. The most common approach today consists of replicating the services that make up the system in a set of virtual machines located in a geographically distant public cloud infrastructure. These computational instances are kept executing in passive mode, receiving updates from the primary infrastructure, in order to remain up to date and ready to perform failover if a disaster occurs at the primary infrastructure. This approach leads to expressive monetary and management costs for keeping virtual machines executing in the cloud. In this work, we present GINJA – a disaster recovery system for transactional database management systems that relies exclusively on public cloud storage services (e.g., Amazon S3, Azure Blob Storage) to backup its data. By eliminating the need to keep servers running on a secondary site, GINJA reduces substantially the monetary and management costs of the disaster recovery. Furthermore, our solution also includes a configuration model that allows users to have a precise control about the cost, durability and performance trade-offs, and introduces a minimum overhead to the performance of the database management system. Additionally, GINJA is implemented as a specialized file system in user space, which brings major benefits in terms of portability, and allows it to be easily extended to support other database management systems. Lastly, we have performed an extensive evaluation of our system, that covers aspects such as performance, resource usage and monetary costs. The results show that GINJA is capable of performing disaster recovery with small monetary costs (less than 5 dollars for certain practical configurations), while introducing a minimum overhead to the database management system (12% overhead for the TPC-C workloads with at most 20 seconds of data loss in case of disasters)
