Summary
Leveraging Pure Storage snapshots for creating new volumes in standalone servers or Windows Server Failover Clusters (WSFC) facilitates agile deployment for dev/test environments, UAT systems, and database scaling, while also addressing updated strategies to manage disk signature conflicts effectively in clustered environments.
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.
Updated Practices for Managing Disk Signatures and Snapshots in Windows Server Failover Clusters (WSFC)
Advancements in both Microsoft Windows Server technologies and Pure Storage solutions have provided new ways to address the challenges of managing snapshots and disk signatures in failover cluster environments. Below are some updated recommendations and insights:
1. Enhanced Disk Management in Modern Windows Server Versions
- Other versions of Windows Server (2016, 2019, and 2022) have introduced improved handling for disk signatures in clustered environments. These versions offer better error messaging and tools for managing duplicate disk signatures when introducing snapshots back into the cluster.
- Automatic Disk Signature Changes: Standalone servers now handle disk signature conflicts more gracefully, and while clusters still require manual intervention, the process is streamlined with PowerShell cmdlets such as
Get-ClusterResourceandSet-ClusterParameter.
2. Pure Storage Features for Clustered Environments
- ActiveCluster Technology: Pure Storage’s ActiveCluster allows for seamless data replication and failover between clusters. This mitigates the need to directly reuse snapshots within the same cluster by enabling replication-based recovery and testing in secondary clusters.
- Snapshot Optimization: Modern Pure Storage arrays include advanced snapshot management, ensuring snapshots are space-efficient and easy to integrate into your data management strategy without introducing signature conflicts. Features like Pure1® provide predictive insights into snapshot usage and recovery scenarios.
3. Steps to Manage Snapshots in WSFC Environments
- Preparation and Planning:
- Before presenting a snapshot to the cluster, plan for a disk signature change. Use tools like
diskpartor PowerShell to inspect and update disk signatures or GUIDs. - For environments using GPT partitions, ensure that both the partition GUID and disk GUID are updated to avoid conflicts.
- Before presenting a snapshot to the cluster, plan for a disk signature change. Use tools like
- Using PowerShell for Disk Signature Updates:powershellCopyEdit
# Example: Viewing and changing disk signatures Get-Disk | Where-Object { $_.UniqueId -eq "<snapshot-disk-id>" } | Set-Disk -UniqueId "<new-unique-id>" - Cluster-Aware Updates:
- Use cluster-aware tools to ensure that the Cluster Disk Driver (
ClusDisk.sys) recognizes and correctly registers the disk after the update.
- Use cluster-aware tools to ensure that the Cluster Disk Driver (
4. Best Practices for Snapshots in Failover Clusters
- Isolate Snapshot Testing: For test or recovery purposes, consider presenting snapshots to standalone servers or separate clusters to avoid conflicts with production environments.
- Implement Backup and Recovery Solutions: Instead of reusing snapshots directly within the cluster, use Pure Storage’s integrated backup and recovery solutions for snapshot replication and restoration.
- Monitor and Automate: Leverage Pure1 to monitor cluster storage performance and automate routine tasks, including snapshot management and disk configuration.
5. Automation and Scripting
- For administrators managing large clusters, scripting tools can save time and reduce the risk of human error. PowerShell and Pure Storage’s REST APIs offer flexible options to automate snapshot creation, presentation, and cleanup processes.
By incorporating these modern strategies and leveraging updated tools and technologies, administrators can simplify storage management, reduce downtime, and maintain the high availability required in failover cluster environments.
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.
