David, Andrew, and Scott, thanks very much for the detailed reply. According to your guys' information, I will probably give the database (CLUSTERING WITHOUT REPLICATION) approach a try, and since we use Sequoia to realize database failover already, the SOF problem of data store could be isolated for this CAS problem.
I am quite new to CAS, and as I mentioned, there is very little information regarding how to configure CAS to use backend database to store SSO information, thus enable user to hit any CAS servers. Could you guys give me a hand? Thanks in advance. On Sat, Oct 11, 2008 at 2:28 AM, Scott Battaglia <[EMAIL PROTECTED]>wrote: > Andrew's assessment is correct: > > We currently support four methods: > > 1. Memcached/repcache > 2. Terraccotta > 3. JBossCache > 4. Database > > #1 is what we use here at Rutgers. We've been relatively happy with it. > We did significant load testing with it and its been in production for about > a month now. We'll know more in another month when the peak period hits ;-) > > #2 is used by some people and they were kind enough to include their > configuration in the CAS distribution. It is a little more involved to set > up. > > #3 is used by a few people. Some people have had great luck. Others like > Andrew, haven't been as lucky :-) We were never able to get the performance > we wanted out of it, though some people in France had no problems. > > #4. A few people in Europe use this. It seems to work well. It only > clusters CAS though. Its up to you whether you care/want your database > replicated. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > On Fri, Oct 10, 2008 at 8:34 AM, Andrew Ralph Feller, afelle1 < > [EMAIL PROTECTED]> wrote: > >> Bin, >> >> This is going to depend on which route you go: clustering, clustering with >> replication, or fail over. >> >> CLUSTERING WITH REPLICATION >> >> We have been struggling to get a clustering with replication environment >> setup using the JBoss Cache solution (JbossCacheTicketRegistry), which was >> outlined in the link you mentioned. However, there have been some >> unexpected problems maintaining a stable JBoss Cache replication cluster. >> Though it is maintained by JA-SIG, there aren't many people you will find >> that are very experienced with it much less managing JBoss Cache; there are >> a number of people who will probably agree with me on that. Another option >> for doing clustering with replication is to use the MemCacheTicketRegistry >> available in CAS 3.3.0. This is the option favored by Rutgers, who is >> the primary maintainer of the CAS code base. Scott B can testify about it >> being lightweight, however I don't know anyone else that has deployed it in >> their environments. >> >> CLUSTERING WITHOUT REPLICATION >> >> If you want plain clustering without replication, then you could either go >> with a backend data store holding users SSO information and have the CAS >> servers be dummies by using the JpaTicketRegistry. This would allow your >> users to hit any of the CAS servers and remove the need for replicating >> data, however you would have a single point of failure (data store). >> >> FAIL OVER >> >> However, most CAS deployments appear to use a active/passive fail over >> setup where you have two deployments and have your load balancer direct >> traffic to the primary and fail over to the secondary when necessary. This >> option requires little / no major customization. >> >> NOTE: All of these options require you to configure the cookie generators >> to set CAS cookies for a domain reachable by all machines within your >> cluster / fail over environment. >> >> HTH, >> A- >> >> >> >> On 10/10/08 12:01 AM, "Bin Rong" <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> I am a newbie to CAS, and in our production environment, we have two >> apahche servers running behind a hardware load balancer, using ajp to >> balance >> out to several tomcat instances. Sticky session is used, and only one of >> the backend tomcat is used for CAS. >> >> Now we want to load balance/failover CAS, the options are: >> >> 1. Clustering CAS >> 2. Have database-backed registry, so that multiple CAS can validate the >> ticket vended by other CAS servers. >> >> Just wondering what is the best practise? >> >> We think the database-backed is a good one, and I've searched the web, >> there is very little information in this regard, except >> http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS. Could anyone >> point to any source of information or any detailed howto guide? >> >> Any advise is appreciated. >> >> Bin >> >> ------------------------------ >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> -- >> Andrew R. Feller, Analyst >> Information Technology Services >> 200 Fred Frey Building >> Louisiana State University >> Baton Rouge, LA 70803 >> (225) 578-3737 (Office) >> (225) 578-6400 (Fax) >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
