Administration and Configuration of XtremeCloud Data Grid-db


XtremeCloud Data Grid-db is an infrastructure component for XtremeCloud applications and, as such, is installed and managed with Ansible Playbooks provided by Eupraxia Labs.

Ansible is an open source software provisioning, configuration management, and application deployment tool. It really is Continuous Integration/Continuous Deployment (CI/CD) for infrastructure.

Ansible is reasonably simple to use, and it works by connecting to your servers through SSH and pushing out small tasks or programs to execute. These small programs are referred to as modules, and they are responsible for executing functions with specific outcomes regarding the target systems. Let’s say you need to create a file, update a configuration file, and execute a script. Ansible can coordinate all these tasks to a single remote server or a set of servers all at once. Because Ansible only uses SSH, there are no processes, daemons or configuration files required on the target hosts. It is agentless. All that is required is a set of SSH keys and proper permissions to allow access to the servers to execute the tasks.


A first step to the installation is to review the Eupraxia Labs Certification Matrix. Ensure that all installed components are in compliance with the matrix to avoid product or support issues. For issues related to support, please refer to our support policy.

Prior to running the Ansible Playbooks for installation of the Oracle Real Applications Clusters (RAC) database, certain prerequisites must be met with the Cloud Service Provider (CSP). Regardless of the CSP, these minimum requirements should be met.

Minimum of two (2) servers each with following configurations:

2 CPUs
2 NICs
100 GB HDD minimum per node                       

Software Requirements

Your workstation or controller machine needs the proper version of Ansible to execute the Eupraxia Labs-provided playbooks:

[centos@vm-controller ~]$ ansible-playbook --version
ansible-playbook 2.8.1
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/centos/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible-playbook
  python version = 2.7.5 (default, Jun 20 2019, 20:27:34) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]

IP Requirements for Oracle RAC Installation

Nine (9) IP addresses (in public IP range) for the purpose as described below:

2 IPs <== 1 Public IP per node (2 node x 1= 2 IPs)
2 IPs <== 1 Public IP per node for the Virtual IP (VIP)  (2 node x 1= 2 IPs)
2 IPs <== 1 Private IP per node for the Fusion Interconnect
3 IPs <== for SCAN
9 IPs

Running the Oracle RAC Ansible Playbook to Support XtremeCloud SSO

After modifying the values for the provided Playbook run:

   $ ansible-playbook xtremecloud-sso-db-oracle.yaml

Similarly Ansible Playbooks are provided for our other supported databases and are executed in a similar manner:


Running the Oracle GoldenGate Ansible Playbook to Support XtremeCloud SSO

After modifying the values for the provided Playbook run:

   $ ansible-playbook xtremecloud-sso-oracle-goldengate.yaml

Similarly Ansible Playbooks are provided to implement multi-master replication (MMR) for our other supported databases and are executed in a similar manner:


Encryption to the Oracle RAC Environment from Kubernetes Cluster

For XtremeCloud SSO pods to communicate securely with the Oracle RAC, the Aspen Mesh (Istio) service entry is implemented.

We use a service entry to add an entry to the Aspen Mesh (Istio) service registry that Istio maintains internally. After we add the service entry, the Envoy XtremeCloud SSO proxy (sidecar) will send encryted (mTLS) traffic to the Oracle RAC instance as if it was a service in the mesh. Configuring service entries allows us to manage traffic for services running outside of the mesh, including the following tasks:

  • Redirect and forward traffic for external destinations, such as APIs consumed from the web, or traffic to services in legacy infrastructure.
  • Define retry, timeout, and fault injection policies for external destinations.
  • Add a service running in a Virtual Machine (VM) to the mesh to expand your mesh.
  • Logically add services from a different cluster to the mesh to configure a multicluster Istio mesh on Kubernetes.

In this case, it is Oracle RAC providing persistent storage for XtremeCloud SSO on a virtual machine (VM) or raw iron host that is external to our Kubernetes Cluster.

   kind: ServiceEntry
     name: oracle-cluster01
     location: MESH_EXTERNAL
     - name: xtremecloud-oracle
       number: 1521
       protocol: tcp
     resolution: DNS

Note that the protocol is tcp

The host in the ServiceEntry manifest above,, is resolving to three (3) IP addresses regardless of the number of RAC nodes. Single Client Access Name (SCAN) is a feature used in Oracle Real Application Clusters (RAC) environments that provides a single name for clients to access any Oracle Database running in a cluster. You can think of SCAN as a cluster alias for databases in the cluster. The benefit is that the client’s connect information does not need to change if you add or remove nodes or databases in the cluster.

For Google Cloud, the DNS entry will look similar to this: IN A
                                    IN A
                                    IN A

The Kubernetes resource manifests, to support the Oracle RAC environment external to the Kubernetes Cluster, are included with the XtremeCloud Single Sign-On (SSO) Helm Charts. Specifics related to these Helm Charts are detailed in the XtremeCloud Single Sign-On (SSO) Quick Start Guide.

Monitoring Oracle GoldenGate