# $OpenLDAP$
-# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Replication
H3: delta-syncrepl replication
-H3: N-Way Multi-Master
+H3: N-Way Multi-Master replication
-http://www.connexitor.com/blog/pivot/entry.php?id=105#body
-http://www.openldap.org/lists/openldap-software/200702/msg00006.html
-http://www.openldap.org/lists/openldap-software/200602/msg00064.html
+Multi-Master replication is a replication technique using Syncrepl to replicate
+data to multiple Master Directory servers.
+* Advantages of Multi-Master replication:
-H3: MirrorMode
+- If any master fails, other masters will continue to accept updates
+- Avoids a single point of failure
+- Masters can be located in several physical sites i.e. distributed across the
+network/globe.
+- Good for Automatic failover/High Availability
+
+* Disadvantages of Multi-Master replication:
+
+- It has {{B:NOTHING}} to do with load balancing
+- {{URL:http://www.openldap.org/faq/data/cache/1240.html}}
+- If connectivity with a master is lost because of a network partition, then
+"automatic failover" can just compound the problem
+- Typically, a particular machine cannot distinguish between losing contact
+ with a peer because that peer crashed, or because the network link has failed
+- If a network is partitioned and multiple clients start writing to each of the
+"masters" then reconciliation will be a pain; it may be best to simply deny
+writes to the clients that are partitioned from the single master
+- Masters {{B:must}} propagate writes to {{B:all}} the other servers, which
+means the network traffic and write load is constant and spreads across all
+of the servers
+
+
+This is discussed in full in the {{SECT:N-Way Multi-Master}} section below
+
+H3: MirrorMode replication
MirrorMode is a hybrid configuration that provides all of the consistency
-guarantees of single-master replication while also providing the high
+guarantees of single-master replication, while also providing the high
availability of multi-master. In MirrorMode two masters are set up to
replicate from each other (as a multi-master configuration) but an
external frontend is employed to direct all writes to only one of
repaired and restarted it will automatically catch up to any changes
on the running master and resync.
+This is discussed in full in the {{SECT:MirrorMode}} section below
+
H2: LDAP Sync Replication
The {{TERM:LDAP Sync}} Replication engine, {{TERM:syncrepl}} for
H2: N-Way Multi-Master
+For the following example we will be using 3 Master nodes. Keeping in line with
+{{B:test050-syncrepl-multimaster}} of the OpenLDAP test suite, we will be configuring
+{{slapd(8)}} via {{B:cn=config}}
+
+This sets up the config database:
+
+> dn: cn=config
+> objectClass: olcGlobal
+> cn: config
+> olcServerID: 1
+>
+> dn: olcDatabase={0}config,cn=config
+> objectClass: olcDatabaseConfig
+> olcDatabase: {0}config
+> olcRootPW: secret
+
+second and third servers will have a different olcServerID obviously:
+
+> dn: cn=config
+> objectClass: olcGlobal
+> cn: config
+> olcServerID: 2
+>
+> dn: olcDatabase={0}config,cn=config
+> objectClass: olcDatabaseConfig
+> olcDatabase: {0}config
+> olcRootPW: secret
+
+This sets up syncrepl as a provider (since these are all masters):
+
+> dn: cn=module,cn=config
+> objectClass: olcModuleList
+> cn: module
+> olcModulePath: /usr/local/libexec/openldap
+> olcModuleLoad: syncprov.la
+
+Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):
+
+> dn: cn=config
+> changetype: modify
+> replace: olcServerID
+> olcServerID: 1 $URI1
+> olcServerID: 2 $URI2
+> olcServerID: 3 $URI3
+>
+> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
+> changetype: add
+> objectClass: olcOverlayConfig
+> objectClass: olcSyncProvConfig
+> olcOverlay: syncprov
+>
+> dn: olcDatabase={0}config,cn=config
+> changetype: modify
+> add: olcSyncRepl
+> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple
+> credentials=secret searchbase="cn=config" type=refreshAndPersist
+> retry="5 5 300 5" timeout=1
+> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple
+> credentials=secret searchbase="cn=config" type=refreshAndPersist
+> retry="5 5 300 5" timeout=1
+> olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple
+> credentials=secret searchbase="cn=config" type=refreshAndPersist
+> retry="5 5 300 5" timeout=1
+> -
+> add: olcMirrorMode
+> olcMirrorMode: TRUE
+
+Now start up the Master and a consumer/s, also add the above LDIF to the first consumer, second consumer etc. It will then replicate {{B:cn=config}}. You now have N-Way Multimaster on the config database.
+
+We still have to replicate the actual data, not just the config, so add to the master (all active and configured consumers/masters will pull down this config, as they are all syncing). Also, replace all {{${}}} variables with whatever is applicable to your setup:
+
+> dn: olcDatabase={1}$BACKEND,cn=config
+> objectClass: olcDatabaseConfig
+> objectClass: olc${BACKEND}Config
+> olcDatabase: {1}$BACKEND
+> olcSuffix: $BASEDN
+> olcDbDirectory: ./db
+> olcRootDN: $MANAGERDN
+> olcRootPW: $PASSWD
+> olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple
+> credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
+> interval=00:00:00:10 retry="5 5 300 5" timeout=1
+> olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple
+> credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
+> interval=00:00:00:10 retry="5 5 300 5" timeout=1
+> olcSyncRepl: rid=006 provider=$URI3 binddn="$MANAGERDN" bindmethod=simple
+> credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
+> interval=00:00:00:10 retry="5 5 300 5" timeout=1
+> olcMirrorMode: TRUE
+>
+> dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config
+> changetype: add
+> objectClass: olcOverlayConfig
+> objectClass: olcSyncProvConfig
+> olcOverlay: syncprov
+
+Note: You must have all your server set to the same time via {{http://www.ntp.org/}}
H2: MirrorMode
+H3: Arguments for MirrorMode
+
+* Provides a high-availability (HA) solution for directory writes (replicas handle reads)
+* As long as one Master is operational, writes can safely be accepted
+* Master nodes replicate from each other, so they are always up to date and
+can be ready to take over (hot standby)
+* Syncrepl also allows the master nodes to re-synchronize after any downtime
+* Delta-Syncrepl can be used
+
+
+H3: Arguments against MirrorMode
+
+* MirrorMode is not what is termed as a Multi-Master solution. This is because
+writes have to go to one of the mirror nodes at a time
+* MirrorMode can be termed as Active-Active Hot-Standby, therefor an external
+server (slapd in proxy mode) or device (hardware load balancer) to manage which
+master is currently active
+* While syncrepl can recover from a completely empty database, slapadd is much
+faster
+* Does not provide faster or more scalable write performance (neither could
+ any Multi-Master solution)
+* Backups are managed slightly differently
+- If backing up the Berkeley database itself and periodically backing up the
+transaction log files, then the same member of the mirror pair needs to be
+used to collect logfiles until the next database backup is taken
+- To ensure that both databases are consistent, each database might have to be
+put in read-only mode while performing a slapcat.
+- When using slapcat, the generated LDIF files can be rather large. This can
+happen with a non-MirrorMode deployment also.
+
+H3: MirrorMode Configuration
+
+MirrorMode configuration is actually very easy. If you have ever setup a normal
+slapd syncrepl provider, then the only change is the following two directives:
+
+> mirrormode on
+> serverID 1
+
+Note: You need to make sure that the {{serverID}} of each mirror node pair is
+different.
+
+H4: Mirror Node Configuration
+
+This is the same as the {{SECT:Set up the provider slapd}} section, reference
+{{SECT:delta-syncrepl replication}} if using {{delta-syncrepl}}.
+
+Here's a specific cut down example using {{SECT:LDAP Sync Replication}} in
+{{refreshAndPersist}} mode ({{delta-syncrepl}} can be used also):
+
+MirrorMode node 1:
+
+> # syncrepl directives \r
+> syncrepl rid=001\r
+> provider=ldap://ldap-ridr1.example.com\r
+> bindmethod=simple\r
+> binddn="cn=mirrormode,dc=example,dc=com"\r
+> credentials=mirrormode\r
+> searchbase="dc=example,dc=com"\r
+> schemachecking=on\r
+> type=refreshAndPersist\r
+> retry="60 +"\r
+>
+> syncrepl rid=002\r
+> provider=ldap://ldap-rid2.example.com\r
+> bindmethod=simple\r
+> binddn="cn=mirrormode,dc=example,dc=com"\r
+> credentials=mirrormode\r
+> searchbase="dc=example,dc=com"\r
+> schemachecking=on\r
+> type=refreshAndPersist\r
+> retry="60 +"\r
+> \r
+> mirrormode on
+> serverID 1
+
+MirrorMode node 2:
+
+> # syncrepl directives\r
+> syncrepl rid=001\r
+> provider=ldap://ldap-ridr1.example.com\r
+> bindmethod=simple\r
+> binddn="cn=mirrormode,dc=example,dc=com"\r
+> credentials=mirrormode\r
+> searchbase="dc=example,dc=com"\r
+> schemachecking=on\r
+> type=refreshAndPersist\r
+> retry="60 +"\r
+>
+> syncrepl rid=002\r
+> provider=ldap://ldap-rid2.example.com\r
+> bindmethod=simple\r
+> binddn="cn=mirrormode,dc=example,dc=com"\r
+> credentials=mirrormode\r
+> searchbase="dc=example,dc=com"\r
+> schemachecking=on\r
+> type=refreshAndPersist\r
+> retry="60 +"\r
+> \r
+> mirrormode on
+> serverID 2
+
+It's simple really; each MirrorMode node is setup {{B:exactly}} the same, except
+that the {{serverID}} is unique.
+
+H4: Failover Configuration
+
+There are generally 2 choices for this; 1. Hardware proxies/load-balancing or
+dedicated proxy software, 2. using a Back-LDAP proxy as a syncrepl provider
+
+A typical enterprise example might be:
+
+!import "dual_dc.png"; align="center"; title="MirrorMode Enterprise Configuration"
+FT[align="Center"] Figure X.Y: MirrorMode in a Dual Data Center Configuration
+
+H4: Normal Consumer Configuration
+
+This is exactly the same as the {{SECT:Set up the consumer slapd}} section. It
+can either setup in normal {{SECT:syncrepl replication}} mode, or in
+{{SECT:delta-syncrepl replication}} mode.
+
+H3: MirrorMode Summary
+
+Hopefully you will now have a directory architecture that provides all of the
+consistency guarantees of single-master replication, whilst also providing the
+high availability of multi-master replication.
+
projects / openldap / blobdiff