Hi Buchan,
Thank you very much for such a detailed response.
We need HA for LDAP writes also.
We are using bdb.
Is it safe to upgraded to OpenLDAP 2.4 without testing compatibility/stability of it with our product?
Can I use the package available at ftp://ftp.dti.ad.jp/pub/net/OpenLDAP/openldap-stable/openldap-stable-20090411.tgz? Or do I need to get specific package for CentOS?
Regards, Prasad.
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Thursday, May 07, 2009 2:53 PM To: openldap-technical@openldap.org Cc: Kukkala Prasad Subject: Re: OpenLDAP 2.1 High Availability
On Thursday 07 May 2009 05:32:25 Kukkala Prasad wrote:
Hi All,
We are planning to configure High Availability for OpenLDAP 2.1 on Linux CentOS.
Why 2.1? AFAIK, no version of CentOS shipped 2.1 anyway (RHEL3 had 2.0.27. RHEL4 had 2.2.13, RHEL5 shipped with 2.3.27, but 5.3 now has a relatively decent 2.3.43).
We are looking at following options and we want to check our understanding about corresponding options and looking for your valuable suggestions.
Using Replica Servicea. This is not enough because if master machine goes down then LDAP updates will not be possible.
You haven't stated all your requirements, but if you require HA for writes, then this is not a sufficient option.
Migrating to OpenLDAP2.4a. Master-Master solution looks promising but in our current project time line it is not possible to migrate.
Why not ? OpenLDAP 2.1 is very old, and not supported any more, same for 2.2, and 2.3 is effectively end of life.
There are packages of 2.4 available for some versions of RHEL or CentOS.
Sharing LDAP file system on NFSa. After going through the thread http://www.openldap.org/lists/openldap-software/200209/msg00256.html it is understood that OpenLDAP does not support GFS or NFS.
It could work on GFS, but not concurrently, and GFS requires the same (or better) infrastructure than a simple HA cluster.
However, I hope this is not the best option you found in researching this.
NFS can't work.
b. But the thread discussion happened very long back around in 2000 to 2002. ????Is that conclusion applicable to OpenLDAP 2.1????
Hosting LDAP Service on CentOS Cluster Suitea. ????Is it possible to configure "Active-Passive" setup using CentOS Cluster Suite????
Of course. I have been running OpenLDAP masters on Red Hat Cluster Suite since 2004 on Red Hat Advanced Server 2.1 (with OpenLDAP 2.1.25). I currently have an active-passive master cluster running RHEL3 with cluster suite, with OpenLDAP 2.3.42 (will be upgraded to 2.3.43 tonight). It has seen a few minutes of downtime in the past 3 years (about one minute for each OpenLDAP upgrade as the service must be migrated twice).
You need some kind of shared storage solution for this (preferably FC SAN, but iSCSI is an option, and DRBD could do the trick).
H/W based clusteringa. We don't know what are the possible solutions in this approach and cost incurred. !!!!Please share your ideas.!!!!
NetApp2020a. We have NetApp 2020 Appliance http://www.b2net.co.uk/netapp/network_appliance_netapp_fas2020.htm with us. ????Does this any way help us????
Other alternativesa. !!!!We need your valuable ideas and suggestions.!!!!
I would probably go for an HA cluster with cluster suite using iSCSI for shared storage, running 2.3.43 or 2.4.16.
Multi-master might also be an option, but then you *must* 2.4.16 (with patches from CVS if you use hdb).
Regards, Buchan
The information contained in this communication is confidential, intended solely for the use of the individual or entity to whom it is addressed and may be legally privileged and protected by professional secrecy. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This email does not constitute any commitment from Cordys Holding BV or any of its subsidiaries except when expressly agreed in a written agreement between the intended recipient and Cordys Holding BV or its subsidiaries. Cordys is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. Cordys does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies.