Following are different types of CUDB data, depending on the nature of data, and distribution property:

• Data Store (DS) data:

  Subscription data for the different application Front Ends (FEs) accessing the CUDB. The subscriber data is the minimum set of data that cannot be partitioned and which is accessed by one or more unique identifiers.

• Processing Layer (PL) data:

  • Identity data: set of identifiers to access the subscriber data. This can be any kind of identifier such as IMSI, IP address, URI, and so on.

  • Distribution Entry (DE) data: contains internal distribution data used by CUDB to locate DS data within the distributed system.

  • Other PL data.

Figure 1 shows the data types and the CUDB node data architecture.

The CUDB node data architecture is based on a set of "in memory databases" storing all these types of data in the following ways:

• DS data is partitioned and distributed across the different databases hosted in the same or in different CUDB Nodes. These databases are called DS units. In this way, different CUDB nodes store different partitions of the subscriber data and there can be CUDB nodes containing not all of the partitions but only a set of the whole distributed database.

• PL Data is stored in a unique database called the Processing Layer Database (PLDB).

For more information on capacity configuration and scalability, refer to CUDB Data Storage Handling.

DS data, once stored, can be redistributed between the different DS units in the system. For more information, refer to CUDB Subscription Reallocation.

The CUDB system is a set of CUDB Nodes interconnected by the IP Backbone as shown in Figure 2.

The CUDB system provides seamless access to the whole distributed database through any CUDB node which has connected an application FE (established Lightweight Directory Access Protocol (LDAP) session).

If CUDB nodes are located in different geographical sites, then distributed data is also geographically distributed.

CUDB supports geographical redundancy so that geographically distributed data can be replicated in one or two other DS units hosted in different CUDB sites within the CUDB system.

The set of DS units storing same replicating data is a DS Unit Group (DSG).

For more information on geographical redundancy, refer to CUDB High Availability.

The LDAP Data Views function supports accessing stored data through customizable views.

Virtual entries are composed of real attributes mapped into virtual attributes, which are grouped into virtual object classes, and those into virtual entries. LDAP users that have a view assigned to them cannot see the core Directory Information Tree (DIT), only the virtual tree. Access to CUDB data through a view supports the same LDAP requests as through the core DIT, but restrictions apply on write operations to ensure data and schema rules integrity. For more details, refer to CUDB LDAP Data Views.

CUDB provides an LDAP interface. The data stored in CUDB is managed as an LDAP DIT. Different type of data is stored in different branches in the DIT.

DIT entries whose descendants store distributed data are called DEs.

CUDB identifies DEs in the DIT based on the branch where the entry instance is stored. The branches can be configured differently.

Figure 3 shows an example of the DIT.

For more information on CUDB DIT and DE configuration, refer to CUDB LDAP Interwork Description.

The default distribution mechanism selects a DSG using a probability function where every DSG is assigned a weight based on its level of occupancy. The occupancy level of a DSG corresponds to the memory level of the most occupied replica.

This distribution mechanism allows the specification, at provisioning time, of a geographical zone (if GeoZones is enabled).

This is specified by the ZoneId attribute received in the LDAP request, as follows:

• If the ZoneId attribute is received and the specified zone is valid, then only the DSGs belonging to that zone are evaluated.

• If the ZoneId attribute is not received and a default zone is configured in the system, only the DSGs belonging to the default zone are evaluated.

• If the ZoneId attribute is not received and a default zone is not configured in the system, all DSGs in the system are evaluated.

For more information on CUDB multiple geographical zones, refer to CUDB Multiple Geographical Areas.

For each available DSG, the following value is calculated:

(random-number MODULUS (max_mem_usage - DSGx occupancy)) + 1

See the following definitions of the terms above:

The system selects the DSG with the highest value obtained.

The custom data distribution mechanism allows the specification of a customized dynamic library that is loaded at system start-up and whose custom function results a target DSG where that specific DE instance must be assigned.

The custom function receives the following set of information from the CUDB:

• Values of the attributes received in the distributed data to be stored. This changes depending on the entry.

• Dynamic information:

  • Memory use of each DSG.

  • List of DSGs that are disabled for provisioning.

• Configuration data:

  • Zone definitions

  • Default zone

  • Maximum occupancy level for a DSG.

This function can be extended to use any information from any external source.

For more details on the use of dynamic library for distribution, refer to CUDB Dynamic Library for Distribution.

Data distribution policy overwrite mechanism allows the specification, at provisioning time, of destination DSG where descendants of that specific DE entry is to be allocated.

This is specified by DSUnitGroup attribute received in the LDAP request. For more information on CUDB DIT and DE configuration, refer to CUDB LDAP Interwork Description.

The reception of this attribute overrides any other mechanism.

CUDB subscription reallocation applies once data is distributed and stored between the different DSGs in the system.

CUDB supports administrative redistribution between DSGs in the system for the distributed data stored in the CUDB system. That is, CUDB administratively moves stored data from one DSG to other DSGs. It is also possible to use it for higher level movements than DSG (node, site, or zone) by a proper handling of origin and target DSGs.

For more details on this feature, refer to CUDB Subscription Reallocation.

CUDB supports the disabling and enabling of a specific DSG for provisioning.

A provisioning-disabled DSG is not involved in any of the mechanisms for data distribution.

Since the DSG0 is the PL, it must be avoided as a possible candidate for storing distributed data. For this reason, the parameter must not accept DSG0 as a possible value.

Specifically in overwrite mechanism, if the DSG id received in the LDAP operation identifies a DSG which is provisioning-disabled the operation is rejected with an error code 53 LDAP unwilling to perform.

The distributedEntryPattern attribute, class CudbLdapAccess, configures the DEs. It specifies which entries are considered DEs in the CUDB.

When a DE is provisioned, both of the optional attributes ZoneId and DSUnitGroup must be defined in any of the objectClasses belonging to that entry.

The use of custom distribution is enabled or disabled.

The customDistributionPolicyEnabled attribute, class CudbLdapAccess, indicates that a custom distribution policy library is loaded. When this attribute is changed to true, the library is loaded and when changed to false, the library is unloaded.

For more information on attributes, refer to CUDB Node Configuration Data Model Description and for further instructions, refer to CUDB System Administrator Guide.

CUDB supports the disabling and enabling of a specific DSG for provisioning by cudbDsgProvisioningManage command. For more information on this command, refer to CUDB Node Commands and Parameters.

For further instructions on how to check the DSGs configured in the system, refer to CUDB System Administrator Guide.