Adaptive Parameter Tuning for Constructing Storage Tiers in an Autonomous Distributed Storage System

Abstract

We are developing an autonomous distributed storage system to make effective use of networked heterogeneous storage devices. It dynamically configures the storage tiers using effective performance values measured during operation, rather than static performance indicators of the storage device. Data blocks are transferred to a more appropriate storage tier according to their read/write tendencies. In the previous paper, the storage tiers were set using statically defined thresholds, but in this paper, we propose a method to set the thresholds adaptively. This method eliminates the need to adjust the runtime parameters for threshold setting according to the runtime environment. It has also been improved so that appropriate parameter values can be set for individual storage, rather than applying a single parameter value to the entire system. In the previous system, the administrator had to readjust the parameter values periodically to match the usage status of the storage device and the behavior of the process. However, in the proposed method, the parameter values are fine-tuned during operation to reduce the workload of the administrator. The simulation results show that the proposed method can reduce the execution time by up to about 30% compared to the previous method with optimum parameters configured statically.

1 Introduction

With the advancement of storage technology, it has become possible to equip client machines used by ordinary users with storage devices of sufficient capacity. In such an environment, much of that storage area is often left unused. To make effective use of these fragmented unused areas, we are developing an autonomous distributed storage system [1,2,3]. In our proposed storage system, network-connected nodes act as both clients and servers that provide unused storage space. This aims to improve the utilization of storage area.

Storage heterogeneity is high in such a distributed storage environment because the storage devices on each node perform differently, and the storage usage varies. Thus, storage heterogeneity is brought about by static and dynamic factors.

System administrators need to manually optimize the placement of data blocks to account for storage heterogeneity. Since the effective performance of a storage device varies depending on the load placed on it or I/O concentration, this optimization process should be done periodically. This is a time-consuming task for administrators, and it is expected to be automated. Our distributed storage system aims to alleviate this burden on system administrators by autonomously relocating data blocks.

Our autonomous distributed storage system left several runtime parameters, and we have found that tuning these parameters can affect the execution performance. In particular, the parameter that determines how to tier the storage nodes is difficult to set the optimal value, because it depends on the system configuration and storage access conditions. To find the optimal values for the parameters, continuous tuning work by the system administrator is required. In our previous work [4], we presented a scheme to reduce the parameter tuning work for the existing autonomous distributed storage system. In that paper, we used a statically defined ratio to adjust the parameters, whereas this paper presents a method to update the adjustment ratio dynamically to eliminate user customize parameter.

The rest of this paper is organized as follows. In Sect. 2, we outline the autonomous distributed storage system that we have proposed so far. In Sect. 3, we describe a method to adapt the parameters used for storage tiering to the execution environment. In Sect. 4, we evaluate the performance and show the effectiveness of the proposed method. Related work is presented in Sect. 5. Finally, Sect. 6 summarizes this paper.

2 Autonomous Distributed Storage System

2.1 Configuration of the Target System

In this section, we first define the system we are considering as our target. Our target system is a set of computers used in small and medium-sized organizations. Concretely, multiple computers that run standalone are connected via a network, and each of them shares the excess storage space. We assume that a single administration group manages these computers and network, and that they have the right to determine the management policy for the entire system. Therefore, it is assumed that there is no information leakage outside the organization due to the relocation of data blocks.

Fig. 1

An example of the target environment

Figure 1 shows an example of the execution environment that is the target of this project. In this project, the network nodes are categorized into the following three types, (1) a client node, (2) a storage node, and (3) a storage node also acts as a client node. Node type 1 is a client node that accesses the storage space provided by other network nodes. Node type 2 is a storage node that provides excess storage space to client nodes. Node type 3 is a node that combines the above two types. It provides excess storage space for the other client nodes and also acts as a client at the same time. It is assumed that these network nodes belong to the same broadcast domain and can communicate with each other without the latency involved in packet routing at the layer 3 level.

2.2 Internode Communication

In our storage system, each storage node needs to exchange storage information at runtime to perform dynamic control. Since this can be an overhead for ordinary storage access, we have proposed a scheme to reduce the number of packets when exchanging storage information [1]. The storage information is a 16-bytes length data structure consisting of the following elements.

• Storage ID: It is generated by hashing iSCSI qualified name in order to identify a storage. It has the length of four bytes.

• Time Stamp: It represents the time when the storage information was issued. It is a four bytes length field.

• Available Space: This field represents the size of available storage space in megabytes, and has four bytes length.

• Throughput: This field has two subfields, read and write throughput. Each value is represented in two bytes length in a unit of megabytes per second.

The protocol used to access the remote storage is iSCSI [5], which is commonly used in SAN (Storage Area Network) environments. The size of most packets used in iSCSI protocol is small compared to the size of Jumbo frames [6] used in current fast Ethernet standards. Our previous work [7] showed the scheme to append several segments of storage information to an iSCSI packet up to the size of MTU (Maximum Transfer Unit). Our preliminary evaluation [8] showed that most of the packets sent and received by the iSCSI protocol are about 100 bytes in length. The use of Jumbo frames, which has 9000 bytes size of MTU, can append a sufficient amount of extra information to such an iSCSI packet [7, 8]. Storage nodes periodically exchange storage information using the Jumbo frames in order to update the current status of storage nodes. In this way, the generation of separate network packets to exchange storage information is avoided, and the storage nodes can share storage status while keeping network overhead low.

2.3 Storage Ranking Method

Storage nodes are ranked based on the effective I/O performance which is collected using the storage information described in Sect. 2.2. The effective I/O performance can be obtained from the throughput fields of the storage information. We have proposed a scheme to unify two-dimensional performance indexes into one-dimensional index in the previous paper [2]. The unified performance index is used to rank the storage nodes. At this time, the method of obtaining the unified performance is changed depending on whether read performance or write performance is more important. For example, when a data block that is frequently read is to be transferred, a unified performance index that emphasizes read performance is calculated, and the storage nodes are ranked using this index.

Fig. 2

Storage ranking by unified performance

Figure 2 shows an evaluation example of a storage node by using the unified performance. In Fig. 2, the vertical and horizontal axes show the write and read performance of the storage, respectively. The performance of a storage node is represented by a point on a two-dimensional plane. For example, a storage node with a write performance value of Pw and a read performance value of Pr is plotted as a point named Storage A in Fig. 2.

The ranking direction represents the straight line along which the results of unifying the two storage performances are plotted. For example, if equal importance is placed on write performance and read performance, the slope in the ranking direction is set to 1. If the source storage node places more importance on write performance than on read performance, it sets a value greater than 1 as the slope in the ranking direction.

The unified performance is indicated by a foot of a perpendicular line from the performance point of the storage node to the ranking direction. This unification operation will allow storage nodes with two performance indices to be evaluated with a single performance index.

Since this unified performance value is calculated based on the read/write characteristics of the data block to be migrated, the ranking of the storage nodes is not fixed for the entire system, but is determined according to the data block to be migrated by the source storage node.

2.4 Static Storage Tiering Method

The storage node that starts transferring frequently accessed data blocks looks for a storage node with higher performance by referring to the unified performance index. Since transferring data blocks comes with a time cost, it is necessary to select a storage node with a certain degree of performance improvement as the destination in order for the effect of the migration to outweigh its cost. Therefore, we proposed to use a statically defined tiering threshold to avoid excessive migration of data blocks [2, 3]. The set of storage nodes with higher performance than its own storage node is called the upper storage tier, and the set of storage nodes with lower performance is called the lower storage tier.

In this method, two tiering threshold values $T_{\text {h}}$ and $T_{\text {l}}$ are set. $T_{\text {h}}$ and $T_{\text {l}}$ are defined by Eqs. (1) and (2).

$$\begin{aligned} T_{\text {h}}= P_{\text {u}}(1+p) \end{aligned}$$

(1)

$$\begin{aligned} T_{\text {l}}= P_{\text {u}}(1-p) \end{aligned}$$

(2)

Here, $P_{\text {u}}$ denotes the unified performance value of the source storage node. p is a parameter used to calculate the tiering threshold, and the value range is $0< p < 1$ The storage group with the unified performance value above $T_{\text {h}}$ is the upper storage tier, and the storage group with the unified performance value below $T_{\text {l}}$ is the lower storage tier.

By setting this tiering parameter p to a large value, it is possible to avoid transferring data blocks to storage nodes that have approximately the same level of unified performance values and also to increase the effectiveness of the migration. On the other hand, if this parameter is made too large, the number of storage nodes that are candidates for the destination of data blocks will be reduced, resulting in a loss of migration opportunities. Since this tiering parameter is set statically for the entire system, it needs to be adjusted to an appropriate value for the execution environment.

After the storage tiers are created, the source storage node transfers frequently accessed data blocks to the upper storage tier. In our previous evaluations [3], good performance results have been observed by transferring data blocks to the storage node located at the center of the upper storage tier in order to enhance the performance improvement per one migration.

Fig. 3

Candidates for migration destination in the previous method

For example, in Fig. 3, the tiering threshold values $T_{\text {h}}$ and $T_{\text {l}}$ are obtained from the unified performance value of the migration source node using the tiering parameter. The locations of these $T_{\text {h}}$ and $T_{\text {l}}$ constitute the upper and lower storage tiers.

When migrating frequently accessed data blocks to the upper storage tier, the storage nodes located in the upper storage tier in Fig. 3 are listed, and the storage node corresponding to the center of the list is selected as the migration destination. When data blocks that are rarely accessed are migrated to the lower storage tier, the storage node with the highest performance among the storage nodes located in the lower storage tier in Fig. 3 is selected as the migration destination to prevent rapid performance drop.

To avoid continuous migration of data blocks, the migration is triggered at satisfying the condition that there is sufficient free space in the destination storage node.

2.5 Data Block Migration

A storage node that receives excessive I/O requests acts as the migration source node and attempts to transfer a data block to the destination storage node in the upper storage tier. The data migration to the upper storage tier is triggered when the queue length of read/write accesses exceeds a threshold. The migration source node selects the data block with the highest access frequency as the data to be migrated.

When the utilization rate of the storage space exposed by a storage node to client nodes exceeds a threshold, data blocks are transferred to the lower storage tier to increase the free space. The migration source node selects the data block with the least recently accessed as the data to be migrated.

3 Adaptive Storage Tiering Method

As mentioned in the previous section, the method of statically setting the tiering threshold requires parameter tuning according to the configuration of the storage nodes, which is a problem that increases the amount of work for administrators. Therefore, we propose a method for tuning the tiering parameter dynamically to prevent its manual readjustment.

3.1 Dynamic Adjustment of Parameters

In our conventional method, a single tiering parameter p was used for the entire system to configure the storage tiers. This reduced the number of parameters to be set by the system administrator, but it did not allow for proper parameter settings for each storage node. We improve the storage tiering method in order that each storage node can perform tiering storage nodes using appropriate parameter values while keeping the workload of system administrators low.

First, we divide the tiering parameter into two sub parameters, $p_{\text {h}}$ and $p_{\text {l}}$. Each of these parameters is used to generate different storage tiers, so they do not need to be set to the same value. It will also be possible to adjust the parameter values independently according to the purpose for which each storage tier is configured. Therefore, the Eqs. (1) and (2) are revised to the following Eqs. (3) and (4), respectively.

$$\begin{aligned} T_{\text {h}}= P_{\text {u}}(1 + p_{\text {h}}) \end{aligned}$$

(3)

$$\begin{aligned} T_{\text {l}}= P_{\text {u}}(1 - p_{\text {l}}) \end{aligned}$$

(4)

Both parameters are initialized with arbitrary values at system startup, but are controlled to approach values appropriate for that storage node each time a data block is migrated.

Each storage node sets a certain value as the initial value of the tiering parameter p as in the conventional method. In the conventional method, this initial value is not changed during the execution, so it is necessary to find an appropriate value empirically before the execution. However, in this method, since each storage node dynamically readjusts p, there is no need to strictly adjust the value given as the initial value. The initial value set for p is used as the initial value for $p_{\text {h}}$ and $p_{\text {l}}$.

If the parameter $p_{\text {h}}$, which determines the boundary with the upper storage tier, is too large, it will reduce the number of candidate migration destinations, and if it is too small, it will be difficult to obtain an effect that exceeds the migration cost. Therefore, we dynamically adjust the tiering parameter $p_{\text {h}}$ according to the following policy.

• Increasing $p_{\text {h}}$: After the data block is migrated, the destination storage node compares the expected access time with the actual access time, and if the data block is accessed later than expected, it is determined that the effective performance of the destination storage node was insufficient. In this case, the current value of the parameter $p_{\text {h}}$ was too small, so the source storage node increases the value of $p_{\text {h}}$.

• Decreasing $p_{\text {h}}$: When a frequently accessed data block is migrated to an upper storage tier, if no candidate exists after searching for the destination storage node, it is determined that the parameter $p_{\text {h}}$ is large. In other words, the number of storage nodes that exist in the storage tier containing the migration source storage node is large, and the upper storage tier does not exist. In this case, the parameter $p_{\text {h}}$ is too large, so the source storage node decreases the value of $p_{\text {h}}$.

On the other hand, adjusting the parameter $p_{\text {l}}$, which determines the boundary with the lower storage tier, has a limited impact on the improvement of effective I/O performance. This is because the data blocks to be migrated to the lower storage tier are accessed relatively infrequently. Therefore, dynamic adjustment of the tiering parameter $p_{\text {l}}$ is not as important as $p_{\text {h}}$. However, if the value of $p_{\text {l}}$ is unnecessarily large, it will reduce the number of candidates for the migration destination in the lower storage tier. In such a case, the value of $p_{\text {l}}$ should be reduced in order to secure the destination candidates for the migration.

This will allow each storage node to set its own tiering parameters individually according to its own relative performance in the system.

3.2 Candidate Nodes for Data Block Migration

In our previous work [3], to improve the effectiveness of data block migration, the center of the upper storage tier was set as the destination node, as shown in Fig. 3.

Fig. 4

Candidates for migration destination in the proposed method

However, since the locations of $T_{\text {h}}$ and $T_{\text {l}}$ can be dynamically changed in the proposed method, the lowest node of the upper storage tier and the highest node of the lower storage tier are used as candidate nodes for data block migration as shown in Fig. 4.

3.3 Implementation

Each storage node has the tiering parameters $p_{\text {h}} (p_{\text {h}} > 0)$ and $p_{\text {l}} (0< p_{\text {l}} < 1)$ , and adjusts these values during execution. Here, the upper limit of 1 which has set for the parameter $p_{\text {h}}$ is eliminated to increase the flexibility of the parameter settings. On the other hand, the upper limit for the parameter $p_{\text {l}}$ is left at 1 to avoid the threshold $T_{\text {l}}$ becoming negative in Eq. (4). To avoid underflow of both parameter values, the lower setting limit should be set statically, so that the adjusted parameters do not fall below this value.

The storage node that migrates the data block to the upper storage tier sends the following information as management information to the destination storage node along with the data block.

• Migration Type: A flag to identify whether the migration is to the upper storage tier or to the lower storage tier. The value is 1 if the data block is migrated from the lower storage tier, and 0 if the data block is migrated from the upper storage tier.

• Estimated Access Time (EAT): The time at which the data block is expected to be accessed, assuming that it is still on the source storage node. This is calculated based on the length of the access queue for the storage and the average latency required for a single read/write operation.

Each storage node maintains the following information for each migrated data block in order to evaluate the effectiveness of the migration of the data block.

• Block ID: Identifier of the migrated data block in local storage. It consists of the identifier of the storage device and the logical block address of the data block.

• Source ID: Storage ID of the source storage node.

• Migration Type: Information provided by the source storage node with the data block. A 1-bit flag indicating the purpose of the migration.

• Estimated Access Time (EAT): Information provided by the source storage node with the data block.

A hash table based on the hash value obtained from the Block ID is used to manage these data structures. Hereinafter, this table is referred to as migration block management table (MBMT). The storage node to which the data block is migrated registers the information about the migrated data block in the MBMT after the data block is stored in the local storage.

When a storage node accesses data in the public storage area, it refers to the MBMT using the Block ID of the access target. If the data block has been recently transferred, an entry will be found. It checks whether the data block has been transferred from a lower storage tier for improved access performance by referring to the Migration Type field.

When accessing a data block migrated from a lower storage tier, the EAT recorded in the MBMT is compared with the current time. If the current time is later than the EAT, it can be judged that the effect of migrating the data block is not sufficient, so it asks the storage node from which the data block was migrated to raise the tiering parameter $p_{\text {h}}$. The source storage node that receives the request raises the value of the tiering parameter $p_{\text {h}}$. If the amount of change in the parameter value is set too large, there is a high possibility that the parameter value will not be adjusted to the optimal value. To mitigate the rapid increase in the parameter value, the rate of increase should be set to double for $N_{\text {a}}$ adjustments. In other words, the ratio should be set to $\root N_{\text {a}} \of {2}$ for one adjustment. MBMT entries that have been referenced once to check the effect of the migration are removed from the table.

When trying to migrate a data block to the upper storage tier, if there is no storage node in the upper storage tier configured by the tiering parameter $p_{\text {h}}$, then the value of $p_{\text {h}}$ is adjusted. In this case, the reason is that the value of $p_{\text {h}}$ is too large, so the value of $p_{\text {h}}$ is decreased. To mitigate the rapid decrease in the parameter value, the decrease rate should be set to $1/\root N_{\text {a}} \of {2}$.

Similarly, when a storage node wants to migrate a data block to a lower storage tier to secure storage capacity, if there is no storage node in the lower storage tier configured with the tiering parameter $p_{\text {l}}$, the value of $p_{\text {l}}$ is adjusted. In this case, the value of $p_{\text {l}}$ is too large, so the storage node decreases the value of $p_{\text {l}}$. The rate of decrease is set to $1/\root N_{\text {a}} \of {2}$ as in the case of $p_{\text {h}}$.

The number of adjustments $N_{\text {a}}$ to double the tiering parameter is initialized at 2. In accordance with the timing for increasing or decreasing $p_{\text {h}}$ described in Sect. 3.1, $N_{\text {a}}$ is decreased by 1 after increasing $p_{\text {h}}$, and $N_{\text {a}}$ is increased by 1 after decreasing $p_{\text {h}}$. Also, if the actual access time does not exceed the EAT after the data block is transferred, $N_{\text {a}}$ is increased by 1. However, the adjustment range of $N_{\text {a}}$ shall be $1 \leqslant N_{\text {a}} \leqslant 3$.

4 Evaluation

We created a simulation environment in which storage nodes and client nodes are connected by a network, and measured the effect of the proposed method. This section shows the evaluation results compared to the method using static tiering parameters presented in our previous work [3].

4.1 Simulation Conditions

Table 1 Simulation parameters

We show statically defined simulation parameters on Table 1. p is the tiering parameter and it is used as initial value for the parameters $p_{\text {h}}$ and $p_{\text {l}}$. Even when both parameter values are decreased, they should not be less than the lower limit $p_{\text {lim}}$.

Each client node issues $N_{\text {io}}$ times I/O requests. Network latency $L_{\text {n}}$ is time to switch an Ethernet frame. It was measured on a consumer-grade 1000BASE-T Ethernet switch which has wire-speed forwarding capability. The parameter $T_{\text {m}}$ was set to the execution time of the code fragment created for the time measurement. In the I/O queue on a storage node, if the expected wait time for I/O processing, calculated from the queue length and the average read/write latency, exceeds the parameter $T_{\text {w}}$, the system will attempt to migrate the data block to the upper storage tier. The parameter $R_{\text {f}}$ is used as a threshold to determine whether or not to start transferring data blocks to the lower storage tier. When a free storage ratio of a storage node falls below the value defined by $R_{\text {f}}$, the storage node initiates the block migration to the lower storage tier. The parameter $U_{\text {m}}$ indicates the amount of data to be transferred in one data migration.

Table 2 Configurations of client templates

Table 2 shows the parameter configuration used for four types of client templates. In Table 2, client nodes with an I/O interval of 10 [$\upmu$s] are assumed to be nodes that access a storage node with high frequency, and nodes with an I/O interval of 160 [$\upmu$s] are assumed to be nodes that access a storage node infrequently. The read/write ratios of I/O requests are shown in the third column of Table 2. In the simulation, we instantiated client nodes from these client templates. For example, in the configuration of $N_{\text {c}}=320$, 80 instances were created from each client template. To impose a sufficient level of I/O workload on the storage nodes, the minimum number of client nodes is set to 320 in the simulation.

Table 3 shows the reference model of storage devices used on storage nodes. Here, two types of HDDs and SSDs are selected each, and there are significant performance differences due to the different product grades.

Table 3 Storage reference models

We also set up derived versions of each device shown in Table 3 to achieve diversity of storage devices in the simulation. The derived versions were configured according to the following rules:

• For HDDs, faster versions with 10%, 15% and 20% better performance.

• For SSDs, slower versions with 10%, 20% and 30% performance reduction.

• Less storage capacity for high-performance storage devices.

Under the rules, we prepared the base storage $S_i^1$ $(1 \leqslant i \leqslant 4)$ and its three derived versions named $S_i^2$ through $S_i^4$.

Table 4 Configurations of storage templates

The parameter configurations for all storage templates, including the derived versions, is shown in Table 4. In Table 4, the column named Initial capacity shows the available storage capacity in the initial state. Storage nodes are also instantiated from these storage templates, just like the client nodes.

No data block will be shared by more than one client node. Therefore, if one of the client nodes migrates a data block, the execution time of the other client nodes will not be affected by the reason that the access time to that data block will vary.

4.2 Results

We focused on client nodes that frequently access storage, i.e., $C_1$ and $C_3$ clients, and measured the average execution time for these clients to complete $N_{\text {io}}$ I/O operations. The execution time includes the time involved in migrating the data blocks, such as the time required to select the destination and the data transfer time. Figures 5, 6, 7 and 8 show results of the simulation. In these figures, the execution time ratio R is calculated by using Eq. (5).

$$\begin{aligned} R = \frac{T_{\text {a}}}{T_{\text {p}}} \end{aligned}$$

(5)

In this equation, $T_{\text {a}}$ and $T_{\text {p}}$ denote the average execution time of the target process in the proposed method that dynamically adjusts the tiering parameters and in the previous method that uses statically fixed tiering parameters, respectively.

Fig. 5

Execution time ratio ($N_{\text {s}}=16$)

Fig. 6

Execution time ratio ($N_{\text {s}}=32$)

Fig. 7

Execution time ratio ($N_{\text {s}}=48$)

Fig. 8

Execution time ratio ($N_{\text {s}}=64$)

We also compared the execution time ratios of the optimal values of the tiering parameters in the previous method and the most time-consuming case in the proposed method. The optimal tiering parameters in the previous method are determined from the results obtained after simulation, and it is not possible to set these optimal parameter values before execution. Figure 9 shows the ratio of the execution time in the proposed method when the execution time in the previous method set to the optimal tiering parameter value is 1.

Fig. 9

Execution time ratio between the case when the tiering parameters are set to the optimal values for the previous method and the case when the proposed method takes the longest execution time

4.3 Considerations

From Figs. 5, 6 and 7, we can see the performance improvement especially when the number of client nodes is 480 ($N_{\text {c}} = 480$). On the other hand, Fig. 8 shows a larger performance improvement when the number of client nodes $N_{\text {c}}$ is small. For $N_{\text {s}} = 16$, the execution time is almost the same as the previous method, regardless of the setting of $N_{\text {c}}$. In an environment with a small number of storage nodes, it is difficult to see the effect of finely setting the values of the tiering parameters because the performance difference between the storage nodes is relatively large. In particular, in the previous method, the center of the upper storage tier is selected as the transfer destination, so the performance improvement effect obtained by a single data block migration is large. In this respect, the improvement in the proposed method of fine-tuning the tiering parameters was not very effective. However, it can be said that the performance of the proposed method could be improved over the previous method by being able to select an appropriate transfer destination so that the data block transfer destination is not concentrated, especially in a high-load environment where there are many access requests from clients. The overall trend shows that as the number of storage nodes $N_{\text {s}}$ increases, the performance improvement rate of the proposed method increases.

In addition, in the previous method, the tiering parameter was set in 10% increments, but the actual optimal value may be smaller than this incremental step. Furthermore, in the proposed method, since the tiering parameter can be set for each storage node individually, it can be adjusted to a more appropriate value. Therefore, the proposed method may improve the execution performance compared to the optimal parameter values in the previous method.

From Fig. 9, we can observe that the proposed method gives better results than the previous method which set the optimal value statically. In particular, in an environment with a large number of storage nodes $N_{\text {s}} = 64$, the proposed method achieves a performance improvement of about 30% compared to the previous method. In this result, the previous method selects the optimal tiering parameters to achieve the shortest execution time, while the proposed method selects the initial value p which took the longest execution time. In fact, to determine the optimal tiering parameters in the previous method, it is necessary to vary the tiering parameters and measure the execution time. On the other hand, since the proposed method dynamically adjusts the tiering parameters, there is no need to strictly set the initial values. When the number of storage nodes is large, even a slight change in the setting value of the tiering parameters has a significant impact on the setting of the destination. This indicates that the setting of the tiering parameters may greatly affect the performance of the previous method, and the proposed method is more practical in such an environment.

5 Related Work

Hierarchical storage has been widely researched and developed to make effective use of the different characteristics of storage devices. Hierarchical storage systems can be broadly classified into two categories: systems that are configured on a single node and systems that are distributed across multiple nodes.

The former includes Hystor [9] and On-The-Fly Automated Storage Tiering [10]. Lipetz et al. [11] also proposed an automated tiering for a stand-alone storage server. In such environments, there is no need to consider performance impact from network or other network nodes because I/O operations are concluded inside the server.

As the latter, Herodotou and Kakoulli [12] have proposed a framework for automatically migrating data across storage tiers in distributed file systems. Their system applies machine learning for predicting file access patterns, and reduces manual parameter tuning. It is expected to be effective for routine workloads.

They have statically defined storage tiers, such as HDD tier and SSD tier, and migrate data across these storage tiers. In contrast, our system employs an approach in which storage tiering is also performed dynamically.

6 Conclusion

In this paper, we proposed an adaptive tiering scheme to reduce the task of tuning runtime parameters. By dynamically adjusting the parameters for storage tiering according to the operating conditions of the storage system, it is possible to select the appropriate destination for data blocks to be migrated. It can reduce the task to find the optimum parameter, which is previously done by administrators manually.

Future work includes the development of schemes that can support hierarchical network topologies with heterogeneous network latency. In addition, we will develop an evaluation system that approximates the real environment for more detailed evaluation.