I have talked about how SLES HA Automation process can really help to build and deploy an SAP HANA environment highly available. Let’s continue to explore SLES 15.2 capabilities for SAP HANA platform and more.
For this second article, I will talk to you about how SLES HA Cluster Update for SAP HANA can be leverage for nZDU (upgrade/update). By using this process, SLES gives the ability to orchestrate your SAP HANA maintenance in an HA environment, fully guided and in the right sequence from a cluster point of view.
What and how to articulate it?
This particular feature can be used specifically for SAP Hana in 2 scenarios, the first one is in the case of an update while the other one is if you perform an upgrade from SAP Hana 1.0 to 2.0. But as mentioned in my previous article, you will need to deploy on both servers the yast2-hana-update package because without it you will not be able to follow the process.
Before to run the tool
SLES really make the procedure easy to follow, however, not the entire sequence is automated and we still have some manual work to do 😉
Before to run execute the process, make sure to create the key “SRTAKEOVER” in your user store
Execute the procedure
From the secondary node (slave) yast2 you need to be executed to start the process by selecting “SUSE HANA Cluster Update”.
Once started, the current topology of the SAP Hana cluster will show the available instances, you may probably ask why, so think about the cost-optimized approach (I will cover it later)
Here, if you need to run an upgrade from Hana 1.0 to 2.0 you will need to check the box, this will basically copy the PKI SSFS keys file from the secondary node where I execute the procedure, to my primary node.
For the current purpose, I will run an update from 122.06 to 122.33, so I will not check the box.
The other point is if you do have a remote server where you store media, you can provide the server://shared/location to be mounted on your host
Once validated, the plan will show the step to be executed on the resource to put the cluster in maintenance mode and thus avoid any failover action.
Once in maintenance mode, I can check the resource state at the OS level by running the “crm status” command. The cluster resources should show “unmanaged”
At this stage, Hana can be updated on the secondary node
When Hana update is completed, the procedure can continue by moving the VIP and taking over the resource on the secondary node
Now the primary node is ready to be updated with the option –hdbupd_server_nostart to avoid the primary node to be stopped again before it can be registered as the secondary.
Hana is updated on the primary node, so you have two choices, keep the secondary as is so it will become the master or clicking on “Reverse” to come back to my original state.
Since I’m running an HA I’m fine to stay on the secondary node, but it’s a personal choice.
The cluster will now come back to its normal state.
The process will take some time until the synchronization is completed, as a summary, I can see both of my Hana system updates to 122.33 and online
At the OS level, I can see that my resources have been promoted to the second server (hanadb03)
And finally, I will run two commands as hb0adm to check the replication state and status
No comments:
Post a Comment