One of the take aways to think about with a active-passive failover setup is how Single Sign Out (SSOut) behaves. For those who use CAS 3.1 and higher, this feature will issue session invalidation calls whenever users logout of CAS to any application that had a service ticket validated.
If registry information is not replicated between machines and applications expect the CAS logout to invalidate session information, then users' application sessions will still be active until whatever mechanism is used to remember the user (cookie, session information, etc). This issue is alleviated when you replicate registry information via JBoss Cache, Memcached, or JPA. $0.02, A- On 11/19/08 7:36 AM, "Lin George" <[EMAIL PROTECTED]> wrote: > Thanks Arthur! >From your below email, I take some time to learn the link you > recommended. Looks like there are 3 solutions. All of them have pros and cons. > In order to achieve high availability (when one server is down, the > authentication system still works) and scalability (when the user base > increases, we could add more servers in order to improve authentication > performance) goal, which solution do you prefer? Or you prefer other > solution? CLUSTERING WITH REPLICATION We have been struggling to get a > clustering with replication environment setup using the JBoss Cache solution > (JbossCacheTicketRegistry), which was outlined in the link you mentioned. > However, there have been some unexpected problems maintaining a stable JBoss > Cache replication cluster. Though it is maintained by JA-SIG, there aren¹t > many people you will find that are very experienced with it much less managing > JBoss Cache; there are a number of people who will probably agree with me on > that. Another option for doing clustering with replication is to use the > MemCacheTicketRegistry available in CAS 3.3.0. This is the option favored by > Rutgers, who is the primary maintainer of the CAS code base. Scott B can > testify about it being lightweight, however I don¹t know anyone else that has > deployed it in their environments. CLUSTERING WITHOUT REPLICATION If you want > plain clustering without replication, then you could either go with a backend > data store holding users SSO information and have the CAS servers be dummies > by using the JpaTicketRegistry. This would allow your users to hit any of the > CAS servers and remove the need for replicating data, however you would have a > single point of failure (data store). FAIL OVER However, most CAS deployments > appear to use a active/passive fail over setup where you have two deployments > and have your load balancer direct traffic to the primary and fail over to the > secondary when necessary. This option requires little / no major > customization. regards, George -------------------------------------------- > ------------------------------------------------------------------------------ > --------- Message: 11 Date: Tue, 18 Nov 2008 14:27:00 +0100 From: Arthur Erd?s > <[EMAIL PROTECTED]> Subject: Re: high availability issue of CAS To: Yale CAS > mailing list <[email protected]> Cc: [EMAIL PROTECTED] Message-ID: > <[EMAIL PROTECTED]> Content-Type: > text/plain; charset=utf-8 There has recently been a question concerning CAS > load balance / failover. Take a look > at http://www.nabble.com/Best-practice-for-CAS-load-balance-failover-td1991210 > 0.html - it might be what you are looking for... Kind regards, Arthur > _______________________________________________ Yale CAS mailing > list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
