Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is SAP HANA system replication and in this video
we will discuss the active/active read-enable feature.
Hi, I am Denys van Kempen.
In the overview video of this series, we looked at high availability concepts
and the importance of the recovery period objective and the recovery time objective:
RPO and RTO.
So, if you are not familiar with these topics, you might want to take a look at this video.
In short, the acronyms cover two important questions.
How much data loss are you willing to accept?
and, how long can your business stay offline?
Planned, due to maintenance,
or unplanned, due to small failures or big disasters.
System replication allows you to replicate, to make an exact copy, of a SAP HANA system
and keep it synchronised.
This will give you the best RPO and RTO
- in other words, no data loss and near-zero down time -
but with one slight disadvantage: cost.
If you want no downtime and no data loss, you need to keep a backup system up and running.
So, that’s twice the cost of hardware and twice the software licenses: operating system, HANA.
Ouch.
Of course, you could tweak your backup system a bit, downsize it, and re-use the memory
now available to run a development, QA or training system on the box
and keep your fingers crossed that nothing goes wrong.
You get some value back for your money but increase the risk that, if shit happens,
your downtime will be longer.
Re-using the backup system for other purposes, in other words, will make the RTO go up.
It is still the same dilemma: do you want it good, cheap or fast? Pick two.
Well, guess what?
This hard nut has been cracked for us in SAP HANA 2.0 with the active/active read-enabled
system replication feature.
With active/active, both the production and the backup system are active:
up-and-running and accessible.
The secondary system can be used for all the heavy-duty, big-impact, long-running, OLAP-type
queries, that read a lot of data but don’t change any.
This has two advantages;
not only are you actually using the backup system for production purposes
- it is no longer siting idle waiting for disaster to strike -
but also, because you can offload some of the resource hungry complex analytical queries
from the production system to the backup box,
you actually improve performance on the production site.
Performance, or throughput; as the production system has to spend less time on analytics,
it can serve more transactions or run them even faster.
The beauty is that this keeps the convergence of OLTP and OLAP, transaction processing and
analytical queries, which makes SAP HANA unique, completely intact.
We still have a single system, a single view on the data, all in real-time.
With active/active read-enabled system replication, not only are you protecting your production
system from disaster and enable near-zero downtime for maintenance but also you can
now use the processing capacity from the backup site to improve the performance on the primary site.
That’s a pretty good investment, if you ask me.
So how do we set this up?
I am connected here to the SAP HANA cockpit.
The database is the system database for our primary site, our production site.
And if we then scroll down a bit, we have a tile for system replication.
Click the tile to open the configuration page.
System replication is not yet enabled for this system.
Then we have two options.
Here, in the top right.
We can either just enable this system as primary.
That’s the first step.
You give the tier 1 site a name and that’s it.
Behind the screens the hdbnsutil tool will then be executed
with the sr (system replication) _register flag.
In case you are not familiar, hsdbnsutil, or HANA database Name Server utility,
is sort of the Swiss army knife for all HANA landscape operations.
It is a command line tool, so you can also script and automate system replication operations.
Anyway, here we are letting cockpit run the commands for us on the linux host.
Second step would be to the secondary site (tier 2) and register that system as well,
and then we could setup replication.
But, if we return to our page and click the dots, we can also select
Configure System Replication.
Now we register both tiers in one go and enable replication directly.
So, this will make it a bit easier for us.
Note that you could also add a tier 3 system here.
You would use this, if you want add support for system replication to a remote location
in another data centre, or even in a completely different region.
The replication mode would be set to asynchronous then, so there is no impact on performance.
Let’s cancel tier 3.
For tier 1, enter the site name.
This is just a label.
I will enter the name of the primary data centre of the HANA Academy at Schiphol, here
in the Netherlands and then for tier 2 use Scheveningen.
I don’t recommend to use names like ‘production’ and ‘backup’.
As the whole idea is that you can easily switch from tier 1 to tier 2.
This is what’s called the takeover.
For when you want to upgrade your systems, for example, or replace some hardware
(near-zero downtime) and when you are done, you can switch back again.
If you use names like 'Production' and 'Backup' or 'Primary' and 'Secondary', then after the switch
the site with name 'Production' will now have the backup role and the site with the name
'Backup' or 'Secondary' will now have the production or primary role.
Not a good idea.
This will get everybody confused.
Just use names that are fixed and clear.
The location of the data centre, for example, would be a good choice.
I would not recommend using Greek Gods, planets, or your favourite cocktail for the same reason.
Then, select the secondary system host.
If you have a lot of hosts registered, you can search for them here.
I have only one, and I have called it Scheveningen.
The System Description is the one you entered when you registered the system as a resource
in the Cockpit Manager - again, there are videos on this topic if you want to learn more.
Note the check box: ‘The system has to be offline to register it as a secondary’.
So, if it is still running, tick the box to let cockpit stop it.
Well, as mentioned, hdbnsutil will do this for us.
Then, select the replication mode.
We have discussed this in our overview video.
Synchronous in memory is the default.
This only requires the log buffer to arrive in memory on the secondary site.
It is the fastest.
The setting Synchronous also requires the log buffer to be persisted; written to disk
that is, to the redo log
and Asynchronous, as mentioned, for remote data centres or unreliable networks.
Again, we got this covered in a video.
You can also look it up in the online documentation, in case you are bit rusty on the topic.
Then, select the operation mode.
Log Replay is the default.
Introduced in HANA 1.0 SPS 11.
Before that, we only did Delta Data Shipping.
This means that at regular intervals, a bucket of data changes would be send over the network
from tier 1 to tier 2.
If you looked at network statistics, you would see these peaks.
With Log Replay, you get a smooth graph as changes are send as they occur.
Apart from better performance this also provides a shorter RPO, as there is no delay.
Here you want to select: Log Replay - Read Access.
This is new HANA 2.0 feature active/active, read enabled.
This will start up the secondary site and make it available for read-only queries.
In the other modes, the tier 2 will not be open.
Then, you can select whether Data Shipping should be initiated or not.
Default is no.
This setting corresponds to the hdbnsutil parameter ‘force_full_replica’.
Typically, a snapshot or recent backup will have been restored on tier 2, so you don’t
have to push the entire database over the network.
Might save you some time.
Note that ‘Start secondary’ is selected.
Then select ‘Configure’ and replication will be enabled.
There are a couple of prerequisites; nothing complex.
You can look them in the Administration Guide.
The systems need to be same, same System Identifier (SID), same instance number, same everything
and this includes the system PKI SSFS store and key file.
If you are not familiar with terms like PKI and SSFS, no worries.
There are videos on this topic in the Academy.
Well, as you can see, system replication has already been activated.
We have red boxes because not all data has been replicated, of course.
This takes some time.
In our test system, there is hardly any data, so if we return to the Home page, System Replication
tile and select it again, we can see that the boxes are green now.
Both systems are synchronised.
Operation mode LOGREPLAY_READACCESS.
Select a service to get more detailed information about log positions, savepoints, the size
of the data replica, and any backlog; currently 0 microseconds.
Then, Network Site 1 to 2 will show us a graph when historical data is available and we get
some information about Log Retention and Log Replay Tier 2.
Then finally, you can also measure your network speed here with a ping, or by sending 1, 10,
100 or 1000 megabytes over the network.
If we return to the overview page of SAP HANA cockpit, we will be kept informed about the
status of system replication and any alerts in real-time.
Let’s do a quick a test to see how this works.
Let’s open the SAP HANA Database Explorer for SAP HANA Cockpit.
Yes, that’s the full name.
Select our primary system, Schiphol, and open a SQL prompt.
I will paste in some code here.
Very basic.
Just create a table, insert a row, and do a select.
Well, that works.
If I now open my secondary system, Scheveningen.
Expand the catalog.
Go to SYSTEM.
Select tables.
I will see TEST appear.
It is real-time system replication, as mentioned.
There is no delay.
Double-click the entry and the data definition appears with a data preview.
So, all is well.
Let’s double check and open a SQL prompt to the secondary site.
Paste in our code.
Run the select.
A value is returned.
So we have read access.
Run the insert.
An error is returned.
Feature not supported.
Writable statement not allowed in read-enabled replication.
Thank you.
That’s exactly what we wanted to see.
Test succeeded.
OK.
So much for active/active read enabled.
SAP HANA System Replication is documented in the SAP HANA Administration Guide.
You can read this guide online or download it, free of charge, from the SAP Help Portal
on help.sap.com, under SAP HANA Platform.
Make sure you select the correct version.
It is in the chapter Availability and Scalability.
You can find more video tutorials on our YouTube channel.
If you would like to be informed about new video tutorials, please subscribe to our channel.
You can connect with us on LinkedIn or follow us on Twitter, as well for updates.
And we also have a page on Facebook and Google+.
If you are watching this video on YouTube, do not hesitate to leave your comments to
the video page and, if you like, give us your vote on his video.
Thank you for watching.