[Deploying Sakai] mod_proxy_balancer and nofailover=On

[Nuno Fernandes]

Hi all,

Please, let me revival this "old" thread about using *nofailover=Off* with
mod_proxy_balancer :)

We are using mod_proxy_ajp and mod_proxy_balancer for a long time now. The
most relevant part of uur configuration is as follows:
ProxyPassMatch /* balancer://sakaiCluster stickysession=JSESSIONID
nofailover=on maxattempts=2
<Proxy balancer://sakaiCluster>
        BalancerMember ajp://localhost:8009 loadfactor=10 route=elearning-a
        BalancerMember ajp://localhost:9009 loadfactor=10 route=elearning-b
redirect=elearning-d status=D
        BalancerMember ajp://10.11.100.162:10009 loadfactor=45
route=elearning-c
        BalancerMember ajp://10.11.100.162:11009 loadfactor=45
route=elearning-d
</Proxy>

However, whenever a tomcat instance goes down (into an error state) users
are presented with the 503 error page and are sticky to that unusable tomcat
instance (forever, unless this is manually changed in the balancer-manager
page).

To my understanding, and accordingly to the Apache
docs<http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass>,
only the *stickysession* parameter is responsible to keep an user on the
tomcat he first connects to, ensuring all subsequent request are all made to
that same tomcat.

On the Apache docs page, the *nofailover* parameter has the following
description:
"*If set to **On** the session will break if the worker is in error state or
disabled. Set this value to On if **backend** servers do not support session
replication*.".
I believe that last sentence is what makes us assume that "On" is also
needed. However, by "googling", I can also find this explanation:
"*(...) **Basically, **nofailover** Off means if the instance that the
session is associated with goes down/becomes unreachable, then redirect the
user to the next available instance. The user will lose their session
information (unless you have set up session replication in **jBoss**- that's
another topic) but will not get a white page. If you set this to On,
individual users will get a 503 error if their server goes down. (...).*"
(from here<https://www.sparkred.com/confluence/display/ATGDC/Load+Balancing+ATG+instances+on+jBoss+via+Apache+mod_proxy>,
a page which contains instructions on configuring JBoss + Load balancing).

By "googling", it also looks that Mondo <https://mondo.su.se/portal> (the
sakai installation from the Stockholms Universitet) is using
*stickysession=JSESSIONID
nofailover=Off*
(here<https://roundup.it.su.se/confluence/display/sakaisam/apache-config>
).

So, apparently, it looks like it is safe to use *nofailover=Off* when load
balancing Sakai with mod_proxy_balancer.

*Can anyone using this setting in production confirm this?*

Thanks,
Nuno




On Tue, Feb 16, 2010 at 8:10 PM, Katherine Faella <kmf at uri.edu> wrote:

>
> Martin,
> We are using Apache to front end our multiple Sakai/Tomcat instances.  We
> have nofailover=On and although I do not know the technical details I think
> you will find it important to have that setting.  As I understand it, some
> part of your state in Sakai is kept with the instance on which you reside.
>
> Our config includes:
> ProxyPass /balancer-manager !
> ProxyPass / balancer://SakaiCluster/ stickysession=JSESSIONID nofailover=On
> ProxyPassReverse / balancer://SakaiCluster/
>
> <Proxy balancer://SakaiCluster>
>
> ProxySet lbmethod=byrequests
> BalancerMember ajp://localhost:8009 route=SakaiAlpha1 retry=1
> BalancerMember ajp://localhost:8010 route=SakaiAlpha2 retry=1
> BalancerMember ajp://localhost:8011 route=SakaiAlpha3 retry=1
> BalancerMember ajp://artlake.pvt.uri.edu:8009 route=SakaiBeta1 retry=1
> BalancerMember ajp://artlake.pvt.uri.edu:8010 route=SakaiBeta2 retry=1
> #BalancerMember ajp://artlake.pvt.uri.edu:8011 route=SakaiBeta3 retry=1
> #BalancerMember ajp://artlake.pvt.uri.edu:8012 route=SakaiBeta4 retry=1
> </Proxy>
>
> We have used the balancer-manager to move users off a particular node. It
> can take some time but is effective.  We do not do maintenance on a per
> instance basis at this point.  If we have updates we use a scheduled
> downtime to move them into production all at once.
>
> Kathy
> University of Rhode Island
> University Computing Systems
> --
> View this message in context:
> http://n2.nabble.com/Deploying-Sakai-mod-proxy-balancer-and-nofailover-On-tp4580633p4582056.html
> Sent from the WG: Production / Deplying Sakai (
> production at collab.sakaiproject.org) mailing list archive at Nabble.com.
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>



-- 
Nuno Fernandes  .  { Analyst/Programmer }

|| web  . { http://www.ufp.pt  |  http://tinyurl.com/nfgrilo  |  follow_me @
nfgrilo }
|| work . { Universidade Fernando Pessoa  |  Praça 9 de Abril, 349  |
 4249-004 Porto }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100518/261bc054/attachment.html