Keywords

1 Introduction

The huge amount of data is being produced by the IT industry due to the execution of massive applications on cloud. When an application underperforms IT analysts are looking towards the standard performance benchmark for hard drives. Even though IOPS calculation is a performance measures by which system administrator can clinch about the storage requirement of the current application’s bottleneck [1]. Due to this aforementioned requirement today’s researchers have concerned about the system performance and develop a software tool for making alert to the administrator for upgradation of underlying system [2].

In this paper the calculation of IOPS on Cloud System for measuring maximum IOPS of running application within a particular refresh period is discussed, which helps the IT personnel or Organizations to take decision for changing the storage architecture. Here slow application delivery time is inspected to develop an enhanced environment. Our proposed tool can calculate IOPS of applications executing on Linux based system and also alert the system administrator to upgrade the disk system when the storage as the potential bottleneck.

2 Background Study

2.1 Basic Definition of IOPS

The number of input/output operations a storage device can complete within one second is called Input/Output Operations Per Second (IOPS) [3]. The performance characteristics are measured by randomly or sequentially. Depending upon the file size the random and sequential operations are done. When we are concerning large file then sequential operations are done to access of stored operation in contiguous manner otherwise random operations are done to access locations in the storage device in a non-contiguous way.

There are different characteristics for IOPS measures:

  • Sequential Write IOPS: The average number of sequential write I/O operations that occur per second

  • Sequential Read IOPS: The average number of sequential read I/O operations that occur per second

  • Random Write IOPS: The average number of random write I/O operations that occur per second

  • Random Read IOPS: The average number of random read I/O operations that occur per second

  • Total IOPS: The total IOPS when performing mixed read and write operations

2.2 Frontend IOPS

Fronted IOPS is the total number of read and write operations per second generated by an application or applications.

2.3 Backend IOPS

Backend IOPS is the total number of read and write operations per second which a storage controller sends to the physical disks. This phenomenon is also known as storage IOPS.

The backend IOPS or storage IOPS is calculated by the formula below:

$$\begin{aligned} {\textbf{Storage}}\,{\textbf{IOPS}} & = {\text{Number}}\,{\text{of}}\,{\text{RAID}}\,{\text{Groups}} \times ((\left( {{\text{Read}}\,{\text{Ratio}} \times {\text{Disk}}\,{\text{Operations}}/{\text{Sec}}} \right) \\ & \quad + \;\left( {\left( {{\text{Write}}\,{\text{Ratio}} \times {\text{Disk}}\,{\text{Operations}}/{\text{Sec}}} \right)/{\text{Write Penalty}}} \right))\, \times \,{\text{Quantity}}\,{\text{of}}\,{\text{Disk}}\,{\text{in}}\,{\text{RAID}}\,{\text{Group}}) \\ \end{aligned}$$
(1)

70 % versus 30 % read/write ratio for 15 K SAS in a single RAID 10, the backend IOPS or storage IOPS is:

$$2 \times \left( {\left( {\left( {70\% \, \times \, 180} \right) + \left( {30\% \times 180} \right)/2} \right)} \right) \times 8 = \text{2,448}\,{\text{IOPS}}$$

2.4 RAID Penalty

Write operation can’t be completed until both the data and parity info have been written to the disk. If the any of the write operations are failed, waiting for extra time to write the parity info on to disk. This phenomenon is called RAID penalty [3] (Table 1).

Table 1 Different RAID level penalties
Full size table

2.5 IOPS Calculation

The number of input/output operations is done per second. The formula of IOPS calculation is given below [4] (Table 2):

Table 2 Range of IOPS
Full size table
$$\begin{aligned} {\text{IOPS}}\,{\text{per}}\,{\text{disk}} & = 1/\left( {\left( {\left( {{\text{average}}\,{\text{read}}\,{\text{seek}}\,{\text{time}} + {\text{average}}\,{\text{write}}\,{\text{seek}}\,{\text{time}}} \right)/ 2} \right)/ 1000} \right) \\ & \quad + \;\left( {{\text{average}}\,{\text{rotational}}\,{\text{latency}}/ 1000} \right)) \\ \end{aligned}$$
(2)

The total IOPS of the application is calculated by the following formula [5]:

$${\text{Total}}\,{\text{IOPS}} = {\text{Read}}\,{\text{IOPS}} + \left( {{\text{RAID}}\,{\text{level}}\,{\text{based}}\,{\text{write}}\,{\text{penalty}} \times {\text{Write}}\,{\text{IOPS}}} \right)$$
(3)

To calculate the number of disks is required for frontend IOPS using the following equation [6]:

$${\text{Total}}\,{\text{number}}\,{\text{of}}\,{\text{Disks}}\,{\text{required}} = \left( {\left( {{\text{Total}}\,{\text{Read}}\,{\text{IOPS}} + \left( {{\text{Total}}\,{\text{Write}}\,{\text{IOPS}} \times {\text{RAID}}\,{\text{Penalty}}} \right)} \right)/{\text{Disk}}\,{\text{Speed}}\,{\text{IOPS}}} \right)$$
(4)

2.6 Flow Chart of Our Proposed Model

2.7 Discussion of Our Proposed Work

In this manuscript we have proposed a tool which is incorporated in cloud environment that can collect the input output statistics record from the Linux based application servers in different time interval [7]. Thereafter the tool calculates the highest read/write IOPS value. Then tool evaluates the total application IOPS or IOPS needed for these application servers using Eq. (2).

When first time configured the tool, the storage IOPS or backend IOPS value is also provided or calculated by the Eq. (1) and also is compared the application IOPS with backend IOPS. If application IOPS is higher than backend IOPS then the system understand the reason for slow application delivery. To solve the problem our proposed tool now calculates the total number of disks required using Eq. (4).

After that our proposed tool informs the storage administrator the following details: Application IOPS, Backend IOPS and number of disks required to run the application smoothly. From this report an administrator can easily add the required number of disks to improve the performance [7–9].

2.8 Statistical Data Analysis

We have taken these statistical data for our proposed tool which is given below (Table 3).

Table 3 Sample outputs
Full size table

We have sorted the r/s and w/s values of various device connected with our proposed tool for any certain running application.

device,

r/s,

w/s,

kr/s,

kw/s,

wait,

actv,

svc_t,

%w,

%b

sda5,

1855.8,

685.6,

3623.79,

244.87,

0.1,

0.7

43.1,

6,

5

sda6,

1855.8,

685.6,

2383.79,

236.89,

8.1,

0.9,

31.1,

1,

5

sda7

505.6,

5.8,

288.6,

46.1,

6.2,

1.1,

25.2,

3,

5

sda3

17.8,

43.68,

754.3,

97.9,

1.9,

0.2,

5.1,

0,

2

sda4

17.8,

42.68,

758.8,

94.9,

1.7,

0.5,

7.3,

0,

3

sda1

0.0,

0.0,

0.4,

0.0,

0.1,

0.0,

0.2,

0,

0

sda2

0.0,

0.0,

0.2,

0.0,

0.4,

0.0,

0.1

0,

0

The maximum r/s, w/s and the value of storage IOPS data are stored in file. Application IOPS is computed using r/s and w/s is 3227.199 which is greater than storage IOPS, i.e. 2448. The number of disk(s) required is 2 in this context.

3 Conclusion and Future Work

In this context the designed Java package is capable of calculating the application IOPS and number of disk(s) required for any application in Linux environment which helps to improve the overall system performance. As Bigdata application majorly depends on fast disk access, designing such a package for those kind of application in near future is one of the challenging task [3, 10].