[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: syncbackup



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Masato Taruishi

> Dear OpenLDAP guys.
>
> First of all, I would like to say sorry about my English as you know,
> but I'd like your opinions and/or suggestions about my recent activity
> to OpenLDAP which we call syncbackup, that is, to provide
> high-availability of master server ( An experimental
> implementation is
> almost done ) keeping the database consistency.
>
> In order to achieve this kind of HA, syncbackup propagates LDAP
> operations for modifications such as ldap_modify, ldap_add,
> ldap_delete and ldap_rename, to other LDAP servers before commiting
> the changes locally.
>
>                           Master                Backup
>  Client -- modify(0) -->    |                     |
>    |                        | --- modify(0) --->  |
>    |                        |                     |
>    |                        | <--- SUCCESS -----  |
>    |                        |
>    | <---- SUCCESS  -----   |
>
> Only if the master slapd server gets the sucuess results from other
> backup servers as well as local commits, it returns the success to the
> client. So, if the master returns success, at least two
> servers have the
> changes.
>
> If the master server hangs up, another backup server can
> become another
> master server because all changes to the original master server have
> been propagated to the new master server.
>
> This is a simple example and has many problems.

It's an interesting idea. I've designed this setup already using an extended
version of back-ldap as an overlay on another database backend. (I called
this the "fanout" overlay as it fans out updates to a collection of servers.)

> First, in this example, if the backup server hangs up, the
> master server
> can't get the response from the backup server. Then if either
> the master
> or the backup hang up, the client can't get result.
>
> Second, when the original master server is restarted, how does this
> server follow the latest directory?
>
> To solve these problems, the following ideas were born:
>
>       *) At least backup
>       *) Boot-time synchronization using syncrepl()
>
>  * At least backup
>
>     This is a way to propagates an operation to several backup servers
>     at the same time and wait for at least one success result.
>
>        +------+
>        |Master| <--- SUCCESS ------------+
>        +------+                          |
>           | |                            |
>           | +------------------+         |
>           |                    |         |
>       propagation          propagation   |
>         XXXXX                  |         |
>        XhangupX               \ /        |
>         XXXXX               +------+     |
>        +------+             |Backup| +---+
>        |Backup|             +------+
>        +------+
>
>    So even if one backup server hangs up or delay because of
> some reason
>    such as network trouble, the master server can return the
> success to
>    the client as soon as possible.

Of course you must queue the updates to the other servers. And if one backup
responds for one update, but a different backup handles the next update, then
you have lost consistency if there are still updates in the queue.

>  * Boot-time synchronization using syncrepl()
>
>     When another backup server fail over the master service,
> the backup
>     server fetches the changes to other servers by using one-time
>     syncrepl.
>
>        +------+
>        |XXXXXX|
>        +------+
>                                  New Master
>                   syncrepl  +------+
>        +------+    +----->  |Backup|
>        |Backup| ---+        +------+
>        +------+
>
>     The new server should be up-to-date within the available servers.

I don't understand the above statements.

>  These are the ohter extensions to construct syncbackup:
>
>       * startSYNC extended operation
>
>          This is a LDAPv3 extended operation to start syncbackup.
> 	 It sends syncCookie and syncid and then the master server
> 	 attaches it to the apropriate list and propagates
> 	 LDAP operations to the backup server.
>
>
>             +------+
>             |Master| ---- propagation +
>             +------+                  |
>               / \                     |
>                |                      |
>       startsync operation             |
>                |                      |     Backup server
>      +----------------------------------------+
>      |         |                  +------+    |
>      |    +---------+             | Core |    |
>      |    |startSYNC|             +------+    |
>      |    +---------+                         |
>      |                                        |
>      +----------------------------------------+
>
>          If the backup server returns error, the master sends the
>          SYNC_ERROR response to the startSYNC operation and
> detaches the
>          backup server.
>
>          If the master server exits, the master sends the SYNC_DONE
> 	 response to the startSYNC operation.

I don't understand the purpose of this operation. A regular Sync request
should suffice.

>       * NOOP extended operation
>
>          This is a LDAPv3 extended operation to check whether
> the server
> 	 works or not. If the server gets the operation, it returns just
> 	 LDAP_SUCCESS.

There is already a NOOP control, so I don't see the need for an exop.

>       * contextCSN LDAP control
>
>          This is a LDAPv3 LDAP control. When the master propagates the
> 	 operation, it puts the appropriate contextCSN value to the
> 	 operation. If the backup server gots the contextCSN control,
> 	 it uses the value rather than using lutil_csnstr().

I see that this is a good idea when performing synchronous replication of
this type.

> Even though the implementation has some bugs yet, I can use this
> replication engine within my OpenLDAP environment. I have to think
> twice about the following topics:
>
>     * considerations about rfc3389.
>     * multi-master environment.

I think this approach can be turned into a form of multimaster, with some
performance loss. If you enforce a strict ordering among all of the servers,
so that updates received by any of them are applied to all of them in the
same sequence, then you can ensure consistency. The only advantage over
single-master is that you don't have to worry about how to promote slaves to
masters in the event of any failures. Otherwise, the update response time is
slower than the single-master case, and the overall bandwidth requirement is
nearly the same.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support