Scott, Do you still use a database to store information about the services and serviceURLs? Is this database failover or otherwise replicated, and if so does this need to be master-master replication as the ticket repository would need to be?
Our current setup is a db on each application server with master-master replication, but I'd like to switch to a ticket repository using ehcache and a centralized database for everything else. I am wondering if this would work. I assume the only reason for needing realtime replication is in cases where the primary server goes down in the middle of someone logging in; the failover server would then still recognize and accept the ticket. If the service URLs in the database are not realtime replicated it shouldn't disrupt service (possible, but not likely). Any thoughts? thanks, Adam On Wed, May 8, 2013 at 11:08 AM, Scott Massari <[email protected]>wrote: > Adam, Yes that is how it works, they are distributed and stored in > memory and are replicated between the cluster members. Also I think an > additional benefit is not needing a ticket registry cleaner, which seems to > have presented some institutions problems with performance. > > The jasig wiki has a good entry on this: * > https://wiki.jasig.org/display/CASUM/EhcacheTicketRegistry* > > > > > Scott Massari > Owens Community College > Senior Systems Administrator > Phone: (567) 661-2059 > Cell: (567) 277-0638 > Fax: (567) 661-7643 > > > > > >>> On 5/8/2013 at 09:48 AM, in message > <CAN6MV5NZVWUsFrC8Hwu51LN1RmUem=aDQgh9p6sEadaHiB6r=a...@mail.gmail.com>, > Adam Causey <[email protected]> wrote: > > Scott - Do you all use distributed ehcache for this? Otherwise how > would each server in the cluster be aware of the tickets for the callback? > I'd be interested in switching to an in-memory solution if others have had > positive results. > > > The tricky thing about CAS is making sure when a client calls back that > the server they connect back to in the cluster recognizes the ticket. > > > We are currently using two app servers - one primary and one failover > (in separate locations) behind a Cisco LB. We are using a database for each > app server in a master-master setup to replicate tickets. Having two DBs > guarantees complete replication in case of failure at one physical > location. We have not had IP issues with this approach, but I am not sure > how it works in a round-robin type setup. The only issue I've run into > recently is getting the originating IP into the audit logs. > > > > -Adam > > > > On Wed, May 8, 2013 at 9:33 AM, Scott Massari <[email protected]> > wrote: > >> Geoff, >> >> Ehcache seems to perform better than using a database (JPA), there is >> also jboss, memcache etc. I am sure you will get lot's of replies as there >> seems to be quite a few that have set it up this way. We are using a Cisco >> ACE LB hardware for our setup (ehcache for tickets, json for service >> registry) that we are rolling into production currently. >> >> >> >> >> >> Scott Massari >> Owens Community College >> Senior Systems Administrator >> Phone: (567) 661-2059 >> Cell: (567) 277-0638 >> Fax: (567) 661-7643 >> >> >> >> >> >>> On 5/8/2013 at 09:24 AM, in message < >> ff549b8a8619594b88cc9f92fc3be5d37ee2af1...@jupiter.unfcsd.unf.edu>, >> "Whittaker, Geoffrey" <[email protected]> wrote: >> >> >> Good morning, >> >> We have a hardware load balancer/proxy that we'd like to use for a >> distributed deployment of CAS using a central database. While we were >> discussing it this morning, we stumbled on the question of whether or not >> CAS will have a problem with all of the connections having the same source >> IP (the balancer/proxy). >> >> Has anyone ever configured CAS like this... with a proxy/load balancer in >> front of two servers and a central database? Is this a terrible idea, >> fraught with peril and heartache? Is there a better way to ensure >> redundancy? >> >> >> Geoff >> >> -- >> >> 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
