SAP HANA Cost-optimized – An alternative Route is available
Why should I change my route?
Sometimes the direct way could end up in dead end. In such cases an alternative route is needed to come to the desired destination. What does that mean for my SAP HANA cost optimized scenario? Where is the possible dead end? In some installations we have seen that the SAPDatabase resource agent using the SAPHOSTAGENT framework could be lead into configuration problems according to
database users, database permissions and user secure store keys. But we have an alternative to control SAP HANA much more easy and independent from such database related objects. It’s the well known SAPInstance resource agent. It could be used for SAP HANA Scale-Up systems, which could completely be started and stopped with HDB start and HDB stop. Internally HDB uses sapcontrol to start and stop the database and that is exactly what SAPInstance is doing for
What needs to be changed?
Follow our best practice about the SAP HANA cost optimized scenario. You just need to adapt to use SAPInstance instead of SAPDatabase. This – of cause – also forces the change of the parameters of the cluster resource. Let us explain it by example. First we have a look at the original SAPDatabase resource mentioned in the best-practice guide:
primitive rsc_SAP_QAS_HDB20 ocf:heartbeat:SAPDatabase \ params DBTYPE="HDB" SID="QAS" InstanceNumber="20" \ MONITOR_SERVICES="hdbindexserver|hdbnameserver" \ op start interval="0" timeout="600" \ op monitor interval="120" timeout="700" \ op stop interval="0" timeout="300" \ meta priority="100"
We change the resource type to SAPInstance and replace the params DBTYPE, SID and InstanceNumber by the parameter InstanceName:
primitive rsc_SAP_QAS_HDB20 ocf:heartbeat:SAPInstance \ params InstanceName="QAS_HDB20_sapqasdb" \ MONITOR_SERVICES="hdbindexserver|hdbnameserver" \ START_PROFILE="/usr/sap/QAS/SYS/profile/QAS_HDB20_sapqasdb" \ op start interval="0" timeout="600" \ op monitor interval="120" timeout="700" \ op stop interval="0" timeout="300" \ meta priority="100"
Arrived at destination
In the resulting cluster the resource SAPInstance controls the actions start, stop and monitor for the non-productive SAP HANA database. Because SAPInstance uses sapcontrol to start, stop and monitor the database. The solution does not longer need database users, special database permissions and user secure store keys for the non-replicated SAP HANA. So now we have the “SAP HANA Cost-Optimized Scenario” optimized. Please also have a look at my other blogs like Let’s flip the flags! Is my SAP HANA database in sync or not? Also my team colleague Bernd Schubert has written interesting blogs about SAP HANA. My colleague Lars Pinne has written about the newest improvements for the Cost-Optimized scenario in his blog “SUSE HA for SAP HANA scale-up cost-optimized improved“. The setup guide SAP HANA System Replication Scale-Up – Cost Optimized Scenario for SLES for SAP 15 describes it step-by-step. Finally enjoy our blog posts with Tag: #TowardsZeroDowntime.
hi good day
I am implementing this solution.. however i notice that when I failover is produced, the cluster is not able to stop the resource for no productive SAP HANA database automatically. Is possible that you can share the constraints in order to tigger this event?
If that is for a productional system please open an SUSE support ticket. If all our rules (constraints) are applied it should do a takeover
Details are in the setup guide and in the blog. Also the priority for cost-opt is to FIRST try to solve that locally and only if not possible do a takeover.
This is because the time to get the non-SR system down takes long.