# Towards a Highly Available Model for Processing Service Requests Based on Distributed Hash Tables
## 2 Materials and Methods
### System Scalability Based on the Intrinsic Properties of the Chord DHT
Even if the obtained infrastructure is not 100% secure, it offers a safety level for the data that is significantly improved from a classical DHT, since it is able to identify and exclude malicious peers from the DHT. The extra safety is also based on another important aspect of this previous work, i.e., the possibility to have a variable replication degree for the data, which allows the system to integrate new storage nodes _only_ when this is necessary. This fact is governed by the internal dynamics of the request processing service, with which the storage layer is in constant dialogue and interaction via the DHT communication layer. Note that the keys of data that a storage peer \(p\), belonging to the highly available database, is responsible for are also Chord IDs and each peer is responsible for the Chord IDs that are situated between its predecessor and himself, i.e., the keys that a peer \(p\) is responsible for are:

\[Finger_{k}\approx ID_{p}+2^{k},\]1

The DHT's hash function ensures that each storage node is loaded equally and participates evenly to the task of storing the entire highly available service's data. The extra time introduced by this database solution, for a group of nodes connected by a local network, is pretty low, especially when also taking into consideration the benefits that the enhanced replication mechanism brings. All this allows us to consider that this decentralized distributed database prototype, based also on the Chord DHT, is a good candidate to reliably store the data for a competitive highly available service that needs to process its clients requests. ## 3 Results

As detailed in Section 2, the key to a good service decentralization is a good, flexible, balanced and scalable distribution of the data, which most importantly needs to be _persistent_. This is why a very important part of this improved solution for decentralizing and distributing a service, in order to make it highly available, is to use a very efficient decentralized distributed database [7; 16; 17]. For the entire improved solution of a highly

\[Finger_{k}\approx ID_{p}+2^{k},\]2 Generic method for distributing and decentralizing a service, in order to make it highly available. available service, we are most interested in not introducing too much overhead by adding this solution's extra components, which yield high availability for the service. The elements that this novel solution aimed to improve, in order to make the service highly available, are: (1) static or dynamic _load balancing_, in order to maintain a high availability for the service, even in the context of increased load, due to a larger number of clients; (2) _fault tolerance_, by proving complete functionality even in the presence of failing nodes; (3) _scalability_, by DHT self-extension described and evaluated also in [41; 42], in order to be able to cover a higher number of clients and the increased needs of persistence, that critical sensitive data have, in order to obtain a generic method for making a previously centralized service to be highly available, with minimum changes at the service level. Note that the load balancing feature of the novel solution presented in this paper has been explained theoretically, in Section 3.1. The experimental evaluations performed are _orthogonal_ to each other, since it is easier to follow if the evaluation is performed separately, for each important feature of this novel approach for improving the service's availability. The testbed used to evaluate the improved solution, for a highly available service processing requests, involves nodes in our team's datacenter, which has a front end and a large collection of working nodes behind it. We have focused on proving the functionality of the model for a highly available service described in Section 2. This is why we have launched the load balancing nodes on the datacenter's front end and the effective service peers on _heterogeneous_ working nodes that we usually contact only via the front end.