Skip to main content
Pure1 Support Portal

Using FlashProtect Snapshots and Cluster Shared Volumes

Overview

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.

 

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 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.

w

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.

Using a Clustered Shared Volume Snapshot

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.

 

Assigning a New Unique Id

DiskPart

This example show changing an MBR disk.

DISKPART> list disk
  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          150 GB      0 B
  Disk 1    Online         2048 GB      0 B        *
  Disk 2    Online         6144 GB      0 B        *
  Disk 3    Reserved       4096 GB      0 B        *
  Disk 4    Online         1024 GB      0 B        *
  Disk 5    Reserved       4096 GB      0 B        *
  
DISKPART> select disk 5

Disk 5 is now the selected disk.

DISKPART> unique disk

Disk ID: {C81F4AE3-967F-4D82-973A-448BD94888D9}

DISKPART>

Screenshot of what this looks likes from a cmd prompt. 

Windows PowerShell

This example shows changing a GPT disk. You will notice that the below script is just automating DiskPart. This method will work with Windows Server 2008, 2008 R2 (Service Pack 1), 2012, 2012 R2 and 2016. 

Be sure to test the below PowerShell in a controlled environment before using across your infrastructure. 

$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 Windows Server Failover Cluster.

 

With a snapshot of the Clustered Shared Volume each VM that is brought back online from that CSV snapshot will have the same IP Addresses, etc. which you should keep in mind when recovering VMs or content within VMs.