Replication for availability/sustainability

Replication for availability/sustainability:
Distributed storage systems must ensure the availability and durability of data, despite the presence of faults. To this end, many systems rely on replication. First, we give an overview of the major families of replication mechanisms then we present RelaxDHT, our solution which allows us to relax the placement constraints of the distributed hash tables in order to improve churn resistance. We then analyze the impact of the distribution of data on the effectiveness of coping mechanisms repair, and therefore on the reliability of the repair system.

storage RelaXDHT: relax DHT placement constraints:
Distributed Hash Tables (DHT) are services distributed storage that uses a structured overlay based on key-based routing protocols (KBR). DHTs provide the system designer with a powerful abstraction for persistent storage over a large zone, hiding the complexity of network routing, replication, and fault tolerance. Therefore, DHTs are increasingly used for reliable and secure applications
such as backup systems, distributed file systems, multi-range query systems, and content distribution systems. In a DHT, each peer and each block of data are assigned a key. the key to a block of data is usually the result of a hash function performed on the block.
The goal of this work is to design a DHT that tolerates a high churn rate without performance degradation.
To do this, we avoid copying blocks of data when not required to restore a replica missing. We introduce a replication based on a flyer that eases the placement constraints in the leaflet. Our solution, named RelaxDHT, is presented afterward.
How RelaxDHT works: RelaxDHT is built on a KBR layer such as Pastry or Chord. Our design decisions are to use the location metadata of the replicas and to separate them from data block storage. We keep the concept root peer for each block of data. However,
the root peer does not necessarily store a copy of the blocks of which it is the root. It only keeps the metadata describing the replica set and periodically sends messages to the replica set peers to ensure that they continue to store their copy. It is possible, but not required, for a peer to be both root and part of the set of replicas of the same data block. The user location metadata allows a replica to the data block to be anywhere in the sheet set; a new peer can join a leaf set without necessarily inducing data block migrations.