# A Novel Global Key-Value Storage System Based on Kinetic Drives +
## 5 Design and Architecture
### Backup and Splitting  
The system backs up a drive to two other regions, when this drive is full or getting too full for _original data (primary copies)_. Based on the information of access frequencies and locations mentioned in the backup preparation and rules, the metadata server of this drive knows the destinations (which two regions) of two backup copies. Hence, it contacts two other metadata servers of those two regions.  
After that, each of these two other metadata servers finds an empty drive in its region and returns its IP address to the metadata server of the _original drive_ that needs backup. Then, this _original drive_ gets those two drives' IP addresses and initiates P2P data transfer operations to them to backup (copy) the data. The data transfer from a drive to another drive does not need a metadata server as the intermediary. As long as the _original drive_ knows the IP address of the destination drive from the metadata server, P2P data transfer can be started and finished.  
An example of backup and splitting is shown in Figure 7. We can see that Drive 3 in Region 4 needs to be backed up. Based on the backup rules, the metadata server MS4 of Region 4 knows that the destinations for backup should be two empty drives in Region 2 and Region 5, respectively. Then, MS4 contacts the metadata server MS2 of Region 2 and the metadata server MS5 of Region 5. Next, MS2 and MS5 find within their regions that drive D21 and drive D18 are empty drives for backup data respectively, so that the IP addresses of drive D21 and drive D18 are returned to MS4. After that, MS4 shares these IP addresses with its drive D3, which initiates P2P data transfer operations to copy data to drive D21 in Region 2 and drive D18 in Region 5 for backups.  
There are three identical copies of data stored in drives in three regions after backup. We know those three drives are full or getting too full. To make more storage space, we need to split the data in them and transfer part of the data to other drives. Here, we adopt the approach in [16]. Since each drive covers key-value pairs in a certain _key_ range as shown in Table 1, it can split its data into two parts with smaller and greater _keys_ and transfer one part to another empty drive in the same region. Then, the metadata server updates the indexing table.  
For example, now drive D3 in Region 4 is full or getting too full, so that it needs to be split. As shown in Table 1, this drive stores key-value pairs whose _key_ range is from \"\(\underline{100}\ 0000011\ 0\ldots\)\" to \"\(\underline{100}\ 0000011\ 1\ldots\)\" currently. The metadata server can find an empty drive (e.g., drive D167) as the destination for splitting. Then, the second half of the data with greater _keys_ in drive D3 is transferred to drive D167. The metadata server MS4 also splits the indexing mapping for drive D3 and updates that as follows.  
\[\begin{array}{l}\underline{100}\ 0000011\ 00\ldots\ \underline{100}\ 0000011\ 01\ldots\ \underline{100}\ 0000011\ 01\ldots\ \underline{100}\ 0000011\ 11\ldots\ \underline{100}\ 00  
From the technical perspective, it is feasible to separate key-value pairs into two parts with smaller and greater _keys_ for data splitting, because Kinetic Drives support the APIs \"GetPrevious(key)\" and \"GetNext(key)\". Practically, the metadata server can record the smallest and greatest _keys_ of data in a drive. Hence, using these APIs, the Kinetic Drive can easily separate data.