7-11 Mirror Disk DR

7-11 Mirror Disk DR

The Mirror Disk DR resource enables replicate a mirror disk set of a cluster to an off-site DR node for the disaster recovery purpose.
Mirror Disk DR agent act according to mirror disk status and role.

Dynamic information like status and roll of Mirror Disk DR is logged into system event log, this is sent to MCCS by MCCS Event Module.
MCCS Event Module is activated when MCCS service starts.
Data replication component operates by creating mirror set for volumes between two nodes.
Source volume is sit on Primary node, Target volume is sit on Secondary node in a cluster and also off-site DR node.
Client is only available to read/write in the source volume, changed block of the volume is replicated to the target volume through the TCP/IP network connection. At this point, target volume is in lock state and read/write is not allowed. This is to ensure data integrity by preventing the use of target volume.

 

Mirror Disk DR resource can only register a pre-configured DRBD resource.


Table of Contents

 

[Figure] Mirroring Configuration

 

 

Mirror Mode

Mirror mode employs both asynchronous and synchronous mirroring schemes. Understanding the advantages and disadvantages between synchronous and asynchronous mirroring is essential to the correct operation of this.

Asynchronization Mode

With asynchronous mirroring, each write is captured and a copy of this is made. That copy is queued to be transmitted to the target system as soon as the network will allow it. Meanwhile, the original write request is committed to the underlying storage device and control is immediately returned to the application that initiated the write. At any given time, there may be write transactions waiting in the queue to be sent to the target machine.  But it is important to understand that these writes reach the target volume in time order, so the integrity of the data on the target volume is always a valid snapshot of the source volume at some point in time.  Should the source system fail, it is possible that the target system did not receive all of the writes that were queued up, but the data that has made it to the target volume is valid and usable. 

Semi Synchronization Mode

With semi-synchronous mirroring, each write is captured and transmitted to the target system. Local write completes in the source as soon as the replication packet has reached the target. Normally, no writes are lost in case of failover , but this may can be lost when both nodes are failed simultaneously

Synchronization Mode

With synchronous mirroring, each write is captured and transmitted to the target system to be written on the target volume at the same time that the write is committed to the underlying storage device on the source system.  Once both the local and target writes are complete, the write request is acknowledged as complete and control is returned to the application that initiated the write.  With synchronous mirroring, each write is intercepted and transmitted to the target system to be written on the target volume at the same time that the write is committed to the underlying storage device on the source system.  Once both the local and target writes are complete, the write request is acknowledged as complete and control is returned to the application that initiated the write.  

 

 

Adding

Add the mirror disk DR resource to a group.

MCCS for Linux support DRBD which is open source for Mirror disk. Therefore, DRBD should be installed in advance.

The size of disk file system that is created by mirror disk should be created with 128MB

128M space is required to store meta data that manages replication volume service.

Mirror Disk DR resource only support internal meta data type of mirror disk. For more detail about meta data type of mirror disk, please refer to "7.7 Mirror Disk" of this guide.

Mirror IP address should be assigned a virtual IP address between active server and standby server in a primary site. So the virtual IP should be added in a group in advance.

Size of meta data can be changed according to the size of the meta data.

Please refer to DRBD meta data size(Calculation for more details).

When use both DBRB and LVM, only DRBD ON LVM is supported and LVM In DRBD is not supported.

 

Mirror IP address of the cluster should be assigned a virtual IP address to represent each real IP addresses of both nodes in the primary site. So the virtual IP should be added in a group in advance.

 

  1. Select a group → right click → "Add Resource'".

  2. Select "MirrorDisk'" from Resource Type lists and click the "Nex"' button.

  3. Select the mirror volume and MCCS will renewal the information automatically.

    The virtual device, mirror IP address and mirror ports will be entered automatically.

    If mirror volume is already configured in the volume, "mirrored" will be displayed.
    Also, the config data will be entered automatically during the selection, and you cannot change it. 


    [Figure] Mirror Disk DR Added

  4. Click the "Finish" button to add the mirror disk DR.

Deleting

Select "Resource type" → right click → delete resource.

  1. Click the "Delete resource" button and a confirming message about deleting resource will appear.


    [Figure] Check resource view

  2. Click the "OK" button and mirror disk is deleted.
    The deleted resource will immediately disappear from the management web console.

 

State

The following table explains the status switching of the MCCS resource caused by a user's command and the status.
The command assumes that it is generated by a user.

Mirror disk DR agent: Manages the mirror disk. Copying program should be installed.

State

Agent command

Description

Note

Online

In this status, you can access the source volume and perform a writing test properly.

Offline

If the role of mirror resource is online,Unmount (umount) the mirror disk from the mount point and the role of mirror disk demoted to secondary and offline the mirror disk resource.
If the mirror volume is not defined, the command is ignored and regarded as a failure.

 

Monitoring

MCCS consistently handles events of the replication component.
The MCCS event monitor is registered as an event receiver when starting the MCCS service. When a system event occurs, it will be automatically informed and it will detect the mirror disk status and role changes.
If the mirror disk's role is primary and it is mounted in the designated mount point, it is deemed to be online.
In other cases, it is recognized as an offline state.
In addition, when you register a new mirror disk, if it is in the primary condition where mounting is not yet to be done, the mirror disk's role is demoted to secondary.

 

Offline

Except for the online and fault states, it is always offline.

Online

Type of operation is determined by the role of the mirror volume at the start node.
 
<Source volume>
After setting the role of mirror disk of the off-site DR node to Primary, mount it in the designated mount point. 

<Target volume>
If you want to go online at the node where the mirror role is target, the following conditions should be met.
1. Both nodes' mirror line conditions are connected.
2. Both nodes' disk status are UpToDate.
3. The other node's mirror disk role is secondary.

If the mirror disk is not defined, it is processed as a failure without any operation.

 

Monitoring

Refer to the description of monitoring as above.

 

Fault

If a writing test failed online, or an attempt to go online is failed, the trouble state is displayed.

*Failover deactivation state
When a mirror network communication failure, target node or target disk failure occurs, the mirror state is changed from 'MIRRORING' to other, such as 'MIRROR_PAUSED'.
If the mirror status is not 'MIRRORING', a failover will take place and it can cause data losses or damages.
To prevent this problem, an agent deactivates the failover mode if the mirror status is not "MIRRORING".
If the failover mode is deactivated, no failover will take place even if manual failover or troubles occur.
If mirror network has been failed and then, recovered as normal, mirror state is changed to RESYNC and data re-synching is initiated between primary cluster set and off-site DR node.

Online

Refer to the above online command.

 

Offline

If the role of mirror resource is online, Unmount (umount) the mirror disk from the mount point and the role of mirror disk is demoted to secondary.
If the mirror volume is not defined, the command is ignored and regarded as a failure.