7.6 Mirror Disk
In case of MCCS needed data cannot be shared among nodes in a cluster, namely NAS or DAS, may not use latest data after failover. In this case, Mirror disk is used when there is no external shared disk, and is replicated between two nodes by using replication component. MCCS provides replication function of DataKeeper from SIOS corporation (OEM Product) and Mirror Disk Agent manages this replicated data set.
It functions properly according to the state and role of mirror disk. Actions such as state and role of mirror disk are all recorded in the system event log, and this information will be sent to MCCS through event log monitor module.
MCCS Event Module is activated when MCCS service starts.
Data replication software operates by creating mirror set for volumes between two nodes.
The primary server has source disk and the secondary server has target disk which is an exact replica of its source.
Client is only available to read/write in the source disk, changed block of this is replicated to the target disk through the TCP/IP network connection. At this point, target is in lock state and read/write is not allowed. This is to ensure data integrity by preventing the use of this.
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.
Async 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.
Sync 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 resource to a group.
When add a resource from a group name, select a group → right click → 'Add Resource'. Or select Edit(E) from the main menu bar → select 'Add Resource'. Or select 'Add Resource' icon from the tool bar.
Select 'MirrorDisk' from Resource Type lists and click 'Next' button. When add a resource from the MirrorDisk resource type name, this step will be skipped.
Enter the resource name. If you skip enter resource name, this will given 'Mirror_value' which value is selected driver letter.(Ex: Mirror_G)
Select the source node and driver letter.
[Figure] Adding mirror disk resourceAs 'Additional Settings', Mirror Type and Check Disk option is available and click 'OK' button.
[Figure] Defining mirror type and check disk option
When click OK button, following warning message will be displayed and click 'OK' button if the informations are correct.
If you select wrong sever, click cancel button.
[Figure] Alert popup message after click OK buttonClick 'Finish' button to add the mirror disk resource.
Deleting
Select resource type → right click → delete resource.
(Current online mirror disk resource cannot be deleted. So it should be taken offline before delete it.)
Click "Delete resource" and a confirming message about deleting resource will appear.
[Figure] check resource viewClick "OK" and a confirming message about deleting the mirror configuration will appear.
[Figure] Delete mirror disk viewClick "OK" and mirror disk is deleted.
State
The following table explains the state of mirror disk resource.
State | Agent command | Description | Note |
|---|---|---|---|
Online Source disk is accessible to read/write. | Offline | It locks the mirror disk using LOCKVOLUME command. Both source and target disk cannot accessible from each node. |
|
Monitoring | The monitoring process is also determined by the mirror disk status and roles. If the writing test is successful, it is regarded as the online state. Otherwise, it is regarded as the offline state. If a user unlocks the target disk while the mirror disk is online, MCCS will automatically lock it again. Thus, the target disk of the node with the online mirror disk cannot be unlocked. |
| |
Offline Source and target disk is not fault state but locked so that cannot access both disk. | Online | Type of command is determined by the role of the mirror disk at the node. <Source role disk> <Target role disk> |
|
Monitoring | Refer to the description of monitoring as above. |
| |
Fault Fail on writing test in online state or fail on attempts to bring online. *Failover disabled state
| Online | Refer to the above online command. |
|
Offline | It locks the mirror disk using LOCKVOLUME command. Both source and target disk cannot accessible from each node. |
|