Hi Misagh, Have you run the HazelcastTicketRegistry in a production environment? It looks promising, but I want to make sure it's been fully vetted.
On Tue, Oct 7, 2014 at 3:40 PM, Misagh Moayyed <[email protected]> wrote: > Right, that’s not going to do you any good because ultimately, the > validation of that service ticket would fail on the failover node since > there is no TGT for that ticket. In other words, if the ST was issued on > the primary node, and the validation of that ST somehow ended up on the > failover node (suppose the failure happened right in between the two > requests), then the validation call would fail. At this point, it’s up to > the application to decide what should happen, which typically is a prompt > to the user that something has gone wrong and reauthentication is required. > > > > …when I say reauthentication, I actually do mean that user would likely > have to close the browser to clear cookies and fully start again. With 4.x, > if I am remembering this correctly, that probably would not be required as > the code actually checks for the TGT validity rather than just the presence > of the cookie. > > > > *From:* Adam Causey [mailto:[email protected]] > *Sent:* Tuesday, October 7, 2014 11:59 AM > *To:* [email protected] > *Subject:* Re: [cas-user] Preferred HA clustering support > > > > 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 > > -- > 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
