[Date Prev][Date Next]
Re: High Availability / Clustering
I read an IBM whitepaper on using heartbeat to change master control
status, but their implementation involved manual intervention after any
failover. Is your implementation 100% automated?
Would you mind sharing your relevant scripts / config files?
On Monday, April 14, 2003, at 10:59 PM, Dave Augustus wrote:
Here is another twist that provides load-balancing and failover for
I have LDAP slaves available for reads via Linux Virtual Server(LVS).
Any servers that require LDAP look at the LVS IP address for
Then I have 2 additional machines runing in a master/slave situation
hearbeat- they share a common IP. When the master(server A) goes down (
for whatever reason) the slave(server B) is promoted. When the original
master(server A) comes up again, it comes up as a slave and then
determines via heartbeat if it needs to promote itself to be the master
again. Any writes and occured while it was offline are attemped by the
slurpd running on the new master (server B) or are available via the
It is all just a matter of some scripts, heartbeat and Openldap. This
system has been in production for 6 months and works great!
On Thu, 2003-04-10 at 16:47, Lee wrote:
Ive read through most of the archives concerning high-availability
options for openldap. Right now, we're trying to create make our ldap
infrastructure highly-available, as well as load-balanced between
servers (more to be added later). From my research it seems like we
have a few options:
1) Experimental Multi-Master: This seems to have a number of atomicity
issues. Plus this doesn't really solve the problem with the ldap
clients not appropriately using the second listed server if the first
2) Plain old Master + Multiple Slaves: Same second issue above, plus
high availability on writes.
3) Master + Slaves, Promotion of Slave if master goes down: Same ldap
client not using second listed server problem as in 1) and 2) above,
plus lots of issues with reclaiming Master status after failure.
4) 1 Master Server Cluster using shared storage: This seems like the
only viable solutions. The problem is we need support for many servers
connecting to one shared storage device, as well some sort of reliable
locking mechanism thats compatible with openldap.
Has anyone successfully implemented 4) ? If so can you recommend any
specific hardware and or software that works nicely with openldap?