Moving Through the VxRail Cluster Life Cycle
Tue, 01 Nov 2022 13:29:21 -0000
|Read Time: 0 minutes
This is the third article in a series introducing VxRail concepts.
The last entry in this series discussed Continuously Validated States and the benefits that come with having new cluster states tested before they ever arrive or are implemented. This article is about movement. More specifically, movement to new cluster states with new software, firmware, and drivers. If Continuously Validated States help provide known-good destination states and create our map, then the VxRail enhanced update process creates the vehicle used to move from one state to the next. Let’s dive into some of the specifics that illustrate the advantage of the VxRail process over traditional update processes and vLCM.
Single-bundle updates
The first step in an update cycle is to define a new state, so let’s discuss that first. Whether updating a single server or an HCI solution you built yourself, the first step in building this state is identifying all the hardware so that nothing gets missed in the cycle. Once all hardware is accounted for, administrators can begin to collect the updated driver and firmware packages. Depending on the volume of hardware, updating a single node might well require around 15 different packages to touch all the system software, drivers, and firmware. If the environment has different hardware among nodes, then this task becomes more complex with more components to account for.
Where administrators would previously construct an update themselves, VxRail users perform updates by using prebuilt packages. These prebuilt packages contain the components to move a cluster to its next Continuously Validated State and are intended to service the VxRail family, as opposed to a specific cluster. This means that whether you’re primarily working with smaller clusters with different hardware or large, monolithic clusters, you can use a single bundle to bring the entire cluster up to date. In addition to the individual update packages, the update also carries a new Continuously Validated State with it. This frees up IT resources to complete more important tasks that have a greater business impact.
Life cycle management prechecks
In addition to compressing updates into single packages, the VxRail update process performs a series of readiness prechecks to ensure that the cluster is in a state where it is ready to accept an update. These tasks are examples of VxRail automation that obviously wouldn’t be present in an IT-designed HCI solution or traditional infrastructure. Let’s talk about what some of these prechecks are and what they can do for you as a user.
The precheck process examines more than 200 different items, so I won’t go into all of them here. However, I would like to highlight a few areas. Let’s start this part of the discussion with hardware and work our way up. Hardware examination runs a full range of exams to confirm cluster health. For example, physical checks are performed on memory to look for memory bit errors that could cause a host to crash during the update. Some other examples include inventory checks, to confirm that the hardware profile hasn’t changed to include components that our bundles can’t address, such as an unsupported NIC or another PCI device.
Prechecks extend to software versions as well. Software prechecks examine items such as whether a host successfully entered maintenance mode or if services are in the proper state to begin an update. These prechecks, in some cases, replace user interaction, as with the ability to cycle hosts into maintenance mode.
Change analysis
After the prechecks are complete, VxRail shows users all the hardware and software affected by the update. This helps users understand exactly what is changing in the environment. As indicated in the screenshot, this information also helps identify the specific changes to the cluster.
Launching an update
Users have two options for launching an update—they can update the cluster immediately, or they can schedule it to run at a planned time. A lot of customers I worked with liked to schedule their updates to run over weekends. Users might think that this is largely analogous to VMware’s vLCM. vLCM does offer automation benefits, but users must still create their own cluster profiles, create their own images, and perform their own testing. So, while vLCM certainly offers some automation advantages, VxRail takes this further by enhancing the update package collection and application processes. VxRail clusters can also be updated through the API or with CloudIQ.
Conclusion
Hopefully, this has helped illuminate some of the value that VxRail can provide to the cluster update cycle. Users get the benefit of consolidated update packages, saving the time and effort of collecting these files themselves. An in-depth series of prechecks then combs through cluster hardware and software to confirm that a cluster is in an ideal state to accept update packages. Once this is complete, change analysis scripting specifies the changes to be made to the environment. Finally, with the application of the update, VxRail sequentially moves node to node and cycles each through the update list, placing the nodes into maintenance mode and having vMotion move workloads to other available nodes. Taken together, these services, which are under continuous improvement by VxRail Engineering, help to make the update cycle as easy as possible.