Keeping OpenLDAP available prevents authentication and directory lookups from becoming a single point of failure for logins, email, VPNs, and applications. A clustered virtual IP (floating IP) provides a stable LDAP endpoint that can fail over to another node without changing client configuration.

The pcs CLI manages Pacemaker and Corosync resources for a floating IP (IPaddr2) plus the OpenLDAP daemon as a systemd unit (systemd:slapd). Grouping both resources ensures the virtual IP comes up on the active node before slapd starts serving requests.

This setup provides an active-passive LDAP endpoint, not automatic data sharing. Replication (syncrepl or mirror mode), TLS material, schema, and ACLs must already be consistent across nodes, and slapd must be able to accept connections on the floating address (for example by listening on 0.0.0.0 rather than a node-specific IP).

Steps to set up OpenLDAP high availability with PCS:

  1. Confirm the cluster is online with quorum.
    $ sudo pcs status
    Cluster name: clustername
    Cluster Summary:
      * Stack: corosync (Pacemaker is running)
      * Current DC: node-01 (version 2.1.6-6fdc9deea29) - partition with quorum
      * Last updated: Thu Jan  1 04:44:01 2026 on node-01
      * Last change:  Thu Jan  1 04:43:59 2026 by root via cibadmin on node-01
      * 3 nodes configured
      * 0 resource instances configured
    
    Node List:
      * Online: [ node-01 node-02 node-03 ]
    
    Full List of Resources:
      * No resources
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled
  2. Choose an unused IPv4 address on the same subnet as the cluster nodes for the directory virtual IP.

    An IP conflict on the same L2 segment can disrupt LDAP clients and any host already using that address.

  3. Identify the OpenLDAP systemd unit name used by the cluster resource.
    $ systemctl list-unit-files --type=service | grep -E '^slapd\.service'
    slapd.service                                generated       -
  4. Create a floating IP resource for the directory endpoint using the chosen ip= value.
    $ sudo pcs resource create ldap_ip ocf:heartbeat:IPaddr2 ip=192.0.2.67 cidr_netmask=24 op monitor interval=30s
  5. Create the OpenLDAP service resource using the detected unit name.
    $ sudo pcs resource create ldap_service systemd:slapd op monitor interval=30s

    If slapd is configured to bind only to a node-specific IP, the service can appear active while the virtual IP fails over correctly but LDAP remains unreachable on the floating address.

  6. Group the IP resource with the OpenLDAP resource so both move together.
    $ sudo pcs resource group add ldap-stack ldap_ip ldap_service
  7. Verify the resource group is started on a single node.
    $ sudo pcs status resources
      * Resource Group: ldap-stack:
        * ldap_ip	(ocf:heartbeat:IPaddr2):	 Started node-01
        * ldap_service	(systemd:slapd):	 Started node-01
  8. Confirm the virtual IP is assigned on the active node network interface.
    $ ip -br address show
    lo               UNKNOWN        127.0.0.1/8 ::1/128 
    tunl0@NONE       DOWN           
    gre0@NONE        DOWN           
    gretap0@NONE     DOWN           
    erspan0@NONE     DOWN           
    ip_vti0@NONE     DOWN           
    ip6_vti0@NONE    DOWN           
    sit0@NONE        DOWN           
    ip6tnl0@NONE     DOWN           
    ip6gre0@NONE     DOWN           
    eth0@if456       UP             192.0.2.11/24 192.0.2.67/24 
    $ ip address show | grep -F '192.0.2.67'
        inet 192.0.2.67/24 brd 192.0.2.255 scope global secondary eth0
  9. Query OpenLDAP through the virtual IP to confirm directory responses are served from the floating endpoint.
    $ ldapsearch -x -H ldap://192.0.2.67 -s base -b "" namingContexts
    # extended LDIF
    #
    # LDAPv3
    # base <> with scope baseObject
    # filter: (objectclass=*)
    # requesting: namingContexts 
    #
    
    #
    dn:
    namingContexts: dc=example,dc=net
    
    # search result
    search: 2
    result: 0 Success
    
    # numResponses: 2
    # numEntries: 1

    If anonymous Root DSE queries are restricted, add bind credentials (-D and -W) or test with a known read-only account.

  10. Move the resource group to another node to perform a controlled failover test.
    $ sudo pcs resource move ldap-stack node-02

    Moving the group forces a failover and can drop existing LDAP client TCP sessions.

  11. Confirm the group is running on the new node after the move.
    $ sudo pcs status resources
      * Resource Group: ldap-stack:
        * ldap_ip	(ocf:heartbeat:IPaddr2):	 Started node-02
        * ldap_service	(systemd:slapd):	 Started node-02
  12. Clear the manual move constraint to return scheduling to normal cluster rules.
    $ sudo pcs resource clear ldap-stack