DataKeeper Volume Resource Private Properties

A DataKeeper Volume resource includes several private properties that are used by DataKeeper Cluster Edition. Among these properties are:

• VolumeLetter (REG_SZ) – the volume letter that is replicated by DataKeeper and associated with this DataKeeper Volume Resource.

• LastSource (REG_SZ) – name of the cluster node that was most recently the source of the mirror.

• NonMirrored (REG_DWORD) – This optional property can be used to configure a non-mirrored storage location for things like SQL tempdb. This private property does not normally exist – it must be manually configured. See Non-mirrored Volume Resource for more information.

• TargetState_<node> (REG_DWORD) – For each <node> in the system that has at some point been a mirror target, this private property will exist. Its value is the current state (the internal DataKeeper mirror state) of the Owner node’s mirror to the given node. Values include:

0 = Node is not currently a target (may be source or shared with a source or target)

1 = Mirroring

2 = Resync

3 = Broken

4 = Paused

5 = Resync Pending

Below is a sample screenshot of the Private Properties of a DataKeeper Volume.

Use the following command in powershell to generate the output:

Get-ClusterResource “<DataKeeper Resource Name>” | Get-ClusterParameter

Implications of the TargetState_ <node> value on Failover

DataKeeper Cluster Edition maintains the TargetState_<node> property value, and updates it whenever the mirror state changes. The cluster networks provide multiple paths for a mirror’s state to be available on a target system. This enhances the reliability of DataKeeper, and reduces the chance of Split Brain occurrences in the cluster for both synchronous and asynchronous mirrors. The DataKeeper Volume Online method tests to make sure that a node is in a Mirror State which allows Online to proceed. For a mirror target node, that state is “1” (Mirroring). All other states will cause the Online to fail and the DataKeeper Volume resource to be marked as Failed on this node.

In some cases, for instance the catastrophic failure of a previous Owner node that is not going to be recovered for a long period of time, it may be necessary to remove the TargetState_<node> private property in order to force a DataKeeper Volume resource to come online on a node. However, because the node may not have been in a mirroring state with the previous Owner, some Data Loss could occur.

The TargetState_<node> property can be removed using the following command in powershell:

Get-ClusterResource “<DataKeeper Resource Name>” | Set-ClusterParameter -Name “TargetState_<node>” -Delete

Note: Servers running Windows 2008 R2 will need to import the ‘failoverclusters’ module before running these commands. Use the following command in powershell:

import-module failoverclusters

Behavior of a Synchronous Mirror after Cluster Integration

The purpose of a synchronous mirror is to ensure data consistency between the source and the target at all times. When a synchronous mirror is integrated as a cluster resource, DataKeeper will begin using the cluster to further ensure data consistency.

When the state of a synchronous mirror changes from a mirroring to a non-mirroring state (such as mirrored to paused), DataKeeper will attempt to set the TargetState_<node> private property to ensure data consistency in the event of a failover.

DataKeeper, to ensure the consistency of the source’s local volume with the targets, will hold all writes that come down to that volume until it has set the TargetState_<node> private property to the appropriate value. The writes will then be allowed to continue.

Should DataKeeper be unable to properly set the TargetState_<node> private property, it will fail those writes and lock the volume. This ensures that the mirrored volume has the same data consistency as when it was last in the mirroring state.