Yellow Bricks

by Duncan Epping

Duncan Epping

vSAN 8.0 U1 – Disaggregated Storage Enhancements!

· · 2 Comments

With vSAN 8.0 U1 a lot of new features and enhancements are introduced. There are many blog posts out there describing the long list of enhancements, but in this post, I want to focus on HCI Mesh or Disaggregated vSAN specifically. (Also read this post by Cato!) For this feature, which in the UI is referred to as “Datastore Sharing”, there are 3 key enhancements introduced in vSAN 8.0 U1. There are enhancements for both the Original Storage Architecture (OSA), as well as the Express Storage Architecture (ESA).

With vSAN 8.0 the initial version of ESA was launched, and it did not support the use of Datastore Sharing. Starting with vSAN 8.0 U1 though, vSAN ESA is now also capable of sharing its storage with other clusters in the environment. To be more precise, a vSAN ESA cluster can now mount the datastore of another vSAN ESA cluster. What we also support is a “compute only” cluster mounting the vSAN ESA datastore remotely. So for those planning on implementing vSAN ESA, I think that is a very welcome enhancement!

For OSA there are also two enhancements for Datastore Sharing. The first I want to discuss is cross-vCenter Server datastore sharing. This feature is especially useful with customers who have a larger estate and are managing multiple clusters via different vCenter Server instances. You simply now have the option to connect the vCenter Server instances from a storage point of view, and then you can simply select the remote datastore in the cluster managed by a different vCenter Server instance. Let me just show you how this actually works in the next demo.

The second enhancement for OSA specifically is support for Stretched Cluster configurations. Starting with vSAN 8.0 U1 it is now possible to mount a vSAN Datastore which is stretched across locations. Your “client” cluster” can be “stretched”, “standard”, or compute-only even. We support all of those combinations. On top of that, the interface enables you to specify which location should be paired with which location, or fault domain. In other words, if you look at the diagram below, I can ensure that the hosts in Site A connect via the “local” network” to the remote datastore as part of Site A. This avoids IO traversing the intersite link, which can make a big difference in terms of latency and available bandwidth for other I/O etc.

I can imagine that the concepts are difficult to grasp without seeing the vSphere Client, so I spend some time in the lab to create a demo for you that walks you through the steps of how to configure this. In the lab I created a vSAN Stretched Cluster, and a standard cluster, and I am going to mount the vSAN stretched Datastore to the host in the standard cluster. Enjoy!

vSAN ESA ReadyNode configurations are more flexible than you think!

· · Leave a Comment

I had a discussion at the Dutch VMUG yesterday about the ReadyNode configurations for vSAN ESA. The discussion was about how difficult it was to select a host and customize it. It was then that I realized that most people hadn’t noticed yet that there is an easier method (or lifehack as my kids would say) when it comes to selecting your server model. How does that work? Well, let me show you!

First, let’s take a look at the vSAN ESA ReadyNode Hardware Guidance Table. The table below shows you what the node capacity is for each profile from a storage, CPU, memory, and networking perspective.

Now if you look at the table you will see that as the “profile” number goes up, so does the capacity for each of the various components. This is actually what provides you with a lot of flexibility in my opinion. If we take Dell as an example, but the same applies for most vendors on the current list, and we select “vSAN-ESA-AF2” and look at the list of options we see the following:

  • PowerEdge R650
  • PowerEdge R6515
  • PowerEdge R750
  • PowerEdge R7515

Now, if we look at “vSAN-ESA-AF8” next, which is the highest profile, we see that we only can pick 1 server model, which happens to be the PowerEdge R750. If we then look at the difference between the hosts selected for each profile a few things stand out:

  • vSAN-ESA-AF2 has an Intel Xeon Silver 4314, while vSAN-ESA-AF8 has a Platinum 8358
  • vSAN-ESA-AF2 has 512GB, while vSAN-ESA-AF8 has 1024GB
  • vSAN-ESA-AF2 a 25Gbps NIC, while vSAN-ESA-AF8 has a 100Gbps NIC
  • vSAN-ESA-AF2 has five 3.2TB NVMe devices while vSAN-ESA-AF8 has twenty-four 3.2TB devices

Now if I look at the KB article which explains what you can, and cannot change, something stands out, most of the components can be modified/customized. For instance, for CPU you can go to a higher core count and/or higher base clock speed! For memory, you can go up, same for storage devices (as long as you stay within supported limits), etc etc.

In other words, what is the difference between a vSAN-ESA-AF2 and a vSAN-ESA-AF8? Basically the expected workload, the performance, the capacity. This ultimately results in a different configuration. Nothing, at this point in time, stops you from selecting the “lowest” vSAN ReadyNode Profile and spec it as an “AF4”, “AF6” or “AF8” from a CPU stance, or from a storage/memory capacity point of view. If you want to have some more flexibility, try selecting a smaller profile, select the host type, and increase the resources/components where needed!

When you start exploring the options it may seem complex, but when you look more closely you will quickly realize that it actually isn’t that complex, and that it actually provides you with a lot of flexibility, as long as you stick to the rules and pick supported components!

Why is vCenter Server trying to access assets.contentstack.io or send DNS requests for it?

· · 6 Comments

On VMTN I noticed somehow asking why vCenter Server was trying to access  assets.contentstack.io, and why there were so many DNS requests for  assets.contentstack.io. It took me a while to figure it out, but I noticed that there’s a plugin for the VMware Cloud Provider Services, this plugin is hosted on contentstack.io, and that is the reason you see vCenter Server trying to connect with that URL and why you are seeing DNS requests for assets.contentstack.io. You can prevent this from happening by simply selecting the plugin, and then removing it. That is, of course, if you are not planning on using these services.

Can I change the “Host Image Profile Acceptance Level” for the vSAN Witness Appliance?

· · Leave a Comment

On VMTN a question was asked around the Host Image Profile Acceptance Level for the vSAN Witness Appliance, this is configured to “community supported”. The question was around whether it is supported to change this to “VMware certified” for instance. I had a conversation with the Product Manager for vSAN Stretched Clusters and it is indeed fully supported to make this change, I also filed a feature request to have the Host Image Profile Acceptance Level for the vSAN Witness increased to a higher, more secure, level by default.

So if you want to make that change, feel free to do so!