Be Prepared for Using Pacemaker Cluster for SAP HANA – Part 2: Failure of Both Nodes
Big thanks to Fabian Herschel and Peter Schinagl from SUSE for proof-reading the blog.
First part of this blog is located here:
* Be Prepared for Using Pacemaker Cluster for SAP HANA – Part 1: Basics
Be Prepared for Using Pacemaker Cluster for SAP HANA – Part 2: Failure of Both Nodes
What happens when both cluster nodes will fail
Let’s start with Pacemaker Cluster running during normal operation. Colors are having following meaning – component is available (green), standby (yellow) or unavailable (red).
Figure 2 – Pacemaker Cluster during normal operation
SAP HANA on server hana43 is primary – this is visible by status PROMOTED, roles string containing “P”, sync state set to PRIM and LPT timestamp set.
SAP HANA on server hana44 is secondary – this is visible by status DEMOTED, roles string containing “S”, sync state set to SOK (meaning replication is healthy) and low “static” LPT value.
Now let’s assume that primary server will crash and is unavailable.
Figure 3 – Pacemaker Cluster after primary server failed
Secondary server will notice that primary server is down and since replication status is SOK it is able to initiate failover. Fencing operation will be executed to ensure hana43 server is offline and failover will be executed.
Figure 4 – Pacemaker Cluster after secondary server failover
When SAP HANA on server hana44 is promoted to new primary all cluster node attributes are updated –status is set to PROMOTED, roles string changed to contain “P” as database failover was executed, sync state was set to PRIM and LPT timestamp was set.
Note that cluster node attributes on primary server remain unchanged – this is because that server is unavailable. These attributes are stored locally on that server.
Now let’s assume that secondary server crashed while primary is still offline.
Figure 5 – Pacemaker Cluster after secondary server failed
Now both servers are offline but SAP HANA databases on both servers are configured to run as primary – this is also confirmed by cluster node attributes set that way.
How to (not) destroy your company data
Now imagine following scenario. You are on-duty System Administrator and you got called in the middle of night that SAP HANA is down and you need fix it. Still half-asleep you are logging to the servers listening to your boss explaining you over the phone how much money your company is losing every minute SAP HANA is down and how important it is to get SAP HANA up and running as fast as possible.
When you are finally there you see that both SAP HANA cluster servers are offline. To make it more obvious – this is what you see.
Figure 6 – Pacemaker Cluster state as System Administrator can see it
Since you are under pressure to fix SAP HANA ASAP you decide to fix primary first – after all secondary can be fixed later once we are back in business.
DANGER!!! Now you should stop and get fully awake. How do we know which server is “last primary”? Unless you got that information from some external monitoring system you have no way of knowing!!!
Let’s look what would happen if you would start wrong server. Let’s assume System Administrator checks the documentation and sees there that hana43 is supposed to be primary and decides to start it up first.
Figure 7 – Pacemaker Cluster after hana43 server was restarted
Once Operating System is rebooted System Administrator starts the Pacemaker Cluster. Since secondary server is still offline Pacemaker Cluster will be unable to retrieve LPT value from cluster node attributes of secondary server. Without LPT values from both server nodes Pacemaker Cluster will not start SAP HANA database and cluster node attribute status will be set to WAITING.
This protection from Pacemaker Cluster is called “restart inhibit”. It is there to ensure that SAP HANA is started only in case that Pacemaker Cluster can clearly determine which server is “last primary”.
DANGER!!! At this point System Administrator should stop and start thinking.
Let’s assume that our System Administrator is still half-sleep and he will be surprised why SAP HANA is still down and will start it manually.
Figure 8 – Pacemaker Cluster after SAP HANA on server hana43 was manually started
Once SAP HANA is started manually Pacemaker Cluster will detect it and will adjust cluster node attribute status to PROMOTED.
From the moment when SAP HANA was started all database updates are stored in SAP HANA database running on server hana43. However SAP HANA database running on server hana43 is not having all the data that was persisted after failover to database on server hana44 – see Figure 4.
By manually starting SAP HANA database our System Administrator caused logical inconsistency that will take incredible effort to fix.
Correct approach
Let’s see what is the correct approach how to deal with situations when both servers are offline.
If you are unable to clearly determine which server was “last primary” then you need to start both cluster nodes. Without access to both servers Pacemaker Cluster is unable to correctly determine which server was running “last primary” SAP HANA database.
Figure 9 – Pacemaker Cluster after both servers are restarted
Once attributes from both cluster nodes are available the Pacemaker Cluster will check which node is having higher LPT value to decide which database was “last primary”. Unfortunately this information is not written to SBD drive or anywhere else outside the local node so both nodes must be available for correct determination of “last primary” SAP HANA database.
Alternative approach can be used only in case that you are 100% sure which SAP HANA was “last primary” – maybe getting this information from some external monitoring system. In such case you can do exactly as described in previous section however you perform described steps on correct server.
First you restart “last primary” server (hana44), start Pacemaker and then manually start SAP HANA that will become primary database. Make sure to execute these steps on correct server.
Later you can restart the other server (hana43), start Pacemaker, register local SAP HANA as new secondary and cleanup resource to start SAP HANA as secondary database.
Please note that there is no protection that will prevent you from manually starting wrong SAP HANA database causing data loss or logical inconsistency. It is responsibility of System Administrator to start both nodes at the same time or correctly determine which database was “last primary”. http://bit.ly/2oNzWh5 #SAP #SAPCloud #AI
New Video Tutorial Series: Studio and Cockpit
Some things are vintage and some things are just old. While we were digging through the archives, we found one of our older videos and decided to dust it off and give it an update. Who says something old can’t be new again? And speaking of new, if you’re starting to learn about streaming analytics and trying to figure out how to create, run, or test a project in studio, this is the perfect video for you.
Ready for more good news? Silly question, I know. That’s like asking if you want the last slice of pizza. Anyways, the good news is that this video is part of a tutorial series. So, after you’ve learned the basics of creating and working with projects in studio, you can then learn how to use cockpit to monitor those projects. The bad news? You’ll have to wait for the end of November for the second video to come out. You know the saying: good things come to those who wait!
On the bright side, this blog does offer a sneak-peek of the second video. Here are the highlights of each video. Happy reading!
Part 1: Studio – Creating, Running, and Testing a Project
In part 1, we:
* create a project that filters data and writes it to HANA,
* compile and execute the project, and
* test the project by manually loading data to the input stream and checking the results.
Here’s a screengrab from the video demo showing us setting a filter:
Only values greater than 20 in the input stream will show in SAP HANA. After setting the filter, we add an SAP HANA Output adapter. Here we are configuring the adapter to write to SAP HANA:
We’re using the ‘hanadb’ service, connecting to the ‘SYSTEM’ schema, and writing to the target table in SAP HANA, ‘TABLE_TEST’.
After running the project, we test it by manually loading two rows into the input stream: the first with a value below 20 (9), and the second with a value above 20 (21):
Because of the filter, only the second row we added shows in SAP HANA:
That’s the gist of the first video tutorial. Check it out for yourself here. Once you’ve completed the studio tutorial, you’re ready to start monitoring streaming in cockpit! (or you will be once we post the video later this month. Stay tuned!)
Part 2: Cockpit – Monitoring Streaming Analytics
In part 2, we monitor:
* streaming analytics and general system behavior, using the Monitoring and Administration section, and
* the streaming project we created in part 1, via the Streaming Analytics
Here’s a screengrab from the video showing the Monitoring and Administration section:
It shows the behavior of the resource you’re connected to, including:
* overall database status,
* number of alerts, and
* memory, CPU, and disk usage.
If you select Show all in the Alerts tile, you can view and configure alerts. In the video, we look at the Inactive Streaming applications alert:
We show you how to:
* set thresholds for prioritized alerting,
* add email recipients, and
* trigger alert checkers.
After monitoring system behavior, next, we monitor the project we created in the previous video, ‘testproject’. We look at the System, Network, Streams, and Adapters tabs. In the Streams tab, you can view QueueDepth and RowsInStore. Here’s a screengrab from the video:
PriceFeed and VWAP have 99 and 26 records in their log store, respectively. If you select a stream, you can see more detailed info, including rows/transaction throughput history.
Finally, in the Adapters tab, you can view the adapters in the project and their status:
And that’s all she wrote!
So, whether you’re a newbie looking to get your feet wet or a wily veteran just looking for a refresher, be sure to check out our video tutorial series on studio and cockpit. Part 1 is already available, and part 2 will be out very soon. Also, if you have any ideas for more videos we could make, let us know in the comments below!
For more on managing projects in studio and monitoring streaming in cockpit, check out:
* the Working with Projects in the Streaming Plugin for SAP HANA Studio section of the Steaming Analytics Developer Guide, and
* the Managing Streaming Analytics with SAP HANA Cockpit section of the Streaming Analytics Configuration and Administration Guide, as well as the SAP HANA Cockpit Administration Guide. http://bit.ly/2Bz1J7V #SAP #SAPCloud #AI
How Four Weeks of Design Thinking Offer Better Digital Transformation
Digital transformation can do a lot to help the mining industry, such as improving onsite operations and decision making. Design thinking can optimize those improvements — if properly utilized.
“The mining sector has embraced the introduction of new technologies, which have resulted in significant productivity benefits,” professional services firm EY stated in a recent mining update. “But there is the gap between the potential from digital transformation and the poor track record for successful implementations.”
Metals and mining corporation Vale has a compelling story of a successful implementation — that only took four weeks. The result was a completely new process, according to Vale’s IT innovation manager at SAP Leonardo Live in Chicago this month.
Management Assets Across a Global Supply Chain
The mining industry is on the upswing, enjoying growth in the U.S., Europe and China, according to EY. Vale has been growing too, investing more than $120 billion during the last decade, and expanding to 27 countries, according to Vale’s Helio Mosquim.
This growth brought a lot of challenges, such as managing new assets across the globe, according to Mosquim; intelligent maintenance would help the company increase up-time, boost productivity and cut costs. Supply chain was also a big concern for the Rio de Janeiro-based multinational, which produces iron ore, copper and more.
“Imagine producing ore in the middle of the Amazon, and transporting it all the way to the ports, and going through the distribution centers in Malaysia and Oman — and on to China,” Mosquim said. “Optimizing production, optimizing logistics and shipping … it’s a big challenge for us to optimize the whole chain.”
Saving Time by Automating Critical Tasks
Workforce effectiveness was another challenge for Vale, which has about 110,000 employees — about 22,000 of whom are SAP users, according to Mosquim. Inventory is about $1.6 billion of Vale’s $11 billion annual spend, so the company automated purchasing processes to make them more intelligent.
For example, maintenance workers used to ask an SAP user to create a purchase requisition before acquiring a new part for damaged equipment, according to Mosquim. This completely manual process often overlooked parts that were already available (perhaps the previous shift ordered the same thing), and finding the missing information required searching through multiple screens.
These steps often resulted in a lot of redundant work and wasted time.
“Between 25 to 40 percent of rejections of all the purchase requisitions [occurred] because [the part] was either available on contract or in inventory,” Mosquim said. “And the equipment was out there waiting for the part.”
A “Totally Different Approach” in Just Four Weeks
Vale only expected to enhance its legacy platform, as opposed to taking full advantage of SAP innovation services. But SAP helped Vale connect APIs directly to its system and use everything in the cloud — and implement it quickly.
“We set up a plan to innovate in four weeks,” Mosquim said. “And that was an amazing experience.”
Vale put its procurement team through an SAP design thinking session to sort major pain points. They had a draft prototype by week one; by the following week, they had feedback — and were making adjustments.
“The result was very effective, very impressive,” Mosquim said. “When we saw the totally different approach, we were very confident that it was going to be able to deliver.”
Find Your Key
“We had an opportunity to have a totally new process … we had other managers come in saying, ‘We would like to invest in this innovation,’” Mosquim said. “In the end, we got a little bit from each solution, and we put it in the cloud.”
Design thinking helped Vale digitally transform its supply chain, asset management, workforce effectiveness and more. Digital technologies — including Internet of Things and machine learning — could also help mining companies improve safety, optimize site-wide operating systems and more, according to a smart mining conference last week.
“You can only truly achieve a sustainable productivity improvement by adopting an integrated end-to-end business approach from market to mine,” as the EY mining update stated.
Design thinking could be your key to a successful implementation.
Follow Derek on Twitter: @DKlobucher
This story originally appeared on Business Trends on the SAP Community.
Top image via Shutterstock http://bit.ly/2BA7zpH #SAP #SAPCloud #AI
