vSAN 6.6 Rebalance & Resync Operations

In this post I will delve a little bit into day 2 OPS here with vSAN. Suppose you have had a maintenance window for rebooting and patching hosts, or perhaps you have a message under vSAN health saying that a proactive disk rebalance is needed on your vSAN cluster. In either scenario you will have components of VM's resyncing or in the case of a rebalance, moving on the cluster. This won't be a long post, but will give you some idea of what to expect when you encounter either disk resync or proactive rebalancing on your vSAN cluster.

First off let's define what the difference between the two operations are. A resync is replicating VM components across hosts in accordance to Storage Policy-Based Management or SPBM FTT=1, FTT=2 etc.

Updating a vSAN Cluster using VUM

I wanted to shed some light on what some may think is a mystery or difficult task. How do I update a vSAN cluster using vSphere Update Manager (VUM)? The quick and simple answer is easily! The great thing about vSAN is that you already know how to upgrade and patch it since it is built into the ESXi hosts and vCenter web client that you already use daily. I will take you through the process of upgrading a host in my home lab. Remember as with any upgrade make sure that your hardware is supported and on the VMware Hardware Compatibility List (HCL) before proceeding with ANY upgrade.

The first step is to make sure you have a baseline attached to your cluster and/or Hosts. You can navigate to the update manager tab in the vCenter Web Client to do this. A baseline is a group that you setup for either patches, or upgrades and then you assign it to physical ESXi hosts or Clusters. You can see here that we have baselines created and VUM tells us that this particular host that we have highlighted is not compliant with this baseline and needs to be patched in order to be in compliance. We will go ahead and create a baseline for this host so you can see that process.

For this example I am going to create a baseline for critical host patches. I will check that box when creating the baseline, in this case since the critical host patches is a predefined baseline I don't need to go any further to assign to my hosts, another way it can be done is by right clicking a cluster or a host and then choosing to attach a baseline that way as well.

Here you can see the current patch level on the host is ESXi 6.5u1 build 5969303 in its non compliant state.

Now that we have created a baseline and told VUM to scan for updates and can see that we are not in compliance, we can start the process of upgrading. What I like to do first is enter the host into maintenance mode, VUM will do this for you but I prefer to do this step manually. 

Setting up Encryption in vSAN 6.6

I have had this post in the works for a while now. I have had some challenges in my home lab with unstable storage and issues with fiber channel support on my freenas server. I have since moved over to a IBM DS3400 SAN and that has been much more stable, anyway I digress, onto the content!

I wanted to play around with the new encryption options that vSAN 6.6 brings to the table and I was fortunate enough to get setup with a HyTrust KMS server so I can get it up and running and test it out. I want to give a huge shoutout to the HyTrust team for providing this to me, without their support this post would not be possible! I will not be doing any benchmarks but rather seeing how the technology works and how easy it is to implement.

The first step is to have a working vSAN cluster. I happen to have a 6 node nested ESXI 6.5u1 vSAN cluster in my lab with each nested host containing 2 vCPU 16GB of RAM, 1 10GB Cache disk and 1 50GB capacity disk for a total of 300GB on the vSAN Datastore. This Cluster is running FTT=2. I will be installing the Hytrust KMS server into the nested environment.

VMware Licensing Organization Tips

I bet there are lots of folks out there that just love managing licensing both on their systems and in the VMware portal. For those of you that didn't sense my sarcasm, there have been some pain points in the past, but I have to say I have been so impressed with recent changes to the VMware portal and some additions in vSphere 6.5 regarding license management that I had to share once I found them.

They have made it really easy to use and have separated the product lines in the main licensing page, this is done by default and is not something you have to setup. The portal is laid out really nice and is pretty easy to navigate compared to how things have been in the past.

Another really cool feature is the ability to split and combine CPU licenses really easy.

VSAN 6.2 Deployment Part 3 Implementation

Today we will be getting back to the VSAN deployment series I had started earlier this summer, it's time to continue on with excerpts from the presentation I have been doing at VMUG's on my VSAN deployment. Today we will be focusing on the Implementation phase. Here is an overview of that process.

We started by getting our 4 new Lenovo servers racked then installed esxi 6.0u2 on them, we then installed our 10Gbe switches and configured our VLANS separating out our VSAN traffic on its own VLAN which we also isolated from talking to the rest of the network as we were told that the multicast traffic VSAN 6.2 required could get quite chatty and could take down other network switches on the network (note that this requirement was removed in VSAN 6.6 which now uses unicast) Our network topology in part 2 of this blog series showed our dual redundancy we planned for by having 2 10Gbe switches and 2 PCIE 10GBe interface cards per host.