3 cnDBTier Features

This chapter describes the key features of cnDBTier.

3.1 Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) encrypts data at the storage layer, that is the files stored in the disk or PVC of the data nodes. TDE encrypts and decrypts data dynamically as it is written to or read from the storage, without requiring any modifications to the application’s code. This guarantees that the sensitive data stored in the database files on disk remains encrypted while at rest, offering a crucial security layer against unauthorized access, particularly in situations where physical security controls fail.

Enabling TDE slightly increases the restart time of the data nodes as TDE handles encryption and decryption dynamically. The following table provides information about the time taken for the data nodes to restart when TDE is enabled or disabled, considering different data sizes in each data node:

Table 3-1 Data Node Restart Time When TDE is Enabled or Disabled

Data Size Per Node (in GB)	TDE Enabled or Disabled	Average Restart Time (in seconds)	Increase in Restart Time when TDE is Enabled (in percentage)
10	Disabled	166.5	NA
10	Enabled	181.5	9%
20.7	Disabled	216	NA
20.7	Enabled	242.5	12.27%
30	Disabled	329	NA
30	Enabled	349.75	6.32%
37	Disabled	376	NA
37	Enabled	397.5	5.72%

Note:

Analysis and testing reveal that enabling TDE increases the restart time of data nodes by an average of 8.33%. Ensure that you understand the performance impact while using TDE for data encryption.

Managing Transparent Data Encryption (TDE)

The following sections provide details about managing Transparent Data Encryption (TDE):

Enabling Transparent Data Encryption (TDE)

You can enable or disable the TDE feature using the /global/ndb/EncryptedFileSystem parameter in the custom_values.yaml file. For more information about enabling and disabling this feature, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Configuring Transparent Data Encryption (TDE)

Before enabling TDE, you must create the necessary secrets that are used to encrypt the data in data nodes. For information about creating secrets for TDE, see the "Creating Secret" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

3.2 Support for CNE Cloud Native Load Balancer (CNLB)

cnDBTier supports network segregation using CNE Cloud Native Load Balancer (CNLB) to effectively manage ingress and egress traffic flows in the system. CNLB is an alternate solution to the existing LBVM solution. To leverage this feature, you must perform the following configurations:

1. Configure the ingress and egress destination subnet addresses in the cnlb.ini file before installing CNE. For more information about ingress and egress destination subnet addresses, see the Ingress and Egress Communication Over External IPs section.
2. Configure the required traffic segregation details in the custom_values.yaml file before installing cnDBTier.

Managing Cloud Native Load Balancer (CNLB)

The following sections provide details on managing the CNLB feature:

Enabling or Disabling CNLB

As CNLB is powered by CNE, you can enable or disable CNLB while installing CNE. For more information about enabling and configuring CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Configuring CNLB for cnDBTier Traffic Segregation

Depending on your requirement, you must perform the following configurations to use CNLB network segregation:

• To use network segregation for active and standby replication channels, configure the required CNLB annotations for ndbmysql pods in the custom_values.yaml file.
• To allow communication between local and remote site replication pods over a separate network, configure CNLB ingress or egress annotations for the db-replication-svc pods in the custom_values.yaml file.

For more information about configuring CNLB for traffic segregation, see the "Configuring Cloud Native Load Balancer" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

3.3 Multithreaded Applier (MTA)

The Multithreaded Applier (MTA) feature provides the functionality allows independent binlog transactions to be run in parallel at a replica thereby increasing the peak replication throughput. NDB replication is modified to support the use of generic MySQL server MTA mechanism.

Managing Multithreaded Applier (MTA)

The following sections provide details on managing the MTA feature:

Enabling or Disabling MTA

You can enable or disable the MTA feature using the replica_parallel_workers parameter in the custom_values.yaml file. This feature is disabled when replica_parallel_workers is set to 1 and enabled when the parameter is set to a value greater than 1. This feature is disabled by default. For more information on this parameter, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

You can refer to the following sample configurations to enable or disable MTA in the custom_values.yaml file:

Sample configuration to enable MTA:

global:
  additionalndbconfigurations:
    mysqld:
      replica_parallel_workers: 4
      binlog_transaction_dependency_tracking: "WRITESET"
      ndb_log_transaction_dependency: 'ON'

Sample configuration to disable MTA:

global:
  additionalndbconfigurations:
    mysqld:
      replica_parallel_workers: 1
      binlog_transaction_dependency_tracking: "COMMIT_ORDER"
      ndb_log_transaction_dependency: 'OFF'

For more information on the MTA feature, see MySQL documentation.

Configuring MTA

Additional configurations are not applicable to this feature.

3.4 TLS Support for Georeplication

Until now, cnDBTier provided support to configure the replication SQL pods manually to establish Transport Layer Security (TLS) for georeplication between cnDBTier sites. With this feature, cnDBTier automates the process of configuring TLS for georeplication between cnDBTier sites.

On enabling this feature, cnDBTier performes or supports the following operations:

• The replication SQL pod uses the certificates provided or configured to establish an encrypted connection for georeplication. This encrypted connection remains throughout the life cycle of the replication. When the replication breaks and a switchover occurs, the standby replication SQL pod establishes a new replication channel using the given certificates and provides the encrypted connection.
• cnDBTier reestablishes the TLS connection after a fault recovery. That is, when a fault recovery completes successfully, the system reestablishes the encrypted connection between the replication channels. This ensures that the TLS is kept intact even after a fault recovery.
• cnDBTier supports maintaining separate certificates for each replication channel groups and each site replicating to other site.
• cnDBTier supports maintaining list of chipers used for replication.

Managing TLS Support for Georeplication

The following sections provide details on managing TLS support for georeplication:

Enabling TLS Support for Georeplication

You can enable or disable the TLS feature using the custom_values.yaml file. While enabling TLS, you must also provide the necessary certificates for the respective ndbmysqld pods in the custom_values.yaml file. For the procedure to enable TLS and provide the required certificates, see Enabling TLS for Georeplication.

Modifying cnDBTier Certificates for TLS Support

You can modify the cnDBTier certificates that the system uses to establish an encrypted connection between georeplication sites using TLS. For procedure, see Modifying cnDBTier Certificates to Establish TLS Between Georeplication Sites.

3.5 Network Policies

Network Policies is an application-centric construct that allows cnDBTier pods to control or restrict the incoming and outgoing network traffic. This ensures security and isolation of services within a Kubernetes cluster.

Network Policies creates pod-level rules to specify how pods (Containers) in a Kubernetes cluster communicate with each other and with external resources. cnDBTier uses Network Policies on the pods to enhance the security and control both incoming and outgoing traffic effectively. For more information about Network Policies, see Kubernetes Network Policies documentation.

Enabling and Configuring Network Policies

You can enable or disable network policies for different pods using the network policy parameters in the custom_values.yaml file. For more information about enabling or disabling this feature for cnDBTier pods, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

3.6 REST APIs for CNC Console

cnDBTier supports CNC Console to integrate cnDBTier functionalists on CNC Console GUI. To enable this feature, cnDBTier exposes REST APIs. CNC Console uses these REST APIs to integrate cnDBTier data on CNC console GUI.

For detailed information about the REST APIs, see cnDBTier APIs for CNC Console.

Network Functions (NFs) can integrate cnDBTier on CNC Console to perform the following (but not limited to) operations:

• Checking the status of cnDBTier cluster or georeplication.
• Checking the list of completed backups.
• Checking cnDBTier version.
• Checking the health status of cnDBTier services such as replication service, monitor service, data service, and backup manager service.
• Initiating on-demand backup.
• Performing georeplication recovery.

To integrate and customize cnDBTier on CNC Console, NFs must configure the menuCncc.json file as shown in the following example:

{
  "menu": {
    "routeConfig": {
      "home": {
        "label": "Home",
        "value": "home",
        "isDefault": true
      },
      "commonServices": {
        "label": "Common Services",
        "value": "commonServices",
        "isDefault": true
      },
      "services/{nf}/{service}": {
        "label": "Services",
        "value": "services"
      },
      "configurations/{nf}/{configType}": {
        "label": "Configurations",
        "value": "configurations"
      }
    },
    "menuItems": [
      {
        "attr": {
          "id": "cnDBTier",
          "name": "cnDBTier",
          "sequence": 10
        },
        "children": [
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-backupList",
              "name": "Backup List",
              "sequence": 10
            }
          },
          {
            "attr": {
              "id": "cnDBTierHealth",
              "name": "cnDBTier Health",
              "sequence": 20
            },
            "children": [
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-backupHealthStatus",
                  "name": "Backup Manager Health Status",
                  "sequence": 100
                }
              }, 
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-monitorHealthStatus",
                  "name": "Monitor Health Status",
                  "sequence": 110
                }
              },
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-ndbHealthStatus",
                  "name": "NDB Health Status",
                  "sequence": 120
                }
              },
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-replicationHealthStatus",
                  "name": "Replication Health Status",
                  "sequence": 130
                }
              }
            ]
          },
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-version",
              "name": "cnDBTier Version",
              "sequence": 30
            }
          },
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-databaseStatisticsReport",
              "name": "Database Statistics Report",
              "sequence": 40
            }
          },
          {
            "attr": {
              "id": "GeoreplicationRecovery",
              "name": "Georeplication Recovery",
              "sequence": 50
            },
            "children": [
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-updateClusterAsFailed",
                  "name": "Update Cluster As Failed",
                  "sequence": 100
                }
              },
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-startGeoreplicationRecovery",
                  "name": "Start Georeplication Recovery",
                  "sequence": 110
                }
              },
              {
                "attr": {
                  "id": "services/<NF Name>/dbconfig-georeplicationRecoveryStatus",
                  "name": "Georeplication Recovery Status",
                  "sequence": 120
                }
              }
            ]
          },
          {
            "attr": {
              "id": "configurations/<NF Name>/dbconfig-geoReplicationStatus",
              "name": "Georeplication Status",
              "sequence": 60
            }
          },
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-clusterStatus",
              "name": "Local Cluster Status",
              "sequence": 70
            }
          },
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-onDemandBackup",
              "name": "On Demand Backup",
              "sequence": 80
            }
          },
          {
            "attr": {
              "id": "services/<NF Name>/dbconfig-heartBeatStatus",
              "name": "Replication HeartBeat Status",
              "sequence": 90
            }
          }
        ]
      }
    ]
  }
}

References:

• For procedures to perform georeplication recovery using CNC Console, see the "Restoring Georeplication (GR) Failure" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
• For information about CNC Console GUI, see Oracle Communications Cloud Native Configuration Console User Guide.
• For more information about integrating cnDBTIer APIs on CNC Console for a specific NF, see the respective NF documents.

3.7 PVC Health Monitoring

The platform-level issues and hardware failures impact the PVC health that in turn impacts the cnDBTier health. Before implementing this feature, to identify any PVC issues, you must wait for the MySQL Cluster processes to log an error. With this feature, cnDBTier provides options to monitor the health of PVCs that are mounted on cnDBTier pods.

Managing PVC Health Monitoring

The following sections provide details about managing PVC Health Monitoring:

Enabling and Configuring PVC Health Monitoring

You can enable or disable PVC Health Monitoring using the PVC health global parameters available in the custom_values.yaml file. For more information about enabling or disabling this feature, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Monitoring PVC Health Through Metrics and Alerts

PVC Health Monitoring facilitates each pod to monitor its PVC and pass the PVC health condition to the monitor service. The monitor service combines this data and produces metrics for each PVC's health. For information about PVC Health Monitoring metrics, see cnDBTier Metrics.

3.8 cnDBTier Automated Backup

The cnDBTier backup service creates and safely stores DB backups periodically so that the user can always have a relatively recent copy of the data, to recover from cnDBTier fault scenarios. cnDBTier backup service works on per MySQL cluster data node basis. Each data node creates a backup of the hosted data and maintains a copy of the backup.

The automatic backup runs when all the DB nodes are running. The retention period and frequency of the backup are configurable. The status of the DB backups taken is stored in the DB nodes and is available to DB monitor service to include in metrics. The following table describes these parameters and their default values.

Table 3-2 DB Backup Service

Parameter	Units	Default	Description
backup_period	integer	1	The number of days between each backup.
num_backups_to_retain	integer	3	The number of backups to retain. Recommended number of backups is at least 3. This ensures at least one backup remains, in case the automated backup system force purges additional backups, due to backup size growth.

The status of the DB backups is stored in the DB nodes and is accessible to the DB Monitor service. The service includes the status in the metrics.

3.9 cnDBTier Password Encryption

cnDBTier provides the password encryption feature to encrypt for replication username and password stored in the database to ensure that the passwords are secure and are not exposed. When the password encryption feature is enabled, the replication username and password are encrypted throughout the life cycle of cnDBTier unless the feature is disabled.

Managing cnDBTier Password Encryption

The following sections provide details about managing cnDBTier password encryption:

Enabling cnDBTier Password Encryption

You can enable or disable the cnDBTier password encryption feature using the /global/encryption/enable parameter in the custom_values.yaml file. For more information about enabling and disabling this feature, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Configuring cnDBTier Password Encryption

Before enabling cnDBTier password encryption, you must create the necessary secrets that are used to encrypt the passwords. For information about creating secrets for password encryption, see the "Creating Secret" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

You can modify the encryption key used to encrypt the replication username and password. For the procedure to modify the password encryption key, see the Modifying cnDBTier Password Encryption Key section.

3.10 Database Backup Encryption and Secure Transfer

cnDBTier supports creation of database backups at configured intervals. It's important to encrypt the backups as they contain sensitive subscriber data that are transferred to remote servers and sites for performing fault recovery. cnDBTier uses the encrypt and decrypt options provided by MySQL NDB cluster to encrypt the on-demand or periodic backups at the cluster level.

cnDBTier provides the functionality to securely transfer the backups stored in the data nodes to remote sites using Secure File Transfer Protocol (SFTP). This ensures that there is no loss of backups due to purging in cnDBTier as the backups are stored in remote servers. The backups in the remote server are saved under the <Path of the remote server configured in custom values file (/global/remotetransfer/remoteserverpath) >/<site name of cnDBTier> path in the following formats:

• backup_<backup_id>_Encrypted.zip if Backup encryption is enabled
• backup_<backup_id>_Unencrypted.zip if Backup encryption is disabled

Managing Database Backup Encryption and Secure Transfer

The following sections provide details about managing database backup encryption and secure backup transfer:

Enabling Database Backup Encryption

Each cnDBTier cluster has an option to enable or disable the backup encryption independently. You can enable or disable the database encryption using the /global/backupencryption/enable parameter in the custom_values.yaml file. For more information about enabling and disabling this feature, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

When this feature is enabled, the backup data record and log files written by each data node are encrypted using the password present in the "occne-backup-encryption-secret" secret and a Salt that is randomly generated using a key derivation function (KDF) that employs the PBKDF2-SHA256 algorithm to generate a symmetric encryption key for that file.

Configuring Database Backup Encryption

You must provide the required credentials to encrypt the backups when the backup is initiated (on-demand backups, periodic backups, or backups initiated during restore georeplication). cnDBTier uses secret keys to encrypt database backups. You can configure these keys using Kubernetes secret during the installation. When the START BACKUP command is initiated, the DB backup manager service reads these keys and initiates the backup using the encrypt password(ENCRYPT PASSWORD=password). For information about creating secrets for encrypting backups, see the "Creating Secret" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

cnDBTier provides an option to modify the backup encryption password when required. For information about modifying cnDBTier backup encryption password, see Modifying cnDBTier Backup Encryption Password.

Note:

The password used for encryption must follow the cnDBTier password requirement or standard.

Enabling Secure Backup Transfer

You can enable or disable secure backup transfer using the /global/remotetransfer/enable parameter in the custom_values.yaml file. For more information about enabling and disabling this secure backup transfer, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Configuring Secure transfer of backups to Remote Server

cnDBTier requires the remote server configurations to securely transfer backups. You can use the custom_values.yaml file to configure the details about remote servers such as remote server IP, port, and path. These configurations can be done during an installation or upgrade. For more information about configuring the remote server details, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

cnDBTier uses SSH key and username to securely transfer backups to remote servers. You can configure these keys and username using Kubernetes secret during the installation or upgrade. For information about creating secrets for secure backup transfer, see the "Creating Secret" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

cnDBTier also provides an option to modify the remote server configurations, such as IP, port, path, usernname, and SSH key in cnDBTier. For more information about modifying remote server configurations in cnDBTier, see Modifying Remote Server Configurations for Secure Transfer of Backups.

Note:

Currently, cnDBTier doesn't support using the remote server backups for performing any restore or recovery procedures.

3.11 Node Selector and Node Affinity

The Node Selector and Node Affinity feature allows the Kubernetes scheduler to determine the type of nodes in which the cnDBTier pods are to be scheduled, depending on the predefined node labels or constraints. cnDBTier uses nodeSelector and nodeAffinity options to schedule cnDBTier pods to specific worker nodes.

nodeSelector is the basic form of cluster node selection constraint. It allows you to define the node labels (constraints) in the form of key-value pairs. When the nodeSelector feature is used, Kubernetes schedules the pods to only the nodes that match each of the node labels you specify.

nodeAffinity allows you to define advanced constraints to limit the pod scheduling on specific nodes. There are two types of node affinity:

• requiredDuringSchedulingIgnoredDuringExecution (Hard type): In this type, the scheduler doesn't schedule the pods unless the defined rules are met.
• preferredDuringSchedulingIgnoredDuringExecution (Soft type): In this type, the scheduler tries to find a node that meets the defined rules. However, even if a matching node is not available, the scheduler still schedules the pod.

Managing Node Selector and Node Affinity Feature

The following sections provide details on managing the Node Selector and Node Affinity feature:

Enabling Node Selector and Node Affinity

You can enable or disable the nodeSelector and nodeAffinity options for the pods using the custom_values.yaml file. For more information on enabling and disabling parameters, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Note:

• You can enable either nodeSelector or nodeAffinity option to schedule cnDBTier pods to specific worker nodes.
• By default, both nodeSelector and nodeAffinity options are disabled.

Configuring Node Selector and Node Affinity

Depending on the nodeSelector or nodeAffinity option enabled, you can configure its parameters in the custom_values.yaml file. For more information on the node selector and node affinity configuration parameters, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Note:

Configure the node selector or node affinity parameters only when either of the options is enabled.