View table: PEPrerequisites

• Persistent Volumes (PVs)
  • Create persistent volumes for workspace storage (5 GB minimum) and logs (5 GB minimum)
  • Set the access mode for these volumes to ReadWriteMany.
  • The Designer manifest package includes a sample YAML file to create Persistent Volumes required for Designer and DAS.
  • Persistent volumes must be shared across multiple K8s nodes. Genesys recommends using NFS to create Persistent Volumes.
• Shared file System - NFS
  • For production, deploy the NFS server as highly available (HA) to avoid single points of failure. It is also recommended that the NFS storage be deployed as a Disaster Recovery (DR) topology to achieve continuous availability if one region fails.
  • By Default, Designer and DAS containers run as a Genesys user (uid:gid 500:500). For this reason, the shared volume must have permissions that will allow write access to uid:gid 500:500. The optimal method is to change the NFS server host path to the Genesys user: chown -R genesys:genesys.
  • The Designer package includes a sample YAML file to create an NFS server. Use this only for a demo/lab setup purpose.
  • Azure Files Storage - If you opt for Cloud storage, then Azure Files Storage is an option to consider and has the following requirements:
    A Zone-Redundant Storage for RWX volumes replicated data in zone redundant (check this), shared across multiple pods.
    • Provisioned capacity : 1 TiB
    • Baseline IO/s : 1424
    • Burst IO/s : 4000
    • Egress Rate : 121.4 MiBytes/s
    • Ingress Rate : 81.0 MiBytes/s

Create a PostgreSQL database and user

Before deploying Genesys Authentication, you must create a PostgreSQL database and a user with superuser permissions. This example creates the "gauth_master" user and "gauth_db" database, but you can use any names that makes sense for your organization: ?'"`UNIQ--syntaxhighlight-00000012-QINU`"'?Note: Make note of the user name, password, and database to configure the postgres settings in the values.yaml file.

• Persistent Volumes (PVs)
  • Create persistent volumes for workspace storage (5 GB minimum) and logs (5 GB minimum)
  • Set the access mode for these volumes to ReadWriteMany.
  • The Designer manifest package includes a sample YAML file to create Persistent Volumes required for Designer and DAS.
  • Persistent volumes must be shared across multiple K8s nodes. Genesys recommends using NFS to create Persistent Volumes.
• Shared file System - NFS
  • For production, deploy the NFS server as highly available (HA) to avoid single points of failure. It is also recommended that the NFS storage be deployed as a Disaster Recovery (DR) topology to achieve continuous availability if one region fails.
  • By Default, Designer and DAS containers run as a Genesys user (uid:gid 500:500). For this reason, the shared volume must have permissions that will allow write access to uid:gid 500:500. The optimal method is to change the NFS server host path to the Genesys user: chown -R genesys:genesys.
  • The Designer package includes a sample YAML file to create an NFS server. Use this only for a demo/lab setup purpose.
  • Azure Files Storage - If you opt for Cloud storage, then Azure Files Storage is an option to consider and has the following requirements:
    A Zone-Redundant Storage for RWX volumes replicated data in zone redundant (check this), shared across multiple pods.
    • Provisioned capacity : 1 TiB
    • Baseline IO/s : 1424
    • Burst IO/s : 4000
    • Egress Rate : 121.4 MiBytes/s
    • Ingress Rate : 81.0 MiBytes/s

Resource recommendations

• Memory consumption is proportional to the size of the customer’s configuration server database.

• Standard operating resources are substantially lower; however, spikes can occur due to environment issues such as server disconnects which can cause significant memory and CPU load.

• These volumes are per historical stream. For example, 5 interactions per second with three reporting streams should be considered as 15 interactions per second. Note: RTA streams do not contribute substantially to resource requirements.

• These tests were conducted with 8 GB RAM, 1 CPU at a speed of 2.7GHz, 100k concurrent agents, and clean routing (mostly an issue for multimedia interactions on Interaction Server).

Storage sizing calculator

The adapter requires storage of recovery logs for 1 week. The recovery logging for the adapter stores the full data for every event it receives from Configuration Server, Interaction Server, and TServer. Customers need to provide enough storage to handle 7 days of TServer and Interaction Server event data. In addition, the adapter downloads a fresh copy of all CME data daily from Configuration Server.  A rough approximation for how much storage is required can be expressed with the following formula:

Storage = 7 days × (EventSize × #Events + CMESize) × Compression × Padding

Storage: The amount of storage required by the adapter.

EventSize: The average size of TServer/Interaction Server events in Bytes.  This depends on the business rules of the contact center and how much user data is being attached to events.  A typical value would be in the range of 1-5KB.

#Events: The average number of TServer/Interaction Server events processed in a typical day.  This can vary widely depending on the complexity and size of the contact center as well as call volume.

CMESize: The aggregate size of all CME data being monitored by the adapter.  The amount of memory taken up by the Configuration Server application can be used as an approximation.

Compression: A multiplier representing the amount of compression of the gzip log files, typically 0.05-0.10.

Padding: A multiplier to provide extra space in case of periods of high activity or unexpected restarts. A value of 2 is recommended.

For example:

To calculate the amount of storage required by a contact center with an average EventSize of 3KB and 5 million events per day, with a CME Size of 1GB then:

 Storage = 7 × (3KB × 5,000,000 + 1GB) × 0.10 × 2 = 21GB per week

Other storage requirements

The speed and throughput requirements for recovery log storage depend on the amount of logging calculated in the previous section. If the adapter writes 21GB per week then it writes 3GB per day and if most of the logging takes place during the 16 busiest hours of the day, then the adapter will need to write at a rate of:

Rate = 3GB ÷ 16hr = 56 MB/s

This kind of throughput can be handled by most disk storage providers.

Media Control Platform

Storage requirement for production (min)

Storage requirements for Sandbox

Resource Manager

Storage requirement for production (min)

Storage requirements for Sandbox

Service Discovery

Not applicable

Reporting Server

Storage requirement for production (min)

Storage requirement for Sandbox

GVP Configuration Server

Not applicable

PostgreSQL

• CPU: 2
• RAM: 8 GB
• HDD: 50 GB

Redis

• 2 nodes:
  • CPU: 2
  • RAM: 8 GB
  • HDD: 20 GB

Elasticsearch

• 3 "master" nodes:
  • CPU: 2
  • RAM: 8 GB
  • HDD: 20 GB
• 4 "data" nodes
  • CPU: 4
  • RAM: 16 GB
  • HDD: 20 GB

Regarding storage characteristics for IXN Server database, refer to PostgreSQL documentation.

Contact your account representative if you need assistance with sizing calculations.

Note: This is 100k of randomized string in a single field in the user data.

Hardware requirements

Genesys strongly recommends the following hardware requirements to run GES with a single tenant. The requirements are based on running GES in a multi-tenanted environment and scaled down accordingly. Use these guidelines, coupled with the callback storage information listed above, to gauge the precise requirements needed to ensure that GES runs smoothly in your deployment.

GES

(Based on t3.medium)

• vCPUs: 1
• Memory: 2 GiB
• Network burst: 5 Gbps

Redis

(Based on cache.r5.large) Redis is essential to GES service availability. Deploy two Redis caches in a cluster; the second cache acts as a replica of the first. For more information, see Architecture.

Callback data is stored in Redis memory.

• vCPUs: 1
• Memory: 8 GiB
• Network burst: 10 Gbps

PostgreSQL

(Based on db.t3.medium)

• vCPUs: 2
• Memory: 4 GiB
• Network burst: 5 Gbps
• Storage: 100 GiB

Sizing calculator

The information in this section is provided to help you determine what hardware you need to run GES and third-party components. The information and formulas are based on an analysis of database disk storage and Redis memory usage requirements for callback data. The numbers provided here include only storage and memory usage for callbacks. Additional storage and memory is required for configuration data and basic operations.

Requirements per callback

Each callback record (excluding user data) requires approximately 6.5 to 7.0 kB of database disk storage, plus additional disk storage for the user data. Each kB of user data consumes approximately 3.0 kB of disk storage.

Each callback record (excluding user data) requires approximately 4.5 to 5.5 kB of Redis memory, plus an additional 1.25 kB for each kB of user data.

Use the following formulas to estimate disk storage and Redis memory requirements:

• Estimate database disk storage requirements for callback data:

  <number of callbacks per day> × (7 kB + (3 kB × <kB of user data per callback>)) × 14 days

• Estimate Redis memory requirements for callback data:

  <number of callbacks per day> × (5.5 kB + (1.25 kB × <kB of user data per callback>)) × 14 days

For example, if a tenant has an average of 100,000 callbacks per day with 1kB user data in each callback:

• The database storage requirement is approximately 14 GB.
• The Redis memory requirement is approximately 9.5 GB.

NOTE: Each callback record is stored for 14 days. If you average about 10k scheduled callbacks every day, and the scheduled callbacks are all booked as far out as possible (that is, 14 days in the future), the number of callbacks to use in storage and memory calculations is 28 days × 10k callbacks per day = 280k callbacks.

Redis operations

The Redis operations primarily update the connectivity status to other services such as Tenant Service (specifically ORS and URS) and Genesys Web Services and Applications (GWS).

When GES is idle (zero callbacks in the past, no active callback sessions, no scheduled callbacks), GES generates about 50 Redis operations per second per GES node per tenant.

Each Immediate callback generates approximately 110 Redis operations from its creation to the end of the ORS session.

For Scheduled callbacks, assuming each callback generates 110 Redis operations when the ORS session is active (based on Immediate callback numbers), there is 1 additional Redis operation for each minute that a callback is scheduled.

For example, if a callback is scheduled for 1 hour from the time it was created, the number of Redis operations is approximately 60 + 110 = 170.

For a callback scheduled for 1 day from the time it was created, it generates approximately 60 × 24 + 110 = 1550 Redis operations, using the following formula for the number of Redis operations per callback:
<number of callbacks> × (110 + <number of minutes until scheduled time>)

Because the longevity of a callback ORS session depends on the estimated wait time (EWT), the total number of Redis operations performed by GES per minute varies, based on both the number of callbacks in the system and the EWT of the callbacks.

Use the following formula to estimate the number of Redis operations performed per minute:
Total number of Redis operations per minute = (50 base GES Redis operations per second × 60 seconds) + <number of upcoming scheduled callbacks in the system> + ((<total number of active callbacks> / <EWT>) × 110)

Where:

• Total number of active callbacks = <number of active immediate callbacks> + <number of active scheduled callbacks>, and
• Number of active scheduled callbacks = (<number of scheduled callbacks per time slot> / <time slot duration>) × <EWT>

For example, let's say we have the following scenario:

• Scheduled callbacks:
  • Time slot duration = 15 minutes
  • Maximum capacity per time slot = 100
  • Business hours = 24x7
  • Assume that all time slots are fully booked for the next 14 days
• Number of active immediate callbacks = 1,000
• Estimated wait time = 90 minutes

Using the preceding formulas, estimate the Redis operations per minute:

• Total number of scheduled callbacks = (100 × (60 / 15)) × 24 × 14 = 134,400
• Number of active scheduled callbacks = (100 / 15) × 90 = 600
• Number of upcoming scheduled callbacks = <total number of scheduled callbacks> - <number of active scheduled callbacks> = (134,400 - 600) = 133,800
• Total number of active callbacks = 1,000 + 600 = 1,600
• Total number of Redis operations per minute = (50 × 60) + 133,800 + ((1,600 / 90) × 110) = 138,756

Redis keys

Each callback creates three additional Redis keys. Given the preceding calculations for Redis memory requirements for each callback, the formula for the average key size is:
(5.5 kB + (1.25 kB × <kB_of_user_data_per_callback>)) / 3

The minimal recommended PVC size is 100GB.

Example usage: https://zhimin-wen.medium.com/local-volume-provision-242affd5efe2

Kubernetes provides a powerful volume plugin system, which enables Kubernetes workloads to use a wide variety of block and file storage to persist data.

You can use the GCXI Helm chart to set up your own PVs, or you can configure PV Dynamic Provisioning in your cluster so that Kubernetes automatically creates PVs.

Volumes Design

GCXI installation uses the following PVC:

Preparing the environment

To prepare your environment, complete the following steps:

1. To log in to the cluster, run the following command:
   • For AKS:

     ?'"`UNIQ--source-0000002D-QINU`"'?

   • For GKE:

     ?'"`UNIQ--source-0000002F-QINU`"'?

   • For OpenShift:

     ?'"`UNIQ--source-00000031-QINU`"'?

     • To check the cluster version on OpenShift deployments, run the following command:

       ?'"`UNIQ--source-00000033-QINU`"'?

2. To create a new project, run the following command:

   GKE or AKS:

   1. Edit the create-gcxi-namespace.json, adding the following values:

      ?'"`UNIQ--source-00000035-QINU`"'?

   2. To apply the changes, run the following command:

      ?'"`UNIQ--source-00000037-QINU`"'?

   OpenShift: ?'"`UNIQ--source-00000039-QINU`"'?

3. For GKE or AKS, to confirm namespace creation, run the following command:

   ?'"`UNIQ--source-0000003B-QINU`"'?

4. Create a secret for docker-registry to pull images from the Genesys JFrog repository:

   ?'"`UNIQ--source-0000003D-QINU`"'?

5. Create the file values-test.yaml, and populate it with appropriate override values. For a simple deployment using PostgreSQL inside the container, you must include PersistentVolumes named gcxi-log-pv, gcxi-backup-pv, gcxi-share-pv, and gcxi-postgres-pv. You must override GCXI_GIM_DB with the name of your Genesys Info Mart data source.

GIM secret volume

In scenarios where raa.env.GCXI_GIM_DB__JSON is not specified, RAA mounts this volume to provide GIM connections details.

1. Declare GIM database connection details as a Kubernetes secret in gimsecret.yaml:

   ?'"`UNIQ--source-00000029-QINU`"'?

2. Reference gimsecret.yaml in values.yaml:

   ?'"`UNIQ--source-0000002B-QINU`"'?

Alternatively, you can mount the CSI secret using secretProviderClass, in values.yaml:?'"`UNIQ--source-0000002D-QINU`"'?

Config volume

RAA mounts a config volume inside the container, as the folder /genesys/raa_config. The folder is treated as a work directory, RAA reads the following files from it during startup:

• conf.xml, which contains application-level config settings.
• custom *.ss files.
• JDBC driver, from the folder lib/jdbc_driver_<RDBMS>.

RAA does not normally create any files in /genesys/raa_config at runtime, so the volume does not require a fast storage class. By default, the size limit is set to 50 MB. You can specify the storage class and size limit in values.yaml:?'"`UNIQ--source-0000002F-QINU`"'?

   ...

RAA helm chart creates a Persistent Volume Claim (PVC). You can define a Persistent Volume (PV) separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.config.pvc.volumeName value, in values.yaml:?'"`UNIQ--source-00000031-QINU`"'?

Health volume

RAA uses the Health volume to store:

• Health files.
• Prometheus file containing metrics for the most recent 2-3 scrape intervals.
• Results of the most recent testRun init container execution.

By default, the volume is limited to 50MB. RAA periodically interacts with the volume at runtime, so Genesys does not recommend a slow storage class for this volume. You can specify the storage class and size limit in values.yaml:?'"`UNIQ--source-00000033-QINU`"'?RAA helm chart creates a PVC. You can define a PV separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.health.pvc.volumeName value, in values.yaml:?'"`UNIQ--source-00000035-QINU`"'?

Genesys expects you to use the same storage account for GSP and GCA. If you want to provision separate storage for GCA, follow the Create S3-compatible storage instructions for GSP to create similar S3-compatible storage for GCA.

PostgreSQL — the Info Mart database

The Info Mart database stores data about agent and interaction activity, Outbound Contact campaigns, and usage information about other services in your contact center. A subset of tables and views created, maintained, and populated by Reporting and Analytics Aggregates (RAA) provides the aggregated data on which Genesys CX Insights (GCXI) reports are based.

A sizing calculator for Genesys Multicloud CX private edition is under development. In the meantime, the interactive tool available for on-premises deployments might help you estimate the size of your Info Mart database, see Genesys Info Mart 8.5 Database Size Estimator.

Genesys recommends a minimum 3 IOPS per GB.

For information about creating the Info Mart database, see Before you begin GIM deployment

Create the Info Mart database

Use any database management tool to create the Info Mart ETL database and user.

1. Create the database.
2. Create a user for all of the Genesys Info Mart services to use. Grant that user full permissions for the database.

   This user’s account is used by Info Mart jobs to access the Info Mart database schema.

   The name of the Info Mart schema name is public.

   Important

   Make a note of the database and user details. You need this information when you configure GIM and GCA Helm chart override values.

Object storage — Data Export packages

The GIM Data Export feature enables you to export data from the GIM database so it is available for other purposes. Unless you elect to store your exported data in a local directory, GIM data is exported to an object store. GIM supports export to either Azure Blob Storage or the S3-compatible storage provided by Google Cloud Platform (GCP).

If you want to use S3-compatible storage, follow the Before you begin GSP deployment instructions for GSP to create the S3-compatible storage for GIM.

If you are not using obect storage, you can configure GIM to store exported data in a local directory. In this case, you do not need to create the object storage.

GSP uses S3-compatible storage to store persisted data. You must provision this S3-compatible storage in your environment.

By default, GSP is configured to use Azure Blob Storage, but you can also use S3-compatible storage provided by other cloud platforms. Genesys expects you to use the same storage account for GSP and GCA.

Create S3-compatible storage

Genesys Info Mart has no special requirements for the storage buckets you create. Follow the instructions provided by the storage service provider of your choice to create the S3-compatible storage.

• For GKE, see the Google Cloud Storage documentation about creating bucket storage.
• For AKS, see Azure Storage documentation about creating blob storage.

To enable the S3-compatible storage object, you populate Helm chart override values for the service (see ). To do this, you need to know details such as the endpoint information, access key, and secret.

Logs Volume

The logs volume stores log files:

• To use the persistent volume, set the log.volumeType to the pvc.
• To use the local storage, set the log.volumeType to the hostpath.

Genesys Pulse Collector Health Volume

Genesys Pulse Collector health volume provides non-persistent storage for store Genesys Pulse Collector health state files for monitoring.

Stat Server Backup Volume

Stat Server backup volume provides disk space for Stat Server's state backup. The Stat Server backup volume stores the server state between restarts of the container.

SIP Cluster Service

VoiceMail Service

For more information, see Storage requirements in the Configure and deploy Voicemail section of this guide.

If Persistent Volume and Persistent Volume Claim are configured, they are created. The log size is adjusted according to the log rate described as follows:

Gateway:

idle: 0.5 MB/hour per agent

active call: around 0.2MB per call per agent.

Example: For 24 hours of work, where each agent gets 7 - 10 calls per hour with a constant call rate, you require around ~500 GB for 1000 agents, with around ~20 GB being consumed per hour.

CoTurn:

For 1000 connected agents, the load rate is approximately 3.6 GB/hour that scales linearly and increases or decreases with the number of agents and stays constant whether calls are performed or not.

Media Control Platform

Storage requirement for production (min)

Storage requirements for Sandbox

Resource Manager

Storage requirement for production (min)

Storage requirements for Sandbox

Service Discovery

Not applicable

Reporting Server

Storage requirement for production (min)

Storage requirement for Sandbox

GVP Configuration Server

Not applicable

PostgreSQL

• CPU: 2
• RAM: 8 GB
• HDD: 50 GB

Redis

• 2 nodes:
  • CPU: 2
  • RAM: 8 GB
  • HDD: 20 GB

Elasticsearch

• 3 "master" nodes:
  • CPU: 2
  • RAM: 8 GB
  • HDD: 20 GB
• 4 "data" nodes
  • CPU: 4
  • RAM: 16 GB
  • HDD: 20 GB

Regarding storage characteristics for IXN Server database, refer to PostgreSQL documentation.

Contact your account representative if you need assistance with sizing calculations.

Note: This is 100k of randomized string in a single field in the user data.

Hardware requirements

Genesys strongly recommends the following hardware requirements to run GES with a single tenant. The requirements are based on running GES in a multi-tenanted environment and scaled down accordingly. Use these guidelines, coupled with the callback storage information listed above, to gauge the precise requirements needed to ensure that GES runs smoothly in your deployment.

GES

(Based on t3.medium)

• vCPUs: 1
• Memory: 2 GiB
• Network burst: 5 Gbps

Redis

(Based on cache.r5.large) Redis is essential to GES service availability. Deploy two Redis caches in a cluster; the second cache acts as a replica of the first. For more information, see Architecture.

Callback data is stored in Redis memory.

• vCPUs: 1
• Memory: 8 GiB
• Network burst: 10 Gbps

PostgreSQL

(Based on db.t3.medium)

• vCPUs: 2
• Memory: 4 GiB
• Network burst: 5 Gbps
• Storage: 100 GiB

Sizing calculator

The information in this section is provided to help you determine what hardware you need to run GES and third-party components. The information and formulas are based on an analysis of database disk storage and Redis memory usage requirements for callback data. The numbers provided here include only storage and memory usage for callbacks. Additional storage and memory is required for configuration data and basic operations.

Requirements per callback

Each callback record (excluding user data) requires approximately 6.5 to 7.0 kB of database disk storage, plus additional disk storage for the user data. Each kB of user data consumes approximately 3.0 kB of disk storage.

Each callback record (excluding user data) requires approximately 4.5 to 5.5 kB of Redis memory, plus an additional 1.25 kB for each kB of user data.

Use the following formulas to estimate disk storage and Redis memory requirements:

• Estimate database disk storage requirements for callback data:

  <number of callbacks per day> × (7 kB + (3 kB × <kB of user data per callback>)) × 14 days

• Estimate Redis memory requirements for callback data:

  <number of callbacks per day> × (5.5 kB + (1.25 kB × <kB of user data per callback>)) × 14 days

For example, if a tenant has an average of 100,000 callbacks per day with 1kB user data in each callback:

• The database storage requirement is approximately 14 GB.
• The Redis memory requirement is approximately 9.5 GB.

NOTE: Each callback record is stored for 14 days. If you average about 10k scheduled callbacks every day, and the scheduled callbacks are all booked as far out as possible (that is, 14 days in the future), the number of callbacks to use in storage and memory calculations is 28 days × 10k callbacks per day = 280k callbacks.

Redis operations

The Redis operations primarily update the connectivity status to other services such as Tenant Service (specifically ORS and URS) and Genesys Web Services and Applications (GWS).

When GES is idle (zero callbacks in the past, no active callback sessions, no scheduled callbacks), GES generates about 50 Redis operations per second per GES node per tenant.

Each Immediate callback generates approximately 110 Redis operations from its creation to the end of the ORS session.

For Scheduled callbacks, assuming each callback generates 110 Redis operations when the ORS session is active (based on Immediate callback numbers), there is 1 additional Redis operation for each minute that a callback is scheduled.

For example, if a callback is scheduled for 1 hour from the time it was created, the number of Redis operations is approximately 60 + 110 = 170.

For a callback scheduled for 1 day from the time it was created, it generates approximately 60 × 24 + 110 = 1550 Redis operations, using the following formula for the number of Redis operations per callback:
<number of callbacks> × (110 + <number of minutes until scheduled time>)

Because the longevity of a callback ORS session depends on the estimated wait time (EWT), the total number of Redis operations performed by GES per minute varies, based on both the number of callbacks in the system and the EWT of the callbacks.

Use the following formula to estimate the number of Redis operations performed per minute:
Total number of Redis operations per minute = (50 base GES Redis operations per second × 60 seconds) + <number of upcoming scheduled callbacks in the system> + ((<total number of active callbacks> / <EWT>) × 110)

Where:

• Total number of active callbacks = <number of active immediate callbacks> + <number of active scheduled callbacks>, and
• Number of active scheduled callbacks = (<number of scheduled callbacks per time slot> / <time slot duration>) × <EWT>

For example, let's say we have the following scenario:

• Scheduled callbacks:
  • Time slot duration = 15 minutes
  • Maximum capacity per time slot = 100
  • Business hours = 24x7
  • Assume that all time slots are fully booked for the next 14 days
• Number of active immediate callbacks = 1,000
• Estimated wait time = 90 minutes

Using the preceding formulas, estimate the Redis operations per minute:

• Total number of scheduled callbacks = (100 × (60 / 15)) × 24 × 14 = 134,400
• Number of active scheduled callbacks = (100 / 15) × 90 = 600
• Number of upcoming scheduled callbacks = <total number of scheduled callbacks> - <number of active scheduled callbacks> = (134,400 - 600) = 133,800
• Total number of active callbacks = 1,000 + 600 = 1,600
• Total number of Redis operations per minute = (50 × 60) + 133,800 + ((1,600 / 90) × 110) = 138,756

Redis keys

Each callback creates three additional Redis keys. Given the preceding calculations for Redis memory requirements for each callback, the formula for the average key size is:
(5.5 kB + (1.25 kB × <kB_of_user_data_per_callback>)) / 3

The minimal recommended PVC size is 100GB.

Example usage: https://zhimin-wen.medium.com/local-volume-provision-242affd5efe2

Kubernetes provides a powerful volume plugin system, which enables Kubernetes workloads to use a wide variety of block and file storage to persist data.

You can use the GCXI Helm chart to set up your own PVs, or you can configure PV Dynamic Provisioning in your cluster so that Kubernetes automatically creates PVs.

Volumes Design

GCXI installation uses the following PVC:

Preparing the environment

To prepare your environment, complete the following steps:

1. To log in to the cluster, run the following command:
   • For AKS:

     ?'"`UNIQ--source-0000002D-QINU`"'?

   • For GKE:

     ?'"`UNIQ--source-0000002F-QINU`"'?

   • For OpenShift:

     ?'"`UNIQ--source-00000031-QINU`"'?

     • To check the cluster version on OpenShift deployments, run the following command:

       ?'"`UNIQ--source-00000033-QINU`"'?

2. To create a new project, run the following command:

   GKE or AKS:

   1. Edit the create-gcxi-namespace.json, adding the following values:

      ?'"`UNIQ--source-00000035-QINU`"'?

   2. To apply the changes, run the following command:

      ?'"`UNIQ--source-00000037-QINU`"'?

   OpenShift: ?'"`UNIQ--source-00000039-QINU`"'?

3. For GKE or AKS, to confirm namespace creation, run the following command:

   ?'"`UNIQ--source-0000003B-QINU`"'?

4. Create a secret for docker-registry to pull images from the Genesys JFrog repository:

   ?'"`UNIQ--source-0000003D-QINU`"'?

5. Create the file values-test.yaml, and populate it with appropriate override values. For a simple deployment using PostgreSQL inside the container, you must include PersistentVolumes named gcxi-log-pv, gcxi-backup-pv, gcxi-share-pv, and gcxi-postgres-pv. You must override GCXI_GIM_DB with the name of your Genesys Info Mart data source.

GIM secret volume

In scenarios where raa.env.GCXI_GIM_DB__JSON is not specified, RAA mounts this volume to provide GIM connections details.

1. Declare GIM database connection details as a Kubernetes secret in gimsecret.yaml:

   ?'"`UNIQ--source-00000024-QINU`"'?

2. Reference gimsecret.yaml in values.yaml:

   ?'"`UNIQ--source-00000026-QINU`"'?

Alternatively, you can mount the CSI secret using secretProviderClass, in values.yaml:?'"`UNIQ--source-00000028-QINU`"'?

Config volume

RAA mounts a config volume inside the container, as the folder /genesys/raa_config. The folder is treated as a work directory, RAA reads the following files from it during startup:

• conf.xml, which contains application-level config settings.
• custom *.ss files.
• JDBC driver, from the folder lib/jdbc_driver_<RDBMS>.

RAA does not normally create any files in /genesys/raa_config at runtime, so the volume does not require a fast storage class. By default, the size limit is set to 50 MB. You can specify the storage class and size limit in values.yaml:?'"`UNIQ--source-0000002A-QINU`"'?

   ...

RAA helm chart creates a Persistent Volume Claim (PVC). You can define a Persistent Volume (PV) separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.config.pvc.volumeName value, in values.yaml:?'"`UNIQ--source-0000002C-QINU`"'?

Health volume

RAA uses the Health volume to store:

• Health files.
• Prometheus file containing metrics for the most recent 2-3 scrape intervals.
• Results of the most recent testRun init container execution.

By default, the volume is limited to 50MB. RAA periodically interacts with the volume at runtime, so Genesys does not recommend a slow storage class for this volume. You can specify the storage class and size limit in values.yaml:?'"`UNIQ--source-0000002E-QINU`"'?RAA helm chart creates a PVC. You can define a PV separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.health.pvc.volumeName value, in values.yaml:?'"`UNIQ--source-00000030-QINU`"'?

PostgreSQL — the Info Mart database

The Info Mart database stores data about agent and interaction activity, Outbound Contact campaigns, and usage information about other services in your contact center. A subset of tables and views created, maintained, and populated by Reporting and Analytics Aggregates (RAA) provides the aggregated data on which Genesys CX Insights (GCXI) reports are based.

A sizing calculator for Genesys Multicloud CX private edition is under development. In the meantime, the interactive tool available for on-premises deployments might help you estimate the size of your Info Mart database, see Genesys Info Mart 8.5 Database Size Estimator.

Genesys recommends a minimum 3 IOPS per GB.

For information about creating the Info Mart database, see Before you begin GIM deployment

Create the Info Mart database

Use any database management tool to create the Info Mart ETL database and user.

1. Create the database.
2. Create a user for all of the Genesys Info Mart services to use. Grant that user full permissions for the database.

   This user’s account is used by Info Mart jobs to access the Info Mart database schema.

   The name of the Info Mart schema name is public.

   Important

   Make a note of the database and user details. You need this information when you configure GIM and GCA Helm chart override values.

Object storage — Data Export packages

The GIM Data Export feature enables you to export data from the GIM database so it is available for other purposes. Unless you elect to store your exported data in a local directory, GIM data is exported to an object store. GIM supports export to either Azure Blob Storage or the S3-compatible storage provided by Google Cloud Platform (GCP).

If you want to use S3-compatible storage, follow the Before you begin GSP deployment instructions for GSP to create the S3-compatible storage for GIM.

If you are not using obect storage, you can configure GIM to store exported data in a local directory. In this case, you do not need to create the object storage.

GSP uses S3-compatible storage to store persisted data. You must provision this S3-compatible storage in your environment.

By default, GSP is configured to use Azure Blob Storage, but you can also use S3-compatible storage provided by other cloud platforms. Genesys expects you to use the same storage account for GSP and GCA.

Create S3-compatible storage

Genesys Info Mart has no special requirements for the storage buckets you create. Follow the instructions provided by the storage service provider of your choice to create the S3-compatible storage.

• For GKE, see the Google Cloud Storage documentation about creating bucket storage.
• For AKS, see Azure Storage documentation about creating blob storage.

To enable the S3-compatible storage object, you populate Helm chart override values for the service (see ). To do this, you need to know details such as the endpoint information, access key, and secret.

Logs Volume

The logs volume stores log files:

• To use the persistent volume, set the log.volumeType to the pvc.
• To use the local storage, set the log.volumeType to the hostpath.

Genesys Pulse Collector Health Volume

Genesys Pulse Collector health volume provides non-persistent storage for store Genesys Pulse Collector health state files for monitoring.

Stat Server Backup Volume

Stat Server backup volume provides disk space for Stat Server's state backup. The Stat Server backup volume stores the server state between restarts of the container.

SIP Cluster Service

VoiceMail Service

For more information, see Storage requirements in the Configure and deploy Voicemail section of this guide.

Persistent Volume and Persistent Volume Claim will be created if they are configured. The size for them optional and should be adjusted according to log rate described below:

Gateway:

idle: 0.5 MB/hour per agent

active call: around 0.2MB per call per agent.

Example: For 24 full hours of work, where each agent call rate is constant and is around 7 to 10 calls per hour, we will require around ~500GB for 1000 agents, with around ~20GB being consumed per hour.

CoTurn:

For 1000 connected agents, the load rate is approximately 3.6 GB/hour which scales linearly and increases or decreases with the number of agents and stays constant whether calls are performed or not.