Deploying VVols on NTAP

VVolsEven before the release of vSphere 6, the hype for VVols has been in the upswing, and for a good reason. VVols allow for a granular management of VM objects within one or more datastores based on policies. I have written a few blogs about VVols, and also the requirements within NetApp here. I tend to write about the integration between the two vendors as I really like, and believe on their technology, and I am an advocate for both.

Anyway, deploying VVols on NetApp requires to first understand how this all works. So, with that in mind, don’t forget that this a software solution that relies on policies from both the VMware side and the NetApp side. As I explained on previous posts, deploying VVols on NetApp has certain requirements, but the one I’ll focus on is the VASA provider (VP). The VP acts as the translator between the VMware world and the storage array world, regardless of the storage vendor. Some storage vendors integrate the VP within the array others come as an OVA.

So, from the storage side, you first need to deploy the VP, and also in this case VSC, which is NetApp’s storage console within VMware. After all components have been installed, VASA will become your best friend as it will provision not only VVol datastores, but will also provision the volumes within NetApp, automatically create exports with proper permissions, and create the PE among others. The PE is a logical I/O proxy that the host sees and utilizes to talk to VVols on the storage side. In the case of an NFS (NAS) volume, the PE is nothing more than a mount point, in the case of iSCSI (SAN), the PE is a lun. Again, the VASA provider will automatically create the PE for you when you provision a VVol datastore.

Let’s start the roll out. Assumptions here are that you have already deployed VSC 6.0, VASA 6.0, and currently have vSphere 6.0 or later. On the NetApp side it is assumed that you have at least ONTAP 8.2.1 or later, and that you have already created an SVM of the protocol of preference whether it is iSCSI, FCP/FCoE or NFS, up to you.

The first thing you should do if you have both NetApp and VMware, or FlexPod for that matter, is to make sure your VMware hosts have the recommended settings from NetApp. To do this, go to VSC within the VMware Web Client, click summary, and click on the settings that are not green. VSC will open a new window and allow you to deploy those settings to the hosts. You should do this regardless if you are deploying VVols or not.

VSC_settings

 

The next step is to create a Storage Capability Profile within VSC/VASA. Within the VSC, go to VASA Provider for cDOT, and select Storage Capability Profiles (SCP). Here you will create your own profile of how you would like to group your storage, based on a specific criteria. For example, if you want a criteria for high performance, you may select a specific storage protocol, SSD drives, dedupe options, replication options, etc. This is the criteria that VASA will use to create your storage volumes when deploying VVol datastores, and if you already created a volume, this is also the criteria that will be qualified as compliant for the desired VVol storage.

I created an SCP that required the protocol to be iSCSI and SAS drives, the rest was set to any. This will result in VVol creation on the SAS drives only, and under the SVM that has iSCSI protocol and LIFs configured. If there are no iSCSI SVMs this would not work. Pretty self explanatory, I hope.

SCP_iSCSI

Now that the SCP is created, we can provision a VVol Datastore. Right click on the cluster or host and select “VASA Provider for clustered Date ONTAP”, then Provision VVol datastore.

Provision_VVol

Start the wizard and type the name of the VVol datastore, and select the desired protocol. Select the SCP that you want to include within the VVol, the qualified SVM(s) will be available if it matches the SCP you selected. For example, if you selected the SCP/protocol that calls for iSCSI and you only have one iSCSI SVM, that will be the only one that you will have as an option, and the NFS or FCP/FCoE SVMs will not appear. If there is a qualified volume, you may select to use it, or you may select none to create a new. If creating a new vol, choose the name, SCP, and other options just like you would from NetApp’s System Manager. You will also have the capability to add/create more volumes to the VVol datastore. The last step is to select a default SCP the VMs will use if the do not have a VMware profile assigned to them.

VVol_Complete

This will cause VASA to talk to your NetApp array and create a volume based on the SCP specified, at the same time, VASA will create the PE, which in this case is a lun.  You can add/remove storage to the VVol datastore you created at a later time simply by right-clicking the VVol and go to the VASA settings. Below you can see the PE that the VP created within the volume that was created during the VVol deployment process.

VVol_PE

 

The next step is to create a VM Storage Policy that points to the SCP. Once this policy is attached to a VM, it will “tell” the VM which datastore it is supposed to be on. So if you have a SQL VM on a high performance policy, you know that as long as the VM is in compliance, it will run in the high performance profile you created.  To create the VM policy within the Web Client, click on VM Storage Policies, select new (scroll with green + sign), give it a name and select the vCenter. For the rule set, select the VP from the drop-down box for “Rules based on data services” and add a rule based on profile name. For the profile name option, select the SCP you created initially under VASA. This will show you what storage is compatible with this rule. Since I selected the iSCSI SCP, it will show me the iSCSI VVol I have already created. This creates the VM policy that you can assign to individual VMs.

VSP_Rule1

VVol_Complete

 

You can also have different storage policies for the Home folder and VMDK.

VM_Policy

 

VM_Storage_Policy

 

Pretty cool, right?!?

I hope this helps you get started with VVols.

SHIFT VMs between Hypervisors

computer_key_ShiftAs more and more hypervisors emerge in the market, and more features are added to current hypervisor offerings; businesses may opt to migrate between vendors to save money, add features, consolidate to a single platform, or simply to follow a strategic plan. The migration is costly, complex, time consuming and disruptive as it requires down time of the VMs to be migrated; which is often not an option.

If you use NetApp as your storage vendor, the solution for this problem is now available to you. NetApp has announced the release of OnCommand Shift; a tool that enables the migration between Hyper-V VMs into a VMware environment and vice versa. This conversion is automated and requires minimum intervention from the user, and it takes a fraction of the time that other tools would take otherwise. OnCommand Shift supports VMware ESX/ESXi 5.0 -> 6.0, and Microsoft Hyper-V 2008 R2 -> 2012 R2.

How does OnCommand Shift works?

OnCommand Shift utilizes NetApp’s FlexClone technology which allows for the creation of the target VM within seconds/minutes. This is accomplished by creating a VMDK; for example, from a VHDX file by simply creating pointers to the existing data rather than copying and duplicating such data in the storage array. So, regardless of the size of the VMs, the time necessary to create the new VMs will be minutes or even seconds, rather than hours or days.

Shift_FlexClone

OnCommand Shift creates a virtual hard disk file in the format of the destination hypervisor and includes headers, metadata, and writes only the differences in the file format, instead of copying all the data from the source. Shift also collects and stores all VM information, as well as other VM settings, removes any hypervisor proprietary tools, and takes a backup of the VM prior to the conversion. It then proceeds to convert the VMs, say from Hyper-V to VMware, and then it restores all the network interface configuration as well as other settings.

Shift_Overview

Requirements

  • NetApp FAS2440 or higher
  • NetApp cDOT 8.2 or later
  • NetApp NFS and CIFS/SMB license for the controllers
  • Server to control the migration process (Physical or Virtual)
    • 2 vCPUs
    • 4GB RAM
    • 250GB storage Minimum (500GB preferred)
  • Data ONTAP PowerShell Toolkit version 3.0.1 or higher
  • PowerCLI 5.1 or higher
  • Microsoft Hyper-V PowerShell cmdlets
  • Microsoft .NET Framework 3.5

 

Golden Nuggets: #1 vSphere vFlash

ToolsWith so many tools and features from many different vendors, it is almost impossible to research them all and find useful tools to make your job easier. Some features also provide a faster/cheaper way to solve common problems without spending a fortune, unfortunately, these “Golden Nuggets” are often underutilized. I’ll post a few quick tools that may make a big difference in someone’s environment. As always, test before deploying to production.

One of the cool features introduced in vSphere 5.5 was vFlash, which replaced swap to SSD from previous versions, but I won’t get into that. Essentially, this is flash-based read cache on the host that functions at the vmdk level for a specific VM. This feature works by adding flash-based resources such as PCIe cards or SSD drives to create a vFlash pool of resources at the host level, and configuring the amount of storage to be used for host swap cache. Such cache is placed on the data path of the vmdk between the host and the storage array.

Once the host is configured, you can expand the virtual disk of a VM’s properties in the Web Client and assign the amount of cache for that particular vmdk, as well as having the option to select the block size (4KB – 1024KB). So, for each pool, chunks are carved out or reserved for a specific vmdk on the host where the VM is located.

vFlash_vmdk

As far as data locality goes and features like HA, DRS, vMotion; it is possible to migrate the cached data to another host while migrating a VM, as long as the other hosts have also been configured with vFlash. You may also specify not to migrate the cached data during migration.

Requirements:

  • Check HCL for compatible Flash devices
  • vCenter 5.5 or later (VCSA or Windows)
  • VM hardware version 10 or later
  • vSphere vMotion if using DRS
    • Requires vFlash on hosts within the cluster

 

Implementing vFlash can be beneficial for resolving or minimizing performance degradation for read intensive applications, or simply by utilizing local resources at the host level for read cache instead or in addition to storage read caching solutions. Having local cache eliminates the “extra hop” on the network to get to cached data at the storage array.

This is a high level view of vFlash but in my opinion, I think this is a nice feature that can get rid of some headaches and fire drills.

 

vFlash_highLevelImage source – VMware doc (Rawlinson)

 

VCSA 6.0 OVA install

In my last post I talked about some of the gaps with VCSA compared to the Windows vCenter version. I mentioned that the OVA was no longer available for download; however, it was quickly pointed out to me by William Lam from VMware that the OVA is in fact still available within the download; however, there is a disclaimer stating that such method is not officially supported by VMware.

Anyway, the OVA is buried within the ISO. Once you have mounted the ISO, you can navigate to the vcsa folder and the file named vmware-vcsa (with no extension) is the actual OVA (ISO->vcsa->vmware-vcsa). You may need to rename the ova to vmware-vcsa.ova or <other>.ova.

vcsa_ovaFile OVA_VCSA

 

 

 

From that point on, the deployment is the same as before.

William works for VMware and is a super sharp guy; although he may not remember me, I had the pleasure of meeting him during the vSphere 6 onsite Alpha over a year ago. Make sure to check out his blog full of tips and tricks. His blog site is virtuallyGhetto .

Deploying VCSA 6.0: Mind the Gap

VMware’s VCSA 6.0 brings a lot of enhancements compared to previous versions. I would seriously consider deploying VCSA in a production environment in order to replace the Windows flavor. For those not familiar with VCSA, this is the virtual appliance option to deploy vCenter in an environment. It reduces the time needed to deploy vCenter and offers an integrated database for no additional cost. Although this post may not be entirely technical, it will allow you to be aware of possible constraints that will prevent you from deploying VCSA before you invest too much time on it.

One of the great things about deploying VCSA over the Windows vCenter is that you will reduce the cost by not deploying a Windows VM as well as having to purchase an MSSQL license. VCSA sounds great so far, but there are some gaps that you need to be aware of before deploying this in an environment.

 

VCSA_mind_the_gap

Some of the shortcomings of VCSA are primarily related to its nature of not being a Windows VM. For some deployments Windows vCenters have been used to also host the VUM (Update Manager) components, as well as programs that provide additional capabilities to the virtual environment such as VSC for NetApp storage, among others. This means that you would still need to deploy a Windows VM to host VUM as well as VSC in this case. Even though you would still be deploying such VM, the need for a MSSQL server/instance is not required which translates in savings.

Another aspect to keep in mind is the installation and migration from previous versions. There is no in-place upgrade from previous versions, but migrations are possible. With this in mind, you may want to consider to just start with a new, fresh environment. I would. Same applies to the Windows flavor. The installation method now comes as an ISO image. This may cause some confusion. In order to deploy VCSA, the ISO is mounted from a Windows system (can be your computer) and installation can be done remotely.

Before installation, make sure you install the Client Integration Plugin located within the ISO under the vcsa folder.

VCSA_CIP

 

 

 

Start the installation by launching the vcsa-setup.html file from the ISO. A Web UI opens up after a few seconds, and gives you the option to install and ‘Upgrade” (migrate). During installation, just provide the target Host information, and the rest of the information needed for the installation. Make sure the VCSA appliance has a proper network connection and you can reach it from the computer deploying the appliance.

vcsa_setupvcsa_UI

 

 

 

 

 

 

 

 

Both Windows and appliance vCenter offerings have the same scalability numbers as it relates to hosts, VMs, clusters, etc.

In conclusion, VCSA is a great choice for vCenter, but just be aware of some of the constraints of not using the Windows option. By the way the Web UI in vSphere 6 is soooo much faster!!! I’m just saying.