A core strength of Nimble storage is the simplicity of management. Another strength is the ability to quickly create space efficient copies of volumes (clones). While the creation of clones has always been super simple, the end-to-end workflow of creating clones, provisioning them to the host and bringing up application instances to use these clones hasn’t been very easy. Specifically, this is a lengthy manual process in Windows environment that involves dealing with Windows failover clustering, cleaning up various metadata on cloned disks using tools such as diskpart, assigning new disk signatures (which at times requires mounting disks to a yet another Windows server) and so on.

 

In Nimble Windows Toolkit (aka NWT) 4.0, a great effort has been made to simplify this process and make it “Nimble”. Let us take a look at the new PowerShell cmdlets in NWT 4.0.

 

Prior to 4.0 release, NWT offered a set of credential management cmdlets (Set-NWTConfiguration, Get-NWTConfiguration and Clear-NWTConfiguration) along with a couple of cmdlets to automate diskpart operations on Nimble volumes (Set-NimVolume) and discovery of Nimble volumes mapped to a host (Get-NimVolume).

 

In NWT 4.0, we have added a bunch of cmdlets to significantly simplify the cloning workflow.

 

Invoke-CloneNimVolume: Create clones of one or more Nimble volumes and attach them to the same host from where the cmdlet is invoked.

 

This cmdlet takes care of:

  • Creating clones
  • Connecting the cloned volumes to the host (or all nodes of a Windows failover cluster)
  • Re-signaturing cloned disks and clearing various metadata information (VSS, VDS and what not!)
  • Mounting the cloned disks using various methods
    • Specified list of drive letters
    • Mount points
    • Auto assign drive letters
    • No drive letter or mount point
  • Adding cloned disks to Windows failover cluster either as “Available Storage” or as a Cluster Shared Volumes (CSVs).

 

Invoke-CloneNimVolume also supports creating clones of Nimble volumes without connecting the clones to the host. The clones can then be connected to another host using Connect-NimVolume cmdlet.

 

Invoke-CloneNimVolumeCollection: Clone volume or snapshot collections and attach to host

 

This cmdlet is similar to Invoke-CloneNimVolume cmdlet except that it works with a volume collection or snapshot collection as input instead of a list of volumes or snapshots.

 

Connect-NimVolume: Connect a volume to the host or cluster

 

This cmdlet connects a Nimble volume to a host and supports all of the post-connect functionality of re-signaturing the disks, mounting the volumes and provisioning them in a cluster.

 

 

Disconnect-NimVolume and Remove-NimVolume

 

These cmdlets handle the cleanup tasks. The Disconnect-NimVolume cmdlet will gracefully disconnect the volume from host by removing the disk from cluster, removing access paths and taking the Windows disks offline. The volume is not deleted from the Nimble array and can be subsequently connected using Connect-NimVolume cmdlet.

 

The Remove-NimVolume cmdlet goes a step further and also deletes the volume from Nimble array after disconnecting it from the host. If the volume being deleted is a clone, it also provides an option to clean up the base snapshot.

 

Putting it together

 

With the above three cmdlets, we can greatly simplify the typical dev-test workflow:

  1. Clone the production data (Invoke-CloneNimVolume or Invoke-CloneNimVolumeCollection)
  2. Connect it to a test server (Connect-NimVolume) (If you just want to create clones on production server itself – may be for recovery – it can be done in the first step itself).
  3. After the testing is done, you can either:
    1. Disconnect the cloned volume, but leave it around (Disconnect-NimVolume), OR,
    2. Clean up the clone and its base snapshot (Remove-NimVolume)

 

Wait, there is more cool stuff!

 

What’s in a snapshot?

 

If you are performing application consistent snapshots of your SQL or Exchange environment, you may have a requirement to clone from a specific snapshot. But how do you find out what’s in a snapshot? NWT 4.0 cmdlets to the rescue again! These cmdlets will tell you what application treasure is hidden in a snapshot.

 

The Get-NimSnapshot and Get-NimSnapshotCollection cmdlets not only allow simple listing of snapshots and snapshot collections, but you can now use these cmdlets to run queries such as:

  • Show me all snapshots for my SQL environment
  • Show me all snapshots that have a consistent copy of database “Payroll”

With these cmdlets, the dev-test workflow is simplified even further. If you want to clone the production database “Payroll” and provision the clone in a test environment, you no longer need to find out which Nimble volumes to clone. Instead, you can find appropriate Nimble snapshot to use for cloning using Get-NimSnapshot or Get-NimSnapshotCollection cmdlet and pipe that output to the clone cmdlet!

 

In a NutShell

Here is a simple script to clone a SQL database “Payroll” from its latest application consistent snapshot. The clone is attached to the same server.

 

Get latest application consistent snapshot of “Payroll” database and clone/attach the storage back to the server:


PS C:\> Get-NimSnapshotCollection -GroupMgmtIP 10.18.236.77 -AppObject Payroll -MaxObjects 1 | Invoke-CloneNimVolumeCollection -AssignDriveLetter


That’s just one line! The cmdlet returns cloned object information, which can be used to attach the database. In this case, the cloned volumes are mounted as H: and I:.

Attach cloned SQL DB:


Import-Module "sqlps" -DisableNameChecking

$dbfiles = New-Object System.Collections.Specialized.StringCollection

$dbfiles.Add("H:\db\payroll.mdf")

$dbfiles.Add("I:\log\payroll.ldf")

$srv = new-object Microsoft.SqlServer.Management.Smo.Server("(local)")

$srv.AttachDatabase("Payroll-clone", $dbfiles)

 

We hope you like these new cmdlets built into NWT 4.0. We are eager to hear your thoughts on how we can improve this further, so please let us know your feedback!