Hi,
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl. Here's the plan, with arrows pointing from the provider to the consumer:
old1 <-> old2 -> new1 -> new2
Once the replicas on "new1" and "new2" are complete, I plan to
1) Direct all LDAP reads to "new1" 2) Direct all LDAP writes to "new1" (=make it briefly the only active LDAP server) 3) Change the replication config on "new1" so that it fetches changes from "new2" instead of "old2" 4) Restart slapd on new1 (it uses slapd.conf) to activate the change 4) Start offloading LDAP reads/writes to "new2" (e.g. using a loadbalancer)
A couple of questions:
. Does this plan makes sense in general? - Which caveats I should be aware of? - How can I ensure the replicas are complete and in the same state[1]? - Does switching the replication provider for "new1" from "old2" to "new2" cause any side-effects?
Also, when is full reload of the replica[2] required/suggested? I've managed to end up with incomplete replicas on "old2" a couple of times even if I've wiped /var/lib/ldap and started replication from scratch.
Any suggestions or pointers are most welcome! Also let me know if you need more info (configs, etc) and I'll provide it.
Best regards,
Samuli Seppänen
---
[1] I've used these command so far:
$ cd /var/lib/ldap $ db_stat -d <database-file>
If the numbers (data items etc) match, can I be sure the replicas are identical?
I've also checked the contextCSN on the using something like this:
$ ldapsearch -H ldap://old2:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com" $ ldapsearch -H ldap://new1:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com" $ ldapsearch -H ldap://new2:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com"
The output seems to be identical for "old2" and "new1", but "new2" differs, even though the database seems identical if checked with db_stat. I assume this is normal given the replication chaining (see above).
[2] Starting slapd with the "-c rid=<rid>" switch should do this, correct?
"samuli.seppanen@gmail.com" samuli.seppanen@gmail.com schrieb am
02.10.2013 um 12:25 in Nachricht 524BF485.1040509@gmail.com:
Hi,
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl. Here's the plan, with arrows pointing from the provider to the consumer:
old1 <-> old2 -> new1 -> new2
I'd like to know a procedure to add a new node for multi-master-sync to an existing configuration, assuming the master is so big and busy that a consistent slapcat is not possible. Or are slapcats always consistent (read-locked)?
In that case I'd suggest to extend the zwo-node multi-master to a temorary thre- or four-node multi-master, then switch servers, then remove the old nodes (first from the configuration, then from the network).
Once the replicas on "new1" and "new2" are complete, I plan to
- Direct all LDAP reads to "new1"
- Direct all LDAP writes to "new1" (=make it briefly the only active
LDAP server) 3) Change the replication config on "new1" so that it fetches changes from "new2" instead of "old2" 4) Restart slapd on new1 (it uses slapd.conf) to activate the change 4) Start offloading LDAP reads/writes to "new2" (e.g. using a loadbalancer)
A couple of questions:
. Does this plan makes sense in general?
- Which caveats I should be aware of?
- How can I ensure the replicas are complete and in the same state[1]?
- Does switching the replication provider for "new1" from "old2" to
"new2" cause any side-effects?
Also, when is full reload of the replica[2] required/suggested? I've managed to end up with incomplete replicas on "old2" a couple of times even if I've wiped /var/lib/ldap and started replication from scratch.
Any suggestions or pointers are most welcome! Also let me know if you need more info (configs, etc) and I'll provide it.
Best regards,
Samuli Seppänen
[1] I've used these command so far:
$ cd /var/lib/ldap $ db_stat -d <database-file>
If the numbers (data items etc) match, can I be sure the replicas are identical?
I've also checked the contextCSN on the using something like this:
$ ldapsearch -H ldap://old2:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com" $ ldapsearch -H ldap://new1:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com" $ ldapsearch -H ldap://new2:389 -D "cn=admin,dc=domain,dc=com" -x -W -v -s base -b "dc=domain,dc=com"
The output seems to be identical for "old2" and "new1", but "new2" differs, even though the database seems identical if checked with db_stat. I assume this is normal given the replication chaining (see
above).
[2] Starting slapd with the "-c rid=<rid>" switch should do this, correct?
On Wed, 02 Oct 2013 13:25:09 +0300 "samuli.seppanen@gmail.com" samuli.seppanen@gmail.com wrote:
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl.
It may or may not work. Likely it depends on the OpenLDAP versions involved. Thorough testing this scenario in a playground deployment is a must!
Ciao, Michael.
On Wed, 02 Oct 2013 13:25:09 +0300 "samuli.seppanen@gmail.com" samuli.seppanen@gmail.com wrote:
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl.
It may or may not work. Likely it depends on the OpenLDAP versions involved. Thorough testing this scenario in a playground deployment is a must!
Old servers are running OpenLDAP 2.4.23 (Debian 6.x). New ones use 2.4.28 (Ubuntu 12.04).
Samuli
On Wed, 02 Oct 2013 15:02:32 +0300 "samuli.seppanen@gmail.com" samuli.seppanen@gmail.com wrote
On Wed, 02 Oct 2013 13:25:09 +0300 "samuli.seppanen@gmail.com" samuli.seppanen@gmail.com wrote:
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl.
It may or may not work. Likely it depends on the OpenLDAP versions involved. Thorough testing this scenario in a playground deployment is a must!
Old servers are running OpenLDAP 2.4.23 (Debian 6.x). New ones use 2.4.28 (Ubuntu 12.04).
If high availability and reliabilty is really needed, as you claimed, then I would not use OpenLDAP 2.4.28. I'd recommend to use self-compiled OpenLDAP 2.4.36.
Ciao, Michael.
--On Wednesday, October 02, 2013 1:51 PM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
"samuli.seppanen@gmail.com" samuli.seppanen@gmail.com schrieb am
02.10.2013 um 12:25 in Nachricht 524BF485.1040509@gmail.com:
Hi,
I'm phasing out two OpenLDAP production servers[1] in a master-master configuration. The production servers can't afford more than a few mins of downtime, so migrating using slapcat/slapadd is out of the question. So, what I'm ending up doing is migrating using syncrepl. Here's the plan, with arrows pointing from the provider to the consumer:
old1 <-> old2 -> new1 -> new2
I'd like to know a procedure to add a new node for multi-master-sync to an existing configuration, assuming the master is so big and busy that a consistent slapcat is not possible. Or are slapcats always consistent (read-locked)?
If you get on 2.4.36, it should be read consistent.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
samuli.seppanen＠gmail.com -
Ulrich Windl