Storage requirements

The integration capabilities in IBM® Security QRadar® EDR use persistent storage to provide reliable and resilient storage of state data. The cluster administrator must provide appropriate storage classes that meet the requirements of the respective Red Hat® OpenShift® Container Platform environment.

Important: To install QRadar EDR, you must use a storage class that supports the Container Storage Interface with allowVolumeExpansion set to true. For more information, see Container Storage Interface (CSI). The storage class must be Block storage with an RWO (ReadWriteOnce) access mode.

Persistence is enabled by default in QRadar EDR. You must have physical volumes available, backed up by a suitable file system. For more information, see Persistent volume storage sizing.

For more information about Kubernetes persistent volumes, see Persistent Volumes.

Suggested storage providers

In a Red Hat OpenShift Container Platform environment where you do not have a managed cluster from a cloud provider, you need to use a storage class from the following storage providers for QRadar EDR.

For Linux® on x86 hardware, the following storage providers are validated for QRadar EDR.
  • IBM Storage Suite for IBM Cloud® Paks. This suite of offerings includes the following validated storage options.
    • Red Hat OpenShift Data Foundation (ODF) 4.2 or later with the block or file storage type
  • Red Hat OpenShift Data Foundation (ODF) 4.2 or later with the block or file storage type
For more information about these options, see the IBM Storage Suite for IBM Cloud Paks documentation.
Important:
  • If you are using VMWare vSphere and ODF, the CPU and RAM requirements must be incremented in line with the resource requirements in the IBM Storage Suite for IBM Cloud Paks documentation.
  • If you are using VMWare clusters that are hosted on multiple ESXi hosts, your storage must be shared between those hosts.
  • The QRadar EDR support team does not support the IBM Storage Suite components. Make sure that you have an appropriate support arrangement with the storage provider for these components.
  • To provide protection for data at rest, use volume encryption for your chosen storage.

Validated storage options

For each cloud environment provider that QRadar EDR supports, the validated storage options are detailed in the following table.

Table 1. Validated storage options
Provider Storage class Storage type Access mode Storage provider Suggested reclaim policy Min. IOPS Encryption is supported on the storage class
Amazon Web Services (AWS) gp3-csi Block RWO AWS Retain 10 IOPS/GB Yes
VMware ocs-storagecluster-ceph-rbd, vsphere-storage-blockvsphere-volume(thin-csi) Block RWO ODF 4.7, VSphere Volume Retain 10 IOPS/GB Yes
Important: If you are using VMWare clusters that are hosted on multiple ESXi hosts, your storage must be shared between those hosts.

In a Red Hat OpenShift Container Platform environment where you do not have a managed cluster from a cloud provider, QRadar EDR requires the following storage classes.

Table 2. Validated storage classes
Storage provider Storage class Storage type Access mode Suggested reclaim policy Min. IOPS Encryption is supported on the storage class
ODF 4.7 ocs-storagecluster-ceph-rbd Block RWO Retain 10 IOPS/GB Yes
VMware vsphere-storage-blockvsphere-volume(thin-csi) Block RWO Retain 10 IOPS/GB Yes

Data encryption

If your cloud provider doesn't encrypt your disks by default, you can make sure that your QRadar EDR data is stored securely by encrypting your disks yourself. If you use Linux Unified Key Setup-on-disk-format (LUKS) for this purpose, enable LUKS and format the disks with the XFS file system before you install QRadar EDR.

Persistent volume storage sizing

QRadar EDR requires one or more persistent volumes of suitable size, as shown in the following table.
Tip: If you don't know the event volume when you are installing the product, select the estimated size of the deployment based on the general number of endpoints.
Table 3. Suggested storage capacity
Deployment size Storage capability Access mode Suggested storage
Small 1 K Endpoints

45M events/day

   
  Cassandra RWO

Cassandra data: 1 TB

(45 million events x 30 days + 25% buffer)

Cassandra backup: 800 GB

Total for 3 Cassandra pods with replication factor of 2

  OpenSearch RWO

2 TB

(45 million events x 30 days + 25% buffer)

Total for 2 OpenSearch pods/replicas

  Postgres RWO 40 GB
  RabbitMQ RWO 40 GB
       
Medium 3 K Endpoints

95M events/day

   
  Cassandra RWO

Cassandra data: 2.2 TB

(95 million events x 30 days + 25% buffer)

Cassandra backup: 1.76 TB

Total for 3 Cassandra pods with replication factor of 2

  OpenSearch RWO

4.3 TB

(95 million events x 30 days + 25% buffer)

Total for 2 OpenSearch pods/replicas

  Postgres RWO 40 GB
  RabbitMQ RWO 40 GB
       
Large 5 K Endpoints

150M events/day

   
  Cassandra RWO

Cassandra data: 3.4 TB

(150 million events x 30 days + 25% buffer)

Cassandra backup: 2.72 TB

Total for 3 Cassandra pods with replication factor of 2

  OpenSearch RWO

6.75 TB

(150 million events x 30 days + 25% buffer)

Total for 2 OpenSearch pods/replicas

  Postgres RWO 40 GB
  RabbitMQ RWO 40 GB
       

10k

10 K Endpoints

300M events/day

   
  Cassandra RWO

Cassandra data: 6.8 TB

(300 million events x 30 days + 25% buffer)

Cassandra backup: 5.5 TB

Total for 3 Cassandra pods with replication factor of 2

  OpenSearch RWO

13.5 TB

(300 million events x 30 days + 25% buffer)

Total for 2 OpenSearch pods/replicas

  Postgres RWO 40 GB
  RabbitMQ RWO 40 GB
       

15k

15 K Endpoints

400M events/day

   
  Cassandra RWO

Cassandra data: 9.06 TB

(400 million events x 30 days + 25% buffer)

Cassandra backup: 7.3 TB

Total for 3 Cassandra pods with replication factor of 2

  OpenSearch RWO

17.9 TB

(400 million events x 30 days + 25% buffer)

Total for 2 OpenSearch pods/replicas

  Postgres RWO 40 GB
  RabbitMQ RWO 40 GB
Tip: For the Backup and Restore pod, instead of using the defaults that are specified in the table, you can provision your own storage. For more information, see Creating the backup and restore PVC.

Creating the backup and restore PVC

QRadar EDR provides backup and restore functions that require access to a Persistent Volume Claim (PVC). You can create the PVC before installation. If you don't create the backup and restore PVC before installation, a 500 GB PVC is created at installation with the overall storage class for QRadar EDR.

About this task

Before you deploy QRadar EDR, consider whether you need to create a PVC for storage of backup data. This PVC must be created in a data store that is separate from the cluster. The data that is stored in the PVC must be encrypted and under access control. The storage class for the PVC and its size can be configured through a YAML file.

Use a CSI storage class with allowVolumeExpanision set to true for the backup and restore PVC. The amount of storage that is required for backup archives is directly related to the amount of data imported into QRadar EDR, the frequency of backups, and the number of backups retained. If numerous backup archives are to be retained, move the backup archives from the backup and restore PVC to a third-party storage to avoid disk space limitations in the PVC.

Procedure

  1. Create a file called backup-pvc.yaml, and paste the following text into the file. Replace <storage_class> with the storage class for your backup and restore PVC, and <storage_size> with the size of the PVC.
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
    # The name of the PVC must be as below and should not be changed.
     name: cp4s-backup-pv-claim
    spec:
    # Set the storageClassName appropriately; for example, thin-csi.
     storageClassName: <storage_class>  
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: <storage_size>
    Important: The storageClassName must be confirmed correct for your environment.
  2. Create the PVC by typing the following command.
    oc create -f backup-pvc.yaml

Retrieving the default block storage class in your environment

Set only one default storage class in your Red Hat OpenShift environment.

Procedure

  1. Verify the default storage class by typing the following command.
    oc get storageclass | grep default
  2. If you have more than one default storage class set, remove one of the storage classes by typing the following command.
    oc patch storageclass <storage_class> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}' 
    
  3. If you install IBM Security QRadar EDR in an air gapped environment or by using case, set the default storage class as the value for the storageClass parameter when you update the values.conf file.