Search
The Best Hyperconverged Infrastructure (HCI) for Enterprise ROBO, SMB & Edge

Updating StarWind VSAN Windows application on a 2-Node Hyper-V Cluster using SCCM

  • Maintenance
  • March 13, 2021

This article is specifically recommended for multi-location deployments, providing a detailed walkthrough to successfully update StarWind VSAN on a 2-Node Hyper-V Cluster using the SCCM.

Description

In case you have multiple locations with Failover Cluster running StarWind VSAN as a shared storage, installing updates for StarWind VSAN might take a lot of time and effort, thus it makes sense to automate it. This article provides a guide on updating StarWind VSAN using the System Center Configuration Manager (SCCM) package in a 2-node Hyper-V cluster, recommended for cases with distributed multiple locations.

Disclaimer: StarWind Support does not write scripts and SCCM package on demand. Custom script troubleshooting is not supported. The script provided in this article is as an example and can be customized by the end-user according to his needs.

Prerequisites: Before proceeding with the update, ensure the following prerequisites are met:

  1. Backup: Conduct a comprehensive backup of Hyper-V virtual machines and critical data to mitigate potential data loss during the update.
  2. System Center Configuration Manager (SCCM): Confirm that SCCM is properly configured and operational in the multi-location environment.
  3. StarWind VSAN Update Package: Download the latest StarWind VSAN update package from the official StarWind website, compatible with the current version.
  4. Cluster Health Check: Verify the health and status of the 2-Node Hyper-V Cluster across all locations to address any issues before initiating the update.

To avoid production interruption, StarWind VSAN cannot be installed on both cluster nodes simultaneously and must be updated in a one-by-one manner. The update script is designed to minimize the probability of production interruption and is intended to execute the update only on the local node with additional verification steps.

Assuming the above, the package has to be deployed to the SCCM collection which consists only of the “first” nodes in the cluster, like SW-HCA-01. Once it is executed successfully ( the script execution time could be up to 5 hours) the same package can be deployed to the “second” node in the cluster, like SW-HCA-02.

It is recommended to deploy the package to smaller collections and update nodes by clusters to avoid cases when in the same cluster the first node is running on the latest StarWind VSAN build, while the second one is running on the old build for a long time. It’s better to keep the same build for the partner nodes to avoid possible differences that could appear in future builds.

NOTE: Please keep in mind that it’s mandatory to test the StarWind VSAN update via SCCM on a pilot group before running it for multiple locations. The post-deployment check must be done to confirm that the StarWind VSAN version is updated, StarWind HA devices are synchronized and cluster nodes and roles are up and running.

 

SCCM Package description

Before deployment to the selected collection, the SCCM package should be created. The package consists of two files:

* starwind-v8.exe – StarWind VSAN installer. The actual version can be downloaded using this link (file name unchanged): https://www.starwindsoftware.com/tmplink/starwind-v8.exe

* swupdate.ps1 – PowerShell script which performs preparation steps, StarWind VSAN update, and post-install actions.

Script description

While executing on the StarWind node, the script swupdate.ps1 is writing a log file swupdate.log which is located in the same folder. The log file location can be changed if required, by changing $LogFile variable.

While installing, StarWind VSAN writes its own log file vsan_update.log which is also located in the folder with the script.

The script swupdate.ps1 performs the following actions:

  • check if there is a pending reboot state on the server.
    There are a lot of registry keys to check it, but most of them were commented on because in most cases StarWind VSAN installation it’s not so important. There were only the most important ones uncommented. If a pending reboot is detected, the script will exit with code 3001.
  • check nodes state in the cluster – both nodes must be in the online state. If one of the nodes is not in an online state, the script will exit with code 3002.
  • check the ISCSI sessions state on the local node. If some session is not connected or not persistent, the script will exit with code 3003.
  • kill StarWindManagementConsole process. It’s required to run the StarWind VSAN installer. If the process is left running, the script will exit with code 3004.
  • update the StarWindX PowerShell module, using the installer file. It has to be installed separately to avoid possible issues later. If the installation is failed, the script will exit with code 3005. To investigate the failure, vsan_update.log can be read additionally.
  • check StarWind devices synchronization state on both nodes. If some device is not synchronized, the script will exit with code 3006.
  • Identify a partner cluster node and move cluster resources to it. If failed, the script will exit with code 3007.
  • pause the local node in the cluster. If that operation is not successful, the script will exit with code 3008.
  • update StarWind VSAN on the local node, using the installer file. If the installation is failed, the script will exit with code 3009. To investigate the failure, vsan_update.log can be read additionally.
  • check StarWind devices synchronization state on both nodes after the synchronization. If some device is not synchronized, the script will check the synchronization 30 times every 10 minutes until all devices are synchronized. It was implemented to make sure that devices are synchronized after the update in case full synchronization occurs. If some devices are not synchronized after 5 hours, the script will exit with code 3010. The number of checks and interval can be changed if required, by changing $timeoutSeconds and $timeoutCount variables.
  • resume local node in the cluster. If that operation is not successful, the script will exit with code 3011.
  • If completed successfully, the script exits with code 0.

Script body:

 

Useful links

The recent StarWind Virtual SAN build can be downloaded here: https://www.starwindsoftware.com/starwind-virtual-san#download
The complete Release Notes can be viewed by following this link: https://www.starwindsoftware.com/release-notes-build

Request a Product Feature

To request a new product feature or to provide feedback on a StarWind product, please email to our support at support@starwind.com and put “Request a Product Feature” as the subject.

Hey! Looking for a cost-effective, high-performance, and easy-to-use hyperconverged platform?
Taras Shved
Taras ShvedStarWind HCI Appliance Product Manager
Look no further! StarWind HCI Appliance (HCA) is a plug-and-play solution that combines compute, storage, networking, and virtualization software into a single easy-to-use hyperconverged platform. It's designed to significantly trim your IT costs and save valuable time. Interested in learning more? Book your StarWind Virtual HCI Appliance demo now to see it in action!