Misagh, Thank you for the comments. I believe one of our options might be to simply stop replicating the tickets since we are using primary/failover setup (even with a 3rd server introduced). As you said the only caveat I can think of is that users would lose their sessions.
Is there a reason to replication service tickets in a primary/failover setup? I assume that since the switch to the failover sever would take ~30 seconds anyway it would not do any good. In this case someone logging in during the switchover would receive an error. Adam On Mon, Oct 6, 2014 at 3:13 PM, Misagh Moayyed <[email protected]> wrote: > If you move away from RDBMS-backed ticket registries and onto those that > are cache-based, there are multiple options you could choose. While EhCache > could still be successful with RMI replication, we have also had good > success with Hazelcast: > > > https://github.com/Unicon/cas-addons/wiki/Configuring-HazelcastTicketRegistry > > > > …which in some ways is to replace Ehcache for distributed data transfer. > Our experience has been that troubleshooting RMI can be very very tricky, > should you run into an issue with the network and/or firewall. > > > > EhCache and the like work best for active/active deployments as tickets > are cached and distributed to all nodes. So you can certainly have your > load balancer keep all nodes in the loop. > > If you choose to decide in favor of a primary/failover setup, then > probably the default ticket registry based on node-memory would suffice. > There is of course the caveat of losing the SSO state when the failover > node takes over (because tickets are not distributed) but I think that’s a > consequence most folks tend to live with, in our experience at least. The > annoyance mostly comes to down to the fact that you’d have to ask the user > to re-authenticate once more. > > > > We took some time to document some of these concerns here: > > http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html > > > > Note the docs mostly is on and for CAS 4, but I think the points made > stilly to any HA deployment. > > > > HTH. > > > > *From:* Adam Causey [mailto:[email protected]] > *Sent:* Monday, October 6, 2014 11:16 AM > *To:* [email protected] > *Subject:* [cas-user] Preferred HA clustering support > > > > Hello, > > > > Currently we have a customized setup of HA clustering of CAS 3.5.2 which > involves two servers (one primary, one failover) with a mySQL master-master > replication. The database caches ticket-granting tickets in case of > failover to the 2nd server. > > > > We've had multiple issues with the master-master replication, and we are > also planning to introduce a 3rd server in the cloud. > > > > Is the EhcacheTicketRegistery still the best method for clustering > multiple servers? We will have to use RMI since multicasting is not an > option in AWS. > > > > If we use the EhcacheTicketRegistery, can we switch to a load balanced > setup instead of having a primary/failover setup? > > > > Thank you, > > > > Adam Causey > Virginia Commonwealth University > > > > -- > > 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 > > -- 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
