We have done more than several deployments of it, yes. I don’t know if it’s “fully” vetted (as that may depend on what plan to accomplish with your deployment) but it’s been very smooth so far. Given what you have described so far, I think it will suite your needs just fine.
Regardless of the registry type, once you have got it up and running it’s usually recommended that you run some sort of load test on it; Realize what parameters best simulate your environment and the CAS experience you want to provide and see how it holds up. From: Adam Causey [mailto:[email protected]] Sent: Wednesday, October 8, 2014 6:20 AM To: [email protected] Subject: Re: [cas-user] Preferred HA clustering support 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] <mailto:[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] <mailto:[email protected]> ] Sent: Tuesday, October 7, 2014 11:59 AM To: [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> ] Sent: Monday, October 6, 2014 11:16 AM To: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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
