Best practice for committing changes in active-passive HA?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Best practice for committing changes in active-passive HA?

L1 Bithead

When making policy changes in an active-passive HA pair, do you usually edit and commit the policy using the active device, or the passive?  I have always made my changes on the active device, but lately I've been thinking that because the management CPU usage on the passive device is much lower, it might be faster running the commit there.  I checked the documentation and couldn't find any advice one way or the other.  Is there an official recommendation?  Would commits be faster if they were initiated from the passive firewall?

1 accepted solution

Accepted Solutions

Retired Member
Not applicable

So long as configs are in HA sync, commits should be possible on either active or passive device. With exception for box specific configs (HA settings, mgmt IP, etc), It should not matter which device you commit from.

View solution in original post

5 REPLIES 5

L4 Transporter

I believe you'll get an error message that says something like "this change will only be applicable on the local device" when making changes to the passive device.

Of course, you could make all your changes in Panorama (if you purchased it) and push it down to the devices from there.

Retired Member
Not applicable

So long as configs are in HA sync, commits should be possible on either active or passive device. With exception for box specific configs (HA settings, mgmt IP, etc), It should not matter which device you commit from.

What about the idea of commit on the passive unit which would have more free cpu at mgmtplane and because of that should compile (and commit) faster than if you do this on the active unit?

Or what is the flow when one hits the commit button?

Is it:

1) The box you are currently logged in to will commit the ruleset (compiling etc) and if successful it will load the dataplane. If commit is successful the config is then synced to its HA-partner who will perform the same operation.

or

2) When you hit commit the config is saved and directly sent to the HA-partner - both boxes will try to compile and program their dataplane at the same time. Not until both succeeded the user will be notified of a "Success!".

or something completely different than above?

L1 Bithead

Just to follow up, I tested this today using 4.0.12 and found that committing changes on the passive firewall was much faster than on the active.  In the past, we have experienced commits taking up to 10-15 minutes because the management CPU on the active firewall tends to be fairly busy.  On the passive firewall the commit took 2 minutes 10 seconds, and the sync to the active firewall finished 2 minutes 42 seconds later.  The web UI on the passive firewall was also a lot more responsive than the active firewall, so that saved some time too.  So my initial conclusion is that committing changes from the passive firewall is the way to go.

Dear mikand,

While this topic has been answered i would like to state my opinion as well.

The commit process is that the unit on which you do the commit will do the verification, the compliling of the configuration xml together with a bunch of other tests that will then be applied to the dataplane. AFTER the commit finishes on the unit, the configuration will be transfered to the paired unit and then a "HA Sync" event will take place. The HA Sync task is nothing more than another commit to that device (delta commit) but it will be a little bit faster because initial compilation does not take place (the configuration is already compiled when sent to the paired unit(.

Be careful and always do the changes on the same unit, to avoid configuration conflicts.

Moreover, it is a good idea to check that the HA Sync task on the paired unit has finished successfully before doing another commit on the unit you are usually committing. And always make sure that both units have the same application, threat, antivirus and url filtering versions (depending on your license some of these features would not be updatable) are the same on both units, and with most important the Application Database version (the appid's).

Regards,

George

  • 1 accepted solution
  • 6265 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!