Skip to Content
Technical Articles
Author's profile photo Arthur Fuscella Silva

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.

By default, SAP Cloud Connector allows the installation of a redundant instance (shadow), which monitors the main instance (master) keeping exposed services online under failures scenarios.

Do not forget to like and to leave a comment,  help us to improve our work ?

Glossary

1. The importance of a redundant instance
2. Before start, make sure that
3. Use case
4. Sizing recommendations
4.1 Sizing for the Master Instance
4.1.1 docker-machine create statement
4.2 Sizing for the Shadow Instance
4.2.1 docker-machine create statement
5. Creating a SCC container
5.1 Container creation using .Dockerfile
5.2 Container creation using docker run

1. The importance of a redundant instance

In a very put simple, redundant means having more than one in case the first fails (believe me, system might fail all the time).

According to SAP in a failover setup, when the main instance (master) goes down for any reason, the redundant instance (shadow) take its role, and services should continue be exposed accordingly.

SAP SCC has a name convention for the main and redundant instances internally

master main instance
shadow redundant instance (takes the main instance role when it fails)

The shadow instance has to be installed and configured for a direct connection to its master, which pushes the entire master configuration to be replicate on the shadow, so set of providers, virtual hosts, mapping, action controls will exists properly on both instances reducing any risk of wrong configuration.

In this manner, shadow instance pings the master regularly, and takes its role when the main instance turns unavailable.

Return to the Glossary ▲

2. Before start, make sure that:

Return to the Glossary ▲

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

Installation Size
(S, M, L)
CPU (x86_64) Machine Memory / Heap /Direct Memory Disk Space

S:

The expected load is small (up to 1 million requests per day, request concurrency and size is in average low) and only a few subaccounts with some applications are connected.

(Source: SAP – Sizing for Master Instance)

2 cores
2.6 GHz
4GB RAM / 1GB / 2GB 10GB

4.1.1 docker-machine create statement

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

Return to the Glossary ▲

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.

Installation Size
(S, M, L)

S:

Same configuration than Master, with the memory provisioning reduced by half.

(Further details: SAP – Sizing for Shadow Instance)

4.2.1 docker-machine create statement

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

Return to the Glossary ▲

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

Assigned Tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo ricardo nabeiro
      ricardo nabeiro

      Great article Arthur, congrats!

      Author's profile photo Former Member
      Former Member

      Very informative and well explained blog. Thanks for sharing.

      Author's profile photo Emerson Alves Tosin
      Emerson Alves Tosin

      Great Job!  Amazing!

      Author's profile photo Rodrigo Oliveira
      Rodrigo Oliveira

      Thank you very much for sharing this, Arthur.

      Docker is awesome!

       

      Author's profile photo Allan Rafael Vasconcelos
      Allan Rafael Vasconcelos

      Congratulations Arthur, is a very helpful Article

      Author's profile photo Daniel da Paixão de Jesus
      Daniel da Paixão de Jesus

      Docker is cool !

      Thanks for Sharing !!

      Author's profile photo Susindiran Rao
      Susindiran Rao

      Good, thanks for sharing this Doc.