NFM-P deployment requirements

Platform requirements

Note: For optimal storage performance on a supported Nokia AirFrame server, set the default write cache policy for each created storage volume to Write Through. See the NokiaAirFrame server documentation for information about verifying, configuring, and setting the write cache policy for a volume.

The following are the NFM-P platform requirements.

• The platform must meet the minimum requirements described in the NSP Planning Guide.

• The OS release and patch level of all main server, main database, and optional component stations in an NFM-P system must be identical unless NFM-P OS support restrictions exist.

• An NFM-P main server creates a small number of RHEL system users for internal functions, so requires available system user IDs on the host station. If no system reserved IDs are available, the main server configuration from samconfig cannot be applied, and the main server installation fails.

• The platform must be dedicated to the NFM-P only; sharing the platform is not supported. System operation may be adversely affected by the activity of other software on the same station.

• Before you install a redundant NFM-P system, you must enable SSH on each main server, auxiliary server, and main database station in the system.

• If the NFM-P is to collect statistics on a large scale, as defined in the NSP Planning Guide, you must use a disk array with the main database to increase performance. See Chapter 2, NSP disk setup and partitioning for information.

• The NFM-P XML API and GUI client real-time clocks must always be synchronized with the main server real-time clock.

• The Bash shell is the supported command shell for RHEL CLI operations.

Security requirements

Note: The use of sudo to gain root user privileges is supported for NFM-P installation, and for any other NFM-P operation that requires root user privileges.

The following are the NFM-P security requirements.

• The Oracle management user requires full read and write permissions on the main database installation directory, /opt/nsp/nfmp/db, and any specifically created partitions, for example, /opt/nsp/nfmp/dbbackup.

• The user that installs an NFM-P single-user GUI client requires local user privileges only, but must have full access permissions on the client installation directory. The user that opens the client installer must have sufficient file permissions to create the installation directory, or the installation fails.

Network requirements

CAUTION Service Disruption

The use of hostname resolution for GUI and XML API client communication with an NFM-P main server in a NAT environment is strongly recommended.

When IP addresses are used in a NAT environment, the following conditions apply:

• All client communication with the main server must use the public IP address of the main server.

• The NAT firewall must be configured to allow the main server to communicate with itself using the public IP address.

CAUTION Service Disruption

In a redundant system, a GUI client that opens a browser connection to the primary NFM-P main server may need to use the address of the peer main server after a main server communication failure.

To resolve the two addresses, a GUI client can use a common DNS name which maps each main server IP address provided by the DNS server to the primary main server.

• Configure a DNS server for GUI clients to map each main server IP address to a common DNS name.

• Configure each GUI client to use the common DNS name for browser connections to the NFM-P.

• Use a client browser that caches multiple IP addresses associated with one hostname.

Regardless of the network addressing scheme and configuration, for example, whether NAT, hostnames, or multiple interfaces are used, the /etc/hosts file of a component must contain valid address entries for reaching other components at the following times:

• during normal operation

• after a network or NFM-P component failure

Using NAT

Network Address Translation adds an extra level of complexity to an NFM-P network. If NAT is to be used in the NFM-P management network, hostname resolution for GUI and XML API client communication is strongly recommended.

The following are the basic network configuration requirements; see Using hostnames in the management network for more information, including an example network configuration that uses hostnames.

• When you use a hostname to identify an NFM-P or NSP component, you must use local hostname resolution; the use of DNS is supported only for non-NSP components such as OSS or external systems.

• The first uncommented entry in the /etc/hosts file must map the local hostname to the private IP address of the interface to the other NFM-P components.

• The hostname of an NFM-P component must:

  • contain only ASCII alphanumeric and hyphen characters.

  • not begin or end with a hyphen.

  • not begin with a number.

  • comply with the format defined in IETF RFC 1034.

  • use period characters delimit the FQDN components.

  • not exceed 63 characters.

• A component hostname that you specify in an /etc/hosts file must be the exact hostname returned by the following command:

  hostname

Note: Hostnames are case-sensitive.

Firewalls

The following firewall types are supported in an NFM-P system:

• native RHEL firewall implemented using firewalld

• external firewall

Before you attempt to deploy an NFM-P system, or add a component to a system, you must ensure that any firewalls between the components allow the required traffic to pass between the components, or are disabled. The NSP Planning Guide lists the open ports required by each component.

Note: If you intend to use firewalld, you must configure firewalld according to the rules in the NSP Planning Guide, which describes using NFM-P templates to create firewalld rules.

Management network

The following requirements apply to the NFM-P management network.

• During a main server installation or upgrade, you must use hostnames to identify the main server interfaces under the following conditions:

  • when the XML API and GUI clients communicate with a main server using multiple IP addresses for the main server

  • when the XML API and GUI clients use different addresses to communicate with a main server through one interface on the main server

• A standalone auxiliary server must be accessible to each main server and database in a redundant NFM-P system. Optimally, all components in a deployment are in the same LAN and have high-quality network interconnection.

• When two components use hostnames to communicate, the /etc/hosts file on each component station must contain the following:

  • an entry that maps the hostname assigned to the interface on the other component to the IP address used to reach the other component

  • an entry that maps the hostname of the other component station to each IP address used to reach the other component

• Specifying a TCP or UDP port other than the default can affect component communication through a firewall. Ensure that you record any changes to default port numbers, and make the ports available through the firewall.

Hostname usage in an NFM-P system has special configuration requirements. See Using hostnames in the management network for an example management network configuration, and Network requirements for specific configuration information.

Managed network and external systems

CAUTION Management Disruption

If an NFM-P system that is to be upgraded manages a device as a GNE, and the new NFM-P release supports native management of the device, you must unmanage the device and delete it from the main database before the upgrade.

After the upgrade, you can use the NFM-P to discover and manage the device natively, rather than as a GNE.

Note: Before you upgrade an NFM-P system that manages 7705 SAR, 7705 SAR-Hm, or VSR NEs using NGE, you must observe the following:

• 7705 SAR - Release 8.0 R3 and earlier support only NGE version 1; Release 8.0 R4 and later support only NGE version 2.

• 7705 SAR-Hm and VSR - Release 15.0 R3 and earlier support only NGE version 1; Release 15.0 R4 and later support only NGE version 2.

If you want to manage such devices after the NFM-P upgrade using NGE version 2, you must do the following:

1. Upgrade each device to a release that supports NGE version 2.

2. Use the NFM-P to specify NGE version 2 for each device.

The following requirements apply to the network of NFM-P-managed devices, and to the external systems with which the NFM-P is integrated.

• Before you upgrade an NFM-P system, you must confirm that the new NFM-P software release supports the release of each managed NE. If this is not true, you must perform one of the following before you attempt the upgrade, or service disruption may occur.

  • Upgrade the NE to a release that the new NFM-P release supports.

  • Use an NFM-P client to unmanage the device, remove the device from the managed network, and remove the discovery rule element for the device.

• Before you upgrade an NFM-P system, you must ensure that the new NFM-P software is compatible with the software release of each integrated external system. Contact technical support for information about external system compatibility.

• An NFM-P system upgrade does not preserve 9500 MPR device software images. If you want to retain the images, you must export the images to a remote file system before the upgrade, and import the images to the NFM-P after the upgrade.

Software deployment requirements

The following are the NFM-P software requirements.

• An NFM-P system deployment requires a license file in compressed format with a .zip extension. A license file has the following characteristics.

  • The UUID of the host station is required to generate the license. To obtain the UUID of a station describes how to obtain a station UUID.

    Note: An NFM-P component upgrade from Release 22.6 or earlier is also a platform migration to a new RHEL OS version. Consequently, the host station UUID changes, and an upgraded main server does not recognize the existing NFM-P license.

    An NFM-P system upgrade from Release 22.6 or earlier requires a new licence based on the new main server UUIDs.

  • A license file can accommodate two system IDs, which enables the use of the same file on redundant main servers, and is recommended.

  • Renaming the compressed file has no effect on the validity of the contained license file, but renaming the contained XML license file renders it invalid.

  • The main server configuration utility copies the license file content to a backup location; a change to the license file content or location after an installation or upgrade does not affect the main server operation.