Highlighted
Regular Contributor.. Regular Contributor..
Regular Contributor..
348 views

NNM Application Failover VS High Availability

Jump to solution

HI ,

Currently I am using NNMi 9.2 version on RHEL 5 and I want to move to 10.10 .

my current NNMi is standalone application and I want to move to Applcation Failover or HA.

I have checked HP doceument for upgrade to 10.10 , it has information only about migrating to 10.10 from 9.20

(stanalone to standalone or HA to HA) but not from standalone to HA or Application Failover.

 

I wanted to know the approach for migrating from standalone 9.2 to HA or Failover 10.10.

also I wanted to knwo about the differnce in configuration and other diffrences between HA and Failover NNMi 10.10 So I can decide which one is better.

Link to any document will be very helpful

 

Thanks

 

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: NNM Application Failover VS High Availability

Jump to solution

Hi,

Regarding the upgrade path, you need to first upgrade your standalone server to the target version then configure the resilience architecture of your choice as described in the Deployment Guide.

Regarding the choice between HA and AF, the deployment reference guide provides a description of both approaches in the introduction of the Resilience Chapter:

https://softwaresupport.hpe.com/km/KM01898617/NNMi10.10_Deployment_Ref_en.pdf

See "Chatper 4: Resilience" here.

If your current standalone 9.20 system is working with a remote NPS server, I would definitively recommend you to choose HA instead of AF as Resilience architecture.

NNMi HA is preferred over NNMi AF when working with a dedicated NPS server since when a dedicated NPS is working with a remote NNMi AF cluster, each NNMi cluster member has its own share which implies a complexe NNMi/NPS file sharing mechanism to take place so that the NPS could always point to the right NNMi active server share at any time.

This mechanism is described at:

KM00573791: NNMi in Application Failover and NPS file sharing mechanism

See my answer to Frank in following forum discussion thread:

/t5/Network-Node-Manager-Support/Recommended-solution-for-NNMi-10-x-Redundancy/m-p/6909294

I hope this will help.

All the best

Marie-Noelle

Micro Focus Customer Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.

If you are satisfied with anyone’s response please remember to give them KUDOS and show your appreciation.

View solution in original post

4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: NNM Application Failover VS High Availability

Jump to solution

Hi,

Regarding the upgrade path, you need to first upgrade your standalone server to the target version then configure the resilience architecture of your choice as described in the Deployment Guide.

Regarding the choice between HA and AF, the deployment reference guide provides a description of both approaches in the introduction of the Resilience Chapter:

https://softwaresupport.hpe.com/km/KM01898617/NNMi10.10_Deployment_Ref_en.pdf

See "Chatper 4: Resilience" here.

If your current standalone 9.20 system is working with a remote NPS server, I would definitively recommend you to choose HA instead of AF as Resilience architecture.

NNMi HA is preferred over NNMi AF when working with a dedicated NPS server since when a dedicated NPS is working with a remote NNMi AF cluster, each NNMi cluster member has its own share which implies a complexe NNMi/NPS file sharing mechanism to take place so that the NPS could always point to the right NNMi active server share at any time.

This mechanism is described at:

KM00573791: NNMi in Application Failover and NPS file sharing mechanism

See my answer to Frank in following forum discussion thread:

/t5/Network-Node-Manager-Support/Recommended-solution-for-NNMi-10-x-Redundancy/m-p/6909294

I hope this will help.

All the best

Marie-Noelle

Micro Focus Customer Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.

If you are satisfied with anyone’s response please remember to give them KUDOS and show your appreciation.

View solution in original post

Highlighted
Regular Contributor.. Regular Contributor..
Regular Contributor..

Re: NNM Application Failover VS High Availability

Jump to solution

HI ,

thanks for the detailed explaination.

I had a query about the snmp trap destination.

in all the network devices we have set the standalone nnm server as trap destination.

after we change it to Application failover or HA , how can i manage these traps or set the trap destiantion.

in case of application failover the nnm server will have a new IP after failover , so how the devices will send traps to new server, we have to add both active and standby as trap destination in network devices , or any other way to manage it.

 

same for HA , what will be trap destination IP to be put in network devices.

I could not find this inforamtion in Resilience.

Thanks

 

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: NNM Application Failover VS High Availability

Jump to solution

Hi,

Yes you'll have to configure your network devices to send the traps to both the active and standby hosts *physical* IP addresses, not any virtual address, whatever your choice of resilience architecture (AF/HA).

This is because starting from 10.x, a new Trap Receiver process runs on both the active and standby nodes as a separate process outside of ovjboss to avoid loss of traps when a failover occurs..

When NNMi is running with HA/AppFailover:

  • The Trap Receiver process running on the Active node sends the trap to the ovjboss process event pipeline
  • The Trap Receiver process running on the Standby node(s) will queue the traps in a Trap Receiver queue, that retains the traps for the last 5mn by default.
  • This way if ovjboss takes less than 5mn to failover, no traps will be lost.

Note that command ovstop does not stop the Trap Receiver process.

To stop the Trap Receiver process, the following commands needs to be run:

nnmtrapreceiver -stop

At any time, the Trap Receiver status can be checked using:

nnmtrapreceiver -status

All the best

Marie-Noelle

Micro Focus Customer Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.

If you are satisfied with anyone’s response please remember to give them KUDOS and show your appreciation.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: NNM Application Failover VS High Availability

Jump to solution

Hi,

Is there anything else we could help you with on this discussion thread?

If not, would you mind marking the most appropriate post as Accepted Solution so that we could close this discussion thread?

This is because we are periodically reviewing the Open discussion threads to determine if any help is expected further.

When it is no more the case, the best is to close the discussion thread by marking the most appropriate post as Accepted solution. I may proceed and do so myself if no more activity is observed on this topic after a couple of days but the best would be for you to do it yourself if no more help is expected here.

Many Thanks

Marie-Noelle

Micro Focus Customer Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.

If you are satisfied with anyone’s response please remember to give them KUDOS and show your appreciation.
0 Likes
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.