Leveraging snapshots to create new volumes that can be used on the same host or other hosts is an important feature as it allows for business and deployment agility when creating dev/test environments, large UAT systems and just general database scale out scenarios.
A question that comes up a lot is on the topic of creating new volumes that are based on volume snapshots that need to be mounted back to the same Windows Server Failover Cluster (WSFC). Before diving into the details I want to explain some terminology so we are all on the same page.
Snapshots Terminology
- Disk – Windows uses the term disk to refer storage objects in Windows Disk Management.
- Snapshot – A point-in-time representation of a Pure Storage volume.
- LUN – A Logical Unit Number used to identify a logical unit, which is a device addressed by the SCSI protocol or Storage Area Network (SAN) protocols which encapsulate SCSI, such as Fibre Channel or iSCSI.
- Volume – What a LUN maps to and provides a 512-byte-sector Logical Block Addresses (LBA) space for reading and writing data. Synonymous with disk for purposes of this article.
- Copy – A new volume which is created from a Pure Storage volume snapshot. Synonymous with volume.
- MBR – Master Boot Record.
- GPT – Global Unique IDentifier (GUID) Partition Table.
Unique Snapshots Identifications
When taking a snapshot of a volume that has partition (MBR or GPT) it contains a unique identification. MBR uses disk signatures and GPT uses GUIDs (Global Unique IDentifiers). See the two examples below.
These unique identifiers represent the signature of a particular disk. When creating a snapshot it creates a block-for-block representation of the original volume that includes the unique identifications. The example below illustrates Volume 1 and Snapshot 1 which shows each have the same ID = 9A802B99. Just as it shows Snapshot 1 represents Volume 1 block-for-block. The process of creating a snapshot does not re-signature the volume.
A copy or volume can be used in two different scenarios as we will discuss below.
Standalone Servers
When using a standalone server or virtual machine a copy can be used without issue because there is logic in Windows Server via the Cluster Disk Driver (CDD) that gets notified through Plug-n-Play that a new disk has been added. The CDD then checks the signature of the disk and in the event that signature collision is detected and a new unique value will be created and the disk presented to the standalone server as a new volume. The result is a new disk connected which is based on a snapshot of a volume.
Windows Server Failover Clusters
If this same scenario targets a Windows Server Failover Cluster (WSFC) much of the process is still the same for detecting signature collisions. The difference comes in when a new disk is connected and has a signature that is recognized by the Cluster Disk Driver it will place this new disk in a Reserved state which signifies the WSFC owns this disk and will handle the overall management (Initialization, Online, Offline). The screenshot below shows what this looks like from Windows Disk Management, notice the Reserved under each of the Disk IDs. This applies to disks that have either been previously added or are new to a WSFC.
In the event a new disk is connected which was created from a snapshot that was created from an existing disk on the same WSFC there will be a detected signature collision; remember the example of Volume 1 and Snapshot 1. The same collision logic described earlier will be used but the WSFC will not re-signature the new disk automatically like the standalone server. The WSFC will connect the disk and place it in an Offline state.
This is done to protect against having two disks with the same signatures which could cause corruption issues. Now even though this disk has been connected to the WSFC node it cannot be used until it has a new unique identification (aka signature). In order to use this disk in the WSFC you need to connect it to a secondary server or virtual machine outside of the desired WSFC and update the unique identification.
Before setting a new unique identification the volume on the FlashArray needs to be disconnected from the existing Host Group and connected to a different Host. Once that is completed you can use either of the methods below to accomplish this task.
- DISKPART
This example show changing a MBR.
- Windows PowerShell
This example shows changing a GPT. You will notice that the below script is just automating DISKPART.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$guid = [GUID]::NewGuid() $connecthost = $env:COMPUTERNAME $uniqueIds = Invoke-Command -Computername $connecthost {Get-Disk} ForEach ($uniqueId in $uniqueIds) { If ($uniqueId.FriendlyName -like “PURE FlashArray*”) { $disknumber = $uniqueId.Number $cmds = “`”SELECT DISK $disknumber`””, “`”UNIQUEID DISK ID=$guid`”” $scriptblock = [string]::Join(“,”,$cmds) $diskpart =$ExecutionContext.InvokeCommand.NewScriptBlock(“$scriptblock | DISKPART”) Invoke-Command -ComputerName $connecthost -ScriptBlock $diskpart } } |
Once the signature of the disk has been changed the volume can then be connected back to the Host Group which is being used for the WSFC.
Thanks,
Barkz
