Yellow Bricks

by Duncan Epping

6.0

Virtually Speaking Podcast – vSAN Customer Use Cases

· ·

As John Nicholson was traveling in and around New Zealand I was asked by Pete if I could co-host the Virtually Speaking Podcast again. It is always entertaining to join, Pete is such a natural when it comes to these things. I euuh, well I do my best to keep up with him :). Below you can find the latest episode on the topic of vSAN Customer Use Cases. It includes a lot of soundbites recorded at VMware World Wide Kick Off / Tech Summit, which is a VMware internal event for all Sales, Pre-Sales and Post-Sales field facing people.

You can of course also subscribe on iTunes!

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.

XenDesktop/XenApp 7.12 MCS works with vSAN

· ·

This is something that has kept me busy for a while. For the past 2 years there were some challenges with regards to the use of MCS and XenDesktop/XenApp in combination with vSAN. In fact, Citrix never supported vSAN and MCS, and it actually did not work either. PVS worked great in combination with vSAN however. Some customers though prefer to use MCS. After various discussions, emails and engineering discussions it seems that the problem customers faced has finally been resolved.

Citrix recently announced a hotfix that will allow you to use MCS with XenDesktop/XenApp 7.12 and vSAN version 6.0, 6.2 or 6.5. You can find the hotfix and details here: https://support.citrix.com/article/CTX219670

I would like to thank a couple of folks for making this happen, from Citrix: Christian Reilly (Thanks for connecting me to everyone!), Vishal Ganeriwala, Paul Browne, Yuhua Lu, Rick Dehlinger, Amanda Austin and from VMware Weiguo He, Tony Kuo and Sophie Ting Yin. Thanks everyone for making this happen in between releases. I am certain our joint customers will appreciate this! Note, that it is not a full statement of support (yet), but a great step in the right direction!

For those interested in XenDesktop/XenApp with vSAN, make sure to read this great reference paper by Sophie Yin. It provides a lot of detail around performance etc.

 

Two host stretched vSAN cluster with Standard license?

· ·

I was asked today if it was possible to create a 2 host stretched cluster using a vSAN Standard license or a ROBO Standard license. First of all, from a licensing point of view the EULA states you are allowed to do this with a Standard license:

A Cluster containing exactly two Servers, commonly referred to as a 2-node Cluster, can be deployed as a Stretched Cluster. Clusters with three or more Servers are not allowed to be deployed as a Stretched Cluster, and the use of the Software in these Clusters is limited to using only a physical Server or a group of physical Servers as Fault Domains.

I figured I would give it a go in my lab. Exec summary: worked like a charm!

Loaded up the ROBO license:

Go to the Fault Domains & Stretched Cluster section under “Virtual SAN” and click Configure. And one host to “preferred” and one to “secondary” fault domain:

Select the Witness host:

Select the witness disks for the vSAN cluster:

Click Finish:

And then the 2-node stretched cluster is formed using a Standard or ROBO license:

Of course I tried the same with 3 hosts, which failed as my license does not allow me to create a stretched cluster larger than 1+1+1. And even if it would succeed, the EULA clearly states that you are not allowed to do so, you need Enterprise licenses for that.

There you have it. Two host stretched using vSAN Standard, nice right?!

Disk controllers for vSAN with or without cache?

· ·

I got this question today and I thought I already wrote something on the topic, but as I cannot find anything I figured I would write up something quick. The question was if a disk controller for vSAN should have cache or not? It is a fair question as many disk controllers these days come with 1GB, 2GB or 4GB of cache.

Let it be clear that with vSAN you are required to disable the write cache at all times. The reason for this is simple, vSAN is in control of data consistency and vSAN does not expect a write cache (battery backed or not) in its data path. Make sure to disable it. From a read perspective you can have caching enabled. In some cases we see controllers where people simply set the write cache to 0% and the rest automatically then becomes read cache. This is fully supported, however our tests have shown that there’s little added benefit in terms of performance. Especially as reads come from SSD anyway typically, theoretically there could be a performance gain, but personally I would rather spend my money on flash for vSAN.

My recommendation is fairly straight forward: use a disk controller which is a plain pass through controller without any fancy features. You don’t need RAID on the disk controller with vSAN, you don’t need caching on the disk controller with vSAN, keep it simple, that works best. So if you have the option to dumb it down, go for it.