Release 22.9 or later NFM-P upgrade considerations
Introduction
|
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 NSP professional services 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.
This section describes the conditions that apply to an NFM-P system upgrade from Release 22.9 or later. Before you attempt to upgrade a Release 22.9 or later NFM-P system, 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: The Bash shell is the supported command shell for RHEL CLI operations.
Upgrade process
The elements of an NSP deployment must be upgraded in a specific order, starting with the NSP cluster. During the upgrade, the NSP UI is unavailable, as is an NFM-P or WS-NOC that is part of the NSP system. After the NSP component upgrade, the NFM-P and WS-NOC can be upgraded in any order.
See the NSP compatibility matrix in the NSP Release Notice to ensure that the proposed upgrade results in a supported configuration.
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: 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.
Important considerations
|
|
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.
|
|
CAUTION Upgrade Failure |
If the system locales of the NFM-P and the NSP cluster do not match, a system upgrade may fail.
Ensure that the NSP system locale matches the NFM-P locale before you attempt a system upgrade. If the locales do not match, contact technical support for assistance.
Note: Before a system upgrade, you must ensure that you have sufficient time to complete the 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.
Obsolete parameters
The following NFM-P main server aux parameters remain in the samconfig utility, but are obsolete and not to be configured:
The following NFM-P auxiliary server service parameters remain in the samconfig utility, but are obsolete and not to be configured:
The following NFM-P auxiliary server tls parameter remains in the samconfig utility, but is obsolete and not to be configured:
NFM-P template files
If you have modified any NFM-P template files, contact technical support before you attempt an NSP or NFM-P system upgrade; an upgrade overwrites customized template values.
Language localization
NFM-P language localization files are not automatically backed up during an NSP upgrade. To preserve your language localization, you must back up your localization file before an NSP upgrade, and then redeploy the file after the upgrade.
NFM-P service group migration to NSP
When you upgrade an NSP deployment that includes the NFM-P, the existing service groups are migrated from the NFM-P to the NSP. The migration may take a few hours, depending on the number of services. During this time, you must not auto-create service groups. You can use the Find Ungrouped members count in Map Layouts and Groups to help determine when the upload is complete, after which you can auto-create groups.
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 a system upgrade.
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.