Upgrade requirements
Primary considerations
|
CAUTION Service Disruption |
An NFM-P system upgrade requires a thorough understanding of NFM-P system administration and platform requirements, and is supported only under the conditions described in this guide, the NSP Planning Guide, and the NSP Release Notice.
Such an operation must be planned, documented, and tested in advance on a trial system that is representative of the target live network. Contact technical support to assess the requirements of your NFM-P deployment, and for information about the upgrade service, which you are strongly recommended to engage for any type of deployment.
|
|
CAUTION Upgrade Failure |
A system upgrade fails unless you strictly comply with the upgrade requirements and operate within the upgrade restrictions.
Ensure that you have a thorough understanding of the NFM-P system upgrade requirements and restrictions in NFM-P deployment configuration and in the NSP Planning Guide, and that you perform a test upgrade in advance of a live upgrade, as described in Staging your upgrade.
This section describes the general conditions that apply to NFM-P system upgrades. Before you attempt to upgrade an NFM-P component, you must comply with the conditions in NFM-P deployment configuration and this section.
NFM-P single-user GUI client upgrade from Release 22.9 or later and NFM-P client delegate server upgrade from Release 22.9 or later describe how to upgrade an NFM-P single-user GUI client or client delegate server.
Note: It is strongly recommended that you verify the message digest of each NSP image file or software bundle that you download from the Nokia Support portal. The download page includes the MD5, SHA256, and SHA512 checksums for comparison with the output of the RHEL md5sum, sha256sum, or sha512sum command. See the associated RHEL man page for command usage information.
Note: Before a system upgrade, you must ensure that you have sufficient time to complete a main database upgrade. The time required for the upgrade depends on the platform resources, database complexity, and tablespace configuration. Contact technical support to obtain a database upgrade duration estimate.
Note: The following NFM-P main server aux parameters remain in the samconfig utility, but are obsolete and not to be configured:
Note: The following NFM-P auxiliary server service parameters remain in the samconfig utility, but are obsolete and not to be configured:
Note: The following NFM-P auxiliary server tls parameter remains in the samconfig utility, but is obsolete and not to be configured:
Note: The Bash shell is the supported command shell for RHEL CLI operations.
Geo-redundant system upgrades
The upgrade of geo-redundant NFM-P sites in a DR NSP deployment is orchestrated using the NSP system upgrade procedures in Chapter 9, NSP system upgrade from Release 22.9 or later. Consequently, an NFM-P system upgrade is an operation that is independent of the NSP deployment type.
Note: The upgrade procedures include a limited number of conditional workflow or procedure steps for special geo-redundant considerations such as auxiliary database upgrades.
Note: If the main servers in a redundant NFM-P system use different time zones, as in a geo-redundant deployment, and NSP Analytics creates reports based on data aggregation, it is recommended that you upgrade the main server in the aggregation time zone first. Otherwise, during the system upgrade, aggregations may run using the previous time-zone setting and skew the aggregation report results. In such an event, after both main servers are upgraded you must use the client GUI to change the Analytics aggregation time-zone setting.
See the NSP Analytics Report Catalog for aggregation configuration information.
Staging your upgrade
It is essential that you plan, document, and test an upgrade in advance on a lab system in a closed environment that is representative of the actual network. Contact technical support to assess the system upgrade requirements.
Note: In a large or complex network, it is strongly recommended that you engage the technical support upgrade service.
Performing a test upgrade involves the same preparation and series of actions as a live upgrade; see General NFM-P Release 22.9 or later upgrade workflow for information.
TLS configuration
In a system upgrade, you can continue to use the current TLS keystore and truststore files; no further action is required.
Note: The NFM-P TLS configuration persists through system upgrades.
Note: An NFM-P system upgrade does not preserve custom TLS version and cipher support settings. You must reconfigure the TLS support after an upgrade.
Note: TLS 1.0 and 1.1 are disabled by default. If either version is enabled before an NFM-P system upgrade and required after the upgrade, you must re-enable the version support after the upgrade.
See the NSP System Administrator Guide for information about using the tool.
XML API client compatibility
An OSS client must use the samOss.jar from the current NFM-P release. If a different samOss.jar is used, the NFM-P system may become unstable. The NFM-P release information is in the JAR manifest file.
Note: If you intend to use an existing OSS client from a previous NFM-P release, you must review the list of NFM-P schema changes in the NSP NFM-P XML API Developer Guide to identify modifications to packages, classes, types, methods, and properties that the OSS client uses.
See the NSP NFM-P XML API Developer Guide for information about how to obtain the required samOss.jar file, and how to configure and test a JMS connection.