Jump to content
Welcome to our new Citrix community!

Active-Passive at Backend Servers (SG) Level.


Recommended Posts

Hi All, 

 

We have a Virtual Server with 02 Backend Server configured with a Service-Group. Eg:

 

Virtual Server IP : 10.100.100.100 : 80

 

Service-Group :    Port-5200

Backend Server-1 :   10.10.10.10

Backend Server-2 :  10.20.20.20

 

Requirement is ->  Traffic/Hits should always be forwarded to backend server-1 (10.10.10.10) till it's UP,  backend server-2(10.20.20.20) should only get traffic when Server-1 goes down.

 

Regards

 

Link to comment
Share on other sites

You can use services or servicegroups, but you will need two separate service groups for this.

 

1. Create an lb vserver (primary) bound to service1 or servicegroup1 with member1

2. Create a non-addressable lb vserver (secondary) bound to service2 (or servicegroup2 with member2)

3) Set lb_vsrv_secondary as the backup vserver to lb vserver primary.

 

Example (using service groups, since you mentioned them):

add servicegroup svcg_primary HTTP

bind servicegroup svcg_primary 10.10.10.10 80

 

add servicegroup svcg_secondary HTTP

bind servicegroup svcg_secondary 20.20.20.20 80

 

add lb vserver lb_vsrv_secondary HTTP 0.0.0.0 0

bind lb vserver lb_vsrv_secondary svcg_secondary

 

add lb vserver lb_vsrv_primary HTTP <VIP1> 80

bind lb vserver lb_vsrv_primary svcg_primary

set lb vserver lb_vsrv_primary -backupVserver lb_vserver_secondary

 

 

 

 

 

Link to comment
Share on other sites

Why, do you want a policy-based feature?  What problem do you want to solve, that you don't think the back up vserver solves (to help get a better idea of how to help).

 

You can use responder policies to redirect traffic based on conditions (like source/destination IP and path/url things). Rate limiting *could* be used based on traffic volume, BUT load balancing's purpose is to direct traffic to available resources base on status (up/down) or load thresholds. If you want to do this in any other feature you are re-inventing a wheel with less tools. 

 

The secondary lb vserver is non-addressable and therefore is never seen by users directly. Traffic goes from to client to VIP1 (vserver1); if its service is dow, then and only then is traffic directed to the service destinations of the secon non-addressable vserver. Since it doesn't have a VIP of its own, the inbound traffic still arrives on VIP1.

 

To handle all traffic on vserver1/service1 while it is up AND only hit vserver2/service2 when the primary is down is what this active/passive implementation does.  Other variations involve priority load balancing.

Remember service and servicegroup member up/down states are controlled by monitors and service-level thresholds (connection limits; health, bandwidth, if configured).

Link to comment
Share on other sites

Quote

 

Hi Rhonda, 

 

We have configured as per solution -1

 

add servicegroup svcg_primary HTTP

bind servicegroup svcg_primary 10.10.10.10 80

 

add servicegroup svcg_secondary HTTP

bind servicegroup svcg_secondary 20.20.20.20 80

 

add lb vserver lb_vsrv_secondary HTTP 0.0.0.0 0

bind lb vserver lb_vsrv_secondary svcg_secondary

 

add lb vserver lb_vsrv_primary HTTP <VIP1> 80

bind lb vserver lb_vsrv_primary svcg_primary

set lb vserver lb_vsrv_primary -backupVserver lb_vserver_secondary

 

Tested the same and it's partially working. Here partially means....

 

When (10.10.10.10-Primary) backend server goes down, traffic failover to Backup Virtual Server configured with (20.20.20.20) . But when Primary (10.10.10.10) comes back the traffic from Secondary (20.20.20.20) didn't fallback to primary which is the desired behaviour here.

 

Simply, Failover is working(Primary to Secondary) ....but Fallback (Secondary to Primary) when primary comes back.

 

Rgds

 

 

Link to comment
Share on other sites

Do you have any lb persistence enabled?  As persistence will keep transaction on secondary destination for existing traffic until expired. While new transactions should to to primary only.

 

Let's check for any unexpected settings:

show ns runningconfig | grep <svcgname primary> -i

show ns runningconfig | grep <svcgname backup> -i

show ns runningconfig | grep <lb vserver primary name> -i

show ns runningconfig | grep <lb vserver backup name> -i

 

You can obscure the ips as needed; but this will let us confirm there isn't an unexpected setting in use as well.

 

Also, confirm if you are using default monitors or any custom monitor scenarios on the servicegroups.

If you toggle the service member or server off, confirm the servicegroup is down and hte lb vserver is down. When you toggle the server backup up, the servicegroup and lb vserver return to an up state (or is there a delay)?

 

 

 

Link to comment
Share on other sites

Hi Rhonda, 

 

Yes, when things were not working as desired we have configured PERSISTENCE on Primary VS.

 

We are using default monitor on services.

 

We have not created any Service-Group. We have calling the Service (created with Single Server) under VS for both Primary and Backup VS.

 

And Primary VS is going down when we are stopping services on server and when services on the Server restored VS is coming up. 

 

Only problem is Traffic is not fallbacking to Primary from Secondary when Primary came UP.

 

Link to comment
Share on other sites

That's why I asked for the config information  to see if something unexpected is configured on the vservers or services.  (Even though you say you aren't using a servicegroup, your reference above says you are...regardless they work the same as individual services if a single member is bound.)

 

In my test, after the primary service/primary lb vserver comes up, the traffic returns to vserver 1.  So I would check if you have any other values set that might be affecting the decision process.  Also, any other features in use such as caching or responder in addition to load balancing that may be changing the processing flow?

 

For example, did you set the option "disable primary when down" on the primary vserver?  This would prevent fallback when primary recovers, without manual intervention. So this setting should not be enabled.  This was the only time in my testing where traffic stayed on backup vserver after the primary returned to an up state, without manually re-enabling.  This setting should not be enabled for the scenario you describe. 

set lb vserver lb_vsrv_primary -disableprimarywhendown OFF

  

 

 

 

 

Link to comment
Share on other sites

Hi Rhonda, 

 

Primary Virtual Server  :   VS_Primary

 

Backup Virtual Server :     VS_Backup

 

Active Service :          Service_Active

 

Passive Service :        Service_Passive

 

Here is the O/P from LB.

 

 

> show ns runningconfig | grep Service_Active -i

add service Service_Active H_10.10.10.10 HTTP 5200 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO -td 2

bind lb vserver VS_Primary  Service_Active

> show ns runningconfig | grep Service_Passive -i

add service Service_Passive H_20.20.20.20 HTTP 5200 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO -td 2

bind lb vserver VS_Backup  Service_Passive

> show ns runningconfig | grep VS_Primary  -i

add lb vserver VS_Primary  HTTP 10.100.100.100 80 -persistenceType SOURCEIP -cltTimeout 180 -backupVServer VS_Backup  -td 2

add lb vserver VS_Backup  HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180 -td 2

bind lb vserver VS_Primary Service_Active

bind lb vserver VS_Backup  Service_Passive

> show ns runningconfig | grep VS_Backup -i

add lb vserver VS_Primary  HTTP 10.100.100.100 80 -persistenceType SOURCEIP -cltTimeout 180 -backupVServer VS_Backup  -td 2

add lb vserver VS_Backup HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180 -td 2

bind lb vserver VS_Backup  Service_Passive

 

 

We have enabled Persistence (SourceIP) on both VS.   "disable primary when down" option is unchecked / not enabled.

 

Link to comment
Share on other sites

Which version of ADC firmware are you on in case there is version specific behavior?

So, the persistence shouldn't be a problem in this case. It didn't affect my testing on the version of the firmware I was on when a single service per destination was used BUT, since you have a single service on the destination, try setting both vservers persistence to none instead and see if this changes behavior.  With only a single service, persistence may not even be required.

 

Confirm that integrated caching (IC) is disabled on the ADC and/confirm that your web browser isn't serving cached content instead of sending traffic to ADC. Such as incognito mode or a Shift+F5 or Ctrl+Shift+Del between requests.  Confirm lb vserver "hits" and service hits in stats.  Browser caching may complicate the test case.

 

Double check that when the primary service comes online, the primary service and lb vserver reflect an UP state and there isn't some sort of monitor delay.

 

Finally, If still no change, run an nstrace to see if anything else unexpected is happening with traffic.

 

We'll see if anyone else has ideas.  IF its none of the above.

  

 

 

 

 

Link to comment
Share on other sites

On 6/4/2021 at 10:23 PM, Rhonda Rowland1709152125 said:

 

Hi Rhonda , 

 

looks none of the above. we already checked all the things did'nt observe anything suspicius

 

Initially persistence was not there, when things were not working we have  enabled the same but no improvement.

Link to comment
Share on other sites

Again, Which version of ADC firmware version are you on in case there is version specific behavior?

Is the  LB feature enabled?  

 

I've repro'd the expected results on two different environments on 13.0.58 and a 13.0.6x version.  And each time, the backup reverts back to primary when the primary comes back online.

Browser caching or ADC caching can interfere with these results.

If you have any other features bound to the lb vserver like responder might impact results.

If the vserver has both a redirect url and a backup vserver, things could get more interesting than expected. 

If you are doing anything by dns name instead of ip, then dns caching may apply.

 

If there are differences in versions and differences in behavior, you may have to go through support.

But the results I've seen for a basic config match up with what I've described. Typically, the only time traffic will not revert back to primary is if the primary is not returning to an UP state (and may be related to monitor issues) or the "disable backup primary when down" setting is in use.

Confirm that when you restore the primary settings the service and its vserver return to an "UP" state and there isn't a delay in the monitor returning to "UP".

 

So, if there is really nothing different than the config you shared, share your firmware version and then it might require support.

 

Unless someone else can thing of any other causes.  Good luck and sorry we haven't figured it out.

 

 

 

Link to comment
Share on other sites

  • 1 year later...

Hi 

 

I see the same behavior with NS13.0 82.42.nc. 

We have 2 backend applications  sing Websockets. The idea is to have active-hotstandby (passive) 

Did that: 

* 1. Create an lb vserver (primary) bound to service1 or servicegroup1 with member1  

* 2. Create a non-addressable lb vserver (secondary) bound to service2 (or servicegroup2 with member2)  

* 3. Set lb_vsrv_secondary as the backup vserver to lb vserver primary.  

 

Do I assume correctly, by default both vlbs are Green and UP. Then the primary fails and all new connections will be used by the backup one. So far so good. 

If the primary comes up, new connections are indeed rerouted to primary, but if I have a client already connected to the backupvlb it doesn't looks like these get disconnect, or any RESET being send. They just continue working on the backup one. 

 

NC.thumb.JPG.7322f4b07dd5a5cf7aacc17e3f563f6a.JPG

Link to comment
Share on other sites

On 11/25/2022 at 10:16 AM, Michal Kuzak said:

Do I assume correctly, by default both vlbs are Green and UP. Then the primary fails and all new connections will be used by the backup one. So far so good. 

If the primary comes up, new connections are indeed rerouted to primary, but if I have a client already connected to the backupvlb it doesn't looks like these get disconnect, or any RESET being send. They just continue working on the backup one. 

 

Michael,

 

If I read what you stated correctly, then "yes". (Depends on your persistence settings.)

If when the primary is down, a user is sent to the backup vserver (#2), and then the primary recovers, the user sent to the backup may remain on the backup vserver due to persistence until that session expires before returning to the regular primary.

New sessions, should only be served by the primary which is NOW up.

 

The first way to modify this behavior is to use the "disable primary when down", meaning you have to manually re-enable the primary after recovery so it will not except connections until you are ready to fail back.  This is set on the primary and when it goes down due to service failure it then enters a disabled state, so even if service recovers, you have to manually enable to return traffic to primary even if it is back in an up state. This doesn't prevent use of secondary, just keeps everything on secondary until you want to fail back. (Again, recommend a test to make sure of behavior.)

 

The other way, is to have the secondary DOWN while the primary is UP and combine with a down state flush setting on the secondary service.  This would require two monitors on the backup service. One to determine if the actual service #2 is working and a second monitor with REVERSE:enabled to monitor the primary service IP/Port (so mon2 is on service2, but monitoring service 1 up/down state.)  Therefore when service 1 is UP, service 2 is down, returning users to service 1. I don't know if I like this method, as it may delay accepting traffic when service 1 first fails.  

 

Third method might be to see if priority load balancing, directs traffic only to Tier 1/service 1 destination.  And only if its down directs traffic to tier 2/service 2 destination. I just haven't tested in a while to verify that all traffic reverts to Tier 1 when it recovers and stops transaction on Tier 2 or if existing Tier 2 scenarios continue until complete.

 

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...