This section describes every Operation and Maintenance (OAM) interface used to access and manage CUDB. An overall view of these interfaces is shown in FigInterfaces. More information on each interface is available in the following chapters.

This section describes the tools used to access and configure CUDB.

The CUDB system supports the import of LDAP data from LDAP Data Interchange Format (LDIF) files to the database, and also the export of data from the database to LDIF files. Refer to CUDB Import and Export Procedures for further information.

Import and export can also be performed by LDAP interface. This is commonly used for smaller amounts of data. Refer to Adding and Searching LDAP Data for more information.

To perform addition or search of data, stored in CUDB, using the LDAP interface, standard LDAP clients with access to CUDB traffic network can be used.

The following chapters contain information about Open LDAP tools ldapadd and ldapsearch, which are delivered with CUDB, to perform these operations.

The Schema Tools software provides an easy-to-use graphical interface to create and edit LDAP schemas. For further information, refer to CUDB LDAP Schema Management Graphical User Interface.

For further information, refer to CUDB LDAP Schema Management Graphical User Interface.

CUDB provides methods for changing LDAP application schemas by adding new object classes, or adding new attributes to already existing object classes. It is also possible to define indexes on new attributes, no matter if they belong to a new or an already existing object class. CUDB also provides methods to add new application schemas.

In general, starting a gracefully shut down CUDB node requires no special procedures other than powering it on, and handling the alarms that may be raised (and remain raised) after the node is back online.

In general, starting a CUDB node after shutting it down requires no special procedures other than powering it on, and handling the alarms that may be raised (and remain raised) after the node is back online. This also applies if the node is restarted after a power failure.

In certain cases (such as large-scale power outages) it can happen that the entire CUDB system must be started up.

Node graceful shutdown allows to manually turn off a CUDB node.

If a CUDB node is disabled in a CUDB system, it can be enabled again if the following conditions are met:

• The configuration of the CUDB node to be enabled again (in short, the "target CUDB node") must contain all information related to the rest of the CUDB nodes present in the system.

• The configuration of the rest of the CUDB nodes in the system must contain all the information on the target CUDB node and its PLDB/DSG units.

If a DSG was created recently, or it was deactivated earlier, it must be activated before using it.

If a CUDB node is added to a CUDB system, the situation can look as follows from the perspective of the DSGs:

• A deactivated DSG is added again to the system.

• A new DSG is added to the system.

Both scenarios are covered in the following sections.

Specific DSG can be disabled or enabled for provisioning of Distribution Entries (DEs). Once provisioning for a DSG is disabled, new entries cannot be created through subscription creation nor through subscription reallocation.

To disable a specific DSG for provisioning, execute the command cudbDsgProvisioningManage in one node of the CUDB system:

cudbDsgProvisioningManage -d <DSGId>”

For further information on this command, refer to the Managing DSG for Provisioning section of CUDB Node Commands and Parameters. For further information on subscription reallocation, see Configuring Subscription Reallocation.

Execute the following command to list all master PLDB and DSG replicas:

cudbSystemStatus -R

For further information on this command, refer to CUDB Node Commands and Parameters.

CUDB supports the global configuration of the default geographical zone.

Perform the procedure described in Setting the Default Geographical Zone on every CUDB node to set the default geographical zone. Refer to CUDB Multiple Geographical Areas for more information on geographical zones.

CUDB supports the global configuration of custom distribution policies for Distribution Entries (DEs).

CUDB supports the global check of the custom distribution policies configured for DEs.

Perform the procedure described in Checking The Custom Distribution Policy of DEs on every CUDB node to check the custom distribution policy of DEs.

CUDB supports the global restore of the custom distribution policies configured for DEs.

CUDB supports the global activation and deactivation of notifications.

CUDB supports the global deactivation of specific notifications.

CUDB supports the global increase of space for a Binary Large Object (BLOB) in the disk storage system.

Subscription Reallocation (also known as "reallocation") makes it possible to move stored data from one DSG to another.

Reallocation can be executed by moving away a specified percentage of DS entries from source DSG or by providing a list of entries to be moved to the specified destination DSG. Refer to CUDB Subscription Reallocation for more information about reallocation and to CUDB Node Commands and Parameters for more information about the options of the cudbReallocate command.

Performing a backup in the CUDB system is recommended before running the reallocation. Refer to CUDB Backup and Restore Procedures for more information.

Defragmentation is aimed to reorganize the way memory is stored in the PLDB or DS units of the target DSG, to reduce the number of memory gaps.

It is recommended to execute defragmentation during low traffic hours, taking into account that the process may take up to a few hours to finish.

Do not run backup and defragmentation at the same time.

CUDB is able to send notifications to the Ericsson Provisioning Gateway (PG) nodes for provisioning to be stopped during procedures such as system data backup or software upgrade.

For more information on stopping provisioning during backup, refer to CUDB Backup and Restore Procedures.

The prerequisite for sending PG notifications is that CUDB nodes are updated with the latest PG configuration information in case there is any change in the PGs connected to the CUDB system. This includes adding or removing PG nodes, or changing the IP address of an existing PG node.

This section describes how to move the mastership of a DSG or PLDB to a preferred node as part of a planned master change.

To perform the mastership change, log in to the target node (where the master replica is to be hosted) and execute the following command:

cudbDsgMastershipChange

Refer to CUDB Node Commands and Parameters for more information on the command.

CUDB supports the global update of the LDAP schema.

The process of activating a DS Unit depends on whether the unit plays a local or remote role in a CUDB node.

• To activate a local DS Unit in a CUDB node, see Activating a DS Unit in a Local CUDB Node.

• To activate the same DS Unit in the rest of the CUDB nodes as a remote node, see Activating a DS Unit in a Remote CUDB Node.

The process of deactivating a DS Unit depends on whether the unit plays a local or remote role in a CUDB node.

• To deactivate a local DS Unit in a CUDB node, see Deactivating a DS Unit in a Local CUDB Node.

• To deactivate the same DS Unit in the rest of the CUDB nodes where it acts as remote node, see Deactivating a DS Unit in a Remote CUDB Node.

CUDB is able to automatically change the master to the highest priority DSG or PLDB replica, when the master replica is in a different DSG or PLDB replica. For more information, refer to CUDB High Availability.

To configure Automatic Mastership Change (AMC), modify the CudbAutomaticMasterChange class (refer to the Class CudbAutomaticMasterChange section of CUDB Node Configuration Data Model Description) in the configuration model as follows:

• To enable or disable AMC, set the enabled attribute to the corresponding value of true or false.

• To change the maximum replication delay, modify the maxReplicationTimeDelay attribute. The value of the attribute is the number of milliseconds. Refer to the Class CudbAutomaticMasterChange section of CUDB Node Configuration Data Model Description for the default value.

• To change the time window, in which AMC is running, modify the attributes timeWindowStart and timeWindowEnd, as described in the Class CudbAutomaticMasterChange section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

The LDAP Data Views function supports accessing stored data through customizable views. The function is based on assigning views to LDAP users. If the LDAP user sending a request has an LDAP view assigned by configuration, then that user can access the data through that view.

Refer to CUDB LDAP Data Views Management for detailed information on all the steps required to create, configure, and delete an LDAP view.

CUDB allows to define and manage new OAM users and groups in remote LDAP servers only, in a centralized way, instead of having to create them locally on all CUDB nodes.

Refer to CUDB Security and Privacy Management for more information on how to create and authenticate remote OAM users.

The Optimized Subtree Searches function enables accessing data in subtree searches in a more efficient way. The function is based on assigning subtree search configurations to LDAP users.

Refer to CUDB Optimized Subtree Searches, for detailed information on all the steps required to create, configure, and delete an optimized subtree search.

When a CUDB node is installed , it must be activated before using it.

To activate a CUDB node locally, set the value of the enabled attribute of the corresponding instance of the CudbLocalNode class to true. For more information, refer to the Class CudbLocalNode section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

Before activating a previously deactivated CUDB node locally, it must be activated remotely in the rest of the CUDB nodes of the system.

To activate a CUDB node remotely, set the value of the enabled attribute of the corresponding instance of the CudbRemoteNode class to true. For more information, refer to the Class CudbRemoteNode section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

The name of a CUDB node can be modified after installation.

To modify the name of a CUDB node, change the value of the networkElementName attribute of the corresponding instance of the CudbLocalNode class. For more information, refer to the Class CudbLocalNode section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

CUDB provides several ways to check what software is installed on a CUDB node. These methods are described in the next sections.

To deactivate a CUDB node locally, set the value of the enabled attribute of the corresponding instance of the CudbLocalNode class to false. For more information, refer to the Class CudbLocalNode section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

The CUDB system can detect storage system failures on SCs and payload blades or VMs by two mechanisms:

• Monitoring I/O heavy processes (the time spent in D state).

• Probing the file system.

CUDB supports the activation, deactivation of the Storage Performance Monitoring function, and the configuration of the function parameters by modifying the /home/cudb/monitoring/blade/config/cudbHwFaultReaction.json configuration file. Storage Performance Monitoring is enabled by default.

Before using a DS Unit in a DSG, it must be activated.

To activate a DS Unit in a local CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbLocalDs class to true. For more information, refer to the Class CudbLocalDs section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

DS Units in a CUDB node are usually deactivated for maintenance reasons.

To deactivate a DS Unit in a local CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbLocalDs class to false. For more information, refer to the Class CudbLocalDs section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To activate a DS Unit in a remote CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbRemoteDs class to true. For more information, refer to the Class CudbRemoteDs section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To deactivate a remote DS Unit, set the value of the enabled attribute of the corresponding instance of the CudbRemoteDs class to false. For more information, refer to the Class CudbRemoteDs section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

After a CUDB node is deactivated locally, it is necessary to deactivate it also in the rest of CUDB nodes.

To deactivate a remote CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbRemoteNode class to false. For more information, refer to the Class CudbRemoteNode section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

CUDB supports adding new DSGs to a local CUDB node.

The unique values of the attributes of the new DSG must be set according to the following guidelines:

CUDB supports adding new blades or VMs to local CUDB nodes.

After new blades or VMs were added to a CUDB node, the DS Unit must be configured.

When a new DS Unit is added to the CUDB system, it must be configured both on its local node, and also on the rest of the CUDB nodes to recognize it in the entire system.

To deactivate a local PLDB unit in a CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbLocalPl class to false. For more information, refer to the Class CudbLocalPl section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To activate a PLDB unit in a CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbLocalPl class to true. For more information, refer to the Class CudbLocalPl section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To deactivate a PLDB unit belonging to another CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbRemotePl class to false. For more information, refer to the Class CudbRemotePl section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To activate a PLDB unit belonging to another CUDB node, set the value of the enabled attribute of the corresponding instance of the CudbRemotePl class to true. For more information, refer to the Class CudbRemotePl section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To set the default geographical zone in a specific CUDB node, set the value of the defaultZone attribute of the corresponding instance of the CudbSystem class to the new default geographical zone. For more information, refer to the Class CudbSystem section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

CUDB supports restoring the default distribution policy of DEs.

CUDB supports enabling or disabling notifications for all applications.

To enable or disable notifications for all applications, change the enabled attribute of the CudbNotifications class to the corresponding value, true or false in the configuration model. For more information, refer to the Class CudbNotifications section of CUDB Node Configuration Data Model Description.

Refer to CUDB Notifications for further details on the configuration of other parameters related to notifications.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

CUDB can prevent the sending of notifications to a particular application Front End (FE) even if notifications are globally enabled (see Enabling or Disabling Notifications for All Applications).

To achieve this, delete all the corresponding instances of the CudbNotificationEndPoint class related to the specific application FE from the configuration model. For more information, refer to the Class CudbNotificationEvent section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To create a new CUDB LDAP user in a local CUDB node, add a new instance of the CudbLdapUserGroup class to the configuration model. For more information, refer to the Class CudbLdapUserGroup section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To add a new CUDB LDAP user to a local CUDB node, add a new instance of the CudbLdapUser class to the configuration model and set the following mandatory attributes:

• cudbUserPassword

• cudbUserGroup

• readModeInPL

• readModeInDS

Additional optional attributes can also be configured for the LDAP user, each in a new line.

For more information on the CudbLdapUser class, refer to the Class CudbLdapUser section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

CUDB supports the following value combinations for the readModeInPL and readModeInDS LDAP user attributes:

• readModeInPL=LP (Local Preferred) and readModeInDS=MP (Master Preferred).

• readModeInPL=MA and readModeInDS=MA (both Master Always).

• readModeInPL=LP (Local Preferred) and readModeInDS=LP (Local Preferred).

  Note:

  The readModeInDS=LP can be configured only if the Deployment Flexibility Value Package is available.

Once a CUDB LDAP user is created, a set of attributes can be modified. These attributes are listed below:

'countersGroup'

'readModeInPL'

'readModeInDS'

'isProvisioningUser'

'isReProvisioningUser'

'userLdapAuth'

'userLdapHash'

'overloadRejectionWeight'

'cudbUserPassword'

'cudbLdapViewId'

'localReadsDsReplicationDelayThreshold'

Changes for the userLdapAuth, userLdapHash, and cudbUserPassword attributes are described in CUDB Security and Privacy Management.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

PG nodes are configured in CUDB nodes as the destination for backup notifications.

Nodes are separated with "," and addresses for each node are separated with ";".

To delete a CUDB LDAP user from a local CUDB node, delete the appropriate instance of the CudbLdapUser class from the configuration model. For more information, refer to the Class CudbLdapUser section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

To delete a CUDB LDAP user in a local CUDB node, delete the appropriate instance of the CudbLdapUserGroup class from the configuration model. For more information, refer to the Class CudbLdapUserGroup section of CUDB Node Configuration Data Model Description.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

The removal of huge files with the rm Linux command results in instability in blades or VMs. Also, if executed on the SC, input/output resources cannot be accessed by the processes running on it.

Therefore, to avoid stability and performance issues, it is strongly recommended to use the following command instead of rm to remove huge files:

ionice -c 3 ls -1 <files to remove> | sed 's/\(.*\)/sleep 1 \&\& ionice -c 3 rm -fv \1/g' | bash

PG endpoints are configured in the CUDB nodes as destinations for the Provisioning Assurance function interworking.

To change the configuration of an existing notification event, modify the read/write attributes of the corresponding instance of the CudbNotificationEvent class or the class instances it contains.

For example, to change the URI attribute of the notification end point from Example 5, follow the steps below (shown in COM CLI):

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

configure
(config)>ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationEndPoint=1,URI="http://127.0.0.1:4040"
(config)>commit

To remove an instance of the CudbNotificationEvent class, first remove all instances of the classes it contains.

For example, to remove the notification event from Example 5, follow the steps below (shown in COM CLI):

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

configure
(config)>no ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationObjectClass=1,CudbNotificationAttr=1
(config)>commit -s
(config)>no ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationObjectClass=1
(config)>commit -s
(config)>no ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationEndPoint=1
(config)>commit -s
(config)>no ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2
(config)>commit

In CUDB the Differentiated Services (DiffServ) computer networking architecture is used to provide QoS (Quality of Service). The basic principle of DiffServ is the classification of IP packets by applying a special marking on them, that is placing a DSCP mark in the IPv4 TOS field in case of IPv4 protocol, or Traffic Class field in case of IPv6 protocol. Based on this mark, the DiffServ-Aware routers in the DiffServ domain can handle the traffic (Per Hop Behavior) depending on the traffic class which the packet belongs to. After that, QoS is provided by iptables in case of IPv4 and ip6tables in case of IPv6. Using this method, the outgoing packages are marked with the preconfigured DSCP values. Refer to CUDB Node Network Description for more information on the preconfigured values.