Re: [cas-user] Problem with CAS Clustering and LT parameter
We've been running a load-balanced CAS cluster of two nodes for a number of years now. Clustering is supported provided you have session affinity during the login process. If anyone has achieved truly stateless clustering, it would include session replication among cluster nodes (among other things), with resulting dramatic increase in complexity. Is there any reason you can't configure your cluster for session affinity? Session affinity is standard practice in the HA deployments I'm aware of. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
I'm only considering shared sessions because that seems to be what's recommended in the CAS wiki. Our networking team was unsure how sticky sessions at the load balancer would affect things (like applications validating STs, etc). Assuming I can get them happy with that solution, I'm perfectly happy to go that route. -ds On 7/6/2015 1:12 PM, Waldbieser, Carl wrote: Dave, We are going ahead with sticky sessions behind an nginx proxy. Authentication at the CAS server is not RESTful due to (I believe) the Spring conversational state. A shared session would be one way to accomplish that, but that seems like a rather complex solution to me. We've tested with sticky sessions and had satisfactory results. Thanks, Carl Waldbieser ITS Identity Management Lafayette College - Original Message - From: Dave Steiner stei...@rutgers.edu To: cas-user@lists.jasig.org Cc: Aditi Deshmukh ad...@oit.rutgers.edu Sent: Monday, July 6, 2015 12:36:59 PM Subject: [cas-user] Problem with CAS Clustering and LT parameter We've been running a load-balanced CAS cluster of two nodes for a number of years now. The TicketRegistry is rep/memcached. Evidently our LT processing has been broken for quite some time. As we are trying to upgrade from 3.3.5 to 3.5.2 we noticed problems due to the LT parameter not being accessible across both CAS instances. In researching this, the Cas Clustering wiki page (https://wiki.jasig.org/display/CASUM/Clustering+CAS) suggests to use Tomcat Session Replication. We don't have any experience with Tomcat Session Replication. Is this definitely the way to go? How does this hold up under heavy loads? I'm assuming no one is recommending sticky sessions at the load balancer? Reasons? Also, I read some messages about putting the LT parameter into the TicketRegistry. Was that ever tried? Is it something that the CAS community recommends or not? Thanks in advance for all help and suggestions. -ds -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
Personally, we just set up our three-node CAS4 instance with Hazelcast and front-ended it with our Barracuda (no special config required.) I'm fairly certain the back end ticket store is irrelevant here. The poster appears to be discussing fully stateless clustering, which involves special (and difficult) distribution of servlet session data between all nodes. Most HA deployments don't care about node loss during the relatively short-lived login process. To the user it would just appear as a glitch when the LB/app router/whatever routes to a new node that doesn't know what session is described by the posted JSESSIONID cookie. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
Personally, we just set up our three-node CAS4 instance with Hazelcast and front-ended it with our Barracuda (no special config required.) It was mch easier, took less than an hour to get set up... We verified that we can kill any number of nodes, and as long as one is up, everything fails over splendidly :) https://github.com/unicon-cas-addons/cas-addon-hazelcast-ticket-registry Added the following tag to web.xml, right before the closing /web-app tag to make it deploy between servers: distributable/ Add the following code dependency groupIdnet.unicon.cas/groupId artifactIdcas-addon-hazelcast-ticket-registry/artifactId version1.0.0-GA/version scoperuntime/scope /dependency to cas-server-webapp/pom.xml edit cas-server-webapp/src/main/webapp/WEB-INF/web.xml add classpath*:/META-INF/spring/*.xml to context-param param-namecontextConfigLocation/param-name param-value /WEB-INF/spring-configuration/*.xml /WEB-INF/deployerConfigContext.xml classpath*:/META-INF/spring/*.xml /param-value /context-param Add the line hz.cluster.members=muwacnode1.millikin.edu,muwacnode2.millikin.edu,muwacnode3.millikin.edu to cas-server-webapp/src/main/webapp/WEB-INF/cas.properties Recompile, redeploy, all set :) Chris Dave Steiner stei...@rutgers.edu 07/06/15 11:37 AM We've been running a load-balanced CAS cluster of two nodes for a number of years now. The TicketRegistry is rep/memcached. Evidently our LT processing has been broken for quite some time. As we are trying to upgrade from 3.3.5 to 3.5.2 we noticed problems due to the LT parameter not being accessible across both CAS instances. In researching this, the Cas Clustering wiki page (https://wiki.jasig.org/display/CASUM/Clustering+CAS) suggests to use Tomcat Session Replication. We don't have any experience with Tomcat Session Replication. Is this definitely the way to go? How does this hold up under heavy loads? I'm assuming no one is recommending sticky sessions at the load balancer? Reasons? Also, I read some messages about putting the LT parameter into the TicketRegistry. Was that ever tried? Is it something that the CAS community recommends or not? Thanks in advance for all help and suggestions. -ds -- Dave Steiner stei...@rutgers.edu Identity Management, ESS ASB101; 848.445.5433 Rutgers University, Office of Information Technology -- You are currently subscribed to cas-user@lists.jasig.org as: cmy...@mail.millikin.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
I'm only considering shared sessions because that seems to be what's recommended in the CAS wiki. I don't feel like the CAS wiki ever had any good high-level discussion of HA. In any case the new-ish CAS4 documentation has a HA page that spells out session affinity as a requirement for active/active deployments: http://jasig.github.io/cas/4.0.x/planning/High-Availability-Guide.html Our networking team was unsure how sticky sessions at the load balancer would affect things (like applications validating STs, etc). It tends to create hot spots on one node for a particular service, thus if you have a single that produces the heaviest load on CAS, it till tend to get pegged to a single node instead of distributing load throughout all peers in the pool. Failover characteristics are exactly the same as without session affinity. We've found that hot spots can cause trouble in fairly extreme circumstances [1], but in most cases it's a non-issue. M [1] Once a CAS-enabled timeclock application got in a redirect loop that generated millions of service tickets in a ~120m period. Our service, remarkably, held up due to a cache-backed ticket registry that simply purged old entries to hold the flood of tickets. The CPU on the node handling all that traffic went red and sent off alarms, but held up admirably. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
Dave, We are going ahead with sticky sessions behind an nginx proxy. Authentication at the CAS server is not RESTful due to (I believe) the Spring conversational state. A shared session would be one way to accomplish that, but that seems like a rather complex solution to me. We've tested with sticky sessions and had satisfactory results. Thanks, Carl Waldbieser ITS Identity Management Lafayette College - Original Message - From: Dave Steiner stei...@rutgers.edu To: cas-user@lists.jasig.org Cc: Aditi Deshmukh ad...@oit.rutgers.edu Sent: Monday, July 6, 2015 12:36:59 PM Subject: [cas-user] Problem with CAS Clustering and LT parameter We've been running a load-balanced CAS cluster of two nodes for a number of years now. The TicketRegistry is rep/memcached. Evidently our LT processing has been broken for quite some time. As we are trying to upgrade from 3.3.5 to 3.5.2 we noticed problems due to the LT parameter not being accessible across both CAS instances. In researching this, the Cas Clustering wiki page (https://wiki.jasig.org/display/CASUM/Clustering+CAS) suggests to use Tomcat Session Replication. We don't have any experience with Tomcat Session Replication. Is this definitely the way to go? How does this hold up under heavy loads? I'm assuming no one is recommending sticky sessions at the load balancer? Reasons? Also, I read some messages about putting the LT parameter into the TicketRegistry. Was that ever tried? Is it something that the CAS community recommends or not? Thanks in advance for all help and suggestions. -ds -- Dave Steiner stei...@rutgers.edu Identity Management, ESS ASB101; 848.445.5433 Rutgers University, Office of Information Technology -- You are currently subscribed to cas-user@lists.jasig.org as: waldb...@lafayette.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
