Managing Hardware Snapshots on Failover Clusters

Managing Hardware Snapshots on Failover Clusters

  • Comments 1

In this blog I will discuss how clusters identify disks and considerations of presenting a hardware snapshot of a LUN back to the same cluster.

Windows Server Failover Clustering has a kernel mode driver called ClusDisk.sys that listens for PnP arrivals of new disks to the system.  When a new disk arrives ClusDisk will look at the disk signature of the disk, if the signature matches that of a known clustered disk, then ClusDisk will call into Partition Manager and register that disk as being owned by clustering.  This will leave the disk in an Offline state with the volume dismounted, and clustering will be registered so that it is the only mechanism that can tell the disk to come online (and on which node).  This enables clustering to orchestrate which server and when disks should be mounted, and ensure volumes do not become corrupted.  This ownership is reflected in Disk Management (DiskMgmt.msc) by the disk being listed as “Reserved”. 

Note:  A disk being listed as “Reserved” in DiskMgmt.msc is related to PartMgr ownership and has nothing to do with Persistent Reservations or SCSI commands to the LUN (this is a common point of confusion).

When leveraging hardware snapshots you will have a block-by-block replica of a disk.  All data on that replica LUN will be identical to the source LUN, including the disk signature in sector 0 of the master boot record.  If you attempt to present that replica LUN back to the same system, you will now have two separate LUN’s with identical disk signatures… Windows does not allow you to mount two disks with the same signature.

To address this, there is logic to handle disk signature collisions.  When a disk arrives that has a signature which matches that of a disk which is already mounted, when the second disk is mounted the signature is changed to a new unique value.  As a result, the disk will be identified as a new disk.

On a Failover Cluster you cannot rely on this signature collision handling logic when a volume is mounted because the ClusDisk driver will see the arrival of the replica disk, it will then recognize it has the signature that matches that of a known clustered disk and will register with Partition Manager to leave that disk in an offline state.  As a result, the mount collision logic will never be able to take effect.

If you want to present a hardware snapshot of a LUN back to the same cluster, which already has the source LUN mounted you will need to change the disk signature of the disk (and cannot rely on the mount collision logic).  There are a few options to achieve this (these comments are primarily directed at storage vendors):

  1. Use the BreakSnapshotSet VSS API when breaking the snapshot, this will allow generating a new disk signature on the snapshot when it is created.
  2. If the storage array does not work within the VSS framework, then the storage array can internally handle generating a new random (non-matching to any already clustered disk) disk signature when breaking the snapshot (just as the VSS API would do).
  3. On a system outside of that cluster, you can use DiskPart with the ‘uniqueid disk’ command to manually change the disk signature.  Then present the LUN to the cluster.

Thanks!
Elden Christensen
Principal Program Manager Lead
Clustering & High-Availability
Microsoft

Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post
  • Hi,

    The article is very good to understand about the hardware snapshot LUNs back to the cluster node.

    I have a small clarification on changing the disk signature ....

    How can storage array(vendor) can change the disk signature ??

Page 1 of 1 (1 items)