To prepare for an NFM-P system upgrade from Release 22.9 or later
Description
CAUTION Upgrade failure |
An NFM-P system upgrade fails if each main server in the system is not fully initialized and functional before the upgrade.
Before you attempt an NFM-P system upgrade, you must ensure that the initialization of each main server in the NFM-P system is complete.
The following steps describe the actions that you must perform in advance of a standalone or redundant NFM-P system upgrade.
Note: You require the following user privileges on each server station in the system:
Note: The following RHEL CLI prompts in command lines denote the active user, and are not to be included in typed commands:
Steps
CAUTION Deployment failure |
The RHEL OS of any NSP component requires specific versions of some RHEL packages. If the required package versions are not installed, the component upgrade fails.
See Manual NSP RHEL OS installation for the required package versions.
Check component hardware | |||||||
1 |
Perform a file system check on each component by entering the following for each file system device as the root user on the component station: # e2fsck -n file_system ↵ where file_system is a specification such as /dev/sdan for a physical disk, or /dev/vdan for a virtual disk If the check passes, the output is similar to the following /dev/sdan: clean, a/b files, x/y blocks If the check indicates a failure, you must correct the disk corruption before you continue. | ||||||
2 |
Check each component station for system error messages; enter the following as the root user on the station: # grep -i error /var/log/messages ↵ If no error messages are present, the command returns nothing. Otherwise, investigate and resolve the issues indicated by the error messages that are displayed. | ||||||
3 |
Perform “How do I test NFM-P disk performance?” in the NSP System Administrator Guide on each component station to ensure that the disk speed and latency meet or exceed your system requirements. | ||||||
Check component OS configuration | |||||||
4 |
Verify that the /etc/hosts file contains the required host entry for each NFM-P component; enter the following as the root user on each station, and ensure that each required entry is present and correctly specified, as described in Network requirements: # cat /etc/hosts ↵ | ||||||
5 |
Verify that the /etc/nsswitch.conf file is configured correctly; enter the following as the root user on each component station: # cat /etc/nsswitch.conf ↵ Ensure that “files” is the first entry for passwd, shadow, group, and hosts, as shown in the following: passwd: files nis shadow: files nis group: files nis hosts: files dns myhostname | ||||||
6 |
Verify that the OS version is compatible with the NFM-P release, as described in the NSP Planning Guide; enter the following as the root user on each component station: # cat /etc/redhat-release ↵ Red Hat Enterprise Linux Server release R.r (codename) | ||||||
7 |
Verify that the disk partitions are correctly allocated and sized; enter the following commands as the root user on each component station, and check the output against the specifications in Chapter 2, NSP disk setup and partitioning: # lsblk ↵ # df -PH ↵ | ||||||
8 |
Verify that the required RHEL OS packages are installed; enter the following as the root user on each component station; see Chapter 3, RHEL OS deployment for the NSP for information about the required packages: # dnf list installed ↵ | ||||||
Verify NE resynchronization status | |||||||
9 |
Use the Discovery Manager in the NFM-P GUI to ensure that no NEs are undergoing or pending resynchronization.
| ||||||
Verify NFM-P license | |||||||
10 |
Verify that you have a valid license; perform the following steps on each main server station. Note: Ensure that you do not modify the contents of a license file; otherwise, the license is unusable.
| ||||||
Back up NFM-P configuration | |||||||
11 |
Copy the following configuration files to a secure location on a station that is not affected by the upgrade: | ||||||
Remove outdated logs | |||||||
12 |
An NFM-P main server may retain logs saved during a previous upgrade in the following directory: /opt/nsp/nfmp/server/nms/log/previous_log The files in the directory may consume excessive disk space. If the directory exists on a main server, it is strongly recommended that you remove the files from the directory before the upgrade.
| ||||||
Check and configure firewalls | |||||||
13 |
You must ensure that each firewall between the system components allows the required traffic to pass between the components, or is disabled. You can configure and enable the firewalls after the upgrade, if required.
| ||||||
Download installation files | |||||||
14 |
Download the following NFM-P installation files to an empty directory on a station that is not affected by the upgrade activity: Note: The station must be reachable by each station that is to host an NFM-P main server or main database. where R.r.p is the NSP release identifier, in the form MAJOR.minor.patch v is a version identifier | ||||||
Validate database | |||||||
15 |
Before you upgrade a main database, you must ensure that the main database contains only valid records, or the upgrade fails. Note: In a redundant system, you must perform the validation on the primary main database station. Log in as the root user on the main database station. | ||||||
16 |
Transfer the following downloaded file to an empty directory on the main database station: | ||||||
17 |
Navigate to the directory that contains the OracleSw_PreInstall.sh file. | ||||||
18 |
Enter the following: # chmod +x OracleSw_PreInstall.sh ↵ | ||||||
19 |
Perform the following steps to validate the Oracle database and resolve any conflicts that may prevent an upgrade. Note: If the validation check reports a small number of errors, for example, a few duplicate and invalid instances of an object, deleting the invalid instances manually may be sufficient. A large number of errors may indicate a significant problem that requires expert attention; in such a case, contact technical support for assistance.
| ||||||
Verify database archive log synchronization | |||||||
20 |
If the system is redundant, ensure that no archive log gap exists between the primary and standby main databases. Note: If you attempt a database upgrade when an archive log gap exists, the upgrade fails.
| ||||||
Back up database | |||||||
21 |
Open an NFM-P GUI client. | ||||||
22 |
Choose Administration→Database from the main menu. The Database Manager form opens. | ||||||
23 |
Click on the Backup tab. | ||||||
24 |
The disk partition that is to contain the database backup must have sufficient space for the database backup file set. Ensure that the backup directory is at least five times as large as the expected database backup size. For more information, contact technical support or see the NSP Planning Guide.
Before the NFM-P performs a database backup, it deletes the contents of the specified backup directory. Ensure that the backup directory that you specify does not contain files that you need to retain.
The backup directory that you specify must not include the main database installation directory, or data loss may occur. Ensure that the directory path does not include /opt/nsp/nfmp/db. Note: The backup directory that you specify must be a directory on a local mounted partition. Note: The Oracle management user requires read and write permissions on the backup directory. Configure the following parameters: | ||||||
25 |
Click Apply. | ||||||
26 |
Click Full Backup. | ||||||
27 |
Click OK. The database backup begins, and the Backup State indicator reads In Progress. Note: Depending on the database size, a backup may take considerable time. | ||||||
28 |
Monitor the Backup State indicator, which is dynamically updated. The indicator displays Success when the backup is complete. | ||||||
29 |
When the backup is complete, close the Database Manager (Edit) form. | ||||||
30 |
Transfer the following backup file sets to a secure location on a separate station that is unaffected by the upgrade activity:
| ||||||
Back up custom configuration files | |||||||
31 |
An NFM-P upgrade does not preserve all non-default settings in configuration files such as nms-server.xml. If an NFM-P configuration file contains non-default settings that you want to retain after an upgrade, contact technical support for assistance before the upgrade. Note: At the beginning of an NFM-P main or auxiliary server upgrade, specific configuration and log files are copied to a directory under the installation directory; the directory name includes a timestamp. The directories below the main server installation directory are then deleted. If you have created or customized a file below the main server installation directory, you risk losing the file unless you create a backup copy. Make a backup copy of each file that you have created or customized in or below the /opt/nsp/nfmp/server directory on each main server station, and store the backup files on a separate station that is not affected by the NFM-P upgrade activity. | ||||||
Verify compatibility with external systems | |||||||
32 |
Ensure that the new NFM-P software is compatible with the software release of each external system that connects to the NFM-P. Contact technical support for information about external system compatibility. | ||||||
Close LogViewer | |||||||
33 |
Close the LogViewer utility, if it is open. | ||||||
Validate main server and GUI client firewall configuration | |||||||
34 |
Confirm that the firewalls between the main servers and the single-user GUI clients and client delegate servers allow traffic to the HTTP or HTTPS port required for client access. Otherwise, you cannot install or upgrade a single-user client or client delegate server. See the NSP Planning Guide for NFM-P port assignment information. | ||||||
Verify NFM-P compatibility with managed NEs | |||||||
35 |
You must confirm that the new NFM-P release supports the software release of each managed NE and pre-provisioned NE, as stated in the NSP NFM-P Network Element Compatibility Guide. Note: See also NFM-P deployment requirements for additional important device-specific compatibility requirements. Note: If the system that you are upgrading manages an NE as a GNE, and the new NFM-P release supports native management of the device type and release, you must unmanage and delete the GNE before you attempt the upgrade. After the upgrade, the NFM-P can discover and manage the device as a native NE instead of a GNE. Perform one of the following for each managed NE at an unsupported release.
| ||||||
Clear CPAM checkpoints | |||||||
36 |
An NFM-P main server upgrade requires additional time if CPAM checkpoints are retained. The additional time varies, depending on the platform resources, managed network size, and checkpoint schedule. To reduce the upgrade time, remove the CPAM checkpoints, as described in the NSP NFM-P Control Plane Assurance Manager User Guide. | ||||||
Gather required information | |||||||
37 |
Choose Administration→System Information from the main menu. The System Information form opens. | ||||||
38 |
Record the following information: | ||||||
39 |
If the system is redundant, record the following additional information: | ||||||
40 |
If the system includes one or more auxiliary servers, click on the Auxiliary Servers tab; otherwise, go to Step 44. A list of auxiliary servers is displayed. | ||||||
41 |
Perform the following steps for each auxiliary server listed on the form.
| ||||||
42 |
Click on the Auxiliary Services tab. Each Preferred auxiliary server entry has a check mark in the Selected column. | ||||||
43 |
Record the hostname or IP address of each Preferred auxiliary server. Note: The auxiliary servers are collectively referred to as the [Aux1] auxiliary servers In To upgrade a redundant Release 22.9 or later NFM-P system. Any other listed auxiliary servers are the Reserved auxiliary servers, and are collectively referred to as [Aux2] in the procedure. | ||||||
44 |
If the system includes one or more client delegate servers, click on the Client Delegate Servers tab. Otherwise, go to Step 46. | ||||||
45 |
Perform the following steps for each client delegate server listed on the form:
| ||||||
46 |
Close the System Information form. | ||||||
47 |
Obtain and record the following additional information for each main server: | ||||||
48 |
Obtain and record the following additional main database information:
| ||||||
Close client sessions | |||||||
49 |
Close the open GUI and XML API client sessions, as required.
| ||||||
Uninstall Mac OS X clients | |||||||
50 |
Uninstall each single-user client installed on Mac OS X. Note: You must use the uninstallation procedure in the documentation for the installed client release, and not the uninstallation procedure in this guide. | ||||||
Close GUI client | |||||||
51 |
If the GUI client that you are using is not required for network monitoring during the upgrade, close the client. End of steps |