CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: replication behind load balancer

--On Thursday, March 24, 2005 9:53 PM -0500 Wesley Craig <wes@xxxxxxxxx> wrote:

On 24 Mar 2005, at 10:46, johanna bromberg craig wrote:
Also, as a side note, I'm not sure fail over in the clients will
work right if both cosign servers are behind a load balancer. I
haven't drawn it all out yet, but the basic idea behind client fail
over is that the filters ask every weblogin server they are aware
of ( A, B, and C ) based on the lookup they did at startup. If they
are talking to a load balancer that only had 1 IP/name, they might
only get A when in fact B happen to have the most  up-to-date
information. Like I said, I haven't really thought about this
though, so I might be wrong, too.

You're correct. My suggested configuration would be to have the load balancer only handle HTTP(S) traffic. In order for filter <-> cosignd interactions (include replication and fail over) to function properly, the filters need to have direct access to each of the cosignd's.

I want to understand more about how cosign replication works. In the scenario described above, it does not seem like cosignd replication has a high-availability architecture. If cosignd on host b has up-to-date info that is not propagated to other cosignds, and host b dies, then the information is lost.

Our intention was to load balance https and port 6663 traffic. Communication between the cosignd processes would occur on the private network and would not be load balanced. If cosignd indeed has replication capabilities, it's not clear to me why this wouldn't work.

Has anyone done any work to replace file read/writes with database calls? It seems like this would provide a high-availability architecture that would be reliable and easy to deploy.


Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010