In my first article of this series of four, 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.
As usual, before starting any action and to guaranty the success of the exercise, it is important to do some reading on our subject. Here is a collection of guides, references, and SAP Notes to be reviewed.
These references differ from the previous article, so take the time to review 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.
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
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
The maintenance process semi-automated ? for SAP HANA is very well integrated. The sequence flow helps to control the dependencies with the cluster resources that need to be placed on the maintenance mode to avoid uncontrolled failover, but also by taking the SAP Hana replication action.
In my next article, I will talk about how the Cost Optimized scenario (QA/PRD) can be leveraged by the SLES HA feature.
Part 1: Use SLES 15.2 To Automate SAP HANA High Availability
Part 2 : current
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.
Some references
As usual, before starting any action and to guaranty the success of the exercise, it is important to do some reading on our subject. Here is a collection of guides, references, and SAP Notes to be reviewed.
These references differ from the previous article, so take the time to review it.
SAP Notes
- 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Application 15
- 1948334 - SAP HANA Database Update Paths for SAP HANA Maintenance Revisions
- 2115815 - FAQ: SAP HANA Database Patches and Upgrades
- 2469025 - How-To: Upgrading to SAP HANA 2.0
- 2372809 - Mandatory Preparation Steps for Upgrading a SAP HANA 1 System to SAP HANA 2
Guides
- SUSE Linux Enterprise Server for SAP Applications 15 SP2
- SAP Hana Administration Guide 2.0 SP5
- SAP HANA Server Installation and Update Guide 2.0 SP5
**Note**
- To run SAP HANA 1.0 on SLES 15.2 you need to be on revision 122.31 minimum, do not use the same revision highlighted in my article for production usage.
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
Conclusion
The maintenance process semi-automated ? for SAP HANA is very well integrated. The sequence flow helps to control the dependencies with the cluster resources that need to be placed on the maintenance mode to avoid uncontrolled failover, but also by taking the SAP Hana replication action.
In my next article, I will talk about how the Cost Optimized scenario (QA/PRD) can be leveraged by the SLES HA feature.
Series
Part 1: Use SLES 15.2 To Automate SAP HANA High Availability
Part 2 : current
- SAP Managed Tags:
7 Comments
