In versions earlier than 220.127.116.11, each load-balancing algorithm had to be explicitly configured with a set of backend servers. This is still supported and might be the preferred configuration in some cases.
For example, explicitly configured algorithms are required if any backend server is not a PingDirectory server or if it is a PingDirectory server version earlier than 18.104.22.168. It might also be preferable if you want to have more direct control over the configuration that the PingDirectoryProxy server uses for each backend server.
Beginning with 22.214.171.124, it is possible to configure the fewest operations and failover
load-balancing algorithms so that they can automatically discover the appropriate set
of backend servers from information in the topology registry. To do this, the
load-balancing algorithm should be configured with a value for the
ldap-external-server-template property rather than with one or
more values for the
For example, the following configuration change can be used to create a fewest
operations load-balancing algorithm that uses an LDAP external server template named
dsconfig create-load-balancing-algorithm \ --algorithm-name fewest-operations-load-balancer \ --type fewest-operations \ --set enabled:true \ --set ldap-external-server-template:dc_example_dc_com
You can use a similar change to create an instance of a failover load-balancing algorithm that automatically discovers its backend servers, as in the following example.
dsconfig create-load-balancing-algorithm \ --algorithm-name failover-load-balancer \ --type failover \ --set enabled:true \ --set ldap-external-server-template:dc_example_dc_com
With the failover load-balancing algorithm, the backend servers are ordered lexicographically by instance name. This ensures that all PingDirectoryProxy server instances have a consistent ordering, but it is not as easy to control the ordering when automatically discovering backend servers as when they are explicitly configured. This is acceptable in many cases because the primary use of failover load-balancing is often to avoid replication and unique attribute conflicts for write operations, and potentially to avoid read-after-write issues. However, if you want to direct all traffic to a specific instance as long as it is available, then it might be better to explicitly configure the set of backend servers rather than use automatic discovery.
Although you can use just the fewest operations load-balancing algorithm or the failover load-balancing algorithm, you should use both of these together with failover load-balancing for writes and fewest operations for reads. When combined with the PingDirectory server’s default use of assured replication (for all add, delete, and modify DN operations, as well as for modify operations that target passwords or password-related attributes) this provides an excellent balance that minimizes the chance for replication and unique attribute conflicts, minimizes the chance for read-after-write issues that result from propagation delay, and maximizes performance and minimizes response time for read operations. You can do this by using criteria-based load balancing, which involves the following:
- Creating a failover load-balancing algorithm instance for write operations
- Creating a fewest operations load-balancing algorithm instance for read operations
- Creating a criteria-based load-balancing algorithm instance that uses failover load-balancing for write operations
- Configuring the proxying request processor to use the above criteria-based load balancing algorithm for writes and the fewest operations load-balancing algorithm for everything else
The following is an example of this configuration.
# Create a health check to verify that the dc=example,dc=com entry can be # retrieved in a timely manner. dsconfig create-ldap-health-check \ --check-name dc_example_dc_com-retrieve-base-entry \ --type search \ --set enabled:true \ --set base-dn:dc=example,dc=com \ --set allow-no-entries-returned:false \ --set allow-multiple-entries-returned:false # Create a health check to verify that replication is working without a # significant backlog. dsconfig create-ldap-health-check \ --check-name dc_example_dc_com-replication-backlog \ --type replication-backlog \ --set enabled:true \ --set base-dn:dc=example,dc=com # Create an LDAP external server template with the above dsconfig create-ldap-external-server-template \ --template-name dc_example_dc_com \ --set health-check:dc_example_dc_com-retrieve-base-entry \ --set health-check:dc_example_dc_com-replication-backlog # Create a fewest operations failover load-balancing algorithm instance that # uses the default LDAP external server template for backend servers that it # discovers from the topology registry. dsconfig create-load-balancing-algorithm \ --algorithm-name dc_example_dc_com-fewest-operations \ --type fewest-operations \ --set enabled:true \ --set ldap-external-server-template:dc_example_dc_com # Create a failover load-balancing algorithm instance that also uses the # default LDAP external server template for backend servers that it # discovers from the topology registry. dsconfig create-load-balancing-algorithm \ --algorithm-name dc_example_dc_com-failover \ --type failover \ --set enabled:true \ --set ldap-external-server-template:dc_example_dc_com # Create a criteria-based load-balancing algorithm instance that will use # failover load-balancing for writes. dsconfig create-criteria-based-load-balancing-algorithm \ --algorithm-name failover-for-writes \ --set load-balancing-algorithm:dc_example_dc_com-failover \ --set "request-criteria:Write Requests" # Create a proxying request processor instance that uses criteria-based load # balancing to ensure that writes use a failover strategy, and the remaining # read operations use a default fewest operations strategy. dsconfig create-request-processor \ --processor-name dc_example_dc_com \ --type proxying \ --set load-balancing-algorithm:dc_example_dc_com-fewest-operations \ --set criteria-based-load-balancing-algorithm:failover-for-writes # Create a subtree view to ensure that operations below "dc=example,dc=com" # will use the above proxying request processor. dsconfig create-subtree-view \ --view-name dc_example_dc_com \ --set "base-dn:dc=example,dc=com" \ --set request-processor:dc_example_dc_com # Update the default client connection policy to include the above subtree # view. dsconfig set-client-connection-policy-prop \ --policy-name default \ --add subtree-view:dc_example_dc_com