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
- 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.
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.
- 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
andibm-file-custom-gold-gid
storage 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