Architecture for IBM Guardium Insights

Guardium Insights is composed of integrated microservices that run on a multi-node Red Hat® OpenShift® cluster, which manages resources elastically and runs with minimal downtime.

Cloud-native design

Many companies are embracing cloud concepts because they need reliable, scalable applications. Additionally, companies need to modernize their data workloads to use hardware effectively and efficiently.

Guardium Insights enables you to reduce the cost and burden of maintaining multiple applications on disparate hardware. It also gives you the ability to assign resources to workloads as needed and reclaim those resources when not in use.

With a single, managed platform, Guardium Insights makes it easier for your enterprise to adopt modern DevOps practices while simplifying your IT operations and reducing time to value.

Run on OpenShift

Guardium Insights runs on top of Red Hat OpenShift, which means that you can run Guardium Insights on:
  • An on-premises, private cloud cluster
    • gp2 and OCS
    • standard and OCS
    • managed-premium and OCS
    • ibmc-vpc-block-10iops-tier and OCS
  • Any public cloud infrastructure that supports Red Hat OpenShift such as AWA, Azure, GCP, and IBM Cloud

For specific information about supported Red Hat OpenShift versions and installation types, see System requirements for Guardium Insights.

Guardium Insights leverages the Kubernetes cluster within Red Hat OpenShift for container management.

Cluster architecture

Guardium Insights is deployed on a multi-node cluster. Although you can deploy Guardium Insights on a 3-node cluster for development or proof of concept environments, it is strongly recommended that you deploy your production environment on a larger, highly available cluster with multiple dedicated master and worker nodes. This configuration provides better performance, better cluster stability, and increased ease of scaling the cluster to support workload growth. The specific requirements for a production-level cluster are identified in System requirements.

In a production-level cluster, there are three master + infrastructure nodes and three or more worker nodes. Using dedicated worker nodes means that resources on those nodes are used only for application workloads, which improves the performance of the cluster.

It is also easier to expand a 6-node cluster, because each node has a specific role in the cluster. If you expand a 3-node cluster, the cluster has a mix of dedicated nodes and mixed-use nodes, which can cause some of the same issues that occur in a 3-node cluster. If you expand a 6-node cluster, each node has a dedicated purpose, which simplifies cluster management and workload management.

The following diagram illustrates the typical topology of a production-level cluster:
This illustration depicts the relationship between the nodes in the cluster. The diagram is explained in the subsequent text.

In this example, the load balancer can either be in the cluster or external to the cluster. However, in a production-level cluster, an enterprise-grade external load balancer is strongly recommended. The load balancer distributes requests between the three master + infra nodes. The master nodes schedule workloads on the worker nodes that are available in the cluster. A production-level cluster must have at least 3 worker nodes, but you might need to deploy additional worker nodes to support your workload.

This topology is based on the minimum recommended requirements for a production-level cluster. However, you could implement a different topology. For example, you might want to separate the master nodes and the infrastructure nodes. Refer to the Red Hat OpenShift Container Platform documentation for other supported cluster configurations.

Storage architecture

Guardium Insights supports NFS, Red Hat OpenShift Data Foundation, and IBM® Cloud File Storage.

If possible, choose a storage provider that is supported by all of the services that you plan to install. If that is not possible, your cluster can contain a mix of storage types. However, each service can target only one type of storage.
NFS storage
If you are using NFS storage, you can use either of the following configurations:
  • You can use an external NFS server. In this configuration, you must have a sufficiently fast network connection to reduce latency and ensure performance.
  • You can install NFS on a dedicated node in the same VLAN as the cluster.
OpenShift Data Foundation
If you are using OpenShift Data Foundation, you can use either of the following configurations:
  • You can use dedicated storage nodes.
  • Your storage nodes can co-exist with your worker nodes.

Because OpenShift Data Foundation uses 3 replicas, it is recommended that you deploy OpenShift Data Foundation on multiples of three. This makes it easier to scale up your storage capacity.

IBM Spectrum® Scale Container Native
IBM Spectrum Scale Container Native connects to your Spectrum Scale Storage Cluster through a remote network mount to provide access to the high-performance General Parallel File System (GPFS). IBM Spectrum Scale Container Native provides persistent data storage through the IBM Spectrum Scale Container Storage Interface Driver.

Both IBM Spectrum Scale Container Native and IBM Spectrum Scale Container Storage Interface Driver are deployed on the worker nodes of your OpenShift cluster.

IBM Cloud File Storage
The ibmc-file-gold-gid and ibm-file-custom-gold-gidstorage classes are supported. The relative location of the storage is managed by your Red Hat OpenShift deployment on IBM Cloud.
Cloud Native Storage
If you are using Cloud Native Storage, you can use either of the following cloud based deployments:
  • AWS
  • Azure
  • GCP
  • IBM Cloud
For specific requirements and considerations, see: