Storage requirements

Edit online

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 configure a VSphere CSI (thin-csi) storage class in the cluster with allowVolumeExpansion set to true. For more information, see VMware vSphere CSI Driver Operator.

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.

Validated storage options

The following table shows the storage options that are validated for QRadar EDR.

Table 1. Validated storage options
Cloud provider	Storage class	Access mode	Storage provider	Reclaim policy	Min. IOPS	Encryption is supported on the storage class
VMware	thin-csi	RWO	VSphere Volume	Retain	10 IOPS/GB	Yes

Data encryption

If your cloud provider doesn't encrypt your disks by default, you can ensure 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 2. Storage capacity for IBM Cloud®
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

Edit online

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

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.

Create the PVC by typing the following command.
```
oc create -f backup-pvc.yaml
```