Thanks for the input. I had seen the article on JPATicketReg, which really got me looking into the persistent registries available, and I think that a lot of the types of problems cited come up frequently in most of the other disk-based persistent shared registries. I'd read a little about the shared memory caching, but didn't realize it was included in the 3.5 distribution. I'll focus on EhCache and post my notes up when I'm done.
On , "William G. Thompson, Jr." <[email protected]> wrote: > On Wed, Aug 1, 2012 at 3:08 PM, CHAD CAMPBELL [email protected]> > wrote: > I am working with a university to implement CAS for SSO. I have some > experience managing the CAS instance at my current institution, but we > are running a single instance in a virtual environment and this > university has asked for a highly available, load balanced cluster. > I have pushed back on the requirement for clustering some. In my > experience AA clusters introduce at least as many points of failure as > they resolve. The only time I would suggest it is if the institution has > way more load than it can handle on a single host and/or has the > available staff to dedicate to troubleshooting issues that arise. Digging > through some of the bug trackers for various products, I've seen a number > of potential pitfalls that could crop up. My intention is to continue to > advise them to deploy the server in a virtual environment and handle > availability concerns there, but I'm preparing for them to insist on full > Active-Active HA clustering. > Build info: RHEL6, Tomcat 7, CAS 3.5, JDK1.7(ish), planning on using the > Maven2 overlay build to ease administration. > Here's the questions I have from what I've gathered so far. Hopefully > someone can respond with actual experience and either confirm or allay > concerns: > SQL vs NoSQL: For shared ticket registry, I've seen a lot of bugs in most > of the mysql based models, usually due to mysql behaving unexpectedly. Is > this something that is consistently true? > Many folks have run with the JpaTicketRegistry successfully, but you have > to be willing to take on the complexity of the RDBMS, Hibernate, etc. In > my opinion this is no longer worth it given the other options that exist > today. > Also see: > http://jasig.275507.n4.nabble.com/JpaTicketRegistry-A-Sinking-Ship-td4256973.html > Version: From what I've read, the 3.5 release of CAS has been an > improvement in this area, but it's still relatively new. Any advice on > versions of any interconnecting pieces that should be avoided? > 3.5 is the recommended version for new deployments. It is a modest > evolution of the well respected 3.4.x line with helpful new features. > Suggestions for adoption: Any suggestions for a blank slate build? The > simplest, easiest to manage, least error prone product capable of > handling two nodes in an active-active capacity would be ideal. They have > some very intelligent people on staff, but not enough of them, so I don't > want to bog them down with an overly engineered behemoth that keeps them > up at night. > EhcacheTicketRegistry that ships with CAS3.5. Simplest way to get a > robust active-active multi-node CAS deployment. > Personal Experience: Any personal experience to share on setting up and > managing a similar environment? If you've made a selection that works > flawlessly, or one that has made your life hell, I'd love to hear about > it. > Unicon has done numerous mulit-node CAS deployments leveraging the > EhcacheTicketRegistry, even before it was part of the Jasig distribution. > I've already reviewed a number of documents, so I have some background > info to make a selection, but I'd be interested to hear from someone with > experience deploying and managing this type of environment. > Hope this helps. Do keep us in the loop on your deployment. > Best, > Bill > -- > 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
