Fault Tolerance Logging-Based Model for Deterministic Systems

Fault Tolerance Logging-Based Model for Deterministic Systems

Fault Tolerance Logging-based Model for Deterministic Systems Óscar Mortágua Pereira, David Simões and Rui L. Aguiar Instituto de Telecomunicações, DETI, University of Aveiro, Aveiro, Portugal Keywords: Fault Tolerance, Logging Mechanism, Software Architecture, Transactional System. Abstract: Fault tolerance allows a system to remain operational to some degree when some of its components fail. One of the most common fault tolerance mechanisms consists on logging the system state periodically, and recovering the system to a consistent state in the event of a failure. This paper describes a general fault tolerance logging-based mechanism, which can be layered over deterministic systems. Our proposal describes how a logging mechanism can recover the underlying system to a consistent state, even if an action or set of actions were interrupted mid-way, due to a server crash. We also propose different methods of storing the logging information, and describe how to deploy a fault tolerant master-slave cluster for information replication. We adapt our model to a previously proposed framework, which provided common relational features, like transactions with atomic, consistent, isolated and durable properties, to NoSQL database management systems. 1 INTRODUCTION This paper presents a model that can be used to provide fault-tolerance to deterministic systems Fault tolerance enables a system to continue its through external layers. We describe how to log the operation in the event of failure of some of its system state, so that it is possible to recover and components (Randell et al., 1978). A fault tolerant restore it when the system crashes; possible ways to system either maintains its operating quality in case store the state, either remotely or locally; and how to of failure or decreases it proportionally to the revert the state after a crash. severity of the failure. On the other hand, a fault We prove our concept by extending DFAF with intolerant system completely breaks down with a the proposed logging mechanisms in order to small failure. Fault tolerance is particularly valued in provide fault-tolerant ACID transactions to NoSQL high-availability or life-critical systems. DBMS. DFAF acts the external layer over a Relational Database Management Systems deterministic system (a DBMS). We consider that (DBMS) are systems that usually enforce non-deterministic events can happen in the information consistency and provide atomic, deterministic systems and are either expected (e.g.: consistent, isolated and durable (ACID) properties in receiving a message), triggering deterministic transactions (Sumathi and Esakkirajan, 2007). behaviour, or unexpected (e.g.: crashing), leading to However, without any sort of fault-tolerance undefined behaviour. mechanism, both atomicity and consistency are not The remainder of this paper is organized as guaranteed in case of failure (Gray and others, follows. Section 2 describes common fault tolerance 1981). techniques and presents the state of the art. Section 3 We have previously proposed a framework provides some context about the DFAF and Section named Database Feature Abstraction Framework 4 formalizes our fault tolerance model, describing (DFAF) (Pereira et al., 2015), based in Call Level what information is stored and how to store it. Interfaces (CLI), that acts as an external layer and Section 5 describes a fault-tolerant data replication provides common relational features to NoSQL cluster which can be used for performance DBMS. These features included ACID transactions, enhancements and Section 6 shows our proof of but our framework lacked fault-tolerance concept and evaluates our results. Finally, and mechanisms and, in case of failure, did not Section 7 presents our conclusions. guarantee atomicity or consistency of information. 119 Pereira, Ó., Simões, D. and Aguiar, R. Fault Tolerance Logging-based Model for Deterministic Systems. DOI: 10.5220/0005979101190126 In Proceedings of the 5th International Conference on Data Management Technologies and Applications (DATA 2016), pages 119-126 ISBN: 978-989-758-193-9 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved DATA 2016 - 5th International Conference on Data Management Technologies and Applications 2 STATE OF THE ART replicates information based on its access pattern. Recently, proposals have also focused on byzantine Fault tolerance is usually achieved by anticipating failure tolerance (Castro and Liskov 1999; Cowling exceptional conditions and designing the system to et al. 2006; Merideth and Iyengar 2005; Chun et al. cope with them. Randell et al. define an erroneous 2008; Castro and Liskov 2002; Kotla and Dahlin state as a state in which further processing, by the 2004). Byzantine fault-tolerant algorithms have been normal algorithms of the system, will lead to a considered increasingly important because malicious failure (Randell et al., 1978). When failures leave attacks and software errors can cause faulty nodes to the system in an erroneous state, a roll-back exhibit arbitrary behaviour. However, the byzantine mechanism can be used to set the system back in a assumption requires a much more complex protocol safe state. Systems rely on techniques like check- with cryptographic authentication, an extra pre- pointing, a popular and general technique that prepare phase, and a different set of techniques to records the state of the system, to roll-back and reach consensus. resume from a safe point, instead of restarting To the best of our knowledge, there has not been completely. Log-based protocols (Johnson, 1989) work done with the goal of defining a general are check-pointing techniques that require logging model that provides fault tolerance as an deterministic systems. Non-deterministic events, external layer to an underlying deterministic system. such as the contents and order of incoming Some solutions provide fault tolerance, but are messages, are recorded and used to replay events adapted to a specific context or system. Others are that occurred since the previous checkpoint. Other overly-abstract general models, like data replication, non-deterministic events, such as hardware failures, and do not cover how to generate the necessary said are meant to be recovered from. Indirectly, they are data from an external layer to provide fault-tolerance recorded as lack of information. to the underlying system. Not only that, but many In the fault tolerance context, logging data replication systems also assume conditions we mechanisms and their concepts and implementation do not, such as the possibility of byzantine failures, techniques have been discussed and researched or overly complex data access patterns. While extensively (Gray and Reuter, 1992), with popular byzantine failures are of enormous importance in write-ahead logging approaches (Mohan et al., 1992) distributed unsafe systems, such as in the BitCoin having become common in DBMS to guarantee both environment (Nakamoto, 2008), we consider their atomicity and durability in ACID transactions. There countermeasures to be complex and performance- are also other approaches which do not rely on hindering in the scope of our research. Not only that, logging systems to provide fault tolerance, like but byzantine assumptions have been proven to Huang et al.’s method and schemes for error allow only up to 1/3 of the nodes to be faulty. We detection and correction in matrix operations (Huang intend to focus on fault-tolerance for underlying et al., 1984); Rabin et al.’s algorithm to efficiently deterministic systems through a logging system, and and reliable transmit information in a network while distributed data replication is used for (Rabin, 1989); or Hadoop’s data replication reliability, expected DFAF use cases do not assume approach for reliability in highly distributed file malicious attacks to tamper with the network. systems (Borthakur, 2007). Some relational DBMS However, our model is general enough that it use shadow paging techniques (Ylönen, 1992) to supports the use of any data replication techniques to provide the ACID properties. However, the above replicate logging information across several described fault tolerance mechanisms are not machines. suitable to be used in an external fault-tolerance layer, since they are very dependent on the architecture of the systems they were designed for. 3 CONTEXT The most general proposals fall in the category of data replication, where several algorithms and We have previously mentioned the DFAF, which mechanisms have been proposed. These include allows a system architect to simulate non-existent Hadoop’s data replication approach for reliability in features on the underlying DBMS for client highly distributed file systems (Borthakur, 2007); applications to use, transparently to them. Our (Oki and Liskov, 1988), which is based on a primary framework acts as a layer that interacts with the copy technique; (Shih and Srinivasan, 2003), an underlying DBMS and with clients, which do not LDAP-based replication mechanism; or (Wolfson et access the DBMS directly. It allowed ACID al., 1997), which provides an adaptive algorithm that transactions, among other features, on NoSQL 120 Fault Tolerance Logging-based Model for Deterministic Systems DBMS, but was not fault tolerant. Typically, recover its previous state. Secondly, logging an NoSQL DBMS provide no support to ACID action is not done at the same time as that action is transactions. An ACID transaction allows a database executed. Taking

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    8 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us