Google Cloud Deployment Overview

Components

The Google Cloud project comprises the following components:

 

Inter-communication between components

The private subnet components (such as the Kubernetes cluster and the NFS storage (FileStore)) communicate with public subnet components (such as load balancers and bastion nodes). See Architecture Security design considerations for details.

The load balancer functions as the entry way for the external traffic. It's usually bound with the site's ArcSight Suite URL (for example, https://arcsight-suite.gcp.opentext.com). Once end-users open the URL in their browser or mobile app, and after DNS resolution, the load balancer routes traffic from external applications to the private subnet applications.

Cluster management is achieved by connecting to the bastion node in the public subnet, and then jumping to the private subnet. The bastion node in this scenario works as a Kubernetes client, database client, or NFS (FileStore) client for operation purposes.

The applications reside inside the Kubernetes cluster in the private subnet, using NFS (FileStore) as their Persistent Volume (which is also in the private subnet).

When the applications in the Kubernetes cluster need to connect to the Internet (for example, when downloading docker images for upgrade or downloading a patch) the traffic goes via Cloud NAT to prevent the Internet from initiating a connection with the instances running those applications.

 

Architecture Security design considerations

The network infrastructure with separate public and private subnets, provides an additional layer of security, where:

Independent routing tables are configured for every private subnet to control the flow of traffic from within or without the VPC

All OMT and ArcSight Suite components are located in the private subnet, with no direct Internet access allowed

End-users and IT agents can only connect to specified ports (for example 443) for business purposes, with a typical traffic path being:

User <-> Load balancer (public subnet) <-> GKE worker nodes (private subnet)

Only a limited number of users can access the bastion node, with a typical traffic path for cluster management being:

DevOps engineer <-> Bastion node (public subnet) <-> GKE cluster or NFS (FileStore)

 

The architecture design also takes into account performance balance against availability. The worker nodes are distributed across multiple Availability Zones instead of regions, ensuring a network latency between different Availability Zones of less than 1 millisecond in most cases.

 

 

Benefits of the Google Kubernetes Engine (GKE)