On Jan 21, 2009, at 11:09 AM, Benn Oshrin wrote: > 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.
I would be interested in hearing more about how you do this, once you have it implemented. > 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. We would use multi-master replication, so that means all LDAP servers are read/write. Also, each CAS host would talk to LDAP on the localhost. -lucas > 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 _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
