ITS-834: Emerging Threats & Countermeasures. Discussion, Final Research Project.

Evaluating Database Replication Mechanisms for Disaster Recovery in Cloud Environments

Júlio Mendonça∗, Wilson Medeiros†, Ermeson Andrade†, Ronierison Maciel∗, Paulo Maciel∗, Ricardo Lima∗ ∗Informatics Center, Federal University of Pernambuco, Recife, Brazil

†Department of Computing, Federal Rural University of Pernambuco, Recife, Brazil [email protected], {wilson.medeiros, ermeson.andrade}@ufrpe.br, {rsm4, prmm, rmfl}@cin.ufpe.br

Abstract—Relational databases are the most popular database system worldwide. The occurrence of failures in these systems may produce severe consequences for the business, such as data loss, customer dissatisfaction, and subsequent revenue loss. Consequently, many organizations have adopted disaster recovery (DR) solutions as an attempt to prevent data loss and ensure business continuity. Data replication for databases is one of the most used DR solution employed to guarantee data safety and availability. However, the analysis regarding DR aspects has been less explored. Therefore, in this paper, we present an integrated model-experiment approach to evaluate replication mechanisms in relational databases for DR purposes. We performed experiments in a geo-distributed cloud environment and developed analytic models to evaluate DR key-metrics such as availability, downtime, Recovery Time Objective (RTO), and Recovery Point Objective (RPO). The results revealed that the adoption of replication mechanisms could increase the system’s availability significantly. It also revealed that the replication mechanisms can guarantee RPO and RTO within seconds.

Index Terms—Disaster Recovery, Fault-Tolerance, Database Replication, Petri Nets

I. INTRODUCTION

Organizations are spending an unprecedented amount of money towards the cost of providing highly available IT services [1]. In a global market where going offline means a significant revenue loss, companies are looking for efficient DR solutions capable of keeping their data safe and IT systems running. The adoption of such solutions is essential for every business supported by IT systems. Even big companies such as British Airways, U.S. Government, and HSBC bank have experienced unexpected outages [2]. It shows that regardless of size, all companies are prone to catastrophic events and need to be prepared to them. Several solutions have been used to provide DR capabilities for IT systems (e.g., data replication, VM migration, and snapshots) [3]. However, there is not a single blueprint solution that works for all organization, since different organizations have unique needs (e.g., budget or availability).

According to different reports [4, 5], relational database man- agement systems (RDBMS) are still the most popular database (DB) systems worldwide. Even with the growing adoption of cloud computing and non-relational databases (NoSQL) such as MongoDB and Cassandra, the RDBMS still play an essential role in the market. In this way, ensuring DR and availability of these systems is crucial.

Data replication is one of the most used mechanisms to provide DR capabilities for database systems [3]. However,

most of the studies available in the literature focus on either improving the performance of database or comparing differ- ent database distributions [6, 7, 8]. Therefore, motivated by the current scenario of cloud computing expansion and high adoption of RDBMS, we extensively analyze the replication mechanisms of RDBMS in cloud environments focusing on DR aspects. We performed experiments in the cloud and developed analytic models to analyze DR key-metrics: avail- ability, downtime, RPO, and RTO. The developed models can help individuals or organizations to choose the appropriate mechanism, compare with existing solutions, and also provide useful information for the decision-making process. In this way, our key contributions are: (i) A model-experiment approach to evaluate replication mechanisms of RDBMS; (ii) DSPN models that represents cloud environments and database replication mechanisms; and (iii) Analysis of DR key-metrics through stochastic modeling.

The remainder of the paper is organized as follows. Section II presents the related work. Section III introduces fundamental concepts used in this paper. Section IV discusses the adopted experimental architecture. Section V presents the proposed analytic models. Section VI discusses the numerical results. Finally, Section VII presents the conclusions and briefly intro- duces the future work.

II. RELATED WORK Although the evaluation of database systems have been

addressed in the literature, there is a lack of studies that focus on DR [3]. To position our paper and indicate its contributions, we first summarize related work that has been done in the area. Then, we provide a comparison of our work and the literature in terms of the evaluation of database systems.

Jogi and Sinha [6] evaluated the performance of the MySQL, Cassandra, and HBase for massive write operations regarding the average number of transactions per seconds. As expected, the results showed that NoSQL databases had better perfor- mance in the executed experiments (Cassandra and HBase, respectively). Santana et al. [7] presented a replication database study to elastic cloud environments. The authors evaluated different replication techniques focusing on performance met- rics such as response time and abortion rate. Azim et al. [9] proposed an offsite two-way database replication for low- quality network connections. The proposed approach creates a modified file to trace the changes in the databases. By creating this trace, the approach could reduce the update log

2019 IEEE International Conference on Systems, Man and Cybernetics (SMC) Bari, Italy. October 6-9, 2019

978-1-7281-4569-3/19/$31.00 ©2019 IEEE 2358

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

size, and consequently, reduce the time to replicate the data for all databases. Zhuang et al. [8] presented a model to forecast incoming traffic rates and predict the corresponding replication latency of LinkedIn database systems. The devel- oped approach could estimate the maximum replication latency for the database system and also the SLA (Service Level Agreement) of the service.

These studies presented above have mostly focused on ana- lyzing database systems regarding performance. However, none of them have analyzed relational database systems for DR purposes. Therefore, differently from these studies, we per- formed measurements using real-world cloud environments to analyze replication mechanisms in an RDBMS and developed analytic models to evaluate these mechanisms regarding DR key-metrics.

III. FUNDAMENTALS

A. Disaster Recovery

In modern business environments, IT systems should not spend hours or even minutes unavailable, in order to support business operations [10]. In order to achieve high-availability, an IT service should spend less than 5.25 minutes offline per year, meaning at least 99.999 % availability (commonly known as “five nines” availability). DR solutions have been employed to ensure normal business operation so that the IT system stays online and can sustain simultaneous failures and disasters [3]. Some studies state that the adoption of DR solutions is a determinant factor for a company’s survival and growth. [10, 11]. Two metrics are essential to evaluate the DR capabilities: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). The RTO is defined as the maximum time to bring a system or application to its operational state after a disaster event, while the RPO comprises the maximum amount of data that could be lost in a disaster event [10].

B. Data Replication Using MySQL 8

Replication is used to keep data synchronized among nodes and occurs when databases have modified data. Replication consists of sending data updates received by primary (master) nodes to secondary (slave) nodes. Therefore, different databases instances (nodes) can have the same data. These nodes with similar data can be used to provide DR capabilities for a database system. Figure 1 shows a typical implementation of database replication. In this example, if the primary node (DB server 1) running in the primary cloud fails, the slave node (DB server 2) executing in the secondary cloud infrastructure (DR cloud) can assume its place and keep the systems running with all the data available. As follows, we explain two replication mechanisms available in MySQL 8.

1) Group Replication: This replication mechanism aims to achieve consistency between the node’s data. A protocol must be adopted to ensure that all nodes receive the messages and that the messages were received in the right order. Atomic multicast is a protocol that can be adopted to ensure that all messages sent to a set of nodes are delivered to all or none of them. One-phase commit, two-phase commit, and three-phase commit are also presented as distributed commit protocols.

Users

D ata replication

Request

DR Cloud

Web servers

Primary Cloud

DB requests in case of failures

DB requests L oad Balancer

Internet

DB Server 1

DB Server 2

Fig. 1. Adopted solution using cloud database replication

One-phase commit, which is adopted by MySQL 8, is the one that the master only sends the updates. That is, it does not notice if the slaves committed the transaction. Two and three- phase commits add one more phase to allow nodes to decide about a transaction. So, the nodes try to reach a consensus about the transaction and commit it or discard the transaction.

2) Synchronization: The synchronization mechanism is used to synchronize the data stored on a master database with the data stored on slave databases. Differently from the group replication, it does not have automatic conflict detection and resolution. In the synchronization mechanism, when the slave receives updates, it writes them in its relay log and then the slave reads the relay log to execute the update. This synchronization takes place when an update is fully written in the relay log. The available configurations are asynchronous and semisynchronous:

• Asynchronous: In this configuration, no synchronization is guaranteed. The master will send the update to its slaves, but it does not wait for synchronization before commit. If the master crashes, there might result in data loss.

• Semisynchronous: This configuration waits for a given number of slaves to receive the updates and only commits after all of them send an acknowledgment or a timeout has occurred. In this way, there is no data loss be- cause the master only commits the request after receiving the acknowledgment from the slaves. Note that when a timeout occurs or the slave fails, the master changes its configuration to become asynchronous.

C. Modeling and evaluation with DSPNs

Availability is an essential dependability attribute, which has been largely adopted in the SLA contracts with many cloud providers. It is defined as the fraction of time that a system provides the service for which it is specified, and can be computed using the Equation 1 [12]:

A = MTTF

MTTF + MTTR (1)

where A is the resulting availability, MTTF (Mean Time to Failure) concerns the average time for the occurrence of failures in the system, and MTTR (Mean Time to Repair) corresponds to the average time taken to fix the system. The systems’ downtime is computed by D = (1 - A) × T, where D is the

2359

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

Data replicationDB Requests

DR Cloud

Internet

Workload Primary Cloud(MS Azure cloud – USA)

(Google cloud – USA) (Google cloud – USA/Europe)

Fig. 2. Testbed setup

computed downtime, A is the system availability, and T is the period of time adopted [12].

Petri nets are a formalism quite widespread to evaluate sys- tems focusing on dependability, concurrency, and performance [13]. Petri nets models are based on states (places) and activities (transitions). The transitions are responsible for performing the model state changing. In this work, we use an extension of Petri nets called Deterministic and Stochastic Petri nets (DSPNs) [13]. The DSPNs consider two types of transitions: timed and immediate. Timed transitions are deterministic or exponentially distributed and have the single-server or infinite- server semantics. In the single-server semantic a transition can only be fired once at a time, even if multiple tokens are enabling the transition firing, while for the infinite-server semantic a transition can perform n simultaneous firings if there are n tokens enabling the transition. For more information regarding DSPNs, the reader should refer to [13].

IV. EXPERIMENTAL ARCHITECTURE

This section details the testbed configuration, and the exper- iments carried out to obtain the parameters of database replica- tion mechanisms. Figure 2 shows how the setup was configured for the experiments, where two different public cloud providers in different geographic locations were adopted. The Microsoft Azure cloud was used to host a JMeter application [14]. The JMeter was used to generate workload for the RDBMS, so that it simulates users requests from a web server application (see Figure 1). In the Google cloud, we configured the Master database server in one location (primary cloud), and the Slave database server in another location (DR cloud). In this way, we created geographic data replication to avoid data loss due to disasters in the same location.

The testbed was configured as follows. The VM for the JMeter workload was hosted into the Microsoft Azure cloud and was located at USA (east US region). We used the VM type B1s, configured with one vCPU, RAM of 1 GB, a standard HDD of 30 GB, and the Ubuntu 16.04 LTS as the operating system (OS). The databases systems were hosted into the Google cloud. The master database was located in the USA (US-east1-b region), and the slave was located in two different regions (USA - US-west1-b, and Europe - Europe-west4-a). We used the same type of VM for both master and slave database servers. These VMs were of the type n1-standard-2, configured with two vCPUs, RAM of 7.5 GB, standard HDD of 40 GB, and Ubuntu 16.04 LTS as the OS. Lastly, the DB requests were of a fixed size of 500KB.

By using the testbed setup mentioned above, we generate different workloads using JMeter to send requests for the master database. Next, we recorded in a log file how long it takes

TABLE I GUARD FUNCTIONS FOR THE DSPN MODELS OF FIGURE 3 AND 5

Guard Function

Gf1 , Gf2 , Gf3 (#Pc1_up = 0) Gfn1 (#Pc1_dis = 1) Gc1-lb , Gc1-db , Gc1-web , Gntw1 (#Pc1_up = 1) Gf4 (#Pc2_up = 0) Gfn2 (#Pc2_dis = 1) Gntw2 , Gdb2 (#Pc2_up = 1) Gf5 (#Pc1-db_up >0)AND(#Pc2-db_up =0) Gf6 (#Pc1-db_up >0)AND(#Pc2-db_up >0) Gdf (#Pc1-db_up = 0) GDB1b , GreturnDB1 (#Pc1-db_up =1) GchkBD2 (#Pc1-db_up =0)AND(#Pc2-db_up >0)AND(#Pntw2_up =1)

to replicate the data into the slave database. Note that for these experiments, we analyzed both asynchronous and semi- synchronous configurations for the synchronization mechanism of MySQL 8 (see Section III-B2).

V. PROPOSED MODELS

This section presents the proposed DSPN models for the adopted solution (see Figure 1) using database replication mechanisms. First, we present the availability models, then we explain the developed models for the RPO and RTO.

A. Availability models

The upper part of Figure 3 shows the DSPN models for the primary cloud. Figure 3 (a) represents the behavior of the primary cloud, while Figures 3 (b) and (c) exhibit the DSPN models for the network components and load balancer (LB), respectively. Lastly, Figures 3 (d) and (e) show the DSPN model for the web servers (WS), and database server, respectively. The core component models reproduce failure and repair behaviors (e.g.: DB servers and LBs). Figure 3 (c) presents the failure and repair behavior of a load balancer. In this model, a token in the place P_up means that the LB is operational. Otherwise, the presence of a token in the place P_down symbolize that the LB is unavailable. The transitions Tc1-lb_fail and Tc1-lb_rep are the ones responsible for the state change. Component redundancy is represented by the numbers of tokens in the DSPN model (see Figure 3 (d)).

Differently from the core components, the DSPN model for the primary cloud (Figure 3 (a)) has two transitions representing failures: one representing transient failures (Tc1_fail), and an- other one modelling disaster events (Tc1_dis). Note that transient failures are easily recoverable and demand a short recovery time, while disaster events require more time to be repaired [11]. The models also consider the dependency between the cloud and its components. When the primary cloud goes down, the VMs become unavailable at the same time. In the DSPN models, this dependency is modeled by the guard functions Gfn1, Gf1, Gf2, and Gf3 assigned to the immediate transitions Tfn1, Tf1, Tf2, and Tf3, respectively. Table I displays all guard functions used in the DSPN models of Figure 3.

The bottom part of Figure 3 presents the DSPN models regarding the DR cloud and its components. Figure 3 (f) shows the DSPN for the DR cloud. Figure 3 (g) and (h) display the DSPN models for the external network and the slave

2360

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

Primary cloud

DR cloud 1

(h) DSPN for the database server 2

Pc2-db2_up

Tc2-db2_fail

Pc2-db2_down

Tc2-db2_rep

1Pntw2_up

Tntw2_fail

Pntw2_down

Tntw2_rep

(g) DSPN for the external network

1

(a) DSPN for the Primary cloud (c) DSPN for the load balancer

Pc1-lb_up

Pc1-lb_down

Tf1Tc1-lb_rep Tc1-lb_fail

2

(d) DSPN for the web servers

Pc1-web_up

Pc1-web_down

Tf2Tc1-web_rep Tc1-web_fail

1

(e) DSPN for the database server 1

Pc1-db_up

Pc1-db_down

Tf3 Tc1-db_rep Tc1-db_fail

[Gc1-lb] [Gf1] [Gc1-web] [Gf2] [Gc1-db] [Gf3]1

Pc1_up

Pc1_fail

Tc1_rep

Tc1_fail

Pc1_dis

Tc1_dis

Tc1_rep-dis 1 Pntw1_up

Tntw1_fail

Pntw1_down

Tntw1_rep Tfn1

[Gfn1]

(b) DSPN for the network

[Gntw1]

1

Pc2_up

Pc2_fail

Tc2_rep

Tc2_fail

Pc2_dis

Tc2_dis

Tc2_rep-dis

(f) DSPN for the DR cloud

[Gntw2]

Tf4 [Gf4]

Tfn2 [Gfn2] [Gc2-db2]

1 Psemisync

Tfail-db2 Pdb2-down

Pasync

[Gf5]

Ttimeout

TbackSemisync [Gf6]

(i) DSPN for the semisync timeout

Fig. 3. Availability models for the adopted solution of Figure 1

TNR PDB1busy

PDB1capacity

TDB1process Treplicate

PrepCapacity

DBC

RC

PwaitRep

Fig. 4. RPO model for database asynchronous replication

TsetDB2

[Gdf]

[GchkDB2]

[GreturnDB1] 1 PwaitFail

TdetectFail PwaitDB2

[GDB1b]TDB1back

PDB2working

TreturnDB1

Fig. 5. RTO model for the database replication mechanism

database server (DB Server 2), respectively. Lastly, Figure 3 (i) represents the timeout behavior when the semisynchronous configuration is adopted. This model is only used when we need computing the system’s availability for the semisynchronous configuration. When the DB server 2 fails, and it is not possible to sustain semisynchronous configuration, the system waits for a particular time (Ttimeout) to set the asynchronous configuration to the DB server 1. Note that, similar to the primary cloud, there is a dependency between the DR cloud and its components. If the DR cloud is unavailable, the slave database server becomes unavailable, and it cannot receive data from the master database (DB Server 1). It is worthwhile to mention that the timed transitions representing failures events have an infinite-server semantics, while the transitions representing repair events have a single-server semantics.

B. Disaster Recovery Models for RPO and RTO

In order to compute the RPO and RTO of the database replication mechanisms, we developed more two DSPN models. Figure 4 shows the DSPN model designed to compute the RPO for the asynchronous configuration. Note that for the MySQL semisynchronous configuration, the RPO is zero since the mas- ter only commits a request after receiving an acknowledgment from the slave nodes (see Section III-B2). The DSPN model

for the RPO represents both the incoming requests on the DB server 1 and the replication process. The transition TNR models the incoming requests on the DB server 1. The requests arrive at the DB server 1 and are processed. The transition TDB1process represents the transactions processing. The requests can only be processed if the server has the capacity. The variable DBC defines the server capacity. After the request is processed, it can be replicated to the DB server 2 (TReplicate). The DB server 1 also has a replication capacity (RC) to send the requests to the DB server 2. We remark that the transitions TDB1process and TReplicate are defined with the infinite-server semantics.

The RPO model represents an M/M/m/K queue system. Then, to compute the RPO, we adopted the Little’s Law [12] defined by the Equation 2:

MeanResponseTime = NRequests

MeanThroughput (2)

where NRequests is the number of customers in the system, MeanThroughput is the arrival rate of customers, and Mean- ResponseTime is the system’s average response time. For the RPO model, MeanResponseTime represents the RPO because it represents the meantime that a request spends to be replicated. In this way, the MeanThroughput is the real throughput for the transition TReplicate, and the NRequests is the expected number of tokens in the place PwaitRep. The MeanThroughput can be computed by the Equation 3:

MeanThroughput = (λDB1 × (1 − pK)) × pC1up × pR (3) where pK represents the probability of the place PrepCapacity having no tokens, pC1up is the probability of the primary cloud to be operational, and pR is the probability of the external network, the DB server 1, and the DB server 2 all to be operational. Lastly, λDB1 is the real throughput of the transition TDB1process. It can be decomposed as shown in Equation 4:

λDB1 = (λA × (1 − pL)) × pDB1up (4) where λA is the rate of the transition TNR, pL is the probability of the place PDB1capacity having no tokens, and pDB1up is the probability of the DB server 1 to be operational. Note that the

2361

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

TABLE II RESULTS OF THE EXPERIMENTS FOR THE DATABASE REPLICATION

Parameter Slave node in the USA

Async Semi-sync

Processing time (St. dev) 240.162 (109.440) ms 482.951 (161.344) msm Replication time (St. dev) 270.887 (112.217) ms 240.970 (109.352) ms

Slave node in Europe

Async Semi-sync Processing time (St. dev) 233.648 (106.354) ms 850.222 (307.534) ms Replication time (St. dev) 486.748 (191.366) ms 579.383 (211.997) ms

values for the pDB1up, pC1up, and pR are achieved through the availability models.

Figure 5 displays the DSPN model to compute the RTO for both asynchronous and semisynchronous configurations. Note that the RTO is computed by the average elapsed time since the DB server 1 failure until the activation of the DB server 2 as the primary database. When a failure occurs in the DB server 1, the transition TdetectFail fires, starting the process to set the DB server 2 as the primary database (TsetDB2). If during such a process, the DB server 1 returns to the operational status a token returned to the initial place (PwaitFail) through the fire of the transitions TDB1back. If the DB server 1 is still down and the guard function GchkDB2 is satisfied, the transition TsetDB2 fires, generating a token in the place PDB2working. It indicates that the DB server 2 is now operating as the primary database. Table I exhibits all the guard functions adopted for the RTO model. We also adopted the Equation 2 to compute the RTO. For the RTO model, the MeanResponseTime represents the RTO value since it compute the meantime to activate the DB server 2 as the primary database. The MeanThroughput represents the throughput for the transition TsetDB2, and NCustomers represents the expected number of tokens in the place PwaitDB2.

VI. RESULTS AND DISCUSSION

This section discusses the numerical results achieved by the experiments and the DSPNs numerical analysis.

A. Experiments results

This subsection presents the results achieved with the ex- periments performed in the adopted testbed shown in Section IV. We performed the experiments to obtain the input param- eter values for the DB processing time (TDB1process) and DB replication time (TReplicate). Table II displays the results of the experiments for the two geographic locations used to config- ure the slave node (DB server 2). The results are presented in milliseconds for both asynchronous and semisynchronous configurations. Furthermore, the standard deviation (St. dev) for each result is exhibited between parentheses.

B. Analysis of the DSPN models

The analysis of the DSPN models was performed using the Mercury tool [15]. We used the input parameters based on [16, 11] displayed in Table III. Note that for the DB server processing time and the DB server replication time we employed the values obtained by the experiments (see

0.99786606

0.998540751 0.99854531

18.69

12.78 12.74

0 2 4 6 8 10 12 14 16 18 20

0.9950 0.9955 0.9960 0.9965 0.9970 0.9975 0.9980 0.9985 0.9990 0.9995 1.0000

w/o DR w/ DR - Semisync

w/ DR - Async

D ow

nt im

e (h

/y ea

r)

Av ai

la bi

lit y

(% )

Configuration

Availability Downtime

Fig. 6. Availability results achieved by the DSPN models of Figure 3

TABLE III INPUT PARAMETERS FOR THE DSPN MODELS

Parameter Assigned Transitions Value (h)

Clouds MTTF Tc1_fail , Tc2_fail 8760 Clouds MTTR Tc1_rep ,Tc2_rep 4 Mean time for a disaster Tc1_dis , Tc2_dis 17520 Mean time to repair a disaster Tc1_rep-dis , Tc2_rep-dis 12 Load balancer MTTF Tc1-lb_fail 8760 Load balancer MTTR Tc1-lb_rep 0.5 Web/Database servers MTTF Tc1-web_fail , Tc1-db_fail , Tc2-db_fail 2654 Web/Database servers MTTR Tc1-web_rep , Tc1-db_rep , Tc2-db_rep 1.25 Networks MTTF Tntw1_fail , Tntw2_fail 10000 Networks MTTR Tntw1_rep , Tntw2_rep 1 Mean time to arrival requests(MTTA) TNR 1.3888E-5 Timeout Ttimeout 0.00833 Time to activate DB2(CDB2 ) TsetDB2 8.3333E-3 DB mean processing time TDB1process variable DB mean replication time Treplicate variable

Table II). Besides, the parameters for the capacity for the DB server 1 were reasonably estimated as DBC=10 and RC=10. First, we analyzed the availability of the adopted solution considering the scenarios without and with the DR strategy using the DSPN models of Figure 3. Table IV details the adopted metrics and Figure 6 shows the availability results. The results revealed that without a DR solution, the availability achieved was 0.99786606, which means a downtime/year of 18.69h. By enabling the DR solution, the availability obtained was 0.99854075 for the semisynchronous configuration, and 0.99854531 for the asynchronous configuration, which means a downtime/year of 12.78h and 12.74h, respectively. Although the database replication was not capable of providing high- availability for the solution (“five nines”), it considerably in- creases the system’s availability, decreasing the downtime/year in almost six hours.

We also analyzed the RPO and RTO metrics using the DSPN models. To compute the RPO for the asynchronous configuration, we calculated the availability metrics (pDB1up, pC1up, pR, pL, and pK) and passed them as a parameter to the RPO metric on the DSPN model of Figure 4. On the other hand, to obtain the RTO, we executed the DSPN model of Figure 5 together with the availability models (see Figure 3). Table IV displays the expressions used to compute the RPO and RTO. We analyzed the DSPN models for the RPO and RTO according to the slave node location (USA and Europe). For each mechanism, we used the correspondent value for

2362

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

TABLE IV EXPRESSIONS USED TO CALCULATE THE METRICS IN THE DSPN MODELS

Metric Expression

Av w/o DR P{(#Pc1-lb_up >0) AND (#Pc1-web_up >0)AND

(#Pc1-db_up >0)AND(#Pntw1 =1)}

Av w/ DR (Async) P{((#Pc1-lb_up >0)AND (#Pc1-web_up >0)AND(#Pc1-db_up >0)

AND(#Pntw1 =1))OR((#Pc1-lb_up >0)AND (#Pc1-web_up >0)AND(#Pc2-db_up >0)AND(#Pntw2 =1)}

Av w/ DR (Semisync) P{((#Pc1-lb_up >0)AND(#Pc1-web_up >0)AND(#Pc1-db_up >0) AND(#Pntw1 =1)AND(#Pdb2-down =0))OR((#Pc1-lb_up >0)

AND (#Pc1-web_up >0)AND(#Pc2-db_up >0)AND(#Pntw2 =1)}

pDB1up P{#Pc1-db_up >0}

pC1up P{#Pc1_up >0}

pR P{(#Pntw2_up >0)AND(#Pc1-db_up >0)AND(#Pc2-db_up >0)}

pL P{#Pdb1Capacity =0}

pK P{#PrepCapacity =0}

λDB1 (1/MTTA) - ((1/MTTA) × pL ) × pDB1up RPO (Async) E{#PwaitRep } / ((λDB1 − (λDB1× pK )) × pC1up × pR )

RTO E{#PwaitDB2 >0} / (P{(#PwaitDB2 >0) AND (#Pc2-db_up >0)

AND (#Pc1-db_up =0)}) × (1/CDB2 ))

0.272595556

0.489817769

0.00 0.02 0.04 0.06 0.08 0.10 0.12 0.14 0.16 0.18 0.20 0.22 0.24 0.26 0.28 0.30 0.32 0.34 0.36 0.38 0.40 0.42 0.44 0.46 0.48 0.50

Slave node in the USA Slave node in Europe

RP O

- A

sy nc

re pl

ic at

io n

(s ec

)

Fig. 7. RPO results for the asynchronous configuration

the DB processing time and the DB replication time achieved by the experiments. Figure 7 displays the RPO results. The best results for the RPO was with the slave node in the USA (near the master DB), showing an RPO of 0.272595 seconds. With the slave node in Europe, the computed RPO was of 0.489817 seconds. We remark that even when the slave node was located on another continent, the RPO results were less than one second. It worth to stress that the RPO is zero for the MySQL semisynchronous configuration because the master only commits a request after receiving an acknowledgment from the slave nodes.

Regarding the RTO, this metric presented the same result for all configurations since we consider that the DR cloud has the same characteristic in both locations (USA and Europe). Therefore, the RTO only depends on the time to detect a disaster and the time that the DB server 2 takes to assume as the primary DB server. In this way, the computed value for the RTO was 41.499 seconds. Note that all the results follow a confidence interval of 95% and an error margin of 5%.

C. Assumptions and Limitations

Some assumptions and limitations were considered in this study: (i) During the experiments, the testbed did not have other workloads. These conditions may not match precisely a business scenario. (ii) The network speed was not considered

in the models since cloud providers usually have great con- nections. (iii) The primary cloud and DR cloud had the same dependability characteristics.

VII. FINAL REMARKS This work presented an approach based on experiments and

analytic modeling to evaluate replication mechanisms on rela- tional databases for DR purposes. We performed experiments in a real-world cloud environment and developed DSPN models to compute DR key-metrics: availability, downtime, RPO, and RTO. The cloud environment was set up in different continents for comparison. Our DSPN analysis revealed that the system’s availability increases when a database replication is used, but it does not achieve five 9’s of availability. Nevertheless, the adopted replication mechanisms can guarantee an RPO and RTO within seconds. For the scenarios studied, the best result was using the slave node at the same continent of the primary DB server. Besides, when the slave node was located on another continent, the RPO was still less than one second. The integrated model-experiment approach presented in this paper can help individuals or organizations to compare DR solutions under construction and provide inputs for the decision-making process. As future works, we consider to analyze different databases and study the trade-offs of the replication mecha- nisms in term of performance.

ACKNOWLEDGMENTS This research was partially funded by FACEPE - Brazil, grant

IBPG-0418-1.03/15.

REFERENCES [1] Zetta, “State of Disaster Recovery 2016,” 2016, [Online]. https://bit.ly/2H6TwhN. [2] IEEE Spectrum’s risk analysis blog, “The biggest it failures of 2018,” 2018.

[Online]. Available: https://bit.ly/2GTNEbj [3] J. Mendonça, E. Andrade, P. T. Endo, and R. Lima, “Disaster recovery solutions for

IT systems: A Systematic mapping study,” Journal of Systems and Software, 2018. [4] T. Shay, “Most popular databases in 2018 according to stackoverflow survey,”

2018. [Online]. Available: https://bit.ly/2DCwqhj [5] DB engines, “Db-engines ranking,” 2019, [Online]. https://bit.ly/2s90XvI. [6] V. D. Jogi and A. Sinha, “Performance evaluation of MySQL, Cassandra and HBase

for heavy write operation,” in 2016 3rd International Conference on Recent Advances in Information Technology (RAIT). IEEE, mar 2016, pp. 586–590.

[7] M. Santana, J. E. Armendáriz-Iñigo, and F. D. Muñoz-Escoí, “Evaluation of Database Replication Techniques for Cloud Systems,” Computing and Informatics, vol. 34, no. 5, pp. 973–995, 2016.

[8] Z. Zhuang, H. Ramachandra, C. Tran, S. Subramaniam, C. Botev, C. Xiong, and B. Sridharan, “Capacity Planning and Headroom Analysis for Taming Database Replication Latency,” in Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering - ICPE ’15. ACM Press, 2015, pp. 39–50.

[9] N. Azim, A. Khan, F. Khan, A. Majid, S. Roohullah Jan, and M. Tahir, “Offsite 2- Way Data Replication towards Improving Data Refresh Performance,” International Journal of Engineering Trends and Applications (IJETA), 2016.

[10] W. J. Rooney, G. E. McBride, and T. Hanif, “IBM TotalStorage Productivity Center for Replication for z/OS,” IBM Systems Journal, vol. 47, no. 4, pp. 681–694, 2008.

[11] J. Mendonça, R. Lima, R. Matos, J. Ferreira, and E. Andrade, “Availability analysis of a disaster recovery solution through stochastic models and fault injection experiments,” in 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA), 2018, pp. 135–142.

[12] C. Cassandras and S. Lafortune, Introduction to Discrete Event Systems, 2nd ed. Springer Publishing Company, Incorporated, 2010.

[13] M. Marsan and G. Chiola, “On petri nets with deterministic and exponentially distributed firing times,” in Advances in Petri Nets 1987, 1987, vol. 266, pp. 132–145. [Online]. Available: http://dx.doi.org/10.1007/3-540-18086-9\_23

[14] The Apache Software Foundation, “Apache JMeter,” 2019. [Online]. Available: https://jmeter.apache.org

[15] B. Silva, R. Matos, G. Callou, J. Figueiredo, D. Oliveira, J. Ferreira, J. Dantas, A. Lobo, V. Alves, and P. Maciel, “Mercury: An integrated environment for performance and dependability evaluation of general systems,” in Proceedings of Industrial Track at 45th Dependable Systems and Networks Conference, DSN, 2015.

[16] F. Machida, E. Andrade, D. S. Kim, and K. S. Trivedi, “Candy: Component-based Availability Modeling Framework for Cloud Service Management Using SysML,” in IEEE 30th International Symposium on Reliable Distributed Systems, 2011.

2363

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.