OSPF was only the example for me, in OSPF the daemon itself has this election logic built in. So either the service is running and can take part in the election or not, this means, the logic needs to be implemented within the ldap daemon. It also implies, that there is some kind of "heartbeat" between the nodes. -----Original Message----- From: 389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Gerrard Geldenhuis Sent: Friday, December 03, 2010 5:52 PM To: '389 Directory server developer discussion.' Subject: Re: [389-devel] Thought excersize: A different take on replication > -----Original Message----- > From: 389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-devel- > bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Soeren Malchow (MCon) > Sent: 03 December 2010 16:42 > To: 389 Directory server developer discussion. > Subject: Re: [389-devel] Thought excersize: A different take on > replication > > Hi Gerrard, > > Since you are already mentioning OSPF, how about grouping the > Masterservers into "zones" and have only one of the hosts taking care > of the communication to other "zones". > > Changes could always only be replicated via the "communication master". > > The main problem that arises here is the potential outage of one of > those "communication masters", this could be solved by either an > election process or by an explicit order. Thanks for the reply Soeren, would this "election" process be on a OSPF basis/level? How do you differentiate between the host not available from a network point of view and from a service point of view. My network skills are limited and to be honest; OSPF was mentioned during our discussions but I had to read up on it afterwards and it seemed similar to the solutions we were discussing. > > I think this would be a good way to go because it is very close to > real life scenarios form my point of view, I most likely have a view > masters in geographically distributed locations, but not tens of > servers in one location ( maybe already counting e.g. different > buildings on a campus as locations ) > > Not sure if that is a way to go, but maybe it helps a little > Regards ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________ -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
