How to run your clients with a Kubernetes-managed Terracotta cluster
Running the Terracotta servers in a given subnet (for example in a Kubernetes cluster) and the clients in another subnet (for example outside of the Kubernetes cluster), will result in a client connection error because the server addresses (host name or IP address) cannot be resolved by a client.
Administrators of the Terracotta cluster can use the public hostport configuration (private subnet address translation) to assign public names (resolvable by the clients) to each server part of the cluster, i.e. to each member of the TSA (Terracotta Server Array).
The following section describes how to use the public hostports configuration.
Configuration and reconfiguration using the cluster tool
Example:
Assuming a two stripes cluster, with two servers running on each stripe; all the servers are running within the same network and the clients need to reach them through Network Address Translation (NAT).
The four servers are configured with the internal names: server-1-1.stripe1, server-1-2.stripe1, server-2-1.stripe2, server-2-2.stripe2 (the same would apply to internal IPs).
However, the clients can reach them only via server1.public.com, server2.public.com, server3.public.com, server4.public.com.
Without public hostports configuration, the clients would be able to reach the servers but the servers would request to use the internal names, which are not available to the clients.
In order to avoid this, a proper configuration will expose the public hostports to the clients.
Note: All cluster tool invocations are run from within the Terracotta cluster network.
cluster-tool.sh configure -n MyCluster
-l ~/TerracottaDB101.xml tc-config-stripe-1.xml tc-config-stripe-2.xml
-m "server-1-1.stripe1:9410=server1.public.com:1111,
server-1-2.stripe1:9410=server2.public.com:2222,
server-2-1.stripe2:9410=server3.public.com:3333,
server-2-2.stripe2:9410=server4.public.com:4444"
Assuming that the cluster had previously been configured with a license, it's nevertheless possible to reconfigure this setting by providing the public hostports:
cluster-tool.sh reconfigure -n MyCluster
tc-config-stripe-1.xml tc-config-stripe-2.xml
-m "server-1-1.stripe1:9410=server1.public.com:1111,
server-1-2.stripe1:9410=server2.public.com:2222,
server-2-1.stripe2:9410=server3.public.com:3333,
server-2-2.stripe2:9410=server4.public.com:4444"
The status can be checked as in the following example:
cluster-tool.sh status -n MyCluster -s server-1-1.stripe1:9410
| STRIPE: 1 |
+--------------------+--------------------------------------------------------+----------------+
| Server Name | Host-Port | Status |
+--------------------+--------------------------------------------------------+----------------+
| server-1-1 | server-1-1.stripe1:9410=server1.public.com:1111 | PASSIVE |
------------------------------------------------------------------------------------------------
| server-1-2 | server-1-2.stripe1:9410=server2.public.com:2222 | ACTIVE |
+--------------------+--------------------------------------------------------+----------------+
| STRIPE: 2 |
+--------------------+--------------------------------------------------------+----------------+
| Server Name | Host-Port | Status |
+--------------------+--------------------------------------------------------+----------------+
| server-2-1 | server-2-1.stripe2:9410=server3.public.com:3333 | ACTIVE |
------------------------------------------------------------------------------------------------
| server-2-2 | server-2-2.stripe2:9410=server4.public.com:4444 | PASSIVE |
+--------------------+--------------------------------------------------------+----------------+
Moving clusters to a new infrastructure, changing public gateways, etc., will render the public hostports inaccessible. These will need to be reconfigured as in the example below:
cluster-tool.sh reconfigure -n MyCluster
tc-config-stripe-1.xml tc-config-stripe-2.xml
-m "server-1-1.stripe1:9410=other.public.com:1111,
server-1-2.stripe1:9410=other.public.com:2222,
server-2-1.stripe2:9410=other.public.com:3333,
server-2-2.stripe2:9410=other.public.com:4444"
TMC updated display
If you have configured public hostports, you can expect the TMC to display the mapping:
SSL Security considerations
Since the clients will use the public hostports, those hostports need to be included in the SSL certificates.
Make sure to emit SSL certificates that include Subject Alternative Names (SANs) that match the public hostports. For further information see this instructions document:
