Part 1/2 – Failover and High Availability for SAP Cloud Connector (using Docker)

Nowadays, business transaction are more likely to happen in real time, directly connected to KPIs displaying results at the same time transactions are being processed. People, gadgets and several types of devices are all connected in architectural models, and batch processing at the end of the day has being deprecated over the years.

When working on productive scenarios, we have to make sure business transactions won’t fail, and systems should be up and running in the whole time (something close to 99.999% of the time). The lack of connectivity may lead negative impacts, compromising the business and advantaging competitors slightly.

3. Use case

A certain company has decided to increase their business by moving existing process (and creating new ones) to run in the cloud – SAP CP specifically. The main point is to reduce the distance and time of transactions between business partners and the company itself. Business aims for more real time operations in order to create more accurate KPIs, so the entire system architecture should be prepared enough for unwanted situations.

Solution architect has the role to design a architecture for this business scenario. Here are a few points of attention:

• Business aims for real time operations;
• Partners may want to exchange information in any time (high availability);
• Cloud operations are getting more frequently;
• The use of on-premise systems is necessary;

As SAP CC was the tool chosen for establishing secure connection between on-premise and cloud, creating reliable access to both on-premise and cloud landscapes consequently. The solution architect identified a high risk in case of the server suddenly goes down, and a feasible approach is to define a redundancy instance for SCC.

Based on the assumptions above, the following diagram was propose in order to handle the redundancy layer for SAP Cloud Connect master <--> shadow.

Return to the Glossary ▲

4. Sizing recommendations

Now that the scenario is well defined, it’s time to provide machines for both SCC master and shadow. This section gives you the sizing of very small instances (type: S[small]). By default, instances type S are able to load up to 1 million requests per day. If you’re looking for a more structured type, capable to load more requests daily, you should take a look at SAP Cloud Platform Connectivity – Sizing Recommendations.

We’re going to use Docker for the machine provisioning in two separated hosts. According with SAP, each Master and Shadow should be treat differently, and consequently both machines should have specifically characteristics.

At the end, the two machines are suppose to run in different hosts. For this example, both scc-master and scc-shadow are in my personal computer. Have in mind in real cases both should be located on different servers, otherwise high availability won’t work (believe me… I already saw master and shadow at the same server in productive scenarios…)

(Optional) You might want to configure the IPs on /etc/hosts.

Return to the Glossary ▲

4.1 Sizing for the Master Instance

docker-machine create scc-master -d virtualbox \
--virtualbox-cpu-count "4" \
--virtualbox-disk-size "10000" \
--virtualbox-memory "4000"

4.2 Sizing for the Shadow Instance

Basically, shadow instance does not share same capabilities than Master, so standard functions might not be used though. Compared with master, the resource consumption is quite low, assuming that shadow will be used for a short period of time (until master get online again).

As a representation of our scenario, the same configuration will be used for both instances.

docker-machine create scc-shadow -d virtualbox \ 
--virtualbox-cpu-count "2" \ 
--virtualbox-disk-size "10000" \ 
--virtualbox-memory "2000"

5. Creating a SCC container

After the machine provisioning for both master and shadow respectively, the next step consist in creating a container with SAP SCC properly. After a detailled study regarding how Docker may properly handle with SAP Cloud Connector the results was satisfatory when using openSUSE as operational system. See SCC Installation on Linux for more details.

Return to the Glossary ▲

5.1 Container creation using .Dockerfile

The Dockerfile template might be found on the project page in https://github.com/afuscella/docker-SAPSCC, and it supposes to downloaded latest version of SAP SCC, install, and run on port 8443

The GitHub project is free of charge, so feel free to contribute with ideas and improvements 😉

Return to the Glossary ▲

5.2 Container creating using docker run

The statement below download the latest image of SAP SCC of tools.hana.ondemand.com, install and runs the newly container automatically. The docker image and its configuration may be found on DockerHub repository https://cloud.docker.com/repository/docker/afuscella/scc (the Dockerfile might be found on DockerHub as well)

Before start the failover setup execute the following statement on both master and shadow hosts create previously. We have to make sure both instances are up and running independently. Only after, we’ll start the failover setup.

docker run -i -d -p 8443:8443 --name scc afuscella/scc:2.12.0

As result, both instance should be up and running on their respectively hosts.Previously, we’ve map the hosts configuration directly in /etc/hosts, so accessing hosts on browser may result in:

https://master.internal.br:8443

https://shadow.internal.br:8443

(Optionally) You may want to peform basic configuration on master instance. Do steps described on [Part 2] Sync SCP account with on-premise systems using SCC

Return to the Glossary ▲

Great, everything looks correct so far. Next chapter we will get into details of High availability demonstrating with practical examples. See you there.

Want to do projects with me ? Just join!

Github: https://github.com/afuscella
Dockerhub: https://hub.docker.com/u/afuscella

– Arthur Silva