Hyper-V: Cluster Shared Volumes, SQL Server, and FlashArray Snapshots

This article originally appeared on Andy Yun’s blog. It has been republished with the author’s credit and consent. 

Many people (arguably most) are currently evaluating hypervisor alternatives to VMware, and one obvious contender is obviously Microsoft Hyper-V. And if you’re a Pure Storage customer today, one thing you may be wondering is whether you can keep utilizing storage-array snapshots to do things like replicate SQL Server data from one VM to another. The good news is yes, absolutely! Let’s take a look at a common scenario as an example.

TL;DR: Show Me the Code!

A PowerShell example to orchestrate the above is now available on the Pure Storage GitHub in the SQL Server Scripts repository. In addition to having the proper setup detailed below, read the README file’s Important Usage Notes section, which will outline other prerequisites.

If you just want to take Hyper-V CSV snapshots without SQL Server involved, check out this GitHub repository, where I’ve shared a PowerShell solution. This is particularly useful if you want to clone an entire VM and present a second iteration of it back to a Hyper-V cluster.

To see this in action, watch this narrated demo recording.

Updating Non-prod Databases with a New Prod Copy

One extremely common task and time sink for DBAs is needing to take a backup of a production database and restore it to a non-production environment. Because it is a size of data operation, it can be quite time-consuming. To help with that, Pure Storage offers solutions that I’ve showcased that leverage FlashArray™ snapshots to orchestrate such workflows nearly instantaneously. But because (anecdotally) approximately 90% of all SQL Servers are on VMware, our examples were written for VMware. So now I want to show you how to do it in Hyper-V.

Hyper-V: Key Tidbits Overview

In Hyper-V, virtual disks take the form of VHDX files that reside on a Cluster Shared Volume (CSV) (or generally pre-Windows Server 2012, VHDs that reside on a clustered disk). While CSVs were around in Windows Server 2008 R2, they only really became useful and relevant in their second iteration, released with Windows Server 2012. This blog has a fantastic deep dive into the CSV stack.

If you’re familiar with VMware, then I would say that a CSV is somewhat analogous to a VMFS datastore. A VMFS datastore contains one or more VMDK files, with each file representing a virtual disk for a virtual machine. With Hyper-V, each VHDX file is like a VMDK file. 

So when you take a snapshot on FlashArray, you’re taking a snapshot of the entire volume—the CSV file in Hyper-V or the VMFS datastore in VMware (unless you’re using vVols—a separate conversation for another time).

The Setup and Workflow

For this, imagine that you have two SQL Servers: SQL-Prod and SQL-NonProd. These are Hyper-V VMs and may reside on the same CSV or different CSVs; it does not really matter. The idea is that we do not want to snapshot the entire VM, but instead isolate one or more SQL Server user databases to clone from Prod to Non-prod. 

So what you’ll do is create two more CSVs, one for each SQL Server VM. We’ll call them CSV-UserDB-Prod and CSV-UserDB-NonProd for the sake of discussion. Inside each CSV will be the VHDX file(s) that corresponds to the virtual disks that contain your user database data files and log files. If you have, say, a D:\ drive for data and an L:\ drive for log, then you should expect to have two VHDX files in your CSV. 

The workflow is that we will then be taking a snapshot of just CSV-UserDB-Prod and cloning that snapshot and overlaying CSV-UserDB-NonProd, thus updating the underlying data and files. Production will not be interrupted at all by the snapshot, but because these are volume-level operations, Non-prod will be disrupted. 

BUYER’S GUIDE, 14 PAGES

Reevaluating Your Virtualization Strategy?

Explore your options in our guide to modern virtualization.

Read the Guide