ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins.Read more for important details.
Captain
Captain
214 views

NA NNMI High Availability URL and Internal access

We are planning to have below configuration in MS Azure.

NNMi in HA Application fail over mode - 2 different RHEL VMs with Embedded DB and QA SPI on each

NA Core 1 and NA Core 2 - 2 different RHEL VMs

NA PostgreSQL DB external - 1 RHEL VM

Few queries around this:

1) For NNMi URL Access, user has to manually switch to Primary or Standby IP to access the console

2) For NA URL access, user has to manually use NA Core 1 or NA Core 2 URL? or any possibility to configure common URL?

3) How NA-NNMi communication will work? Both NA Cores to be pointed to NNMi Primary and Secondary?
Any manual configuration required if one of the server failure happens?

4) How Traffic/NPS servers will communicate with NNMi through both Primary and Secondary server IP/Host? Any manual configuration required if one of the server failure happens?

5 Replies
Micro Focus Expert
Micro Focus Expert

Hi,

 

>>HA Application fail over

High Availability cluster that is for MS Clustering Suite or in Linux RHCS, while the AF is Application Failover feature of jboss/jgroup. You cannot combine these within the supported scope. I assume, I mean only AF here.

1. Yes

2. Yes

3. It's a variety of possible architectures - more than one Core integrates to NNMi:

https://docs.microfocus.com/itom/Network_Node_Manager_i:2020.11/IntegrateNNMiwithNA

4. At the Traffic iSPI configuration page you set up both Primary and Secondary, so it knows both and switches to an active.

BR,

Captain
Captain

Yes, that's right Application Failover and not Cluster.

Understood the NA and NNMi URL access part. That individual IP/Hostname to be used while accessing.

Thanks for the clarification.

Still not clear about the NA Cores and NNMi. Is it like NA Core 1 and NA Core 2 to point to NNMi Primary?

or any option available in NA to point towards both NNMi Primary and Secondary?

Same with NPS as well? It has option to configure both NNMi Primary and Secondary?

Hello Ak,
NA-NNM-Integration:
Are the two NA Cores independent, or forming a Horizontal Scalability setup?
If they were independet, then you need to integrate both with the primary NNM.
If you have a HS-setup they act as one NA installation and you - as far as I know - only need to integrate once with the primary NNM.
In both cases the NNM integration module takes care, if NNM switches to the standby node and updated NA.

NPS:
NPS needs to be a separate server. (You haven't listed that one in the opening post.)
In the NPS Config UI, you specify the primary NNM to access the NPS Share on the NNM Server.
Once connected NPS regularly joins the JGroup of the Application Failover Cluster to check the "active NNM" and - if necessary - switches to the other NNM NPS Share.

Traffic SPI:
in the Traffic SPI Master configuration UI you configure both NNM servers and the Master tries to reconnect to both, once the established connection breakts until he is successfull.

Regards
Karsten
Captain
Captain

Yes 2 NA Cores on separate server pointing to External DB/PostgreSQL for Scalability.

We also have 3 NA Satellite servers based on Region/Location - should that be pointed to NA core 1 or NA Core or both?

About NPS, sorry I missed in my post - we will have separate server for NPS with embedded DB pointing to NNMi.

0 Likes

I interpret your answer as "Yes, horizontal scalability."
If you utilize Satellites, you also need Gateways. I would implement: 2 NA cores, each hosting a Core-Gateway. Each Gateway connected to all 3 Satellites.
So you can fully utilize the horizontal scalability feature, since each NA Core can "talk" to each node.
If the Satellites are only connected to one NA Core (Gateway), you need - at least partially - work with Core-Binding. (Or the other Core must establish a direct connection to the nodes.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.