Including the NFM-P in an NSP deployment
NFM-P deployment types
Figure 1-5, Collocated standalone NFM-P deployment is an example of a standalone NFM-P deployment in which the NFM-P main server and main database are collocated on one station.
Figure 1-5: Collocated standalone NFM-P deployment
Figure 1-6, Distributed standalone NFM-P deployment is an example of a standalone NFM-P deployment in which the NFM-P main server and main database are hosted on separate stations.
Figure 1-6: Distributed standalone NFM-P deployment
The following illustrates a typical deployment of NFM-P in standalone mode when the NFM-P server and NFM-P database functions are in a distributed configuration and NFM-P auxiliary servers are used. In this configuration there can be up to three active NFM-P auxiliary statistics servers or it could be configured redundant.
Figure 1-7: NFM-P standalone deployment - distributed NFM-P server and NFM-P database configuration and NFM-P auxiliary servers
For bare metal installations, the NFM-P server, NFM-P auxiliary server, NSP auxiliary database, and NFM-P database are supported on specific Intel x86 based HP and Nokia AirFrame stations.
The NFM-P client and client delegate server software may be installed on stations running different operating systems from the NFM-P server, NFM-P auxiliary, NSP auxiliary database, NSP Flow Collector, NSP Flow Collector Controller, and NFM-P database. The NFM-P client can be installed on RHEL 8 server x86-64, Windows, or Mac OS where the NFM-P client delegate server can be installed on RHEL 8 server x86-64, Windows Server 2016, Windows Server 2019, or Windows Server 2022. See Third-party software for NFM-P single-user client or client delegate server for Operating System specifics.
All NFM-P stations in the NFM-P management complex must maintain consistent and accurate time. The RHEL chronyd service is strongly recommended as the time-synchronization mechanism.
NFM-P system redundancy
NFM-P supports redundancy of the NFM-P server, NFM-P database, and NFM-P auxiliary server stations. The NFM-P auxiliary statistics server supports 3+1 redundancy.
Redundancy between NFM-P server and database applications is used to ensure visibility of the managed network is maintained when one of the following failure scenarios occur:
-
Loss of physical network connectivity between NFM-P server and/or NFM-P database and the managed network
-
Hardware failure on station hosting the NFM-P server and/or NFM-P database software component
NFM-P supports redundancy of the NFM-P server and NFM-P database components in the following configurations:
The following illustrates an NFM-P redundant installation when the NFM-P server and NFM-P database components are installed in a collocated configuration.
Figure 1-8: NFM-P collocated server/database redundancy deployment
The following illustrates an NFM-P redundant installation when the NFM-P server and NFM-P database components are located on different stations in a distributed configuration.
Figure 1-9: NFM-P distributed server/database redundancy deployment in a geographically redundant setup.
Redundancy and NFM-P auxiliaries
In customer networks, where the statistics collection requirements exceed the scalability capabilities of an NFM-P server, the NFM-P auxiliary statistics server can be used. As with other HA components, the NFM-P auxiliary statistics server can be configured to be redundant. When collecting statistics using the NFM-P database, each NFM-P server can be configured to have one preferred and one reserved NFM-P auxiliary statistics server. When collecting statistics using the NSP auxiliary database or using logToFile only, each NFM-P server can be configured with up to three preferred and one reserved NFM-P auxiliary statistics server.
In Figure 1-10, NFM-P distributed server/database redundant deployment with redundant NFM-P auxiliaries that crosses geographic boundaries there are NFM-P auxiliary servers configured. In the example where redundancy is geographic, there can be up to four NFM-P auxiliary statistics servers configured in each geographic location. The Preferred/Reserved/Remote role of the NFM-P auxiliary statistics server is dependent upon and configured, based on the NFM-P server that is active. When there are more than one active auxiliary statistics server, local redundancy (Preferred/Reserved) of the auxiliary statistics server must be used in conjunction with geographic redundancy, where the same number of auxiliary statistics servers will be deployed in each geographic site. The NFM-P auxiliary statistics servers in the opposite geographic location are configured to be Remote. In this scenario, if one of the NFM-P auxiliary statistics servers for the active NFM-P server were no longer available, the active NFM-P server would use the reserved NFM-P auxiliary statistics server in the same geographic location to collect statistics. If using the same redundant configuration but with statistics collection using a geographically redundant NSP auxiliary database the latency between geographic sites must be less than 200 ms.
Figure 1-10: NFM-P distributed server/database redundant deployment with redundant NFM-P auxiliaries that crosses geographic boundaries
Further information about NFM-P redundancy can be found in the NSP NFM-P User Guide.
Redundancy deployment considerations for NFM-P
When deploying NFM-P in a redundant configuration, the following items must be considered.
It is a best practice to keep the NFM-P server, NFM-P database, and NFM-P auxiliary servers in the same geographic site to avoid the impact of network latency. When the NFM-P database or NFM-P server switches sites, the NFM-P auto-align functionality will ensure the NFM-P server, and NFM-P auxiliary servers are all aligned in the same geographic location. If the auto-align functionality is not enabled, a manual switch of the stations is desirable.
Redundancy with collocated NFM-P server/database
Requirements:
-
The operating systems installed on the primary and standby NFM-P server/database must be of the same versions and at the same patch levels.
-
The layout and partitioning of the disks containing the NFM-P software, the Oracle software and the database data must be identical on the active and standby NFM-P server/database.
-
The machine which will be initially used as the active NFM-P server/database must be installed or upgraded before the machine that will initially be used as the standby.
-
The stations hosting the NFM-P software should be connected in a way to prevent a single physical failure from isolating the two stations from each other.
-
Stations that host the NFM-P server/database software must be configured to perform name service lookups on the local station before reverting to a name service database located on the network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/nsswitch.conf file to ensure that files is the first entry specified for each database listed in the file.
Redundancy with distributed NFM-P server and NFM-P database
Requirements:
-
The operating systems installed on the primary and standby NFM-P server as well as the primary and standby NFM-P database must be of the same versions and at the same patch levels.
-
The layout and partitioning of the disks containing the NFM-P software, the Oracle software and the database data must be identical on the primary and standby NFM-P database.
-
The machines which are intended to be used as primary NFM-P server and NFM-P database should be installed on the same LAN as one another with high quality network connectivity.
-
The machines which are intended to be used as standby NFM-P server and standby NFM-P database should be installed on the same LAN as one another with high quality network connectivity.
-
The pair of stations to be used as active NFM-P server and NFM-P database should be connected to the pair of stations to be used as standby NFM-P server and NFM-P database in a way that will prevent a single physical failure from isolating the two station pairs from each other.
-
Stations that host the NFM-P server and NFM-P database software must be configured to perform name service database lookups on the local station before reverting to a name service located on the network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/nsswitch.conf file to ensure that files is the first entry specified for each database listed in the file.
Redundancy with distributed NFM-P server and NFM-P database and NFM-P auxiliary servers
In addition to the rules stated above for distributed NFM-P server and NFM-P database, the following rules apply:
-
The operating systems installed on the NFM-P auxiliary servers must be of the same versions and patch levels as the NFM-P server and NFM-P database stations.
-
If collecting statistics using the NSP auxiliary database, the operating systems installed on the NSP auxiliary database stations must be of the same versions and patch levels as the NFM-P server, NFM-P database, and NFM-P auxiliary statistics server stations.
-
NFM-P auxiliary servers are intended to be on the same HA network as the NFM-P server and NFM-P database. NFM-P auxiliary statistics servers are intended to be geographically collocated with the active and standby locations of the NFM-P server and NFM-P database.
-
When the NSP auxiliary database is deployed in a cluster of at least three separate instances, it can tolerate a single instance failure with no data loss. All NSP auxiliary database nodes in the same cluster must be deployed in the same geographic site, with less than 1 ms of latency between the nodes. A second cluster can be deployed to implement geographic redundancy and must contain the same number of nodes as the primary cluster.
-
When using more than one active NFM-P auxiliary statistics server in a geographic (greater than 1 ms latency) configuration, the active and reserved servers for a give NFM-P server must reside in the same geographic site. The auxiliary statistics servers in the opposite geographic site would be configured as Remote.
-
Stations that host the NFM-P auxiliary server software must be configured to perform name service database lookups on the local station before reverting to a name service database located on the network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/nsswitch.conf file to ensure that files is the first entry specified for each database listed in the file.