3 cnDBTier Features
This chapter describes the key features of cnDBTier.
3.1 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, 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 also reestablishes the TLS connection after a georeplication recovery. That is, when a georeplication recovery completes successfully, the system reestablishes the encrypted connection between the replication channels. This ensures that the TLS is kept intact even after a georeplication recovery.
Managing TLS Support for Georeplication
The following sections provide details on managing 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.
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.2 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.3 REST APIs to Display cnDBTier Data on CNC Console
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": 20
}
},
{
"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": "configurations/<NF Name>/dbconfig-geoReplicationStatus",
"name": "Georeplication Status",
"sequence": 50
}
},
{
"attr": {
"id": "services/<NF Name>/dbconfig-heartBeatStatus",
"name": "HeartBeat 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
}
}
]
}
]
}
}3.4 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:
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.
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.5 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-1 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.6 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.
<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:
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.
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.
Note:
The password used for encryption must follow the cnDBTier password requirement or standard.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.
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.7 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.
- 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:
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.
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.