Layer 7 Identity Management

Setting up DSA replication using text based configuration 

05-15-2019 10:55 PM

Here I would like to present Justin McDonald's example of setting up replication between two DSAs using text based configuration and command line tools.

This thorough example deserves to be a separate document.

 

Say we have two DSAs on two servers

server1: dsa1

server2: dsa2

 

To enable multi-write replication with DISP recovery (MW-DISP) on UNIX (procedure same for Windows just different paths/env vars).

 

Stop DSAs

server1: dxserver stop dsa1

server2: dxserver stop dsa2

 

Enable multi-write on server1: $DXHOME/config/knowledge/dsa1.dxc

    set dsa "dsa1" =

    {

    prefix = <c US><o CA>

      dsa-name = <c US><o CA><cn "dsa1">

      dsa-password = "secret"

      address = tcp "{hostname}" port 20000

      disp-psap = DISP

      snmp-port = 20000

      console-port = 20001

      auth-levels = anonymous, clear-password

      dsa-flags = multi-write

      trust-flags = allow-check-password

    };

 

Enable multi-write on server1: $DXHOME/config/knowledge/dsa2.dxc.

 

If this file doesn't exist copy from server2, for example, copy server2: $DXHOME/config/knowledge/dsa2.dxc to server1: $DXHOME/config/knowledge

    set dsa "dsa2" =

    {

     prefix = <c US><o CA>

     dsa-name = <c US><o CA><cn "dsa2">

     dsa-password = "secret"

      address = tcp "{hostname}" port 20000

      disp-psap = DISP

      snmp-port = 20000

      console-port = 20001

      auth-levels = anonymous, clear-password

      dsa-flags = multi-write

      trust-flags = allow-check-password

    };

 

Note: The prefix must be the same for dsa1 and dsa2 for replication to work

 

 

Create a knowledge group server1: $DXHOME/config/knowledge/dsas.dxg

    source "dsa1.dxc";

    source "dsa2.dxc";

 

Note: If a knowledge group file already exists for dsa1 and dsa2, this can be updated to ensure that both dsa1 and dsa2 are sourced.

 

Update server1: $DXHOME/config/servers/dsa1.dxi to source knowledge group and also enable MW-DISP while there

 

         Locate the following line

        clear dsas;

        source "../knowledge/dsa1.dxc";

        And replace with

        clear dsas;

        source "../knowledge/dsas.dxg";

 

       To enable MW-DISP locate the following line

       # multiwrite DISP recovery

       set multi-write-disp-recovery = false;

       And replace with

       # multiwrite DISP recovery

       set multi-write-disp-recovery = true;

 

Check for syntax errors

server1: dxsyntax dsa1

 

Copy the following files to server2

Copy server1: $DXHOME/config/knowledge/dsa1.dxc server2: $DXHOME/config/knowledge

Copy server1: $DXHOME/config/knowledge/dsa2.dxc server2: $DXHOME/config/knowledge

Copy server1: $DXHOME/config/knowledge/dsas.dxg server2: $DXHOME/config/knowledge

 

Note: It is a good idea to update the knowledge on one server and copy. This keeps them consistent!

 

Update server2: $DXHOME/config/servers/dsa2.dxi to source the newly copied knowledge group and also enable MW-DISP while there

 

         Locate the following line

        clear dsas;

        source "../knowledge/dsa1.dxc";

        And replace with

        clear dsas;

        source "../knowledge/dsas.dxg";

 

       To enable MW-DISP locate the following line

        # multiwrite DISP recovery

        set multi-write-disp-recovery = false;

       And replace with

        # multiwrite DISP recovery

        set multi-write-disp-recovery = true;

 

Do the DSAs contain data?

If the DSAs contain data and the data is synchronized (loads from the same LDIF for example) then when enabling MW-DISP it is important to checkpoint the DSAs.

server1: dxdisp dsa2

server2: dxdisp dsa1

This step prevents existing data from being superfluously replicated.

 

Start the DSAs

server1: dxserver start dsa1

server2: dxserver start dsa2

 

Check Replication is Ok

It is important to check that the DSAs have contacted each other and the state of replication is ok.

 

server1: telnet localhost 20001

server1: get dsp;

server1: logout;

   ...

   ...

    multi-write-group-credit = 0

    multi-write-outstanding-ops = 10

    dsa2: OK, total 0, waiting remote 0, confirmed local 0

 

server2: telnet localhost 20001

server2: get dsp;

server2: logout;

   ...

   ...

    multi-write-group-credit = 0

    multi-write-outstanding-ops = 10

    dsa1: OK, total 0, waiting remote 0, confirmed local 0

 

For the output of "get dsp;" we are looking for the replicating queue status to be OK. Anything other than OK like DISP-FAILED indicates either a replication problem or a connectivity problem between the two DSAs. The warn-log and alarm-log a good places to start when diagnosing these kinds of replication problems.

 

Another sanity test is to connect to dsa1 via an LDAP browser (like JXplorer) and perform a modify. Then connect to dsa2 and ensure the update has been replicated. A similar test for MW-DISP can be performed by stop dsa2 before updating dsa1. When dsa2 is started it will recov0r from dsa1 and the update should be reflected.

 

Other considerations

* We would also recommend running one or more router DSAs with the replicas to allow for automatic failover and failback

* Ensuring $DXHOME/config/knowledge are identical between machines will ensure that all DSAs will function in a consistent manner

* We would recommend setting one of the replicas as a preferred master. This is achieved adding the following line to the router.dxi file: "set write-precedence = dsa1, dsa2;". This prevents update conflicts (same entry updated at the same time on dsa1 and dsa2).

 

In Summary

  • We ensured the that the 2 DSAs have the same prefix
  • We set dsa-flags = multi-write in the knowledge file for both DSAs
  • We ensured that the knowledge files for both DSAs were copied to each server and sourced via a knowledge group file
  • We then sourced this knowledge group from each initialization file (.dxi) instead of sourcing the individual knowledge file for the DSA
  • We enabled MW-DISP by changing multi-write-disp-recovery from true to false
  • We check pointed the data if any pre-existing data after ensuring that the data is synchronized
  • We then verified replication was working as expected

 

I hope that helps in enabling MW-DISP with 2 DSAs. Please let me know if you have any further queries. I will talk to our tech writing team to ensure an example like the above is included to assist in setting up 2 replication peers.

Statistics
0 Favorited
5 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

05-16-2019 10:57 AM

Thank you for sharing this with the community!

Setting up DSA replication using text based configuration 

Related Entries and Links

No Related Resource entered.