NetApp Cloud Volumes Service with Google Cloud VMware Engine - Part 4
In the fourth installment of this multi-part blog series about storage options for Google Cloud VMware Engine, I will be discussing the NetApp Cloud Volumes Service. More specifically, since I have already covered NFS services in the past, this service offers SMB protocol support, which can help integrate things such as user directory storage for VDI implementations.
Previous posts in the series:
- Storage Options with Google Cloud VMware Engine - Part 1
- Google Cloud Filestore with Google Cloud VMware Engine - Part 2
- Google Cloud Storage with Google Cloud VMware Engine - Part 3
NetApp Cloud Volumes Service (CVS) – Overview
If you are looking to extend storage for your Google Cloud VMware Engine private cloud, the NetApp offering has an attractive set of features and capabilities available. Not to mention, these benefits would be expanded if you have an existing on-premises datacenter that already has NetApp arrays installed for your workloads.
When getting started, this service has multiple service types, each offering different capabilities, protocols, features, and speeds. The services types chart in the previous link will help you quickly find which type would be best for you. As mentioned previously, the NetApp CVS service even offers volumes to be presented to your private cloud as a vSphere datastore. In my opinion, the two most attractive features offered are the multiple protocol selection and snapshots. For example, SMB is offered for Microsoft clients, and the snapshots allow for a full protection schedule.
Configuration example
In this configuration example, I will be showing creating an SMB “user share” for my Windows 11 clients that will store their persistent data such as personal files or even profile information.
Prerequisites
After enabling the NetApp Cloud Volume Service API for the first time, there are some prerequisite networking steps that need to be done to connect your project’s VPC to the NetApp VPC. The easiest way to accomplish this is to start to create a new Cloud Volume, scroll down to the networking section, and then select the network you wish to connect it to.
(Click to Enlarge)
The configuration will automatically alert you to whether this network is peered with NetApp and allow you to view the commands that can be entered into the Google Cloud shell to configure it.
(Click to Enlarge)
I found it helpful to open a new browser tab for the Cloud Shell so that I could easily cut and paste the commands into it. In addition, the commands need to be issued in order and they may take a couple of minutes for each command to complete, so don’t get concerned if the operations take some extra time.
(Click to Enlarge)
Once peering your VPC to NetApp is complete, the previous alert message should disappear from the volume creation screen, and you can continue.
At this point in the process, you can either create a standard CVS volume, or a CVS-Performance volume. Make note that the availability for each type is dependent on the region.
In addition, if you want to create a standard CVS volume, you will have to create a storage pool first. However for this example, I will be creating a CVS-Performance volume, which does not need a storage pool created beforehand.
NFS or SMB?
At this point in the process, you can easily create an NFS volume, but if you want to create an SMB volume, the Active Directory settings must be completed first. Since I want to create an SMB volume, I need to provide NetApp with credentials, DNS, and AD information. This is because the CVS service needs to create the server object in AD and manage permissions. For the credentials portion, I created a dedicated service account with elevated privileges. (In my test environment, I just assigned the account Domain Admin rights, but you could also restrict permissions for least-privilege if your organizational policy requires it.)
(Click to Enlarge)
From there, you can navigate to the Active Directories tab, and click Create to supply your environment’s specifics.
(Click to Enlarge)
NOTE: The username needs to be entered using the User principal name (UPN) format such as svc_netappcvs@corp.multicloud.internal. The username box will let you specify the username in the “MULTICLOUD\svc_netappcvs” format, but unfortunately it will produce an error message suggesting the UPN format when it attempts to authenticate for the first time.
Creating the volume
Now that all the prerequisites have been satisfied, it is time to create the SMB volume.
(Click to Enlarge)
Just as a personal preference, I checked the option to “Make snapshot directory (.snapshot) visible”, because I think that feature is extremely useful for recovering individual user files. I also set a full hourly, daily, weekly, monthly snapshot policy to protect the directory contents.
Once you click save, it could take several minutes for the first volume to be created. Once it is done, you will notice that a server name has automatically been assigned, and its respective computer object has been added to Active Directory.
(Click to Enlarge)
With the volume and server creation completed, there is still one last step in making sure that the volume can be presented to Google Cloud VMware Engine virtual machines.
Configure the Google Cloud VMware Engine Private Connection
The last major configuration step is to ensure that your Google Cloud VMware Engine private cloud can connect to the NetApp VPC network where the new volume is located. To do this, navigate to the network section within the Google Cloud VMware Engine console, and add a private connection.
(Click to Enlarge)
These values can be found in your VPC network peering page as shown below.
(Click to Enlarge)
Important note: Once the private connection’s status changes to Active and Connected, it may still take several more minutes for the back-end workflows to complete before the clients can connect. In my case, it took an added 10-15 minutes after the private connection connected and became active.
Client configuration
Now that all the networking, the volume, and the server object has been set up, the clients should be able to connect to the network share. One thing that I found handy was the mount instructions for the share to be accessible from the volume’s configuration page.
(Click to Enlarge)
When you click on Mount Instructions for a particular volume, it will show either the NFS Linux commands or the Windows SMB commands for the client to mount the share, as well as a text copy link to easily copy and paste it.
(Click to Enlarge)
From here, the network share can be mapped manually, mapped through a logon script, or even provided to VMware Horizon for a user profile repository or persona management.
Snapshots and Recoveries
As you may have noticed earlier, I configured the share properties to take hourly/daily/weekly/monthly snapshots, and to keep a certain number of each for recovery purposes. The snapshots supply several recovery methods from recovering an individual file all the way up to restoring the entire share.
(Click to Enlarge)
From the snapshots menu, it shows a list of all snapshots in a region, as well as provides the ability to Revert the entire share. In my opinion, the Revert share functionality should only be used as a last resort. This is because it induces several complications with files that could still be opened by clients, not to mention reverting to a previous state could potentially lose any changes made since the snapshot was taken.
Because of this, the reason I called out making the snapshot directory visible earlier is because it allows an administrator to recover files super easy. When you navigate to the snapshot directory at the root of the share, it will list all the available snapshots along with the original folder structure contained in each.
(Click to Enlarge)
Drilling further into the directory structure, you will notice the list of my files, all exactly from the point in time the snapshot was taken. I can view or copy any of these files to recover data from the previous point in time.
(Click to Enlarge)
In addition, the ability for a user to recover from their own mistakes using the Previous Versions within the file properties is a bonus.
(Click to Enlarge)
Conclusion
The NetApp Cloud Volume Service delivers many enterprise storage features to your Google Cloud VMware Engine private cloud, making it yet another excellent tool in your cloud toolbox. This is particularly helpful if you do not want to create your own file server cluster, or just need extra capacity beyond what vSAN has available.
For more information about Google Cloud VMware Engine, please visit VMware Cloud Tech Zone.