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?
>>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.
3. It's a variety of possible architectures - more than one Core integrates to NNMi:
4. At the Traffic iSPI configuration page you set up both Primary and Secondary, so it knows both and switches to an active.
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?
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 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.
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.
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.
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.