Over the summer of 2021, VxRail added quite a bit of new features around the LCM functionality in the VxRail 7.0.240 release. In addition to vLCM integration with VxRail Manager, which we'll talk about, we also added "Configuration Drift Reporting" and "Advisory Reports". Both those reports are beneficial in making sure your VxRail system is 1) ready for an upgrade and 2) running the correct versions for your validated state.
I want to focus on the vLCM integration we've added into VxRail. By adding in the ability for customers to choose their LCM engine - either the VxRail maintained or vLCM - it provides additional flexibility for the upgrades. VMware first introduced vLCM with vSphere 7.0 and it added the ability for customers to create their own base image utilizing tools from the vendor of their server platform. This provided vendors with a framework they could choose to tie into if they felt obliged. From the VxRail side, adding in our ability to tie into the vLCM framework continues to provide additional flexibility to our customers when it comes to how and what is covered by a VxRail upgrade event.
Why would I use vLCM? This is a question we are often asked - why would I do this? There are a few use cases around changing to the vLCM engine for your upgrades: 1) FC HBA - if you have a fiber channel HBA in your system (either for secondary storage or primary with VxRail dynamic nodes) - using the vLCM engine allows you to customize the upgrade package with the FC HBA firmware/driver package 2) NVIDIA GPUs - as of VxRail 7.0.350 and vSphere 7.0U3, vLCM can be used to upgrade NVIDIA GPUs 3) Partial cluster upgrade (selectable hosts) - with vLCM enabled and using the VxRail Manager API, you can now tell the system to upgrade specific hosts inside the cluster (so if you have a large cluster and would prefer the upgrade to span multiple change windows). 4) Aligning with other VMware ecosystem components. If you have integrated NSX-T, or Tanzu (or other VMware products that align with vLCM), you can use the vLCM framework to help streamline those upgrades to reduce the number of reboots to update more than just the VxRail stack.
How do I enable this?
To enable vLCM in the VxRail, it's quite simple. In 7.0.240 and later, there was a slight change to the VxRail updates screen inside the VxRail Manager plug in as you can see below:
We changed the first tab from "System" to "Compliance" - this is where you can see your daily compliance drift report for the system. We kept the options for internet and local updates unchanged, but we also added in the "Settings" tab. This is where you go to enable vLCM. Once you click on "Enable", the system will prompt you for credentials, do a validation that everything is in order and then change the underlying LCM engine to use API calls to vLCM in place of the VxRail maintained LCM engine.
That's it! This is the most streamlined way to leverage vLCM for your vSAN clusters - no need to configure any additional components.
Once the change has been made, you'll see that the system highlights that vLCM has now been enabled.
NOTE: Changing to the vLCM engine is a one direction change - you cannot go back once the change has been made.
Does this change the LCM experience? Now that you've enabled vLCM, what changes? NOTHING! That's right, nothing changes from the overall experience with regards to VxRail updates. You still use the same workflow (and make sure you generate that SolVe procedure). The key thing here is this helps provide additional options, but the overall flow is still the same. As a customer, the same upgrade composite package is still used, you still initiate the upgrade from the same workflow inside the plug in as well.
Performing Update with vLCM enabled This is mainly to provide the option to update non-VxRail components. For this upgrade, I did create an advisory report first. Here's a quick screenshot of what that report shows:
As you can see, this report give you a quick and easy glimpse into what will (and won't) be updated as part of the VxRail upgrade process. This isn't a required step, but it's highly recommended.
After the upgrade package has been fully loaded into the plug in, you will get a list of all the components in the upgrade.
You'll notice here you now have the "customize" or "scan" button at the top right. Clicking on "customize" is where you could supply the system with updated FW/Driver files for the FC HBA (if applicable).
Once the additional files are added, you can then continue with the upgrade by clicking on "next" in the bottom left of the previous screenshot. At this point, everything looks identical to an update with (or without) vLCM enabled and how VxRail has handled updates since the plug in integration to vCenter.
You're now ready to click on "Continue Update" and let VxRail Manager run the update non-disruptively, just like it has always done. When it's completed, you can go back to the compliance tab to verify the update completed successfully and you're now running your desired version of VxRail.
Closing Thoughts As you can see, we're continuing to bring flexibility to the operations of VxRail, enabling our customers to expand on their overall LCM functionality. While the traditional VxRail LCM engine is still quite relevant, in some use cases enabling the vLCM functionality does make sense as outline previously. In my opinion, if you don't have one of the use cases outline, I would continue to use the VxRail LCM engine. One last tidbit I like to highlight for customers is that VxRail Manager does trigger 2 alerts during the LCM of the cluster (regardless of the engine). There's one alert for "upgrade operation started" and the other is "upgrade operation was successful".
If you have any monitoring tools or SNMP email setup on your vCenter, these are two alerts that can help you monitor your VxRail upgrades without the need to watch vCenter during the update - just check you monitoring system for these alerts on each node to know when the upgrade started and when it completed!
Bình luận