Yes, we are running two servers, load balanced at the network level with ticket replication via repcached, which runs on the same servers. Our plan is to add a second location once our network supports it, probably this summer.
Regarding your ldap replication plan, if you are using one master where all writes go to, you still have a single point of failure. I personally wouldn't go that route. -Benn- On Jan 20, 2009, at 12:58 PM, Lucas Rockwell <[email protected]> wrote: > On Jan 20, 2009, at 9:01 AM, Benn Oshrin wrote: > >> At the time it was Oracle though it has since moved to mysql. The >> idea >> was to offload HA to the database, though I'm not sure how successful >> that was. > > That's what I want to avoid. > >> Here at Rutgers we're using repcache, which is lightweight but fits >> well. > > So that means you are using 2 CAS servers? We are currently using 2, > but it would be ideal to have 4 (2 on campus, and 2 in the data > center). > >> The only catch is that the protocol is clear text, so you need >> to have a secure network layer, all the more important if you're >> replicating across campus. > > Thanks. > > -lucas > >> On Jan 19, 2009, at 2:07 PM, Lucas Rockwell <[email protected]> wrote: >> >>> Hi Benn, >>> >>> Thanks for the reply! >>> >>> On Jan 19, 2009, at 10:05 AM, Benn Oshrin wrote: >>> >>>> We thought about doing something similar at Columbia a few years >>>> ago, >>>> but ultimately went with a DB backed store. Our concerns included >>> >>> What database and clustering method are you using? I am not opposed >>> to >>> using a DB, but I am having difficulty finding a relatively simple >>> cluster technology. >>> >>> Also, a little more background from our situation: Our higher-ups >>> want >>> us to explore moving the CAS servers around campus so that if there >>> is >>> a problem with the data center, people can still authenticate, which >>> that means moving our LDAP servers out as well (our Kerberos servers >>> are already distributed). >>> >>>> (1) Only 1/n (where n=# of servers) validation requests would hit >>>> the correct server and not need forwarding, meaning an increase >>>> of (n-1)/n transactions >>> >>> This is true. >>> >>>> (2) It wasn't replication, so if a server went down, we would >>>> still lose 1/n of the login state, meaning we couldn't >>>> really call this high availability >>> >>> This is why I suggest replicating the TGTs in something like LDAP, >>> which does secure HA replication very well (but is not super speedy >>> on >>> writes, so that is why it would be good for TGTs). >>> >>> -lucas >>> >>>> Lucas Rockwell <[email protected]> wrote on January 15, 2009 1:57:12 >>>> PM >>>> -0800: >>>> >>>> ] Hello CAS developers, >>>> ] >>>> ] I have an idea about how to make CAS highly available (HA) >>>> without >>>> ] doing Service Ticket/Proxy (Granting) Ticket (ST and PT) >>>> replication, >>>> ] so I would like to propose it to you all and see what you think. >>>> ] >>>> ] First, let me start off by saying that I think it is still wise >>>> to >>>> ] replicate TGTs, especially considering replicating TGTs can >>>> withstand >>>> ] very high latencies (several seconds or more). Actually, the >>>> latency >>>> ] tolerance for TGTs is such that you could even replicate them in >>>> ] LDAP if you wanted to (which does replication very well, and >>>> ] securely). >>>> ] >>>> ] So, my proposal for "replicating" STs and PTs is as follows: Make >>>> ] each CAS server aware of its peers, and use the CAS protocol >>>> itself >>>> ] for validating tickets. I will try to clarify this with an >>>> example: >>>> ] >>>> ] The simplest scenario is 2 CAS servers -- CAS1 and CAS2 -- (but >>>> this >>>> ] scales to n CAS servers). Each CAS server has a list of all the >>>> CAS >>>> ] servers in the cluster (using "cluster" for lack of a better >>>> term), >>>> ] including itself. When a CAS server (CAS1) receives a ST or PT >>>> for >>>> ] validation, it simply looks at the ticket to determine where the >>>> ] ticket originated (this is done by inspecting the end of the >>>> ticket >>>> ] value which will have the hostname of the originating CAS server >>>> ] appended to it -- just as tickets do now). If the ticket >>>> originated >>>> ] with itself (CAS1), it handles the validation like normal. If the >>>> ] ticket originated with another CAS server (CAS2), the CAS1 server >>>> now >>>> ] becomes a CAS client and asks CAS2 to do the validation (using >>>> the >>>> ] CAS protocol), and then CAS1 just passes the response right >>>> back >>>> to >>>> ] the client as if it (CAS1) had done the validation. >>>> ] >>>> ] That's it. This whole concept could probably be implemented in >>>> the >>>> ] CentralAuthenticationService class. >>>> ] >>>> ] Of course, this concept scales to n CAS servers, but I do not >>>> know >>>> ] the throughput of even doing this with just 2 CAS servers. But >>>> this >>>> ] certainly makes CAS HA without a lot of extra baggage. The local >>>> ST >>>> ] and PT ticket registry can be implemented in memcache or even a >>>> DB >>>> ] but the nice thing about it is that they do not have to be >>>> ] replicated. As I said in the beginning, the TGTs could be >>>> stored >>>> in >>>> ] something like LDAP which does replication very well, but it is >>>> not >>>> ] fast enough for STs and PTs. >>>> ] >>>> ] Please let me know what you think and/or if you need more >>>> ] clarification. >>>> ] >>>> ] Thanks. >>>> ] >>>> ] -lucas >>>> ] >>>> ] ----------------------- >>>> ] Lucas Rockwell >>>> ] CalNet Team >>>> ] [email protected] >>>> ] >>>> ] >>>> ] >>>> ] >>>> ] _______________________________________________ >>>> ] 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 > > _______________________________________________ > 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
