In our last article, we looked at a potential approach for developing automation to solve a business need. This business need was to move the daily reporting over a series of SQL Server VMs’ production data to a set of secondary reporting VMs where the jobs could be run without impacting production.
In this article, we’re going to start to take a look at development of the actual script. We’ll do this in PowerShell, but the same high-level process applies regardless of the tools used.
Moving The Data
As mentioned in the last article, we have a database log disk and a database disk on each VM as well as the disk containing the operating system and applications. Let’s assume that they’re called sqlprod1, sqlprod2 and sqlprod3. Since then, we have cloned each VM and the application owners have performed any steps needed to have the reporting work within the clones. Let’s call the clones sqlrep1, sqlrep2 and sqlrep3.
What we want to do nightly is to use Tintri SyncVM to sync the database and log disks from each production VM to its corresponding reporting VM. This has no more impact on the production VMs than taking a snapshot.
Here’s how this SyncVM case would look if we weren’t automating it:
We’re replacing the log and data vDisks on our reporting VM with vDisks from a recent snapshot taken of our production VM. This will restart the reporting VM, but not the production VM.
Looking at the online help for the Sync-TintriVDisk PowerShell cmdlet (from the Tintri PowerShell Toolkit), we figure that we’ll need a command that looks something like this:
$result = Sync-TintriVDisk -VM $report ` -SourceSnapshot $snapshot ` -AllButFirstVDisk
Let’s break this down in case the specifics aren’t familiar or obvious:
- $result = collects the result of the Sync-TintriVDisk cmdlet. This will often contain useful information about whether the cmdlet succeeded, or failed and often some detail about why. We’ll deal with this information later.
- -VM $report is us providing the cmdlet with an object representing the VM that we’re operating on. We’ll call the object $report here and fill it in as we work backwards.
- -SourceSnapshot $snapshot is where we provide the snapshot from which we’re synchronising vDisks. This will be a snapshot on our production VM and we’ll fill that in as we work backwards.
- -AllButFirstVDisk is an option to allow us to sync all but the first vDisk. You’ll recall that our database VMs have the OS and applications on the first disk and then the logs on the second and database files on the third. We only want to sync the 2nd and 3rd disks.
So we have our SyncVM command, but we still need to find our reporting VM and fill in the $report variable with it and we need to take the production snapshot and fill in $snapshot with it. Running the following commands before calling Sync-TintriVDisk in our script ought to suffice for the $report variable:
$reportname = "sqlrep1" $report = Get-TintriVM -Name $reportname
Here, we’re setting a variable name with the name of the reporting VM, requesting that VM by name and storing the object in the $report variable we need for SyncVM. We don’t need to do this in two distinct steps — the -Name option allows us to specify “sqlrep1” as a string. We’ll come back to why we’re doing this as we continue to build this example.
By looking at the API documentation for snapshots, it looks like breaking down of the snapshot process into smaller tasks consists of these steps:
- Find the VM,
- Take the snapshot, remembering the returned snapshot ID, and
- Retrieve that snapshot object.
This equates to the following PowerShell commands being added to our script before the SyncVM call:
$prodname = "sqlprod1" $prod = Get-TintriVM -Name $prodname $snapshotId = New-TintriVMSnapshot ` -SnapshotDescription "Reporting snapshot" ` -VM $prod ` -SnapshotConsistency CRASH_CONSISTENT $snapshot = Get-TintriVMSnapshot -VM $prod -SnapshotId $snapshotId
I’m using crash consistent snapshots here, but VM-consistent work and may be a better choice depending on your use case.
At this point, our automation script is not complete, but is starting to take some real shape. We’re currently able to use SyncVM to automatically take a snapshot of one of our production VMs, and attach the data and log disks from that snapshot to our reporting VM.
I’ll summarise all of the code that we have so far here. Given that we started at the bottom and have been working backwards, it’ll be helpful to see it all in one. I’ll also add some PowerShell comments to the code to make it easier to understand and maintain over time.
I’ve also added an extra line of code to call Connect-TintriServer to create a PowerShell API session to the Tintri VMstore. We introduced this cmdlet, and using Single-Sign-On (SSO) in an earlier article.
Keep your eye out for subsequent articles.
# Variables containing our VM names (for now) $prodname = "sqlprod1" $reportname = "sqlrep1" # Connect to our VMstore $vmstore = "vmstore01.vmlevel.com" Connect-TintriServer -UseCurrentUserCredentials $vmstore # Retrieve a VM object for both VMs by name $report = Get-TintriVM -Name $reportname $prod = Get-TintriVM -Name $prodname # Take a snapshot of our production VM and using the # Returned snapshot ID, retrieve the snapshot object $snapshotId = New-TintriVMSnapshot ` -SnapshotDescription "Reporting snapshot" ` -VM $prod ` -SnapshotConsistency CRASH_CONSISTENT $snapshot = Get-TintriVMSnapshot -VM $prod ` -SnapshotId $snapshotId # Use SyncVM's vDisk sync to synchronise the data and # log vDisks from the prod snapshot to the reporting VM $result = Sync-TintriVDisk -VM $report ` -SourceSnapshot $snapshot ` -AllButFirstVDisk