Jump to content
Welcome to our new Citrix community!

Is there a default soAction?


Ross Helfand

Recommended Posts

Hi everyone,

 

I tried looking this up in the Docs but either I'm not looking in the right place or I'm missing something obvious.

 

I have an LB vserver configured, it has "-soMethod DYNAMICCONNECTION" set.  It is bound to our content switching vserver.  There is no soAction defined.  I understand that the threshold is based on 8 servers with maxClients of 90 for each.

I'm curious what happens to the request when the spillover threshold is reached?  I don't see any mention of soAction, so is the request just getting dropped or does it fall through back into our CS vServer?

 

Here is the config:

 

> show lb vserver MY_LBVS
	MY_LBVS (0.0.0.0:0) - HTTP	Type: ADDRESS
	State: UP
	Last state change was at Wed Feb  5 07:20:04 2020
	Time since last state change: 211 days, 05:42:15.880
	Effective State: UP  ARP:DISABLED
	Client Idle Timeout: 300 sec
	Down state flush: DISABLED
	Disable Primary Vserver On Down : DISABLED
	Spillover Method: DYNAMICCONNECTION	Dynamic Spillover Threshold: 720
	Appflow logging: DISABLED
	Port Rewrite : DISABLED
	No. of Bound Services :  8 (Total) 	 8 (Active)
	Configured Method: LEASTCONNECTION
	Mode: IP
	Persistence: NONE
	Vserver IP and Port insertion: OFF
	Push: DISABLED	Push VServer:
	Push Multi Clients: NO
	Push Label Rule: none
	L2Conn: OFF
	Skip Persistency: None
	Listen Policy: None
	IcmpResponse: PASSIVE
	RHIstate: PASSIVE
	New Service Startup Request Rate: 0 PER_SECOND, Increment Interval: 0
	Mac mode Retain Vlan: DISABLED
	DBS_LB: DISABLED
	Process Local: DISABLED
	Traffic Domain: 0

Bound Service Groups:
1)	Group Name: MY_SG

		1) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		2) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		3) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		4) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		5) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		6) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		7) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2
		8) MY_SG (xx.xx.xx.xx: 80) - HTTP State: UP	Weight: 2

Thanks!

Link to comment
Share on other sites

The spillover actions are determined by the backup vserver OR redirect url specified. If you are in GUI, you will see them and the spillover values under "protection  methods".

from the cli, these are the following parameters:

set lb vserver <vservername> -redirectURL <url destination> -backupvserver <backup vserver name>

Command reference here:  https://developer-docs.citrix.com/projects/netscaler-command-reference/en/12.0/lb/lb-vserver/lb-vserver/#set-lb-vserver

 

Spillover can be based on connection limit, percentage of health by weight, dynamicconnection and a few others in that section.

 

If spillover method is NONE:  vserver goes down for normal reasons:  all services down, no services bound, all services at max threshold. 

- With neither backup vserver or redirect url specified, then there is no spillover action and the vserver goes down (out of service actually)  when the spillover threshold is reached.

 

If the spillover threshold is reached (but no backup action specified (backup vserver or redirect url), then spillover threshold provides an additional condition to trigger a vserver down condition. Useful if you need a down state due to vserver connection or bandwidth limit (as opposed to the service limits), health allows you bring a vserver down when the health of services UP (by weights) falls below the minimal threshold so you can go "down" prior to all services failing.  DynamicConnection bases the threshold based on sum of max connections of the bound services (as opposed to a separate total on the vserver).

- Without a spillover action, the vserver just goes down.

- If a backup method is specified, then when the vserver is DOWN (for usual reasons) or the SPILLOVER CONDITIION is met, now the traffic spills over to the entity specified.

 

For Backup vservers, traffic continues to go to VIP1 (vserver1) and get a response; but the the backup vserver (vserver2) actually handles the load balancing/service destinations. The user is unaware of the change.

If a redirect URL is specified instead, then the user connects to VIP1 (vserver1) and when down or spillover limit reached, user will receive a 302 redirect to new redirect URL.

Usually, you only specify one or the other. But if both specified, backup vserver is attempted first (and any methods it has) before redirect url.

Non web-entities have backup vserver only and not a redirect url option.

 

Link to comment
Share on other sites

Thank you Rhonda!  I think I understand now.  Let me ask a follow-up.

 

We have our main application coming into a content switching vServer.  It has a bunch of rules and policies bound.  For example:

If requested URL = "a" then go to "a_lb_vserver"

if requested URL = "b" then go to "b_lb_vserver"

...

Then at the end, we have:

bind cs vserver main_app_cs_vserver -lbvserver default_lb_vserver

 

We do not have a backup vserver OR redirect url specified.  So, if "a_lb_vserver" hits spillover, due to DYNAMICCONNECTIONs being maxed out, then my understanding is that "a_lb_vserver" will go DOWN, and the request will fall through to the "default_lb_vserver."

 

Am I understanding correctly?

Link to comment
Share on other sites

Ignore cs vserver for a second.

If this was a regular lb vserver with its own backup methods, then when a_lb_vserver hits the spillover threshhold and no spillover method is specified...then yes the a_lb_vserver is DOWN or more technically out of service (as its down due to limit being reached and not down due to failure).

Existing transactions may complete; but no transactions going to a_lb_vsrver will not be processed.   The adc does not drop them, but if no destination is available the client will eventually timeout.

 

With cs in the mix, the cs vserver state update being UP or DOWN will determine how cs reflects the backend vserver "down" states (but won't change this conversation).

 

If policies hitting the cs vserver would go to a_lb_vsrver, but "a" is down/out of service, those requests will "fail" and or timeout, the request will timeout.

 

To test the impact simply:

1) create an lb vserver with no services bound so it is down and without a backup method, you get no response/timeout.

2) Then with cs vserver, you can see the same thing occurs...if no backup method on lb tier is present.

 

 

 

 

  • Like 1
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...