Yellow Bricks

by Duncan Epping

vvols

What is this Catalog folder on my datastore?

· · Leave a Comment

A question popped up on our internal slack earlier these days, and as I didn’t find anything online for it I figured I would write a quick article. When you look at your datastore, you may find various folders. Some you will recognize like the “.vSphere-HA” folder structure, which is used by vSphere HA, others you may not recognize, like the folder called “catalog” (see screenshot below), which has folders like “shard”, “mutex”, “tidy”, and “vclock” in it. The folder “catalog”, and all folders underneath, are created automatically when you use First Class Disk’s (FCD). FCD uses the folder structure to store it’s metadata in it. So please do not remove/delete or touch these folders. If you like to know more about FCD, make sure to read Cormac’s post on it.

Oh and if wonder why you are using FCD in the first place, it is often used for Kubernetes “persistent volumes”. So if you are using Tanzu/Kubernetes and have persistent volumes, chances are you are using FCD, which would result in those folders on your datastore. Nothing to worry about. 🙂

vSphere FT and vVols/SPBM an unsupported config? Why?

· · Leave a Comment

I was pointed out by a customer (thanks Johan), that vSphere FT is not supported when using SPBM on non-vSAN based storage systems. You may wonder why this is, at least I did wonder. I figured it would be a testing constraint of some sort, but after emailing product management, engineering, and our quality engineering team I now understand why it is. Now before I explain it, the constraint is documented here, let me quote the section for you:

Virtual Volume datastores.
Storage-based policy management. Storage policies are supported for vSAN storage.

So why is this and why would vSAN be supported as that also uses SPBM? Well the difference is in the implementation. For vVols there’s a dependency on vCenter Server to be available when creating new VMs. This is essentially what happens when an FT instance needs to be restarted. We will need to associate an SPBM policy with it and we can only retrieve it via vCenter Server. With vSAN, FT/HA can also retrieve the needed info via the ESXi host. This is why FT and vSAN are a supported configuration, and vVols and FT, unfortunately, is not at the moment. Hopefully, though, this will change in the future. (Yes, I filed a feature request before anyone asks.)

Part 2: Is VSA the future of Software Defined Storage? (Customer use case)

· · Leave a Comment

About 6.5 years ago I wrote this blog post around the future of Software-Defined Storage and if the VSA (virtual storage appliance) is the future for it. Last week at VMworld a customer reminded me of this article. Not because they read the article and pointed me back at it, but because they implemented what I described in this post, almost to the letter.

This customer had an interesting implementation, which kind of resembles the diagram I added to the blog post, note I added a part to the diagram which I originally left out but had mentioned in the blog (yes that is why the diagram looks like it is ancient… it is):

I want to share with you what the customer is doing because there are still plenty of customers that do not realize that this is supported. Note that this is supported by both vSAN as well as VMware Cloud Foundation, providing you a future proof, scalable, and flexible full-stack HCI architecture which does not need to be implemented in a rip and replace approach!

This customer basically leverages almost all functionality of our Software-Defined Storage offering. They have vSAN with locally attached storage devices (all NVMe) for certain workloads. They have storage arrays with vVols enabled for particular workloads. They have a VAIO Filter Driver which they use for replication. They also heavily rely on our APIs for monitoring and reporting, and as you can imagine they are a big believer in Policy-Based Management, as that is what helps them with placing workloads on a particular type of storage.

Now you may ask yourself, why on earth would they have vSAN and vVols sitting next to each other? Well, they had a significant investment in storage already, the storage solution was fully vVols capable and when they started using vSAN for certain projects they simply fell in love with Storage Policy-Based Management and decided to get it enabled for their storage systems as well. Even though the plan is to go all-in on vSAN over time, the interesting part here, in my opinion, is the “openness” of the platform. Want to go all-in on vSAN? Go ahead! Want to have traditional storage next to HCI? Go ahead! Want to use software-based data services? Go ahead! You can mix and match, and it is fully supported.

Anyway, just wanted to share that bit, and figured it would also be fun to bring up this 6.5 years old article again. One more thing, I think it is also good to realize how long these transitions tend to take. If you would have asked me in 2013 when we would see customers using this approach my guess would have been 2-3 years. Almost 6.5 years later we are starting to see this being seriously looked at. Of course, platforms have to mature, but also customers have to get comfortable with the idea. Change simply takes a lot of time.

SRM support for VVols coming!

· ·

VMworld is coming up, which means that is “announcements season”. First announcement that I can share with you is the fact that VVols support for SRM is now officially on the roadmap. This is something Cormac and I have pushed hard for the past couple of years, and it is great to see this is finally being planned! A post about this was just published on the VMware Virtual Blocks blog and I think the following piece says it all. Read the blog for more info.

Some of our storage partners such as HP Enterprise 3PAR, HP Enterprise Nimble, and Pure Storage have developed and certified to the lastest VVol 2.0 VASA providers specification. VVol 2.0 is part of the vSphere 6.5 release and supports array-based replication with VVol.  To support VVol replication operations on these storage arrays, VMware also developed a set of PowerCLI cmdlets so common BC/DR operations such as failover, test failover, and recovery workflows can be scripted as needed. The use of PowerCLI works well for many VVol customers, but we believe many more customers will be able to take advantage of SRM orchestrated BC/DR workflows with VVol.

I can’t wait for this to be made available, and I am sure many VVol customers (and potential customers) will agree with me that this is a highly anticipated feature!

VVols design and procurement considerations

· ·

Over the past couple of months I have had more and more discussions with customers and partners about VVols. It seems that Policy Based Management and the VVol granular capabilities are really starting to sink in, and more and more customers are starting to see the benefit of using vSphere as the management plane. The other option of course is pre-defining what is enabled on a datastore/LUN level and use spreadsheets and complex naming schemes to determine where a VM should land, far from optimal. I am not going to discuss the VVols basics at this point, if you need to know more about that simply do a search on VVol.

When having these discussions a bunch of things typically come up, these all have to do with design and procurement considerations when it comes to VVol capable storage. VMware provided a framework, and API, and based on this each vendor has developed their own implementation. These vary from vendor to vendor, as not all storage systems are created equal. So what do you have to think about when designing a VVols environment or when you are procuring new VVol capable storage? Below you find a list of questions to ask, with a short explanation of why this may be important. I will try to add new questions and considerations when I come up with them.

  • What level of software is needed for my storage system to support VVol?

In many cases, especially existing legacy storage systems, an upgrade is needed of the software to support VVols, ask:

  • What does this upgrade entail?
  • What is the risk?

When it is clear what you need to support VVols from a software point of view, ask:

  • What are the constraints and limits?
    • How many Protocol Endpoints can I have per storage system?
      • Do you support all protocols? (FC, NFS, iSCSI etc)
      • Is the IO proxied via the Protocol Endpoint? If it is, is their an impact with a large number of VMs?
        • Some systems can make a distinction between traffic type and for normal IO will not go through the PE, which means you don’t hit any PE limitations (queue depth being one)
    • How many Storage Pools can you have per storage system?
      • In some cases (legacy storage systems) the storage pool equals an existing physical construct on the array, what is it and what is the impact of this?
        • What kind of options do I select during the creation of the pool? Anything you select on a per Pool level means that when you change policy VVols may have to migrate to other pools, I prefer to avoid data movement. In some cases for instance “replication” is enabled on a storage pool level, I prefer to have this as a policy option
    • How many VVols can I have per storage system? (How many VMs do you have, and how many VVols do you expect to have per VM?)
      • In some cases, usually legacy storage systems, the number of VVols per array is limited. I have seen as “low” as 2000, with 3 VVols per VM at a mininum (typical 5) you can imagine this restricts the number of VMs you can run on single storage system

And then there is the control / management plane:

  • How is the VASA (vSphere APIs for Storage Awareness) Provider implemented?
    • There are two options here, either it comes as part of the storage system or it is provided as a virtual machine.
  • Then as part of that there’s also the decision around the availability model of the VASA Provider:
    • Is it a single instance?
    • Active/Standby?
    • Active/Active?
    • Scale-out?

Note, as it stands today, in order to power-on a VM or create a VM the VASA Provider needs to be available. Hence the availability model is probably of importance, depending on the type of environment you are designing. Also, some prefer to avoid having it implemented on the storage system, as any update means touching the storage system. Others prefer to have it as part of the storage system as it removes the need to have a separate VM that needs to be managed and maintained.

Last but not least, policy capabilities:

  • What is exposed through policy?
    • Availability? (RAID type / number of copies of object)
    •  QoS?
      • Reservations
      • Limits
    • Replication?
    • Snapshot (scheduling)?
    • Encryption?
    • Application type?
    • Thin provisioning?

I hope this helps having the conversation with your storage vendor, developing your design or guide the conversation during the procurement process. If anyone has additional considerations please leave a comment so I can add it to the list when applicable.