What is invloved with a VPSA upgrade?
The need for an upgrade could be to move the VPSA onto a newer release for a new feature or fix. Or perhaps to change the Engine size and resource capabilities available to your workloads if your workloads have increased from the initial Solution recommendations.
Overview
A VPSA has two Virtual Controllers(VCs), one VC is active and the other is passive or standby. Each VC is hosted on a separate Storage Node as part of the VPSAs High Availablity model. Should there be a problem with the Storage Node hosting the active VC then the standby VC is promoted to active and the VPSA is "failed-over" and storage activites move to run from the new active VC.
Upgrade Process
Here we see two physical Storage Nodes, each running several VPSAs. We have a DEMO VPSA with it's active VC shown in red on Node 1 and the standby VC on Node 2 shown in blue.
Let's walk through the DEMO VPSA being upgraded from an old software release to a new release.
______________________________________________________________________________
When a VPSA upgrade is actioned; the first step is to remove the old Standby VC and then recreate this using the new software image. The IO engine size - ie: the vCPU and RAM resources allocated will remain the same ( unless an IO Engine change has also been requested).
______________________________________________________________________________
With the DEMO standby VC now upgraded; storage services transfer from the active VC - promoting the the standby to our new active VC ie: we failover from the active to the standby. During this period we temporarily freeze IO to the VPSA.
This failover and freeze in IO typically happens within 30 to 40 seconds for pre 21.07 releases and from 21.07 is sub 30 seconds.
______________________________________________________________________________
With the upgrade now applied to your active VC your clients can resume working as before, however in Zadara terms we are not quite finished. We must now repeat the above process on the ex-active VC hosted on Node 1 to ensure that both VCs are at the same software release or in the case of an engine change that the same engine size (vCPU and RAM) resources are set.
This may take another 10 to 15 minutes, but is at this point completely transparent; the storage services are already active on the upgraded VC and data I/O is flowing.
______________________________________________________________________________
The end status after upgrade is a reverse of what we originally had, the active VC is now hosted on Node 2 and the standby is on Node 1.
- Software release upgrades for a VPSA might be recommended for several reasons, but usually it will be to ensure that you are on the latest supported software version with the very latest security patches and features.
- Engine change upgrade recommendations tend to relate to increased workloads on the VPSA which necessitate additional RAM and vCPUs. Engine upgrade could be due to expansion, where a higher engine size is required to cater for additional drives.
- We recommend periodic VPSA checks and reviews with the Solutions Architecture and Account teams so that you always have the most optimal configuration. The version in use should be no more than 2 major releases older than the latest release.