IBM Support

Data Collection and Troubleshooting for LDAP replication issues existing (once working) configurations

Troubleshooting


Problem

Once any form of data replication is used, all data, network, systems management becomes more complex for the entire environment. In similar fashion LDAP replication once setup is far from a "set and forget" solution, instead requiring greater expertise, more documentation of the solution, and intervention to maintain it's function through day-to-day data management, LDAP and network changes, as well as changes made on any/all of the systems involved is often required. If LDAP replication has been included as part of an overall High Availability solution, The complexity of managing LDAP replication through fail over / role swap events unique to each environment, must be carefully designed, documented, tested, and executed. The LDAP servers involved are hosted by the IBMi are certainly covered under the SWMA (Software Maintenance Agreement) for the hosting IBMi system. The complexity and integrety of the LDAP data replication / High availability strategy, design, execution, documentation, and administration are not included under However s., the network, DNS servers, and most importantly , and as such are not covered under SWMA.

Symptom

After Network, LDAP configuration, and/or an HA fail over / role swaps, errors are noted in LDAP replication

Cause

Data transfer between systems requires constant consideration, documentation, and modification whenever LDAP, system, and/or network changes are made.

Environment

LDAP Data replication and/or High Availability

Diagnosing The Problem

Comparison of the replication plan to actual replication function

Resolving The Problem

Resolution of any LDAP replication issue can be separated into the following major categories, listed in order of likelihood:

  1. Network / DNS: The LDAP servers involved can no longer find or communicate with each other using the IP addresses or System names configured.
  2. LDAP replication strategy: Flaws in the original replication / HA strategy don't allow for reliable replication function after a role swap / fail over events. Not maintaining the replication strategy through system, network changes can also yield failure.
  3. LDAP Binding: LDAP security requirements or passwords have changed and the LDAP replication configuration hasn't been updated with the new password(s) resulting in replication attempts being rejected.
  4. Data: In cases where errors are made entering records or programmatically being entered on the systems involved, replication operations can be flagged in error, and will require manual replication administration to remove replication actions queued for deleted or damaged records.
  5. LDAP server issues: If one or more of the LDAP servers involved will not start or function or the IBM Tivoli directory server management tool fails to function.

Trouble shooting strategy for LDAP replication outages

Configuration information:

  1. How was this designed to work? A diagram of all the hosts and IP addresses involved is a key recommended documentation.
    • What IP addresses and ports are the LDAP servers involved using? , when did it stop, and if known, what action triggered the event?
    • Complete typology of LDAP replication configuration, the current production and replica if it applies
    • In the event of a fail over / role swap, has the role swap ever been verified this configuration (with the current system as the production unit)?
    • If the HA plan includes IP address and DNS records changes were the required actions completed? If a virtual IP strategy being used do you knwo how to verify it? These are key points unique to your environment and replication / HA strategy.
  2. Key questions on the replication event:
    • When did it stop? and if known, what action triggered the event?
    • Where are you seeing indications of replication issues and what the error indications?
  3. Data collection:
    • Joblogs for the LDAP servers involved: Basic binding issues will be reported here
    • LDAP traces for the LDAP servers in question: LDAP records issues (missing, replicated, locked, and/or damaged) will show here
    • TRCCNN from each system involved: This trace will show what IP addresses are being attempted, and if they are accessible.
Armed with the information above it is possible to compare the replication plan to what is currently happening and deduce the source of the issue. As these are often high severity / impact issues when they occur, the most efficient approach is to have an replication (HA) administrator that is familiar with the overall configurations, aware of any changes that may have triggered the replication issues, and can identify and resolve the network, data, and/or binding issues.

For situation where LDAP server issues are suspected, the LDAP development team would required the same configuration and data collection, to understand and work through the issue.

Where to go for help:

  • If you have have a working knowledge of your Replication / HA strategy and need assistance with executing and analyzing traces, IBMi LDAP support can assist you.
  • If the replication / HA strategy and implementation is unknown the most effective source of assistance will be the business partner that set it up originally. If they aren't available, IBM Lab Services can help reverse engineer the replication / HA solution for a fee.
  • If a general LDAP server failure is suspected, the IBMi LDAP support can help you collect the data to focus on the suspect area.

    • 1.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Document Information

Modified date:
18 December 2019

UID

nas8N1020155

Page Feedback