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
The following illustrates a deployment of NFM-P in standalone mode when the NFM-P server and NFM-P database functions are in a distributed deployment and NFM-P auxiliary servers are installed with statistics collection using the NFM-P auxiliary database. In this configuration, there can be up to three preferred NFM-P auxiliary statistics servers. The NFM-P auxiliary database cluster comprises of either a single instance or a cluster of at least three instances.
Figure 1-8: NFM-P standalone deployment - distributed NFM-P server and NFM-P database configuration and NFM-P auxiliary servers with statistics collection using the NFM-P auxiliary database
For bare metal installations, the NFM-P server, NFM-P auxiliary server, NSP Flow server, NSP Flow Collector Controller, NFM-P auxiliary database, NSP analytics server, 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, NFM-P auxiliary database, NSP Flow Collector, NSP Flow Collector Controller, NSP analytics server, 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, NFM-P auxiliary server, and NSP analytics 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-9: 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-10: NFM-P distributed server/database redundancy deployment in a geographically redundant setup.
Redundancy and NFM-P auxiliaries and NSP Flow Collectors
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 NFM-P 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 customer networks where cflowd data is to be collected from network elements, an NSP Flow Collector must be used. The NSP Flow Collector can only be installed in a standalone configuration. To achieve data redundancy, network elements can be configured to forward cflowd data to multiple NSP Flow Collectors. The NSP Flow Collector Controller can be installed in a standalone or redundant configuration.
In Figure 1-11, 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. Figure 1-12, NFM-P distributed server/database redundant deployment with redundant NFM-P auxiliaries using the NFM-P auxiliary database for statistics collection shows the same redundant configuration but with statistics collection using a geographically redundant NFM-P auxiliary database. Latency between geographic sites must be less than 200 ms.
Figure 1-11: NFM-P distributed server/database redundant deployment with redundant NFM-P auxiliaries that crosses geographic boundaries
Figure 1-12: NFM-P distributed server/database redundant deployment with redundant NFM-P auxiliaries using the NFM-P auxiliary database for statistics collection
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 NFM-P auxiliary database, the operating systems installed on the NFM-P 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. The NSP Flow Collector typically resides in the managed network, closer to the network elements.
-
When the NFM-P 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 NFM-P 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.