12.2 Introduction to Server based Replication

In the server based replication, the servers resources such as CPU and memory are utilised to perform and manage the replication operation. The server based replication supports both local and remote replication techniques and the following types of replication techniques are available to be used to protect the organisations data. The server based replication supports both Local and remote site replications.

Server based Local replication technique offers

Filesystem Snapshot

Hypervisor based Snapshot - VM snapshot & VM Clone

Server based Remote based replication techniques offers

Log Shipping

Hypervisor based replication - Synchronous & Asynchrous

Server based Local Replication Techniques Overview

Filesystem Snapshot

A filesystem snapshot is a virtual copy of a set of files in a server as they appear at a specific PIT. Snapshots can establish recovery points in just a small fraction of a time and can significantly reduce RPO by supporting more frequent recovery points. If a file is lost or corrupted, it can typically be restored from the latest snapshot data within a few seconds.

Also Read: Types of Data Backup Methods

A file system (FS) snapshot creates a copy of a file system at a specific point-in-time, even while the original file system continues to be updated and used normally. It uses the Copy on First Write (CoFW) principle to create snapshots. When a snapshot is created, bitmap and blockmap are created in the metadata of the snapshot FS. The bitmap is used to keep track of blocks that are changed on the production FS after the snapshot creation. The blockmap is used to indicate the exact address from which the data is to be read when the data is accessed from the snapshot FS.

Typically read-only snapshots are created to preserve the state of the production FS at some PIT, but sometimes writeable FS snapshots are also created for some business operations such as testing and decision support.

Virtual Machine (VM) snapshot

A VM snapshot preserves the state and data of a VM at a specific PIT. The state includes the VM’s power state (for example, powered-on, powered-off, or suspended). The data includes all of the files that make up the VM. This includes disks, memory, and other devices, such as virtual network interface cards. This VM snapshot is useful for quick restore of a VM.

Also Read: Types of Backup Techniques

For example, an administrator can create a snapshot of a VM, make changes such as applying patches and software upgrades to the VM. If anything goes wrong, the administrator can simply restore the VM to its previous state using the VM snapshot. The hypervisor provides an option to create and manage multiple snapshots. Taking multiple snapshots provide several restore points for a VM. While more snapshots will improve the resiliency of the infrastructure, it is important to consider the storage space they consume.

Sometimes it may be required to retain a snapshot for longer period, but it must be noted that larger snapshots take longer time to commit and may impact the performance. Source (parent VM) must be healthy in order to use snapshot for rollback.

Virtual Machine (VM) clone

A VM clone is a copy of an existing VM. The existing VM is called the parent of the clone. When the cloning operation completes, the clone becomes a separate VM. The changes made to a clone do not affect the parent VM. Changes made to the parent VM do not appear in a clone. A clone's MAC address is different from those of the parent VM.

In general, installing a guest OS and applications on a VM is a time consuming task. With clones, administrators can make many copies of a virtual machine from a single installation and configuration process. For example, in a VDI environment, the administrator can clone a VM for each new employee, with a suite of preconfigured software applications. In general, snapshot is used to save the current state of the virtual machine, so that it allows to revert to that state in case of any error. But clone is used when a copy of a VM is required for separate use.

Also Read: Taking Backup and Archive to Cloud Storage

There are two types of clone namely full clone and linked clone. A full clone is an independent copy of a VM that shares nothing with the parent VM. A linked clone is made from a snapshot of the parent VM. The snapshot is given a separate network identity and assigned to the hypervisor to run as an independent VM. However, all files available on the parent at the moment of the snapshot creation continue to remain available to the linked clone VM in read-only mode. Ongoing changes to the virtual disk of the parent do not affect the linked clone and changes to the virtual disk of the linked clone do not affect the parent. All the writes by the linked clone are captured in a delta disk.

There is another type of VM clone called Instant Clone. Instant Clone enables a running VM to be cloned, such that the new VM is exactly identical to the original. This enables to get a new, running, booted up VM in less than a second. This capability is very useful in quickly scaling up a large number of VMs to meet the needs of spiking workload in a cloud environment.

Server based Remote Replication Techniques Overview

Log shipping

In a log shipping technique, the transactions to the source database are captured in logs, which are periodically transmitted by the source server to the remote server. The remote server receives the logs and applies them to the remote database.

Pic Credits - EMC

Prior to the starting of production work and replication of the log files, all relevant components of the source database are replicated to the remote site. After this step, the production work is started on the source database. The remote database is started in a standby mode. All DBMSs switch log files at preconfigured time intervals or when a log file is filled. This process ensures that the standby database is consistent up to the last committed log. The log shipping allows to use the existing standard IP network for replicating log files. The server based log shipping requires low network bandwidth because it transmits only the log files at regular intervals. In log shipping, RPO at the remote site is finite and depends on the size of the log and the frequency of log switching.

Hypervisor-based remote replication

Although server based replication within a data center is useful, organizations often replicate virtual machines (VM data and configuration files) between a primary site and a remote site. By doing this, if one site is down as the result of a disaster, the remote site is available to take over the operations.

Also Read: Software Defined Storage Overview

Hypervisor-based remote replication employs an agent installed on the server. This agent is responsible for sending changed data from a running VM at source site to the disk files for the virtual machine at the remote site. The process begins with initial full synchronization of the source and its replica copy. The time required to complete this initial synchronization depends primarily on the amount of data to be replicated and the available network bandwidth. After the initial full synchronization, changes to the protected VM are tracked and replicated on a regular basis. Their frequency is determined by the RPO that was configured for the VM. A lower RPO requires more-frequent replication.

Hypervisor-based replication supports both synchronous and asynchronous replication. In synchronous replication, the write or update to the source VM is replicated and committed to the target disk file of the VM. This may increase the application response time, but provides near zero RPO. Because latency is a concern, synchronous replication is typically considered to be suitable only when a high bandwidth connection is available between two sites that are separated by about 100 miles or less. In asynchronous replication, the write or update to the source VM is committed and acknowledgment is immediately sent. These updates are replicated to the target VM at regular intervals. The challenge with this type of replication is that data is not replicated in real time. Therefore, if a failure occurs in the source site then there is a chance that the replica in the remote site might not be completely up to date.

Previous: Data Replication Overview & Types of Replication

Next: Storage System Based Replication Overview

Go To >> Index Page

What Others are Reading Now...