I had one more demo to finish and share and that is the vSAN 6.6 stretched cluster demo. I already did a stretched clustering demo when we initially released it, but with the enhanced functionality around local protection I figured I would re-record it. In this demo (~12 minutes) I will show you how to configure vSAN 6.6 with dedupe / compression enabled in a Stretched Cluster configuration. I will also create 3 VM Storage Policies, assign those to VMs and show you that vSAN has place the data across locations. I hope you find it useful.
vSphere
vSAN 6.6 Demo: Configuration Assist
I just noticed I still had a demo recoding on my desktop from a couple of weeks ago. The topic is vSAN 6.6 configuration assist. Hadn’t done anything with it, so I just added the narratives and shared it on youtube. Only a 3 minute video and quickly shows you where Configuration Assist can be useful. Hope you like it.
Change multicast address when running multiple vSAN clusters in same VLAN
Before vSAN 6.6 we would always recommend to change the multicast address when running multiple vSAN clusters in the same VLAN. Now that with vSAN 6.6 we removed multicast, does this best practice/recommendation still apply? I went looking for a clear statement but couldn’t find any, until Cormac pointed me to the excellent vSAN Networking Guide he wrote together with Paudie. After reading the table a couple of times, this is what I would consider to be the new best practice/recommendation:
If you run a vSAN 6.6 cluster with on-disk format v5.0 then there’s no need to change the multicast address when you have multiple clusters in the same VLAN as there’s no chance older host can be introduced in to the cluster as they will be partitioned instantly.
If you run a vSAN 6.6 cluster with on-disk format pre v5.0 then it is recommend to change the multicast address when you have multiple clusters in the same VLAN as when older hosts are added the cluster switches back to multicast mode. Although this could be considered an “operational consideration”, to avoid problems we would recommend changing the multicast address.
We also stated in the past that you could give each vSAN cluster a different VLAN for the vSAN network, the same applies. You can use a single VLAN for multi clusters, as long as those clusters are vSAN 6.6 and running on-disk format v5.0.
I hope that helps.
vSAN 6.6: Manual vs Automatic Disk Claim Mode
I received this question on Manual vs Automatic disk claim mode in vSAN 6.6. Someone upgraded a cluster from 6.2 to 6.6 and wanted to add a second cluster. They noticed that during the creation of the new cluster there was no option to select “automatic vs manual”.
I think a blog post will be published that explains the reasoning behind this, I figured I would share some of it before hand so you don’t end up looking for something that does not exist. In vSAN 6.6 the “Automatic” option which automatically creates disk groups for you has disappeared. The reason for this is because we see the world moving to all-flash rather fast. With All-Flash it is difficult to differentiate between the capacity and cache device. For that reason, in previous versions of vSphere/vSAN you already had to grab the devices yourself when it was an all-flash configuration. With 6.6 we removed the “automatic” option as we also recognized that when there are multiple disk groups and you need to take disk controllers, and location of disks etc in to account it even becomes more complex to automatically form disk groups. In our experience most customers preferred to maintain control and had this configured to “manual” by default. As such this option was removed.
I hope that clarifies things. I will add a link to the article explaining it.
Can I front vSAN with a VAIO Caching Solution?
I had this question a couple of times already, so I figured I would write a quick post. In short: yes you can put a VAIO Filter in front of vSAN. The question really is, which one would you like to use and why?
First of all, the VAIO Filter needs to be certified to be placed in front of vSAN storage. Just like it needs to be certified for VMFS and NFS. You can go to the VAIO HCL and check this yourself:
- Go to: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio
- Select the Vendor, for instance Infinio
- Then click the product that comes up and open up the version of vSphere you want to use it for, for instance 6.5
- Now it should state something like this : VMFS5, vSAN, VVOL
In this example Infinio supports VVols, vSAN and VMFS. Great! Now the next question is: why? Well that is the bigger question, personally I don’t see a real compelling reason. For traditional storage it makes a lot of sense, as you want to keep IOs local and add cache in a “cheap way” instead of expanding, a potentially close to end of life, storage system. For vSAN that is different. vSAN has a distributed architecture and every node has a flash device that is being used for write caching, and also read caching in a hybrid scenario. If this is a new deployment invest your money in NVMe instead. If you want to repurpose existing hardware and it is not on the vSAN HCL, ask yourself if you should complicate your deployment or not?
I would personally recommend to keep it simple, but than again I can also understand you do not want to let flash resources go to waste if vSAN does not support the devices. If you want to go VAIO, make sure to check the HCL and take the potential risks and operational complexity in to account and weigh that against the cost.