How to setup a performant and highly available SAP HANA Cloud Connector

High Availability

For my high available SCC installation, I need a Master (Primary Installation):

And Shadow (Backup Installation) instance:

For this I extend the HANA, express edition architecture from my previous HANA Rules Framework (HRF) blog, by adding the two SCCs and access from the HANA Cloud Platform (HCP) through a List Report Application:

Originally, I intended to call HRF Rules Services from the HCP but it turned out to be more practical to call an OData service from the SAP HANA Interactive Education (SHINE) content. Therefore, I configure the respective connectivity in my Master SCC:

In a multiple HANA database container environment like mine, it is important, that my Virtual Host concurs with my database tenant HTTP and HTTPS settings. If I chose a different virtual host, epmhost in this example, the HANA Web Dispatcher would not know where to connect to:

On the basis of my SCC configuration I create a Destination in the HCC:

And check it respectively:

Now I can use this connection in my List Report Application to connect to the PO_WORKLIST collection:

As a result, I see all the POs from the SHINE content in my List Report Application:

To add high availability, I have to configure my Master SCC to enable High Availability Through my Shadow SCC:

Next I configure my Shadow SCC respectively and connect to my Master SCC:

When I now shutdown my Master SCC this is recognized by my Shadow SCC after the Check Interval period and is Attempting to take over after counting down the Takeover Delay period:

As a result, my Shadow SCC has become my Master SCC and my connection from the HCP continues to work seamlessly. Once restarted, my former Master SCC resumes the role of Shadow SCC. If I did not like this, I could always switch back the roles again:

Sizing

On the one hand side, there are no guidelines concerning the sizing of a SCC installation from SAP yet, that I would be aware of. Instead, if you were running your environment virtualized on VMware like I do, you could refer to the SAP On VMware Best Practices guide.

On the other hand, the SCC is just a java process running natively on the operating system without the need for any form of SAP application server:

Therefore, general Java sizing guidelines apply and in my scenario, all except one request have been delivered in less than 125ms:

Finally, the SCC Hardware Metrics would give me an indication if Disk Space, Java Heap, Physical of Virtual Memory became a bottleneck which they currently do not: