Note: This is another guest blog by Kyle Grossmiller. Kyle is a Sr. Solutions Architect at Pure and works with Cody on all things VMware.
In VMware Cloud Foundation (VCF) version 4.1, vVols have taken center stage as a Principal Storage type available for Workload Domain deployments. This inclusion in one of VMware’s premier products reinforces the continued emphasis on vVols and all the benefits that they enable from VMware. vVols with iSCSI is particularly exciting to us as this is the first instance of the iSCSI protocol being supported as a Principal Storage type within VCF. We at Pure Storage are honored to have had a little bit of influence over this added functionality by serving as a design partner for this new feature and we are confident you are going to like what you see!
Someone who is using VMFS datastore with VCF today might ask themselves ‘why vVols’? This is a great question deserving of an expansive answer beyond this blog post. Fundamentally, though, using vVols enables you to fully use the FlashArray in the way it was intended. By leverage VASA (VMware API for Storage Awareness) you gain far more granular control and monitoring abilities over your individual VMs. Native FlashArray capabilities such as snapshots and replication are directly executed against the underlying array via policy-driven constructs. Further information on these and other benefits with vVols are available here.
Using vVols as Principal Storage is a lot like the methods VCF customers are used to for pre-existing Principal Storage options. Image an ESXi host, apply a few prerequisites to it, commission it to SDDC manager and create Workload Domains. Deploying Workload Domains with VMware Cloud Foundation automates and takes all the guesswork out of deploying vCenter and NSX-T for modern use cases such as Kubernetes via Workload Management.
Stepping into some specifics for a moment; here’s the process on how to use FlashArray iSCSI and vVols for VCF Workload Domains:
The most fundamental update to SDDC Manager to allow vVols is the capability to register a VASA Provider. In the below screenshot and following detailed information, we show an example of how you can add a FlashArray using another block protocol: Fibre Channel:
Provide a descriptive name for the VASA provider. It is recommended to use the FlashArray name and append it with -ct0 or -ct1 to denote which controller the entry is associated with.
Provide the URL for the VASA provider. This cannot be the management VIP of the array. Instead this field needs to be the management IP address associated with one of the controllers. The URL also is required to have the VASA port and version.xml appended to it. The format for the URL is: https://<IP of FlashArrayController>:8084/version.xml
Give a FlashArray user name with the arrayadmin role. The procedure for how to create such a user can be found here. While the pureuser account can be used, we recommend creating and using a separate FlashArray user for VASA operations.
Provide the password for the FlashArray username to be used.
Container Name must be Vvol container. Note that this value is case-sensitive.
For Container Type, select FC from the drop-down menu to use Fibre Channel.
Once all entries are completed, click Save.
Obviously, there’s a lot more to share here so we will be expanding on this substantially in the very near future on our VMware Platform Guide site.
Rounding out this post, I’m happy to show a demo video of just how easy it is to deploy a FC+vVols-based Workload Domain with VMware Cloud Foundation.
Note: This is a guest blog by Kyle Grossmiller. Kyle is a Sr. Solutions Architect at Pure and works with Cody on all things VMware.
As we’ve covered in past posts, VMware Cloud Foundation (VCF) offers immense advantage to VMware users in terms of simplifying day 0 and 1 activities and streamlining management operations within the vSphere ecosystem. Today, we dive into how to use the Pure Storage leading vVols implementation as Supplemental storage with your Management and Workload Domains.
First though, a brief description of the differences between Principal Storage and Supplemental Storage and how it relates to VCF is in order to set the table. Fortunately, it is very easy to distinguish between the two storage types:
Principal Storage is any storage type that you can connect to your Workload Domain as a part of the setup process within SDDC Manager. Today, that’s comprised of vSAN, NFS and VMFS on Fibre Channel, pictured below. We’ve shown how to use VMFS on FC previously.
Supplemental Storage simply means that you connect your storage system to a Workload Domain after it has been deployed. Examples of this storage type today include iSCSI and the focus of this blog: vVols.
Another quarter, another vSphere Plugin release from Pure! This is the release I have been really looking forward to as it sets the stage for a lot of the future work I want to build into the plugin. To recap:
4.0.0 was our initial release of our plugin that only had the basic configuration support and VMFS management.
4.1.0 was the 2nd release that added vVol support back into the plugin.
4.2.0 enhances the plugin to add more vVol stuff into it as well as Pure1 Integration! So we are finally to the point where we are adding features into it that were never in the previous flash plugin. Yay!
This is the start of many blog posts around the recent Purity 5.0 release. I figured I would start with one that doesn’t require an upgrade of Purity to even get!
Alongside Purity 5.0, we released the 3.0 version of theFlashArray plugin for the vSphere Web Client. This is bundled in Purity 5.0, so if you upgrade any one of your FlashArrays you can then use it to upgrade the plugin in one or all of your vCenters.
Let me be clear though–if you want to use VVols or ActiveCluster you need Purity 5.0. Without Purity 5.0, you can use the 3.0 plugin of course, but you can only use non-VVol or non-ActiveCluster features.
In the recent release of the Purity Operating Environment on the FlashArray we deprecated TLS 1.0 support due to the ever growing list of vulnerabilities in it. Communication will be restricted to TLS 1.1 and later. Unfortunately, this affects some plugins/integrations. This is not an exhaustive list, but related to the ones VMware customers probably touch the most. If something is not listed ping the relevant support organization for more information.
The following plugins are NOT affected and will continue to work with Purity 4.7:
vRealize Operations Management Pack
vRealize Orchestrator Workflow Package
vRealize Log Insight Content Pack
The following are affected and will need to be upgraded to a specific version to work with Purity 4.7:
Site Recovery Manager Storage Replication Adapter (this needs to be version 1.5, which will be out soon)
vSphere Web Client Plugin (this needs to be version 2.0.10+)
This is part 1 of this 7 part series. Questions around managing VMFS snapshots have been cropping up a lot lately and I realized I didn’t have a lot of specific Pure Storage and VMware resignaturing information out there. Especially around scripting all of this and the various options to do this. So I put a long series out here about how to do all of this. Let’s start with what an unresolved VMFS is and how to mount it.
I was working on rebuilding my VMware lab environment today and for simplicity’s sake decided to leverage two external Platform Services Controllers (PSC), one for each of my vCenter environments (I need two because I am setting up Site Recovery Manager) in a federated manner. Akin to the previous term of “linked mode” If you are not familiar with PSC which was added in vSphere 6.0, check out this KB. I went with the 3rd deployment model illustrated in this KB. Continue reading “Pure Storage vSphere Web Client Plugin and Multiple vCenters”
I’ve been with Pure Storage for about ten months (time flies!) and a noticeable trend I’ve seen in the past six or so months is in the number of customers who are deciding to use iSCSI as their storage protocol of choice. This is increasingly common in greenfield environments where they don’t want to invest in a Fibre Channel infrastructure. I’ve helped quite a few set this up in VMware environments so I thought I would put a post together on configuring ESXi software iSCSI with the Pure Storage FlashArray (I have yet to see a hardware iSCSI setup).
Before I begin, I highly recommend reading the following two documents from VMware:
I’ve have been working with VMware’s vCenter Site Recovery Manager since the tail end of the 1.x release and I have to say this is the most excited I have been about a Storage Replication Adapter release that I can remember. Since I started with Pure in late April 2014 I have been working with our development team and product management to design and shape this initial release of the Pure Storage SRA. I have to say it has been a blast–a really great team that does some really amazing work! It is now officially approved and posted on VMware’s compatibility guide and SRA download site:
The vSphere Web Client Plugin for the Pure Storage FlashArray has been updated and released and it is the largest update to the plugin since, well, it was first released. A lot of feature enhancements–the majority focused on integrating local and remote replication management into the plugin. Our long term goal is to offer feature parity of FlashArray management with the plugin as compared to our own GUI. It is getting close. Let’s take a look at the new features.