CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

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

Re: replication behind load balancer




> 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.


Haven't started with replication yet, but using a load balancer was
the way I was going to implement this.  (I work at F5, so it's a
"eat your own dogfood" issue.  ;-)

In our case, the number of connections (internal users) is going to
be much smaller than in a university setting, so I was planning on
having one be primary and the other secondary, so you'd only hit
the secondary if the first is down.  However 'true load balancing'
would be something I'd be interested in looking at and helping out
with.

Will have to think about how this could work.

Here's a horrible thought: does the filter try each returned A record in
sequence, without eliminating duplicates?  You could increase your odds
by having multiple A's for the DNS reply, all with the same load
balancer as the IP address, and have the load balancer use simple round
robin to get to the actual daemons.  Not 100% (other competing
connections could cause you to get to the same machine repeatedly)
but a possibility.

Perhaps a better possibility is this:

	Load balancer has X IP addresses listening to port 6663
	Load balancer has X pools of weblogin daemon hosts, like this:
	   Pool 1:
		A is primary
		B is secondary
		...
		X is last
	
	   Pool 2:
		B is primary
		C is secondary
		...
		A is last
	   ...

Then in DNS, list all IP addresses for weblogin.example.com.  As you
loop through, you'll hit the highest priority machine that's working
in the first pool, if that doesn't have answers you like you hit
the next pool's top ranked machine, etc.

How often does it check the DNS name weblogin.example.com, by the way?
Another possibility is to use small DNS TTLs, but that will not work
if you cache an IP address list beyond the TTL that is returned.
(Not honoring TTLs would break my ability to add or change hosts
regardless.)

If it does a lookup any time it gets a negative response from an
existing TCP connection and then wants to find other servers
to contact, you're probably fine.


I'm going to need to think about this too.

-- 
Brian Hatch                  Good. Bad.
   Systems and                I'm the guy
   Security Engineer          with the gun.
http://www.ifokr.org/bri/

Every message PGP signed

Attachment: signature.asc
Description: Digital signature


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