Matt, based on what I have read on the JASIG site, I agree with you.
Part of the requirements given to me was to not have a user re-authenticate if part of the cluster fails. Memcache was eliminated. Using a DB involved too many groups within IS and increased cost. I am curious why you are choosing the EHCache ticket registry over DefaultTicketRegistry. Am I missing something? -john From: Kirk, Matt [mailto:[email protected]] Sent: Tuesday, August 16, 2011 10:05 AM To: [email protected] Subject: RE: [cas-user] CAS in load balanced environment Thanks for all the feedback. We're opting for the distributed Ehcache ticket registry over a database persistent registry across a CAS Cluster as we feel that if a node goes down, then the ticket replication will allow seamless access to services and therefore the DB is not required (and would itself be a single point of failure unless replicated in some fashion). The failed node can then be re-started and rejoin the cluster and be re-populated with the current tickets via the distributed Ehcache. If the entire cluster were to go down it would require users to re-authenticate but we consider this a (hopefully) rare and fatal system failure so forcing users to re-authenticate after system re-start is acceptable. This approach removes the need for a database and all the cost / admin etc that goes with it. Do you think is is a reasonable solution? Have I missed something which may change my thoughts? Thanks, Matt ________________________________ From: Scott Battaglia [[email protected]] Sent: 16 August 2011 14:55 To: [email protected] Subject: Re: [cas-user] CAS in load balanced environment On Tue, Aug 16, 2011 at 9:47 AM, Marvin Addison <[email protected]> wrote: > what is the Memcache solution and do you have a setup guide? See https://wiki.jasig.org/display/CASUM/MemcacheTicketRegistry. I'll discuss briefly what's _not_ in the manual. I think there's some misinformation in the community, borne out in list discussions and other venues, about the need for the repcache patches to memcached for clustering. I think repcache is absolutely unnecessary based on the failure mode of memcached. Consider a memcached cluster of 3 nodes, all noted in the CAS configuration. The Java memcached client will calculate a key and store it on one node. If that node goes down, the client will attempt to retrieve the key from the dead node and fail, returning an empty value. That will appear to CAS and ultimately the user that he or she is unauthenticated and will simply need to reauthenticate. Upon reauthentication the client will know that there are only two nodes remaining, and calculate a new key that will be stored on one of the two available nodes and proceed as normal. That is a _very_ graceful failure mode in my opinion, and there's no need for anything additional like repcached. It really depends on your needs. You may feel that its acceptable to force them to log back in if a node goes down, others may not. This is why we have a number of these backing mechanisms, you find the one that matches your expertise and meets your availability requirements. However, as you note, using repcached is optional, and just provides an extra level of redundancy if you want to apply the patch. (we did at Rutgers) Cheers, Scott > Is one solution favourable over another? Most folks choose based on experience with a particular technology. We use JpaTicketRegistry on PostgreSQL in production, but I'd be happy to switch to memcached if needed. I personally think Terracotta, JBossCache, and Infinispan are interesting technologies that are overkill for CAS. The complexity is not worth the benefits. That is absolutely a personal opinion and lots of folks would disagree. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
