Take a look at this: http://www.ja-sig.org/wiki/display/CASUM/JpaTicketRegistry
-Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Sun, Oct 12, 2008 at 7:49 PM, Bin Rong <[EMAIL PROTECTED]> wrote: > 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 > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
