Jump to: navigation, search

Configuring Tenant Keyspaces

DESCOPED 4i13 now 4i14

Use these two contact center properties to specify a tenant-specific recording keyspace:
In the array of keyspace defintions keyspaces:

  • Settings Group: recording-provisioning
  • name—keyspace name to use
  • locations —a list of nodepaths that the keyspace applies to

If the keyspace property does not exist, then shared GWS keyspace (sipfs) will be used.

This location-based setting is similar to decrypt-uri-prefix(screen-recording settings group) and local-decrypt-uri-prefix (interaction-recording” settings group).

Technical Notes

If you create a keyspace for each tenant, then the replication strategy, is determined by the business needs of the tenant; for example, specifying the data centers where recording metadata is replicated. You can easily alter this replication strategy as a specific tenant's business needs change, without impacting other tenants.

Creating a Keyspace for Use by a Tenant

Keyspace Naming Protocol

Using a consistent naming format makes the naming procedure automatable.
Genesys recommends this format:
irfs_<tenant ID minus dashes> Example:
If the tenant ID is
1a2b3c4d5e-6f7g8h9i0
then the keyspace name should be
irfs_1a2b3c4d5e-6f7g8h9i0

Specifying Data Centers

Data centers are determined by deployment. If the customer spans across multiple data centers, or they have a Disaster Recovery data center in addition to their main data center, then include all the data centers the customer is deployed in, plus all their DR data centers.

If the customer is deployed in only one data center with no DR, their data should be replicated to one additional data center, for durability.

Running the Commands

For Two Data Centers

To create a keyspace for a pair of data centers, SSH into a Cassandra node on any data center and execute:

$ sudo su ¬# cqlsh 'hostname' > SELECT * FROM system.schema_keyspaces WHERE keyspace_name = 'sipfs'; 
The output of the SELECT should look similar to: 
keyspace_name| durable_writes | strategy_class | strategy_options ---------------+----------------+----------------------------------------¬-------------+-----------------------------------------------------------¬
sipfs | True | org.apache.cassandra.locator.NetworkTopologyStrategy | {''<data center name 1>'':<replication factor 1>, ..., ''<data center name n>'':<replication factor n>} 

…where are the data centers where all possible alternate keyspaces will be replicated to, and <replication factor 1><replication factor n> are positive integers.

Then execute:

> CREATE KEYSPACE irfs_<modified-tenant-id> WITH replication = {'class':'NetworkTopologyStrategy', ''<data center name x>'':<replication factor x>, ''<data center name y>'':<replication factor y>}; > exit; 

…where:

  • <modified-tenant-id> is the tenant ID for which the keyspace is being created with all '-' removed.
  • :<replication factor x> and :<replication factor y> are key-value pairs taken from the output of the SELECT statement above, for the two data centers selected for the tenant.

For example:

> CREATE KEYSPACE irfs_a1b84664297d484185960d1c1f78be68 WITH replication = {'class':'NetworkTopologyStrategy', "usw1": 3, "use1": 3}; > exit; 

For More than Two Data Centers

To running the command for more than two data centers, add more key-value pairs from the output of the SELECT statement above for the additional data centers required by the tenant.

For example:

> CREATE KEYSPACE irfs_711ba95be2704543a5e57d264e5ae90f WITH replication = {'class':'NetworkTopologyStrategy', "usw1": 3, "use1": 3, "aps1": 3}; > exit; 

OR

> CREATE KEYSPACE irfs_f0268459ad824b309810c0c9249ff306 WITH replication = {'class':'NetworkTopologyStrategy', "usw1": 3, "use1": 3, "euw1": 3, "euw2": 3, "aps1": 3}; > exit; 

Altering a Keyspace for Use by a Tenant

As a growing tenant deploys additional data centers, recording metadata must be replicated into these data centers. The tenant must alter a keyspace's replication factor to include the existing data center key-value pairs, as well as the additionally required data center key-value pairs taken from the SELECT output above. The steps are the same as creating a keyspace, but instead of the CREATE verb, use the ALTER verb:

> ALTER KEYSPACE irfs_<modified-tenant-id> WITH replication = {'class':'NetworkTopologyStrategy', ''<data center name x>'':<replication factor x>, ''<data center name y>'':<replication factor y>, ''<data center name z>'':<replication factor z>}; > exit; 

where:

  • <modified-tenant-id> is the tenant ID for which the keyspace is being created with all '-' removed,
  • :<replication factor x>, :<replication factor y> and :<replication factor z> are key-value pairs taken from the output of the SELECT statement above for the data centers selected for the tenant.

For example:

> ALTER KEYSPACE irfs_a1b84664297d484185960d1c1f78be68 WITH replication = {'class':'NetworkTopologyStrategy', "usw1": 3, "use1": 3, "aps1": 3}; > exit; 

Note: You must run nodetool repair on each node of each data data center that was introduced for a keyspace; this will cause all data within the keyspace to be replicated to those nodes.

This page was last edited on December 20, 2018, at 14:14.
Comments or questions about this documentation? Contact us for support!