A self-adapting peer-to-peer logical infrastructure, to increase storage reliability on top of the physical infrastructure

A scalable solution for balancing the peer load in a chord DHT

“…The purpose of this experiment was to see how well and how fast new storage peers are included by the Chord infrastructure and also to see how the dimension of the Chord ring influences the time needed for such a new peer to take over some of the load from the formerly overloaded peer. We did not intend to measure separately how much it takes for a new Chord peer to start up, since such measurements, for seeing how the storage infrastructure can auto-extend, at need, have been performed in [8] and we have started our experiments in this work based on these results from previous work. In figure 3, we can visualize the results of the experiment we have performed, to measure the impact of the Chord topology dimension on the time needed by the new peer to become a full member of the Chord network, and to take over some duties from a formerly overloaded peer.…”

“…Self-extending mechanisms, by adding new peers on-demand, have been studied both for efficient resource usage reasons, such as in [1], for scalability reasons, such as in [3], and also for both scalability and reliability reasons, as proposed by [8].…”

“…This is true, because our model's decision to launch and integrate a new node into the network is local, and the results of this experiment confirm this locality. The time needed for a newly launched peer to take over some of the duties of the overcharged peer includes: (1) the time needed to evaluate if the peer is overloaded, which is a simple test, and should not take very long; (2) the time needed to launch a new peer, which, combined with (3) the time needed for the new peer to effectively join the network, has been measured by [8], and is about 100ms; (4) the stabilization time interval, which is fixed and is equal to 1s, which has to pass until a peer is able to notice that one of its neighbour or finger nodes has changed and (5) the time needed by the new peer, that joins the network, to request the keys it has become responsible for from its successor, namely, the overloaded node, which has launched it, time interval which also includes (6) the network communication latency between the Chord peers. We would like to mention that we have not included in our measurements the actual time needed to download data from the successor of the new node, since this data can vary very much in size, and so this performance measurement is out of our current work's scope.…”

“…The main directions behind our research are: (1) defining a mechanism for the Chord network to self-extend, similar to the one presented in [8], for the case when certain peers would have to handle too much data; (2) defining the position of the new peer to be added to the network, in case this peer is needed for load balancing; and (3) defining load thresholds for the peers and state transitions when these thresholds are overpassed or undergone. We will define the architecture of the system, seen as a whole, which contains individual peers, whose behaviours we will also define in this paper.…”

Towards a Highly Available Model for Processing Service Requests Based on Distributed Hash Tables

“…The good dispersion properties of the DHT's hash function will enable an equitable partition of the distributed network service's clients among the Chord peers that offer the service, so that none of the peers will be stressed with too much load. In the current improved approach, in case the load of peers becomes too high, the system should launch a new peer in the overloaded area of the Chord ring, as described in our team's previous work [41,42].…”