Jump to content
Welcome to our new Citrix community!

MPX 8200 HA PAir


Recommended Posts

Does anyone know if when breaking the HA pair/sync on MPX devices and leaving Primary as Stay Primary and Secondar as Stay Secondary is there a way to firmware upgrade on Secondary node without failing over to it and making it primary?

 

Basically we upgraded fw on Secondary node and I want to test all the VIPs and VPN connectivity without having to if possible make the current Secondary node Primary .

 

Not sure if this is possible but let me know what you guys have done.

 

Also we upgraded from 12.1.51.19 to 12.1.55.18 does the Netscaler Gateway plugin need to be updated on client PCs?

Link to comment
Share on other sites

Just to be very clear about terminology:

if you *break* the ha pair (aka rm ha node), then you have two netscalers with the same config both trying to be active at the same time and causing ip conflicts unless you a) remove one form the network or b) clear config on one.

 

If you are in an ha pair and want to prevent ha sync/prop events while doing upgrades, you can disable sync/prop on both nodes. You are still in ha pair BUT command prop/sync is suspended until you re-enable the settings. Remember to save ns config on both nodes before doing any reboot, or they will forget this is off.  This helps prevent sync/prop from resuming until you are ready while you are moving between states during upgrade/maint cycles.

 

--------

StaySecondary and StayPrimary limit the failover of the primary node to the partner system under certain circumstances; but are not stopping participation in the ha pair, depending on what we actually describe.  For example, if StayPrimary is set on the current primary ns (NSA) in an HA pair. Then it will not voluntarily give up the role or allow failover to the partner NS (NSB), UNLESS something is wrong on NSA.  Sync/Prop is still in effect.  Just manual failovers will not occur (like force failover) unless something is wrong on NSA.

 

StaySecondary on the other hand prevents NSB (in this case) from taking over as primary no matter what is wrong with NSA.  EVen if failsafe mode is enabled, NSB will not take over, unless the staysecondary is returned to enabled status.  But this NS is still participating in ha prop/sync events (unless explicitly disabled).  While StaySecondary is set (and anytime it is in the secondary role without staysecondary), the secondary member of the HA pair only has ownership of the NSIP. It only takes ownership of shared ips (SNIPS/VIPS/etc). when it becomes the primary member.

 

Please note that if you set StaySecondary on a standalone netscaler (not in a pair). Or if staysecondary is set and the ns is removed from the pair, it is active for all IPs.  So breaking the ha pair, even if stay secondary is set, is not going to prevent you from having an ip conflict if both ns are still connected to the active network.

---

 

So to your question, you want to upgrade an ha pair's secondary member (confirm if it is working) but without impacting the primary....  The only way to do this would be to make sure the secondary was on an isolated network so that it doesn't create a conflict. Usually during the Upgrade cycle. You suspend sync/prop between nodes.  You upgrde current seconddary (NSB). Then you failover to make NSB primary to confirm things are working. If not, you then fail back to NSA (not upgraded) as primary.  If it works, you proceed to upgrade the new secondary NSA.  

 

So if you wanted to test the upgrade on NSB without affecting real traffic. You would have to somehow isolate NSB when it becomes active to make sure you don't have two primaries owning duplicate ips in the same live network.

 

But setting staysecondary will not have it own ips while in the ha pair. And breaking the ha pair is going to cause two duplicates with ip conflicts on network.

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

43 minutes ago, Sukhwant Singh1709160818 said:

Also we upgraded from 12.1.51.19 to 12.1.55.18 does the Netscaler Gateway plugin need to be updated on client PCs?

Just because I thought this would get lost in the above post.

 

I do not know if the gateway plugin from 12.1.51.19 to 12.1.55.18 is a required upgrade or optional.  I don't know if they have a matrix to identify this  beyond testing and confirming your plugin upgrade (essential or always) option in the session policy or global parameters.  But it isn't documented in an obvious location that I can find.    I  know you are trying to test to confirm this; but you might just need to spin up a test vpx and try it there to see.

Link to comment
Share on other sites

3 hours ago, Rhonda Rowland1709152125 said:

Just to be very clear about terminology:

if you *break* the ha pair (aka rm ha node), then you have two netscalers with the same config both trying to be active at the same time and causing ip conflicts unless you a) remove one form the network or b) clear config on one.

 

If you are in an ha pair and want to prevent ha sync/prop events while doing upgrades, you can disable sync/prop on both nodes. You are still in ha pair BUT command prop/sync is suspended until you re-enable the settings. Remember to save ns config on both nodes before doing any reboot, or they will forget this is off.  This helps prevent sync/prop from resuming until you are ready while you are moving between states during upgrade/maint cycles.

 

--------

StaySecondary and StayPrimary limit the failover of the primary node to the partner system under certain circumstances; but are not stopping participation in the ha pair, depending on what we actually describe.  For example, if StayPrimary is set on the current primary ns (NSA) in an HA pair. Then it will not voluntarily give up the role or allow failover to the partner NS (NSB), UNLESS something is wrong on NSA.  Sync/Prop is still in effect.  Just manual failovers will not occur (like force failover) unless something is wrong on NSA.

 

StaySecondary on the other hand prevents NSB (in this case) from taking over as primary no matter what is wrong with NSA.  EVen if failsafe mode is enabled, NSB will not take over, unless the staysecondary is returned to enabled status.  But this NS is still participating in ha prop/sync events (unless explicitly disabled).  While StaySecondary is set (and anytime it is in the secondary role without staysecondary), the secondary member of the HA pair only has ownership of the NSIP. It only takes ownership of shared ips (SNIPS/VIPS/etc). when it becomes the primary member.

 

Please note that if you set StaySecondary on a standalone netscaler (not in a pair). Or if staysecondary is set and the ns is removed from the pair, it is active for all IPs.  So breaking the ha pair, even if stay secondary is set, is not going to prevent you from having an ip conflict if both ns are still connected to the active network.

---

 

So to your question, you want to upgrade an ha pair's secondary member (confirm if it is working) but without impacting the primary....  The only way to do this would be to make sure the secondary was on an isolated network so that it doesn't create a conflict. Usually during the Upgrade cycle. You suspend sync/prop between nodes.  You upgrde current seconddary (NSB). Then you failover to make NSB primary to confirm things are working. If not, you then fail back to NSA (not upgraded) as primary.  If it works, you proceed to upgrade the new secondary NSA.  

 

So if you wanted to test the upgrade on NSB without affecting real traffic. You would have to somehow isolate NSB when it becomes active to make sure you don't have two primaries owning duplicate ips in the same live network.

 

But setting staysecondary will not have it own ips while in the ha pair. And breaking the ha pair is going to cause two duplicates with ip conflicts on network.

 

 

 

 

 

 

 

 

Thanks for this very detailed and insightful reply! This is great! So I currently have our MPX devices in non SYNC and Propagation mode. When you mentioned creating an isolated network basically what you're saying is if we are using 10.x for everything then we should carve out a 192.X for this isolated network, correct? Then I'd assume I would modify my local host file and put in 192.x IP that would map to the virtual server on the Netscaler that I'm trying to connect to?

Link to comment
Share on other sites

All I'm saying is is that if you have both netscalers on the same live, physical netscaler and you break the ha pair, you will create two systems on the same network with conflicting ips and you will break something affecting your users.

 

There is no easy way to make a current secondary netscaler actively pass traffic for validation purposes without it being the primary (and therefore possibly creating a conflict with your other primary if you don't do this right); if you are trying to do this without affecting user traffic you can't do it in the regular network deployment.  To bring it online in an isolated network segment and make changes would give you the chance to potentially verify things... but then you have to get it back to the right state for return to ha. And at this point, things are messy, hard, and likely to go wrong.

 

You should have a test netscaler that you can do the upgrade on and validate in an isolated segment. Then on the production system, make the secondary live; if it doesn't work failback to the primary to continue.  Trying to isolate the secondary for a test without impacting production is going to be tricky.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...