Vectorization and Efficient Memory Usage

Since the emergence of the cloud computing paradigm, researchers have conducted studies that are related to disaster recovery. In this section, the researcher takes a critical look at these different Disaster Recovery systems with special emphasis on the various algorithms they used, benefits and weaknesses of each system.

2.9.1 SecondSite: Disaster Tolerance as a Service

The SecondSite is a disaster tolerance as a service deployed over the cloud (Rajagopalan, Cully, O'Connor, and Warfield, 2012). This platform is intended to handle three challenges:

1. Reducing RPO

2. Failure detection 3. Service restoration.

For this reason, it uses three techniques:

1. Using storage to keep writes between two checkpoints: Checkpoints move between sites in a specific period. However, if a failure happens in this time, some data will be lost. For this reason, a Distributed Replicated Block Device (DRBD) is used to store replications in both synchronous and asynchronous modes

2. Using a quorum node to detect and distinguish a real failure: A quorum node has been designed to monitor primary and backup server. If replications have not been received by the backup site in the waiting time, the backup site sends a message to quorum node. In this case, if the quorum node receives a heartbeat from a primary node, it means the primary server is active and the replication link has a problem; otherwise the backup site will be activated.

3. Using a backup site: There is a geographically separated backup site which allows replicating groups of virtual machines through wide-area Internet links.

SecondSite increases ability to fast failure detection and also differentiate between network failures and host failures. Using DRDB, resynchronize storage can be done for recovering primary site without VMs interruption in the backup site. Although SecondSite is not suitable for stateless services, however, it increases availability for small and medium businesses.

2.9.2 Remus: High availability via asynchronous virtual machine replication Remus is based on Xen hypervisor (Barham et al., 2003). It is a high availability cloud service to tolerate disaster using storage replication combined with live VM migration (Cully et al., 2008). In this system, protected software is encapsulated in the virtual machines to asynchronously replicate whole-system checkpoints in a backup site with a high frequency. It is assumed that both replicas are in the same local area network (LAN). Remus is aimed at three main goals:

1. Providing low-level service to gain generality 2. Transparency

3. Seamless failure recovery.

Remus uses an active primary host and a passive backup host to replicate checkpoints.

All writes have to be stored in backup RAM until a checkpoint completes. Migrated Virtual machines execute on the backup only if a failure is detected. Remus usage consists of four stages:

1. Stop running VMs and propagate only changed states into a buffer 2. Transmission of buffered states into backup RAM

3. Send an ACK message to the primary host after checkpoint completion 4. Release the network buffer to external clients.

This system integrates simple failure detection into the checkpoint process. If checkpoints are not received by the backup site in an epoch, the backup site will be activated. On the other hand, if the backup response is not received during a specific period, the primary site will suppose a failure at the backup host. However, Remus increases performance overhead which leads to some latency, because it requires ensuring consistent replication. In addition, this system needs a significant bandwidth.

Similarly, this platform focuses on Service Provider and their infrastructures.

2.9.3 Romulus: Disaster tolerant system based on kernel virtual machines

Romulus as a Disaster Recovery Solution is an extension of the Remus system (Caraman, Moraru, Dan, and Kristaly, 2009). It is based on the KVM hypervisor (Kivity, Kamay, Laor, Lublin, and Liguori, 2007). Romulus provides an accurate algorithm for disaster tolerant in seven detailed stages which are:

1. Disk replication and network protection 2. VM checkpoint

3. Checkpoint synchronization

4. Additional disk replication and network protection 5. VM replication

6. Replication synchronization 7. Failure detection and failover.

The flaw of Remus is that it uses one buffer to replicate writes between primary host and backup. If a failure occurs in this buffer before transferring checkpoint, it causes an inconsistency between the disk and VM state; and it can break fault tolerance of Remus. For this reason, Romulus uses a new buffer to replicate disk writes after any checkpoint. The second flaw is that network egress traffic cannot be released until

completely transferring checkpoint to storage backup host which can decrease system performance. However, Romulus uses a new egress traffic buffer to solve this problem.

Romulus can tolerate failure in two situations:

1. On the fly: it consists disk and VM state replication into a new writes buffer during VM running.

2. Failover: the ability of service recovery after a disaster.

2.9.4 Myriad: Cost-Effective Disaster Tolerance

This work proposed a new approach for achieving disaster tolerance in large, geographically-distributed storage systems. The system, called Myriad, can achieve the same level of disaster tolerance as a typical single mirrored solution, but uses considerably fewer physical resources, by employing cross-site checksums (via erasure codes) instead of direct replication (Chang et al., 2002). It provides a disaster tolerant service with respect to resource allocation issue which is a challenge in DT services.

Host and backup clusters are monitored by high availability controllers. Each cluster has three different controllers:

1. Storage controller: To control and manage the cluster storage.

2. Cluster controller: To manage IPs, centralized memory and CPU availability.

3. Node controller: To load, start and stop the VM.

Different nodes and also different clusters can communicate with each other for better resource allocation. For this purpose, backup cluster controller allocates a VM to a node. Then, node controller loads and starts the VM and allocates it to the primary host.

Finally, primary node controller loads and starts the VM.

In this system, VM failover consists of two scenarios. The first scenario is cluster failure. In this situation, the backup cluster will be activated. Node failure is another scenario in which cluster controller releases VMs' IP and allocates a backup node to compose required VMs. This system is most useful for extended distance and metropolitan clusters because of low latency requirements.

2.9.5 Kemari: Virtual machine synchronization for fault tolerance

Kemari is a cluster system which tries to keep VMs transparently running in the event of hardware failures (Tamura, Sato, Kihara, and Moriai, 2008). Kemari uses the

primary-backup approach so that any storage or network event that changes the state of the primary VM must be synchronized in backup VM. This system has gained the benefits of the Lock stepping and the Checkpointing (Bressoud and Schneider, 1996).

Two main approaches for synchronizing VM state include:

1. Less complexity compared to lock stepping approach.

2. It does not need any external buffering mechanisms which can affect the output latency.

2.9.6 RUBiS: Disaster Recovery as a Cloud Service

RUBiS, according to (Wood et al., 2010) is a cloud architecture aims at both Disaster Recovery and also minimizing costs with respect to Service Level Agreement. As shown in Figure 2.7, in ordinary operation, a primary data center including some servers and a database accomplish normal traffics. A cloud is in charge of disaster recovery with two types of resources;

1. Replication mode resources for getting backup files before a disaster which is active

2. Failover mode resources that will be activated only after a disaster

It is notable that service providers can rent inactive resources to other customers for revenue maximization. In the case of a disaster, leased resources must be released and allocated to the failover procedure.

Figure 2.7: Overviews of RUBiS system architecture (Wood et al., 2010)

2.9.7 Hypervisor-Based Fault Tolerance (HBFT) System

This system is a Hypervisor-Based Fault Tolerant (HBFT) prototype which uses a mechanism similar to Remus (Zhu, Jiang, Xiao, and Li, 2011). However, instead of Remus which uses a separate local disk for replication, HBFT uses a Network Attach Storage (NAS). Shared storage may become a single point and cause a weakness of this method, so RAID or commercial NAS solution should be deployed (Patterson, Gibson, and Katz, 1988). On the other hand, because of using shared storage, the need for synchronizing is decreased and also file system state is maintained in the event of a disaster. Another major setback of this system is that it is only operational as service provider premises.

2.9.8 High Security Distribution and Rake Technology (HS-DRT) System

The goal of the HS-DRT system is protecting important data from natural or subversive disasters (Ueno, Miyaho, Suzuki, and Ichihara, 2010). As illustrated in Figure 2.8, this system uses an HS-DRT processor with a cloud computing system. Clients serve as terminals which request some web applications. The HS-DRT processor has functioned as a web application and also encryption, spatial scrambling, fragmentation of data. In the end, data is sent and stored in a private or public cloud. The system architecture is as shown in Figure 2.7. This system severely increases the security of data before and after the disaster in cloud environments. However, it has some weaknesses;

1. The performance of the web application will be decreased if the number of duplicated copies increases.

2. This system cannot guarantee consistency between different copies of file data.

3. Also it is only operational within service provider premises.

Figure 2.8: The architecture of the HS-DRT system (Ueno et al., 2010) 2.9.9 PipeCloud: using causality to overcome speed-of-light delays in cloud-based

disaster recovery

This cloud-based multi-tier application system uses the Pipelined replication technique as a Disaster Recovery solution (Wood, Lagar-Cavilla, Ramakrishnan, Shenoy, and Van der Merwe, 2011). PipeCloud architecture is composed of a cloud backup site and a primary data center. The goal of this system is mirroring storage to the backup site and minimizing RPO. The main tasks of PipeCloud are;

1. Replicating all disk writes to a backup site by the replication technique 2. Tracking the order and dependencies of the disk writes

3. Releasing network packets only after storing the disk writes on the backup site.

This system results in a higher throughput and lower response time by decreasing the impact of WAN latency on the performance. For this purpose, the system overlaps replication with application processing. Also, it guarantees zero data loss consistency.

However, unlike of Remus, PipeCloud cannot protect the memory states because it leads to large overhead on WAN. Also, it is only operational within service provider premises.

2.9.10 Knowledge as a service framework for disaster data management

A huge amount of disaster-related data has been generated by government,

Knowledge as a Service KaaS framework for disaster data management which can lead to better preparation, response and recovery of disasters (Grolinger, Capretz, Mezghani, and Exposito, 2013). As shown in Figure 2.9, this system uses both relational and NoSQL databases to store data (Schram and Anderson, 2012). Disaster-CDM consists of two parts;

1. Knowledge acquisition: Obtaining knowledge from a variety of sources, processing and storing in data centers.

2. Knowledge delivery service: Merging information from diverse databases and delivering knowledge to users.

Figure 2.9: Disaster-CDM Framework (Grolinger et al., 2013) 2.9.11 Distributed Cloud System Architecture

Distributed Cloud System Disaster Recovery Architecture provides high dependability of the system based on severe redundancy (Ousterhout et al., 2010). The system has multiple data centers which are geographically separated from each other. Each data center includes both hot and warm physical nodes. VMs are active in both warm and hot physical nodes but only running in the hot nodes. In order for a Distributed Cloud System Architecture to be effective, there must be a backup server which stores a copy of each VM. When a physical node failure occurs, the VMs migrate to a warm physical node. In the case of a disaster which makes a data center unavailable, backup site transmits VM copies to another data center. Although this system architecture is expensive, it highly increases the dependability which can be adequate for Infrastructure as a Service (IaaS) clouds. Figure 2.10 shows the architecture of this DR system.

Figure 2.10: Distributed Cloud System Disaster Recovery Architecture (Ousterhout et al., 2010)

2.9.12 Oracle Recovery Manager (RMAN)

Oracle developed and integrated Recovery Manager (RMAN) into Oracle DBMS 12c (Kuhn, Alapati, and Nanda, 2013). With RMAN, one can perform the following types of backups;

1. Datafiles and control files 2. Server parameter file 3. Archived redo logs 4. RMAN backups

RMAN can store backup data in a logical structure called a backup set, which is the smallest unit of an RMAN backup. A backup set contains the data from one or more data files, archived redo logs, control files or server parameter file. Backup sets which are only created and accessed through RMAN, are the only form in which RMAN can write backups to media managers such as tape drives and tape libraries. RMAN is a very powerful and users’ friendly tools; however, it is not compatible with other DBMSs and it does not perform a checksum on backup files. (Kuhn et al., 2013)

2.9.13 Backup as a Service from MTN – Cloud Storage Packages

MTN Backup as a Service (BaaS) is a prepaid hosting service that offers MTN subscribers the ability to back up their SIM and Phone securely onto backup servers in the MTN datacenter via the internet contacts (Paschal, 2016). The MTN BaaS is a service that provides MTN subscribers the ability to initiate and manage backups and restores on their phones virtually from anywhere in the world via a secure connection.

The service requires subscribers to buy a new MTN 128k SIM Card with MTN Backup enabled, in order to back up the contacts stored on their SIM. The service is not compatible with other networks or MTN SIM that are not MTN Backup enabled. It is ideal for small-size data backup from mobile devices. It does not use the pay-as-you- go billing system.

2.9.14 Disaster Recovery as a Service

This is a Disaster Recovery Plan in the Cloud for SMEs (Rebah and Sta, 2016). The solution is based on the use of the virtual servers in the cloud which are started in case of disaster. Therefore, users are working on cloud mode with the saved data (i.e.

replicated and installed on these virtual servers at the last automatic backup operation).

When the problem that caused the accident is technically solved, data can be relocated to the company's servers and users can connect as usual. On the other hand, the solution proposed a new solution called "DRaaS" which benefits from the main advantages of Cloud and offers SME more beneficial solutions through improved quality recovery service and a significant decrease of costs due to low prices of data storage and pay per use. The effectiveness of this solution was also justified by listing several researches offering DR models in the cloud and the feedback from several companies.

Cloud computing is an economic and technological revolution that is being increasingly imposed on SMEs especially in terms of data storage and disaster recovery (Rebah and Sta, 2016).

2.9.15 Embedded Backup System

The work focused on the design and implementation of an embedded backup system which uses a hard disk and an embedded development board to integrate a

backup-server and a backup-client. It also uses increment backup in non-fixed block-level, and provides a friendly Web UI (user interface) to the end-user (Liu, Liu, and Yang, 2009).

The uses checksums algorithm to compare backup files. However, it does not encrypt backup file and this could expose the files to Man in the Middle (MITM) attack.

2.9.16 Cross Platform Backup System

This work as proposed by (Chen and Zheng, 2008) is a design of XML-based GUI for cross platform backup system, in which the interface definitions are based on XML storage format. The implementation of the work achieves the plug-in management for centrally backup/restore processing of heterogeneous systems. The system is compatible with most DBMS. It also provides friendly user interfaces. However, it lacks system security since it does not encrypt data. Data leakages are very possible in multi tenant’s environment.

2.9.17 Auto-Data Recovery System on Cloud Scheme

This scheme offers data storage and sharing services to users (Dhane and Joshi, 2015).

The system uses a Trusted Third-Party Auditor (TTPA) to publicly audit the integrity of shared data in the cloud for users. In a group, there is one original user and a number of group users. The original user is the original owner of data. This original user creates and shares data with other users in the group through the cloud. Both the original user and group users are able to access, download and modify shared data. Shared data is further divided into a number of blocks. A user can modify a block in shared data by performing an insert, delete or update operation on the block. However, the system lack adequate data security and prevention from Man in the Middle (MITM) attack.

2.9.18 Server Virtualization Data Storage and Backup System

(Mayur and Vani, 2016) integrated server using private cloud model for backup and data storage. They developed an application for the implementation in such way that automatically synchronizes all information backed up or stored by the user in the virtual folder to the cloud. They used Parallel Virtual File System (PVFS) for data storage in order to increase the performance of applications that requires high I/O data demands.

PVFS is an open source file system. The system was able to reduce access time to data

by allowing both input and output operations to be carried out simultaneously. On the client-side, an application is developed that allows data to be transferred much faster.

The advantages of this implementation are that it can reuse existing infrastructure (servers, cluster, and other devices) that reduces the cost and increases the throughput

2.9.19 HDFS Backup and Disaster Recovery System

In this work, a system for Hadoop Distributed File System (HDFS) was introduced to backup and protect data from all kind of damages (Luo, Wang, Huang, and Yu, 2016).

This system backups not only the metadata but also the real data of file system to a remote backup server, and can be applied to any other file systems which implements HDFS. The system achieved its primary aim by implementing a backup system built for HDFS with little effect to normal service, low cost for backup generation, high speed for backup transmission, and user-friendly interaction. Many practical features are also imbedded in the system.

2.9.20 Dependability models for designing disaster tolerant cloud computing systems.

In this work, models are presented for dependability evaluation of cloud computing systems deployed into geographically distributed data centers as well as taking into account disaster occurrence (Silva, Maciel, Tavares, and Zimmermann, 2013). The approach is based on a hybrid modelling technique, which considers combinatorial and state-based models. The proposed technique allows the impact assessment of disaster occurrence, VM migration and data center distance on system dependability. With this system, it is possible to run multiple VMs in the same host. The system aims at reducing VM migration times and distances between data centers. However, it does not encrypt or compress backup files. Also, the system is only operational as service provider premises.