Government Documents

Bizantium Replicação Bizantina de Bases de Dados

Description
Bizantium Replicação Bizantina de Bases de Dados Cristóvão Tavares Honorato Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. José Delgado Orientador:
Published
of 26
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
Bizantium Replicação Bizantina de Bases de Dados Cristóvão Tavares Honorato Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. José Delgado Orientador: Prof. Paulo Ferreira Co-Orientador: Prof. Nuno Preguiça Vogais: Prof. Helena Galhardas Abril de 2009 Abstract Database systems are a key component behind many of today s computer systems. As a consequence, it is crucial that database systems provide correct and continuous service despite unpredictable circumstances, such as software bugs or attacks. This dissertation presents the design of Byzantium, a Byzantine fault-tolerant database replication middleware that provides snapshot isolation (SI) semantics. SI is very popular because it allows increased concurrency when compared to serializability, while providing similar behavior for typical workloads. In out design, clients execute transactions speculativelly in a primary replica. Only the commit operation is executed as PBFT operation, which reduces to a minimum the number of PBFT operations issued. Thus, we are able to minimize the heavy overhead that PBFT features. Byzantium improves on existing proposals by allowing increased concurrency and not relying on any centralized component. Our middleware can be used with off-the-shelf database systems and it is built on top of an existing BFT library. i Abstract Actualmente as bases de dados transaccionais constituem um componente chave na infra-estrutura da maioria dos sistemas existentes. Como consequência, é crucial que os sistemas transaccionais forneçam um serviço correcto e contínuo, apesar da existência de circunstâncias imprevistas como ataques, erros de software, falhas de hardware ou enganos de um operador. Esta dissertação apresenta o desenho do Bizantium, um middleware de replicação Bizantina que implementa a semântica Snapshot Isolation (SI), e é baseado na biblioteca de replicação PBFT. O SI é actualmente um nível de isolamento popular pois permite um nível de concorrência superior quando comparado com semânticas que implementam o nível Serializable. No nosso desenho, clientes executam transacções especulativamente numa réplica, para apenas confirmarem os resultados no momento do commit, através de uma operação PBFT. Como tal, o nosso desenho reduz o número de operações PBFT emitidas, evitando o overhead do protocolo de replicação. O Bizantium melhora relativamente a propostas de replicação semelhantes ao permitir um nível de concorrência superior, e ao não depender de nenhum componente coordenador centralizado. O nosso middleware pode ser usado com implementações standard de sistemas transaccionais e é construído no topo de uma biblioteca de replicação BFT já existente. ii Agradecimentos Queria deixar uma nota de agradecimento às duas pessoas que me orientaram e que tornaram esta tese possível, Professor Rodrigo Rodrigues e Professor Nuno Preguiça. O acompanhamento e auxílio que me facultaram foram sempre excelentes. iii Index Abstract Abstract Agradecimentos i ii iii 1 Introdução Replicação para tolerar faltas Bizantinas Solução proposta Contribuição Organização da Dissertação Trabalho Relacionado Replicação convencional Tipos de replicação Modelo fail-stop vs modelo bizantino Replicação com faltas Bizantinas Replicação de Base de Dados com faltas Bizantinas Execução especulativa Contexto Snapshot Isolation Definição Garantias da semântica Practical Byzantine Fault Tolerance Modelo do sistema Propriedades do algoritmo Visão geral do algoritmo Interface da biblioteca Desenho Modelo do sistema Arquitectura do Sistema Como mapear transacções em operações BFT Visão geral da solução Principais Passos Consistência dos dados Correcção dos dados Funcionamento do sistema Operação begin iv 4.5.2 Execução Especulativa Operação commit Cliente Binzantino Réplica primária inactiva Operação rollback Lidar com concorrência no sistema Controlo de concorrência com first updater wins Consequências do controlo de concorrência Implementação Operações Cliente Servidor Proxy BFT/Bizantium Núcleo do servidor Avaliação Visão geral do benchmark TPC-C Configuração experimental Bizantium vs BFT Standard Bizantium vs Execução Convencional Conclusão 45 Bibliography 47 v List of Figures 3.1 Duas transacções concorrentes Algoritmo BFT, funcionamento normal Algoritmo BFT, mudança de vista Interface da biblioteca BFT Arquitectura do Sistema Código cliente Código servidor Código servidor, suportando clientes Binzantinos Mensagens de begin e de uma operação Vista da implementação cliente Interface de comunicação Vista da implementação servidor Núcleo do servidor vi List of Tables 6.1 Comparação BFT Standard - Bizantium (Resumo) Bizantium, execução read-only com 2 clientes BFT Standard, execução read-only com 2 clientes Bizantium, execução read-only com 3 clientes BFT Standard, execução read-only com 3 clientes Bizantium, execução read-only com 4 clientes BFT Standard, execução read-only com 4 clientes Comparação Bizantium - Execução Convencional (Resumo) Bizantium, 2 clientes Execução Convencional, 2 clientes Bizantium, 3 clientes Execução Convencional, 3 clientes Bizantium, 4 clientes Execução Convencional, 4 clientes vii 1 Introdução As bases de dados transaccionais formam actualmente um componente chave na infra-estrutura de muitos dos sistemas. Sistemas de comércio electrónico, websites ou sistemas de informação corporativos são apenas alguns exemplos de dependências fortes relativamente a um serviço de base de dados. Como consequência, é crucial que as bases de dados forneçam um serviço correcto e contínuo, mesmo que circunstâncias imprevistas surjam, e.g., erros de software, falhas de hardware ou ataques. Os sistema de processamento transaccional são tipicamente sistemas complexos, sofisticados e extensos, geralmente constituídos por milhões de linhas de código. Este tipo de sistema necessita garantir as propriedades da semântica ACID, e ao mesmo tempo atingir bons níveis de desempenho e de disponibilidade. Como é habitual em projectos de grande dimensão, podemos contar com um grande número de erros de software. Um destes erros pode fazer com que o sistema falhe imediatamente através de um crash. No caso de um crash, o sistema tira partido de mecanismos de recuperação, como write-ahead logs, e o único impacto sentido pelo cliente é o tempo de espera durante o período de recuperação. No entanto, um bug pode dar origem a faltas bizantinas. Uma falta bizantina é constituída por qualquer comportamento arbitrário diferente do correcto, i.e., qualquer tipo de comportamento incorrecto não necessariamente um crash. Este tipo de falta pode causar que uma resposta incorrecta seja entregue ao cliente (e.g., cliente emite um select), ou a serialização no estado da base de dados de informação incorrecta (e.g., cliente emite um update). De facto, um estudo recente aponta que a maioria dos erros presentes nos logs de três bases de dados comerciais, causam que o sistema falhe de uma forma Binzatina ao invés de induzirem directamente um crash[1]. 1.1 Replicação para tolerar faltas Bizantinas Uma aplicação pode melhorar a disponibilidade do seu serviço de base de dados através do recurso à replicação. Muitas técnicas foram desenhas para implementar sistemas com alta disponibilidade, e podem ser aplicadas directamente a bases de dados. Estas técnicas centram-se em replicar um serviço, e usar um algoritmo para coordenar as réplicas. Uma visão transparente é fornecida ao cliente, enquanto que o serviço replicado contínua operacional mesmo que uma fracção das réplicas falhe. Este tipo de esquemas assume um comportamento benigno por parte dos nós intervenientes, ou seja, é assumido que um nó apenas falha por crash. Este modelo é apelidado na literatura de fail-stop model. Na realidade, um nó pode aparentar ser correcto, mas estar a comportar-se incorrectamente, assumindo comportamento Bizantino. As técnicas tradicionais de replicação endereçam com sucesso problemas de disponibilidade (i.e., ocorrência de faltas benignas), mas falham em aumentar a resistência do sistema a faltas bizantinas. Estes esquemas normalmente baseiam-se numa vista, que é comandada por um nó primário. Quando uma operação é executada, o primário recebe a operação, executa-a e então envia os resultados da operação para as restantes réplicas. As réplicas por sua vez actualizam o seu estado. Quando um primário falha, os restantes nós iniciam uma mudança de vista garantindo que o sistema está sempre disponível. Na eventualidade de o primário assumir comportamento Bizantino, 1 este irá contaminar o estado das restantes réplicas porque as coordena. Algumas técnicas de replicação bizantina para bases de dados foram propostas, no entanto estas não contemplam níveis de concorrência adequados e limitam fortemente o desempenho do sistema. Um esquema eficiente foi proposto, mas este baseia-se num nó seguro para coordenar as operações[2]. A biblioteca de replicação PBFT[3] fornece uma forma eficiente de replicação bizantina. O PBFT é baseado num esquema de replicação por máquina de estados, e tem como requisito que as operações do serviço replicado sejam determinísticas. Os autores mostram que a biblioteca é eficiente a replicar serviços como o sistema de ficheiros NFS. No entanto, uma aplicação directa desta biblioteca à replicação de uma base de dados iria produzir um sistema pouco eficiente, porque para garantir a equivalência das execuções de cada uma das réplicas, é necessário que cada operação seja executada sequencialmente, o que não é um nível de concorrência adequado a um sistema de base de dados. Acreditamos que existe uma lacuna em termos de replicação descentralizada de bases de dados, tolerando faltas bizantinas. 1.2 Solução proposta Neste trabalho é proposto o Bizantium, um middleware de replicação bizantina para bases de dados, baseado no sistema PBFT e que disponibiliza uma semântica Snapshot Isolation. Na nossa solução os clientes acedem ao sistema usando uma interface JDBC convencional, pelo que o Bizantium pode ser usado por qualquer aplicação sem modificação. Ao executar as operações de uma transacção, o sistema de middleware controla a execução da mesma nas várias réplicas, garantindo a tolerância a faltas bizantinas. Para tal, o sistema recorre a uma biblioteca BFT que usa como caixa preta. Utilizamos o sistema PBFT e as caracteristicas do Snapshot Isolation para mapear transacções nas diferentes réplicas. Com o objectivo de minimizar o overhead de todo o sistema (dado o peso de executar operações tolerantes a faltas bizantinas), o sistema executa especulativamente uma transacção numa réplica. Apenas no momento do commit é verificada a validade da execução, recorrendo a uma operação executada através do protocolo PBFT. Caso os resultados da execução especulativa se confirmem, a transacção é concluída fazendo progredir o estado das réplicas (correctas). Caso se verifique a incorrecção da execução especulativa, a transacção é abortada. Para o correcto funcionamento do sistema, é necessário fazer diferentes verificações de forma a evitar situações de deadlock, isto para o caso de sistemas de bases de dados que utilizem locks no seu modelo de concorrência. 1.3 Contribuição Esta dissertação contemplou o desenho e implementação do Bizantium, uma solução de replicação com tolerância a faltas bizantinas. O Bizantium utiliza uma biblioteca de replicação bizantina como 2 base, mas minimiza o número de operações com acordo Bizantino por transacção. Permitimos que um cliente execute operações directamente numa única réplica, de uma forma especulativa. 1.4 Organização da Dissertação Após a introdução efectuada neste capítulo, esta dissertação continua no capítulo 2 com uma síntese do trabalho relacionado. No capítulo 3, são apresentados conceitos com os quais o nosso desenho está fortemente associado; o nível de isolamento Snapshot Isolation e a biblioteca de replicação BFT. No capítulo 4, é apresentado o desenho e as principais características do Bizantium. Na secção 5 são descritos, com algum nível de detalhe, os pormenores de implementação do nosso sistema. O capítulo 6 endereça a avaliação do desempenho do Bizantium e a sua comparação com outros esquemas relevantes. Finalmente, o capítulo 7 faz um balanço de todo o trabalho desenvolvido no âmbito desta dissertação. 3 2 Trabalho Relacionado 2.1 Replicação convencional Quase todo o trabalho desenvolvido em replicação, foi desenhado para tolerar apenas faltas benignas [1]. Este tipo de falta é vulgarmente conhecida por crash, e pode ser definida como um fenómeno em que um determinado processo entra num estado inactivo, para permanecer indefinidamente nessa condição. Estas técnicas têm como principal objectivo aumentar a disponibilidade do sistema. Este acréscimo de disponibilidade é conseguido ao introduzir no sistema mais do que uma cópia do seu estado; o serviço continua operacional, mesmo que algumas destas cópias estejam inacessíveis (e.g., um crash no servidor que alojava uma das cópias replicadas). Uma técnica base usada para replicar serviços, é a técnica de cópia primária, e funciona da seguinte forma. Uma réplica é designada a primária; as restantes são secundárias. O primário é responsável por processar as operações sobre o estado do serviço; alterações ao estado são notificadas às réplicas secundárias pela réplica primária. Quando um nó falha, a estrutura primário-secundário tem de ser reorganizada. Esta técnica foi primeiro introduzida por Alsberg, através do seu conceito de resiliência [4]. Stonebreaker deu também a sua contribuição para este assunto, através do seu modelo [5]. Quóruns, são outra técnica usada para replicar dados. Este tipo de abordagem, baseia-se em recolher junto das diferentes réplicas, um determinado nível consenso sobre uma operação, tal que, o estado do sistema se mantenha consistente, sem que seja necessário contactar todas as réplicas em cada operação. Por outras palavras, este tipo de sistemas assume que, observar uma porção maioritária dos nós do sistema, é equivalente a observá-los por completo. Um quórum com recurso a pesos dinâmicos foi introduzido em [6]. Este tipo de quórum introduz flexibilidade, por exemplo, uma configuração pode ser adoptada para privilegiar a disponibilidade (pesos elevados em nós mais fiáveis) ou para privilegiar o desempenho (peso acrescido nas réplicas com maior capacidade). Em [7] foi introduzida uma técnica de replicação que utiliza o conceito de vista. Este esquema usa uma combinação de replicação por réplica primária, com quoruns. O primário é usado para atribuir numeros de sequência a todos os pedidos submetidos ao sistema. Quando um primário falha, um esquema de mudança de vista é usado. Quoruns são usados para garantir que as mudanças de vista são feitas com sucesso Tipos de replicação Tipicamente os sistemas de replicação são classificados como eager ou lazy. Genericamente esta classificação é feita com base no facto de os sistemas propagarem, ou não, modificações ao estado do serviço dentro dos limites da transacção. Ténicas eager baseiam-se em actualizar todas as réplicas de uma forma atómica, como parte da própria transacção. Desta forma todas as réplicas estão permanentemente sincronizadas. Este tipo de técnicas de replicação garante uma execução serializável das transacções, o que faz com que estas estejam imunes a problemas de concorrência. Ainda assim, as técnicas eager penalizam o desempenho das escritas e aumentam o tempo de resposta das operações em geral. 4 Protocolos de replicação Lazy optam por executar transacções localmente, e apenas propagar as alterações para os restantes nós, depois de o commit estar já efectuado. Esta propagação é assim feita assincronamente, e de um modo geral, em períodos regulares no tempo. Esta solução é óbvia para aplicações móveis, em que os nós estão normalmente desconectados. Existem também alguns sistemas em que todos os nós estão continuamente conectados, mas que graças à natureza do negócio que suportam, podem usar esquemas lazy para dessa forma aumentarem o seu desempenho global. A replicação convencional também pode ser distinguida entre esquemas que asseguram semânticas transaccionais fortes, como o serializable [8, 9], ou semânticas mais fracas [10, 11, 12] como o Snapshot Isolation, que permitem níveis de concorrência superiores Modelo fail-stop vs modelo bizantino As técnicas de replicação convencional introduzidas no início deste capítulo toleram apenas faltas benignas, no entanto existem também outro tipo de faltas que não são contempladas pelo modelo benigno. No modelo fail-stop, ou benigno, um nó é assumido como correcto a menos que esteja numa condição inactiva. Este tipo de falta é vulgarmente conhecida como crash. Esquemas que apenas lidam com faltas benignas, têm como principalmente objectivo aumentar a disponibilidade de um serviço através da introdução de redundância. O modelo Bizantino por seu lado, contempla um conjunto de faltas mais alargado, designadas de bizantinas. Uma falta Bizantina consiste de um comportamento incorrecto por parte de um nó. Este comportamento não está no entanto limitado a uma falha por crash, como no modelo fail-stop. Uma falta Bizantina pode ser definida como qualquer comportamento arbitrário, diferente daquele que é o correcto. Técnicas que toleram este tipo de faltas não fazem nenhuma assunção acerca do comportamento das entidades do seu modelo, e como tal, toleram qualquer tipo de comportamento anómalo como, ataques, falha de um operador, erros de software ou falhas de hardware. 2.2 Replicação com faltas Bizantinas De uma forma geral, um sistema que tolera faltas Bizantinas constrói execuções equivalentes em diferentes réplicas, para no final executar uma votação. O resultado votado como correcto pela maioria das réplicas é considerado o correcto e entregue ao cliente. Construir um sistema eager, que no contexto de uma base de dados eficientemente tolere faltas Bizantinas, não é uma tarefa trivial. Um sistema eager mantém o estado constantemente actualizado em cada uma das réplicas do sistema. Para além disso é necessário garantir que as diferentes execuções são perfeitamente equivalentes entre si [13]. Para tal, as réplicas necessitam acordar sobre as operações que vão executar. Este acordo corresponde a atingir consenso, que é por si só uma operação bastante pesada [14, 15, 16]. Por outro lado, não é suficiente garantir uma igualdade na ordem com que diferentes operações se iniciam, para garantir que as diferentes execuções de um serviço são equivalentes entre si. Este facto é particularmente verdade quando o serviço em questão se trata de uma base de dados. Assim, por forma a obter execuções equivalentes e paralelas de um serviço 5 de base de dados, é necessário executar operações em cada réplica de uma forma sequencial, i.e., garantir a ordem com que as operações são executadas e para além disso, esperar que uma operação termine a sua execução, antes de a execução da operação seguinte ser iniciada. Um protocolo de replicação por máquina de estados como o BFT [17], que é discutido em mais detalhe na secção 3.2, pode ser usado como base para implementar uma base de dados tolerante a faltas Bizantinas. O BFT garante que as diferentes máquinas de estado replicadas recebem a mesma sequência de operações. Embora as operações sejam entregues por ordem, é complexo executá-las em diferentes réplicas com concorrência. Para que a serialização seja assegurada, as operações têm de ser executadas sequencialmente, ou seja sem qualquer concorrência. No caso dos sistemas de bases de dados, e da linguagem SQL, não é directo extrair os conjuntos de escrita e de leitura de uma operação. Uma extracção deste tipo envolveria acessos à própria base de dados, o que por si só é uma operação que tem de ser serializada. 2.3 Replicação de Base de Dados com faltas Bizantinas Existem poucas propostas para a replicação Bizantina de bases de dados. Os modelos propostos por Garcia-Mol
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x