Setting up SSH tunnels for cloud to on-premise with SOA Cloud Service clusters by Christian

Executive Overview

With the current release of SOA Cloud Service (SOACS) a common requirement often requested is to connect to an on-premise  database from the cloud SOACS instance. SSH tunnels can be used to establish cloud to on-premise communications, allowing SOA Cloud Service to access resources from on-premise applications.

Companion post : Single host SSH tunneling

My colleague, Shub Lahiri has written an excellent article as well, he discusses the simpler configuration where there isn’t a cluster of managed servers in the cloud- this is much simpler to setup,more suited for a development environment but cannot work with a cluster set up in the cloud.

Overview

This post expands on the concept of ssh tunneling using a more advanced setup to allow connection of a SOA Cloud cluster to a on-premise database. In principle this setup could be configured to access any tcp based service on-premise.

Motivation

Every managed server requires access to the on-premise database or other resource, for composite flows using the resource to function, as work is almost universally load-balanced between managed server nodes. Unfortunately, that means either we have multiple on-premise ssh connections to the cloud, or we have this solution. Multiple connections requires every managed server have a unique public IPV4 address. Unfortunately, IPV4 addresses are a scarce resource and as such, SOACS does not provision one for every managed server node.

Network topology

For this example, we will be tunneling database traffic, allowing a Database Adapter deployed in the cloud to access an on-premise Oracle Database. The SOA Suite cluster will be running on 2 compute nodes (a 2 node SOA cluster) with the standard SOA CS setup – an LBR node as the front end gateway, and a Database Cloud Service node for SOA Suite persistence.

The diagram shows the basic idea of the network topology. SSH is used from the database server on-premise to connect the database node of the SOA cluster in the cloud. The specific choice of the databases is technically incidental – this approach will work with the bridge between any two hosts on-premise and cloud, but it seems the most natural fit for a tunneled database connection to use the databases.

The DB host on-premise runs a reverse SSH tunnel to the DB host in the cloud. Traffic for the on-premise database flows (green lines) from the managed servers, via the SSH tunnel to the DB on-premise. The apparent connectivity is to the DB host in the cloud, but in reality SSH is back-hauling the traffic through the tunnel to on-premise.

Setting up

Unlike the single managed server usecase, we need to tweak some components of the cloud setup to allow the shared SSH tunnel to work.

First, we need to clarify some terminology:
The SSH server host – the endpoint in the cloud to which ssh connectivity is established. In the diagram above, it is the “DB” node in the cloud.
The SSH client – the endpoint on-premise from which ssh connectivity is established. In the diagram above it is the “OnPremise DB” node.
The managed servers – the hosts in the cloud which require access to the SSH tunnel to communicate to on-premise. In the diagram above, they are identified as MS1 and MS2. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki