by Before coming to the vendor space years ago, I worked in an environment where we hosted applications over various banks, credit unions, and other lenders across North America.
We sold and also hosted our own software, which gave our customers the ability to service (review/approve/deny) loans for a wide variety of things such as homes, cars, and the like.
Personal experience with custom solutions
While we had our own “standardized” platform, it was only used by our customers. In this highly specialized lending environment, there are not that many companies that offer this type of solution, so suffice to say that much of the code is custom.
Just like any other software vendor, we would continue to add new features, introduce core code optimizations, and so on, with the desire to make a more stable and efficient platform for our customers. And anyone who has been in the software field for any amount of time, knows that you can seldom test every potential configuration of your solution. The process of identifying every possible use case is time consuming and expensive. Test cases are often targeted to the most common configurations/scenarios to keep the cost down, as well as reduce the overall testing and validation time.
When new releases of our software were available, our customers would often upgrade a test instance of their hosted environment and perform their own UAT to unsure our new release met their expectations. They could easily prepare for upgrading their production environments without having to worry about any unexpected issues.
Well, most of the time…
We had some robust granularity in our software, sometimes at the expense of validation or proper error handling, which from time to time resulted in the product behaving a bit differently than expected. When these situations presented themselves, the datacenter team was often asked for a copy of the customer’s environment, or at a minimum a copy of their database. At that point our escalation team would perform a root cause analysis and attempt to get a fix in place.
Use Case: Refresh from Production for Root Cause Analysis
We would typically restore a VM’s virtual disks from the previous night’s backups (if they included the latest code changes), or a backup would have to be taken, and then manually attached to another VM or set of VMs.
It was a very manual process. But what if we could automate this process?
While there are a lot of packages on the market today that can handle the backup & recovery/copy process, there are some pretty interesting capabilities when running vSphere VMs on top of FlashArray and using VMware Virtual Volumes (vVols). Cloning vVols on FlashArray is a very fast and efficient process that requires little capacity. FlashArray performs amazing data reduction, and presents a copied vVol back to vSphere and an alternate VM very quickly.
Manually Using PowerCLI
As a PowerShell/PowerCLI aficionado, I looked to see what we have in the bag of PowerShell/PowerCLI tricks, and I ran across some code in our PureStorage.FlashArray.VMware module that met the need.
Using the Copy-PfaVvolVmdkToNewVvolVmdk function, it is easy to take a retrieved vVol vmdk from a source VM and attach to a target VM.
The resulting script looks something like this:
# Connect to vCenter
Connect-viserver vc02.fsa.lab
# Connect to and set the active Pure Storage FlashArray
New-PfaConnection -endpoint fa1.fsa.lab -credentials (Get-Credential) -defaultArray -ignoreCertificateError
# Get the vVol vmdk on the ProductionDatabaseVm virtual machine (Just happen to know it is 200GB)
$DatabaseVvolVmdk = Get-VM -Name "ProductionDatabaseVm" | Get-HardDisk | Where-Object {$_.CapacityGB -eq "200"}
# Clone the vVol and attach it to the RcaDatabaseVm virtual machine
Get-VM -Name "RcaDatabaseVm" | Copy-PfaVvolVmdkToNewVvolVmdk -vmdk $DatabaseVvolVmdk
Pretty easy! This capability would have saved me a wealth of time. Sure, we’d still have to do some in-guest work, but a quick, easy, & current copy of the data was just attached with only a few lines of code. This code attaches a new copy of the specified vVol vmdk.
Alternatively, the Copy-PfaVvolVmdkToExistingVvolVmdkfunction could be used to replace an existing vVol vmdk.
Self Service with vRealize Automation
While this is beneficial to me, it would be even better if I could present this capability to my organizational members that directly worked with our hosted customers, but without full administrative control, while adding some change control to the process?
Enter a combination of VMware vRealize Automation, VMware vRealize Orchestrator, and the FlashArray Plugin for VMware vRealize Orchestrator. Customers who already have vRealize Automation understand the flexibility and capabilities that vRA has to create catalogs that can enable users to request tasks to be performed, and then performed without requiring any intervention.
If you haven’t used vRealize Automation in a while, or haven’t used it with a Pure Storage FlashArray, my colleague David Stamen has a great post that can get you started.
After getting the FlashArray Plugin for vRO installed, I could then create a new XaaS blueprint (Design section), by selecting the Orchestrator > Library > Pure Storage > FlashArray Virtual Volumes > Snapshots and Cloning > Overwrite Existing VVol from another VVol workflow.
Give the XaaS Blueprint a name
Setup the form (hint, I just clicked next because the workflow does the work for you)
I didn’t configure the Provisioned Resource
I did make sure to select the Category XaaS under Component Lifecycle.
When complete, be certain to Publish the blueprint.
Under Administration > Catalog Items, be certain to set the status to Active and associated with the Pure Storage service.
The application should be Entitled for which ever user group you wish to be able to perform this operation (Pure Admin in the Lab Business Group in my case)
From the main Catalog area, searching for “Refresh” the new item can be seen.
With the new catalog item in place, anyone entitled to it, can execute it, select any source VM that has a vVol vmdk, and to refresh any other vVol vmdk.
That could actually be quite dangerous.
What if a user refreshed a production vVol with other data?
By going back into the XaaS Blueprint, we can hard code choices, such as source VM, source vVol, target VM, and target vVol to be refreshed.
This takes the guess work/human error out of the equation and prevents a “resume generating event” from occurring.
After submitting, the RcaDatabaseVm’s vVol vmdk is refreshed with the ProductionDatabaseVm’s vVol vmdk automatically and without any user interaction.
While I didn’t add the process to prompt for approval, vRealize Automation can certainly add additional workflow items to ensure that requests such as this are only performed when approved.
vVol Flexibility & Choice
This post has illustrated a couple different mechanisms that are available today for customers using VMware vSphere with Pure Storage FlashArray to easily manipulate VM data (refreshing from Prod in this case) using a couple different methods.
For individual, one-off and ad-hoc requests, PowerCLI in addition to the PureStorage.FlashArray.VMware module is quick/easy and can work in a pinch.
For longer term situations where controlled workflows that can enable application owners are desired, vRealize Automation & Orchestrator along with the FlashArray Plugin for vRO can provide the custom ability to offload those requests with certainty and reliability, without having to worry.
