Automate your private cloud to protect enterprise apps on vVols with NetApp ONTAP

ChanceBingen · ‎2022-04-20

Introduction

VMware virtual volumes (vVols) have been known in the marketplace for some time now for providing highly scalable solutions for businesses requiring fine-grained controls without the hassle of having to manage storage configurations independently for each VM or even each individual virtual disk.

vVols achieve this by using VMware’s native storage policy-based management, or SPBM for short, which empowers the vSphere administrator to define storage characteristics that match the requirements of the services and applications being hosted by the platform, without having to learn how to be a storage administrator in the process.

SPBM leverages the vSphere API for Storage Awareness (VASA), which was first introduced by VMware along with NetApp support back in 2012. Vendor specific VASA Providers provide an out of band command and control path for both storage management and awareness. With NetApp ONTAP, the VASA Provider is implemented as part of the ONTAP tools for VMware vSphere appliance. ONTAP tools facilitates management of many ONTAP clusters with just a single appliance, minimizing the number of VASA Providers and SSL certificates that vCenter must manage.

With the release of ONTAP tools 9.10, and SnapCenter plugin for VMware vSphere (SCV) 4.6, NetApp introduces a first party solution for backing up and recovery vVols based VMs using storage-based snapshots and native replication to a second ONTAP system using NetApp SnapMirror technology. Another powerful new feature for the IT service provider unique to vVols based VM backups is tag-based resource groups. More on that below.

NetApp storage snapshots are incremental forever type snapshots, and SnapMirror transfers are also incremental forever after the initial baseline. Furthermore, SnapMirror preserves storage efficiency savings from deduplication and compression, which saves time and money for environments that pay for network ingress or egress bandwidth.

Back in 2020, version 9.7.1 of the VASA Provider added support for replication using SnapMirror, but only when used in conjunction with VMware Site Recovery Manager (SRM).

But what if your organization doesn’t use SRM or even SCV? But rather, writes its own code for disaster recovery, replication controls, backup and recovery, or more?

New REST API support in ONTAP tools 9.10

ONTAP tools and SCV are designed to accelerate the journey to cloud-scale automation by not just providing simple, intuitive, and insightful UIs that help the vSphere admins on the operations team, but also by exposing functionality via RESTful APIs allowing automation engineers to quickly and easily adapt storage management to their cloud service catalog.

One example could be creating a new datastore using iSCSI. With traditional automation, you must do the following tasks, keeping in mind you must select all the correct options along the way.

Without ONTAP tools for VMware vSphere:

Configure ESXi iSCSI initiator to log into iSCSI target
Create igroup in ONTAP
Add IQNs to igroup
Create FlexVol
Create LUN in FlexVol
Map LUN to igroup
Rescan HBAs in ESXi
Create datastore in ESXi

With ONTAP tools for VMware vSphere:

Authenticate VMware session with secure REST API endpoint
Use authenticated session to send REST API to create datastore
…. No, that’s it.

But that’s not really what I wanted to blog about today. This basic functionality has been there for years. You can see some more examples of ONTAP tools REST APIs with Ansible on GitHub, and I definitely recommend getting familiar with it. You can also use the Swagger UI, which is conveniently linked to from the ONTAP tools “Getting Started” page.

What’s new is the context of this blog post is that ONTAP tools is now able to import a vVol from unmanaged storage using REST APIs. And in fact, currently, only REST APIs. This is important because a vVol isn’t just a LUN or file. It also exists within the VASA Provider’s database. So, in essence, this new API allows you to take a VMDK vVol data file, generate a new VMDK descriptor, and import it into the database. Only then are you able to manage it as you would any other disk.

The practical implication is that this allows you to snapshot and replicate vVols datastores the same way you have always done with traditional datastores, and still automate recovery tasks with vVols datastores the same way you would with any other traditional datastore. Only now you can take advantage of the full power of SPBM and VASA-based storage accelerations that I’ve talked about in previous posts.

Demo

In the following video, I’m going to illustrate the process of attaching a vVol from a SnapMirror replica in order to recover a guest file, such as an application database or other user data. To do so, I’m going to use the new tag based backup policies in SCV to automatically snapshot and replicate a VM based on the requirements I have set forth in my fictional private cloud. For example, I could setup my backups in SCV to look for a tag called “hourly_with_SM” and this backup would run on the hour and update SnapMirror when it is finished. This is important for the cloud service provider because now you only need to tag VMs with the desired policies and SCV will make it happen regardless of which datastore they live on, just so long as it’s an ONTAP vVols datastore. Remember, SCV has its own set of REST APIs that allow you to control backup and recovery services, so this can all be automated within your private cloud environment.

After that, I am going to run a PowerShell script that performs the following tasks for me:

Clones the SnapMirror destination volume using a standard ONTAP PowerShell Cmdlet (REST APIs also exist for this if you don’t use PowerShell)
Add the volume as a new temporary vVols datastore using an ONTAP tools REST API and the PowerShell Invoke-RestMethod Cmdlet
Create a new VM folder in the temporary datastore using VMware’s PowerCLI to store the new VMDK descriptor file
Rename the VMDK data file with a randomly generated ID# to recover to avoid any chance of a UUID conflict
Execute the new vvol/import REST API to register the vVol with the VASA Provider
Use PowerCLI again to add the vVol to the VM so that the end user can recover their files

A few code snippets I’ll share from the script in case you want to copy and paste for your own testing. This isn’t the whole script, just the important parts.

I’m skipping step 1 since that is already well known and documented

Step 2

Note that $headers includes my authenticated session info, and also $Datastore is the name of the FlexClone volume which I am also using as the datastore name for consistency. All fields shown here are required.

ProfileID is the ID of the storage capability profile. If you don’t know it, you can use the /api/rest/1.0/admin/storage-capabilities REST API to get them. For example:

$SCP = Invoke-RestMethod -SkipCertificateCheck -Uri "https:// <my VP address>:8143/api/rest/1.0/admin/storage-capabilities" -Method 'GET' -ContentType 'application/json' -Headers $headers -ErrorAction Stop

A helpful tip is that the targetMoref is the MoRef (Managed Object Reference ID) of the host or cluster you want to mount the datastore on. In this example, it’s a cluster. You can find the MoRef of a host or cluster using PowerCLI, or you can simply peak at the URL in the vCenter UI when selecting the host or cluster.

One other thing is that I am outputting the task ID, just in case something goes wrong and I need to debug later. It isn’t required, but I think it’s always good to include debugging tips.

#Define new DS from cloned volume

$BodyDS = @{   

    vvolDatastoreRequest= @{

        clusterIp= $clusterIp

        defaultSCP= "AFF_Default"

        description = $null

        existingFlexVolList= @(

            @{           

                flexvolName= $Datastore

                profileId= 9999954

            }

            )

    name= $Datastore

    protocol= "nfs"

    targetMoref= "domain-c485"

    vserverName= $SVM

    newFlexibleVolumes= $null   

    replicationSchedule= $null

    replicationType= $null

    }

} | ConvertTo-Json -Depth 4

Write-Host $BodyDS

#Invoke the DS REST API in ONTAP tools

$DSTask = Invoke-RestMethod -SkipCertificateCheck -Uri "https://<my VP address>:8143/api/rest/3.0/admin/datastore" -Method 'Post' -ContentType 'application/json' -Headers $headers -Body $bodyDS -ErrorAction Stop

write-host " "

Write-Host "Task ID:"$DSTask.taskId

Step 3

In my script, I have defined $VM at the very beginning. In practice, this would be a variable passed from your cloud service portal.

Write-Host "Add folder to store the vVol we plan to register"

connect-viserver $viserver -Credential $myCredentialsObject

Start-Sleep -s 10

$DatastoreMOREF = (Get-Datastore $Datastore).Id

$DatastoreObj = Get-Datastore $Datastore

mkdir -Path $DatastoreObj.DatastoreBrowserPath -Name $VM

Step 4

Note that in this case, I have decided to import a copy of the second VMDK, identified as $hdVvolId[1], and I am using the NetApp PowerShell Toolkit Cmdlet Rename-NcFile to do the rename.

Write-Host "identify vVol UUID"

$vmdata = get-vm $VM

$hd = $vmdata | get-harddisk

$hdVvolId = $hd.ExtensionData.Backing.BackingObjectId

Write-Host "vVol ID for second disk"$hdVvolId[1]

Write-Host "Rename file to avoid UUID conflict"

$RandomNumber = Get-Random -Minimum 100000000000 -Maximum 999999999999

$NewvVolUUID = $hdVvolId[1].Substring(0,32)+$RandomNumber.ToString()

Write-Host "New vVol UUID"$NewvVolUUID

$OldPath="/vol/"+$Datastore+"/"+$hdVvolId[1]+".vmdk"

Write-Host "Old path"

$OldPath

$NewPath="/vol/"+$Datastore+"/"+$NewvVolUUID+".vmdk"

Write-Host "New path"

$NewPath

Rename-NcFile -Path $OldPath -NewPath $NewPath -VserverContext $SVM

Step 5

Write-Host "Register vVol"

$BodyImport = @{

    vmVVolData= @{

        vmName= $VM

        vmw_vmID= $null

        vvols= @(

        @{

            ancestorRelationship= $null

            clusterName = $null

            clusterUuid = $null

            datastoreMoRef = "Datastore:"+$DatastoreMOREF

            datastoreName = $Datastore

            filePath = $null

            flexVolName = $Datastore

            flexVolUuid = $null

            keyValuePairs= @(

                @{

                    key = "VMW_VVolName"

                    value = "Clone-Wks_2.vmdk"

                },

                @{

                    key = "VMW_VVolType"

                    value = "Data"

                })                           

            osType = $null

            protocol = $null

            san = "false"

            sizeInMB = 4096

            spaceSetting = "Thin"

            svmName = $null

            svmUuid = $null

            targetflexVolName = $null

            targetflexVolUuid = $null

            type = "DATA"

            uuid = $NewvVolUUID

            vmStorageProfileNames = @("VVol No Requirements Policy")           

            vvolName = "Clone-Wks_2.vmdk"

        })

    }

} | ConvertTo-Json -Depth 5

$BodyImport

Invoke-RestMethod -SkipCertificateCheck -Uri "https://<my VP address>:8143/api/rest/3.0/admin/vvol/import" -Method 'Post' -ContentType 'application/json' -Headers $headers -Body $BodyImport

Step 6

Write-Host "Add vVol to VM"

$RecoveryvVol = (Get-HardDisk -Datastore $Datastore).Filename

write-host " "

write-host "Recovery vVol is:" $RecoveryvVol

New-HardDisk -DiskPath $RecoveryvVol -VM $VM