Monday Nov 30, 2009

OpenDS 2.2.0 Release Candidate 4 is now available

Opends Logo TagLast week, the OpenDS 2.2.0 Release Candidate 4 has been made available on our website. This new release candidate was mostly done to accommodate with some late changes to messages being localized, and give more time for testing to OpenDS 2.2 and the Sun branded product based on it.

OpenDS 2.2.0-RC4 is built from revision 6147 of the b2.2 branch of the source tree.

The direct link to download the core server is: http://www.opends.org/promoted-builds/2.2.0-RC4/OpenDS-2.2.0-RC4.zip

The direct link to download the DSML gateway is: http://www.opends.org/promoted-builds/2.2.0-RC4/OpenDS-2.2.0-RC4-DSML.war

We have also updated the archive that may be used to install OpenDS via Java Web Start. You may launch that using the URL http://www.opends.org/promoted-builds/2.2.0-RC4/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information.

Detailed information about this build is available at http://www.opends.org/promoted-builds/2.2.0-RC4, including the detailed change log

Major changes incorporated since OpenDS 2.2.0-RC3 include:

  • Revision 6150 (Issue #4355) - Fixes a caching issue with the Control Panel when aborting a search
  • Revisions 6156, 6160, 6172 (Issue #4358, #4329, #4340) - Resolve several issues with the External Change Log at initialization or shutdown
  • Revision 6181 (Issue #4325) - Resolves an issue with values of Enumeration Syntax not being case insensitive in Add or Modify operations

Technorati Tags: , , , , , , ,

Thursday Jul 23, 2009

Assured Replication: A New Feature of OpenDS 2.0

OpenDS 2.0 has just been released and there are several new and exciting features in it.

To me, the biggest innovation in this release is "Assured Replication", an extension to the loose consistency multi-master replication feature that brings tighter consistency of data between replica. "Assured Replication" is not to be taken for a full synchronous and transactional replication mechanism. A change is not transactionally applied to a set of or all replicas of a topology. With "Assured Replication", the response to an LDAP modification is delayed until the change has been received or applied by other servers, in a best effort mode. It provides a greater assurance that a change is not lost even if the server receiving it crashes.

Opends Assured Replication with Safe Data level 2

Assured Replication can function in 2 modes :

  • Safe Data Mode: an update must be propagated to a defined number of Replication Servers before returning a response to the client. So if the server or the replication server is stopped, the data is still available to all other replicas.
  • Safe Read Mode: an update must be propagated to all directory servers in the domain before the client is returned a response for the update.

Of course, for both modes, it's possible to configure a timeout interval to prevent LDAP clients to be waiting indefinitely if some servers are not available.

Configuring Assured Replication is pretty straightforward but cannot be done when setting up replication itself. So the first step is to configure Multi-Master Replication for a domain with dsreplication.

$ bin/dsreplication enable --host1 localhost --port1 5444 --bindDN1 'cn=directory manager' --bindPassword1 secret12 --replicationPort1 8989 --host2 localhost --port2 6444 --bindDN2 'cn=directory manager' --bindPassword2 secret12 --replicationPort2 8990 --adminUID admin --adminPassword secret12 --baseDN "dc=example,dc=com" -X -n

Establishing connections ..... Done.
Checking Registration information ..... Done.
Configuring Replication port on server localhost:5444 ..... Done.
Configuring Replication port on server localhost:6444 ..... Done.
Updating replication configuration for baseDN dc=example,dc=com on server localhost:5444 ..... Done.
Updating replication configuration for baseDN dc=example,dc=com on server localhost:6444 ..... Done.
Updating Registration configuration on server localhost:5444 ..... Done.
Updating Registration configuration on server localhost:6444 ..... Done.
Updating replication configuration for baseDN cn=schema on server localhost:5444 ..... Done.
Updating replication configuration for baseDN cn=schema on server localhost:6444 ..... Done.
Initializing Registration information on server localhost:6444 with the contents of server localhost:5444 ..... Done.
Initializing schema on server localhost:6444 with the contents of server localhost:5444 ..... Done.

Replication has been successfully enabled. Note that for replication to work you must initialize the contents of the base DN's that are being replicated (use dsreplication initialize to do so).

$ bin/dsreplication initialize --baseDN "dc=example,dc=com" --adminUID admin --adminPassword secret12 --hostSource localhost --portSource 5444 --hostDestination localhost --portDestination 6444 -X -n

Initializing base DN dc=example,dc=com with the contents from localhost:5444:
23 entries processed (100 % complete).
Base DN initialized successfully.

See
/var/folders/SH/SHFsRjymHtqiZ4GxPNZERU++Fwk/-Tmp-/opends-replication-737929812662715818.log
for a detailed log of this operation.

$ bin/dsreplication status -h localhost -p 5444 --adminUID admin --adminPassword secret12 -X

dc=example,dc=com - Replication Enabled
=======================================
Server : Entries : M.C. (1) : A.O.M.C. (2) : Port (3) : Security (4)
---------------:---------:----------:--------------:----------:-------------
localhost:5444 : 23 : 0 : N/A : 8989 : Disabled
localhost:6444 : 23 : 0 : N/A : 8990 : Disabled

Now that replication is setup, we can enable the Assured Replication mode, using the dsconfig utility. For this, on each of the OpenDS direcotry servers, we first need to retrieve the full name of the replication domain.

$ bin/dsconfig -D cn=directory\\ manager -w secret12 -n -s list-replication-domains --provider-name "Multimaster Synchronization"

cn=admin data (domain 29167)
cn=schema (domain 9674)
dc=example,dc=com (domain 14741)

$ bin/dsconfig -D cn=directory\\ manager -w secret12 -n set-replication-domain-prop --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com (domain 14741)" --advanced --set assured-type:safe-data --set assured-sd-level:2

Note that the Replication Domain has a different value on each server, so you have to repeat these 2 commands on each instance.
Setting the assured level for Safe Data to 2 means that the server will make sure the data has been received by at least 2 replication services before returning to the LDAP client the response to the update request.

From a client point of view, there should be no difference, except that the server might take a little longer to return the response to an update request. In our measures, we found that the response time increased by 25% for Safe Data Level 2, which seems a lot, but honestly, when the response time is in the order of 2ms, it's hard to notice !

You can find more information about Assured Replication on OpenDS 2.0 documentation wiki, both in the overview of OpenDS Replication Architecture and the Replication Administration Guide, and more specifically Assured Replication Administration Guide

Technorati Tags: , , , , ,

Wednesday Dec 19, 2007

Directory Services Art

150Mastertopo

Thanks to Sebastien Bertholet, an esteemed engineer in the Directory services quality engineering team, for producing this amazing picture of a fully partially connected topology of 150 Master Directory Servers (each master is connected to 5 other servers).
Click on the picture for the full size version for the details, but be patient the image is huge.

Technorati Tags: , ,

About

This is the blog of a senior software engineer, specialized in LDAP, Directory Server and OpenDS. Ludovic Poitou works in France at the Grenoble Engineering Center, in the Directory Services Engineering team. Outside work, I love skiing and taking photo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today