Hi, So if I use JpaTicketRegistry in cluster (CLUSTERING WITHOUT REPLICATION), and I follow this tutorial about Clustering : http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS
So I don't have to configure anything about Ticket Cache Replication , is this correct? scott_battaglia wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Best-practice-for-CAS-load-balance-failover-tp19912100p23054860.html Sent from the CAS Users mailing list archive at Nabble.com. -- 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
