4 Upgrading NSSF

This chapter provides information about upgrading Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF) deployment to the latest release. It is recommended to perform NSSF upgrade in a specific order. For more information about the upgrade order, see Oracle Communications Cloud Native Core, Solution Upgrade Guide.

Note:

  • In a multisite georedundant setup, perform the steps explained in this section on all the georedundant sites.
  • For NSSF georedundant deployments, the difference between the NSSF release versions for all the georedundant sites cannot be more than 1 release. For example, in a three-site NSSF deployment, all the 3 sites are at the same release version as N. During site upgrade, site 1 and site 2 are upgraded to N+1 version, and site 3 is not upgraded yet. At this state, before upgrading site 3 to N+1, upgrading site 1 and/or site 2 from N+1 version to N+2 version is not supported as the difference between the NSSF release versions for all the georedundant sites cannot be more than 1 release.
  • For more information about the cnDBTier georedundant deployments, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  • For more information about the CNC Console georedundant deployments, see Oracle Communications Cloud Native Core, CNC Console Installation, Upgrade, and Fault Recovery Guide.

4.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF):

Table 4-1 Supported Upgrade Paths

Source Release Target Release
25.1.1xx, 25.1.200 25.1.201

Note:

In case of georedundant deployment, upgrade all sites first and then cnDBTier on all sites. For example: There are two sites (site 1 and site 2). Both running on release N-1 and cnDBTier is also on N-1. To upgrade NSSF and cnDTier to release N:
  1. Upgrade NSSF at Site 1 to version N. Wait for 10 minutes.
  2. Upgrade NSSF at Site 2 to version N. Wait for 10 minutes.
  3. Upgrade cnDBTier at Site 1 to version N. Wait for 10 minutes.
  4. Upgrade cnDBTier at Site 2 to version N. Wait for 10 minutes.

To rollback from N to N-1:

  1. Rollback cnDBTier at Site 1 to version N-1. Wait for 10 minutes.
  2. Rollback cnDBTier at Site 2 to version N-1. Wait for 10 minutes.
  3. Rollback NSSF at Site 1 to version N-1. Wait for 10 minutes.
  4. Rollback NSSF at Site 2 to version N-1. Wait for 10 minutes.

4.2 Upgrade Strategy

NSSF supports in-service upgrade. The supported upgrade strategy is RollingUpdate. The rolling update strategy is a gradual process that allows you to update your Kubernetes system with only a minor effect on performance and no downtime. The advantage of the rolling update strategy is that the update is applied Pod-by-Pod so the greater system can remain active.

Note:

It is recommended to perform in-service upgrade  in maintenance window where the recommended traffic rate is 25% of the configured traffic or below. We also expect the traffic failure to stay below 5% during the upgrade and fully recover post upgrade.

The following read-only-parameters are used to define upgrade strategy:

  • upgradeStrategy parameter indicates the update strategy used in NSSF.
  • maxUnavailable parameter determines the maximum number of pods that will be unavailable during upgrade.

Table 4-2 Predefined Upgrade Strategy Value

Microservice Upgrade Value (maxUnavailable)
<Helm-release-name>-nsselection 25%
<Helm-release-name>-nsavailability 25%
<Helm-release-name>-nssubscription 25%
<Helm-release-name>-nsconfig 25%
<Helm-release-name>-nsauditor 25%
<Helm-release-name>-ocnssf-nrf-client-nfdiscovery 25%
<Helm-release-name>-ocnssf-nrf-client-nfmanagement 25%
<Helm-release-name>-ingressgateway 25%
<Helm-release-name>-egressgateway 25%
<Helm-release-name>-appinfo 25%
<Helm-release-name>-perf-info 25%
<Helm-release-name>-config-server 25%
<Helm-release-name>-alternate-route 25%

Note:

  • <Helm-release-name> is the Helm release name. For example, if Helm release name is "ocnssf", then nsselection microservice name will be "ocnssf-nsselection"
  • When NSSF is deployed with OCCM, follow the specific upgrade sequence as mentioned in the Oracle Communications, Cloud Native Core Solution Upgrade Guide.

4.3 Preupgrade Tasks

This section provides information about preupgrade tasks to be performed before upgrading NSSF.

  1. To check the preupgrade health of NSSF, perform a Helm test before starting the upgrade. For more information about Helm test, see Performing Helm Test section.
  2. Keep current ocnssf_custom_values.yaml file as backup.
  3. Update the new ocnssf_custom_values.yaml file for target NSSF release. For details on customizing this file, see Customizing NSSF.

    Caution:

    The readOnlyRootFilesystem parameter is set to false by default. Do not set this parameter to true, as NSSF requires elevated privileges during installation. Enabling a read-only root filesystem would block the necessary permissions, resulting in installation failure.
  4. Before starting the upgrade, take a manual backup of NSSF REST based configuration. This helps if preupgrade data has to be restored. For Rest API configuration details, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
  5. Before upgrading your cnDBTier instance, update the ocnssf_dbtier_25.1.201_custom_values_25.1.201.yaml file as explained in the cnDBTier Requirement section.

4.4 Upgrade Tasks

This section provides information about the sequence of tasks to be performed for upgrading an existing NSSF deployment.

Helm Upgrade

Upgrading an existing deployment replaces the running containers and pods with new containers and pods. If there is no change in the pod configuration, it is not replaced. Unless there is a change in the service configuration of a microservice, the service endpoints remain unchanged.

Upgrading NSSF

Caution:

  • Stop the provisioning traffic before you start the upgrade procedure.
  • No configuration should be performed during upgrade.
  • Do not exit from helm upgrade command manually. After running the helm upgrade command, it takes some time (depending upon the number of pods to upgrade) to upgrade all the services. In the meantime, you must not press "ctrl+c" to come out from helm upgrade command. It may lead to anomalous behavior.
  1. Untar the latest NSSF package and if required, re-tag and push the images to registry. For more information, see Downloading the NSSF Package and Pushing the Images to Customer Docker Registry.
  2. Modify the ocnssf_custom_values_25.1.201.yaml file parameters as per site requirement.
  3. Do not change the nfInstanceId configuration for the site. In case of multisite deployments, configure nfInstanceId uniquely for each site.
  4. Assign appropriate values to core_services in the appInfo configuration based on nssf Mode.
  5. Run the following command to upgrade an existing NSSF deployment:

    Note:

    If you are upgrading an existing NSSF deployment with georedundancy feature enabled, ensure that you configure dbMonitorSvcHost and dbMonitorSvcPort parameters before running helm upgrade. For more information on the parameters, see Global Parameters.
    • Using local Helm chart: 
      $ helm upgrade <release_name> <helm_chart> -f <nssf_customized_values.yaml> --namespace <namespace>

      Where,

      <release_name> is the NSSF release name.

      <helm_chart> is the Helm chart.

      <nssf_customized_values.yaml> is the latest custom-values.yaml file. For example, ocnssf_custom_values_25.1.201.yaml

      <namespace> is namespace of NSSF deployment.

      For example:

      $ helm upgrade ocnssf ocnssf-25.1.201.0.0.tgz -f ocnssf_custom_values_25.1.201.yaml --namespace ocnssf
    • Using chart from Helm repo: 
      $ helm upgrade <release_name> <helm_repo/helm_chart> --version <chart_version> -f <nssf_customized_values.yaml> --namespace <namespace>

      Where,

      <release_name> is the NSSF release name.

      <helm_repo/helm_chart> is the Helm repository for NSSF.

      <nssf_customized_values.yaml> is the latest custom-values.yaml file. For example, ocnssf_custom_values_25.1.201.yaml

      <namespace> is namespace of NSSF deployment.

      For example:

      $ helm upgrade ocnssf ocnssf-helm-repo/ocnssf--version 25.1.201 -f ocnssf_custom_values_25.1.201.yaml --namespace ocnssf
  6. Run the following command to check the status of the upgrade: 
    $ helm status <release_name> --namespace <namespace>

    Where,

    <release_name> is the NSSF release name.

    <namespace> is namespace of NSSF deployment.

    For example:

    $ helm status ocnssf--namespace ocnssf
  7. If the upgrade fails, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.

4.5 Postupgrade Tasks

This section provides information about postupgrade tasks to be performed after upgrading NSSF.

  1. To check the postupgrade health of NSSF, perform a Helm test after the upgrade. For more information about Helm test, see Performing Helm Test section.
  2. After NSSF upgrade, upgrade cnDBTier using the ocnssf_dbtier_25.1.201_custom_values_25.1.201.yaml file provided in the ocnssf-custom-configtemplates-25_1_201_0_0 file. For information about the steps to download ocnssf-custom-configtemplates-25_1_201_0_0 file, see Customizing NSSF.

    Note:

    There are no customizations required in the ocnssf_dbtier_25.1.201_custom_values_25.1.201.yaml file for installing NSSF 25.1.200.
  3. Run the following command to upgrade your current cnDBTier installation using the ocnssf_dbtier_25.1.201_custom_values_25.1.201.yaml file: 
    helm upgrade <release-name>  <chart-path> -f <cndb-custom-values.yaml> -n <namespace>

    For example:

    helm upgrade mysql-cluster occndbtier/ -f ocnssf_dbtier_25.1.201_custom_values_25.1.201.yaml -n nssf-cndb

    For more information about cnDBTier installation and upgrade procedure, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Note:

  • To automate the lifecycle management of the certificates through OCCM, you can migrate certificates and keys from NSSF to OCCM. For more information, see "Introducing OCCM in an Existing NF Deployment" in the Oracle Communications Cloud Native Core, Certificate Management User Guide.
  • You can remove Kubernetes secrets if the current version of NSSF does not use that secret by checking the ocnssf_custom_values_25.1.201.yaml file. Before deleting, please make sure that there is no plan to rollback to the NSSF version which uses these secrets. Otherwise, the rollback will fail.