Jump to content
Welcome to our new Citrix community!

Load balancing: Configured Method: CustomLoad but Current Method=Round Robin


Raza Mir

Recommended Posts

Hi,

 

We have configured the Load Balancing Method as CUSTOMLOAD (CPU Based), but when I run cmd, 'show servicegroup ServiceGrp-1', I can see that it show as below;

 

Configured Method: CustomLoad

Current Method=Round Robin Reason: All bound services are UP.

 

Please advice how I can have the Current Method as Round Robin,

 

Thanks

Link to comment
Share on other sites

Most of the performance load balancing methods (leastconnection, leastbandwidth, etc) fall back to roundrobin under certain conditions to avoid load balancing black hole issues. Documented as the "slow start" process. After so many requests, in roundrobin, the lb vserver returns to the configured load balancing method.

 

Custom Load also falls back to roundrobin under certain conditions; afterwards it will return to the configured load balancing method based on least load by customload (via load monitor). Details here:  https://docs.citrix.com/en-us/netscaler/12/load-balancing/load-balancing-advanced-settings/slow-start-service.html

 

In the above statement when you asked how can i have current method as roundrobin, i think you mistyped your question. What you have currently is fallback to roundrobin.

IF you want the ocnfigured method roundrobin, change the lb vserver method to roundrobin or other and unbind the load monitor from the destination services/service group.

If you in fact meant, how do you get the current method to be based on the configured method customload...then it depends on why the fallback to roundrobin occurred.

 

By default the slow start process falls back to roundrobin fro the next 100 req * # of bound services *# PPE.  (If you have 3 services bound it will be the next 300 requests * # ppe (packet processing engines).  

 

For custom load, the fallback reason is usually due to a scenario like services going from DOWN to UP, lb method being changed, or some other reason that could result in an uneven distribution of load balancing.  It might also be that the metric you are using hasn't reached threshold yet or no metric has been retrieved yet to distribute based on load.  If for custom load the fallback occurs and this is a new setup, it could be waiting until metrics are available from the load monitor to generate metrics for comparison. Remember for custom load, though you need the load monitor to gather the snmp metrics AND a separate monitor for up/down detection.

 

IT could also be an issue with the customload threshold you set. If none of the services are above a given threshold, then roundrobin will be in use until there is a comparison that can be made.  (This is a breakdown from an old versin of the code/gui...but the config digs into custom load):  http://netscalerassasin.blogspot.com/2016/12/custom-load-monitor-on-netscaler.html

 

Bottom line, fallback to roundrobin is normal and works if we don't have metrics to evaluate or when services go from down to UP and to avoid an uneven distribution scenario.  

Second thought: custom load should only be used if it really is the best way to load balance as opposed to simpler scenarios like leastconnections.  (Its there and it is there for a reason, but a lot of times a simpler method will work just as well.  You working a bit harder to gather snmp polling data.)

 

Link to comment
Share on other sites

Thanks for detailed reply. SNMP Monitor is up.  Yes that correct that I want the Load Balancing method CUSTOMLOAD, but its currently running with Round Robin.

 

Please have a look at my  attached settings, can you see any issue.

1)     I am not understanding that at which point or request I will be start using the CUSTOMLOAD. 

2)     If CUSTOMLOAD Start & after that number of requests drop , do the load balancing method will fallback to Round Robin Again.

Thanks

vServer+monitor.rtf

Link to comment
Share on other sites

Requests aren't being dropped; they are being distributed by roundrobin (which is a normal procedure for this type of load balancing methods). When conditions are met, it will return to load by load monitor.  Any time a service goes from DOWN to UP it is going to go back to roundrobin for a period of time.  

This is the reason code givin on the vserver here:

On lb vserver status:

Configured Method: CUSTOMLOAD

        Current Method: Round Robin, Reason: Bound service's state changed to UP       

So the reason why you are getting this message on the servicegroup members:  "Service contributing to RR" is effectively noting that these are the members being distributed against (in case some were down or not in play.  Why they list it as  warning is an odd choice; but its normal behavior for the fallback scenario. If you don't want fallback to roundrobin, you would use a plain hashing algorithm instead of customload or the least<methods>.

 

Without the fallback to roundrobin, you could end up overwhelming a given service with too many requests if the load was wildly different from the other services as it is the only one getting requests for the foreseeable future. Also, if there isn't current snmp data to gather.  

 

So, the fallback to roundrobin is normal and then it will go back to the load based requests if applicable. Persistence is still honored, so transactions will not be broken.

 

In general customload load balancing is complicated and usually can be accomplished with a more traditional method instead. But if you need it, just recognize the fallback to roundrobin is normal. Make sure the snmp metric table is being populated...but here's the thing, all the weights are equal so that's the same has having no weight specified.  But your threshold takes CPU to 100% utilization; the whole point of a cpu-based load evaluation is to make sure the ADC doesn't continue sending traffic to the server once its at a max load threshold; reality is your server will stop performing before you get it to 100% cpu (effectively anyway); so CPU should be maxed at 70% or 80% or 85% or I wouldn't even bother with a cpu-based load metric. (You want existing transactions to have enough head room to complete while rejecting new connections/requests at this level.)

 

 

 

 

Link to comment
Share on other sites

Thankyou soo much Rhonda for great details explanation of ''fallback to Round Robin', '"Service contributing to RR" 'CPU threshold mistake I was doing' & explanation of weight. I understand now. Much Appreciated.

 

- Kindly just only explain further that when you says that 'When conditions are met, it will return to load by load monitor. what are these conditions?

Thanks 

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