Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Advanced Topics

Multi-tier Load Balancing Group

search

Please Note:

Multi-tier Load Balancing Group

The multi-tier load balancing feature enables you to create multiple levels of load balancing groups, called as tiers. When one tier is unreachable, the system fails over to the next tier. You can have a maximum of three tiers. You must configure the tiers in order, that is, you can’t have tier 3 without tier 1 and tier 2.

The following parameters are tier-aware, meaning that their values can vary by tier:

  • CA_File

  • Cert_File

  • Connection_Idle_Timeout

  • Connection_Retry_Interval

  • Connection_Timeout

  • Connection_Read_Timeout

  • Key_File

  • NAE_Port

  • KMIP_Port

  • Passphrase

  • Protocol

  • Size_of_Connection_Pool

To vary the values in tier, add the suffix .n to the parameter's name, where n is the tier number. You can opt to apply one value to all tiers by omitting the .n suffix.

For example, to set up the port for tiers 1, 2, and 3, you could set the following:

NAE_Port.1=9000
NAE_Port.2=9000
NAE_Port.3=7000

You can also do this:

NAE_Port=9000
NAE_Port.3=8000

Because tiers 1 and 2 do not have their own settings, they use the Port value. Tier 3 uses the Port.3 value.

You can not set the following: 

NAE_Port.2=9000
NAE_Port.3=7000

As there is no setting for tier 1.

How it Works

The following steps describe what happens when the client attempts to connect to the multi-tier load balancing group for the first time.

  1. The client creates a session. This, in turn, creates a new load balancer, which stores the NAE_IP, Port, Protocol, Connection_Timeout, and Connection_Retry_Interval parameters. If persistent connections are enabled, the load balancer also creates a new connection pool for each server in the load balancing group.

    Note

    If persistent connections are not enabled, the load balancer does not create a connection pool. Connection pools enable the client to reuse existing connections if it needs them after receiving the server response. It recommends enabling persistent connections, because the performance cost of maintaining a connection pool is much less than the cost of opening a new connection for each client request.

  2. The client requests a connection from the load balancer. Since this is the first connection request, the load balancer chooses one of the servers on tier 1 at random and creates a connection. (When the client makes future requests, the load balancer applies the algorithm selected in Load_Balancing_Algorithm.) The load balancer chooses server 1 on tier 1.

  3. The client waits for the duration specified by Connection_Timeout for server 1’s response. Server 1 does not respond within the timeout period. The client ignores server 1 for the duration specified by Connection_Retry_Interval.

  4. The client attempts to connect to server 2 on tier 1.

  5. The client waits for the duration specified by Connection_Timeout for server 2’s response. The client can’t connect to any server on tier 1.

  6. The client attempts to connect to a server on tier 2. The load balancer chooses one of the servers on tier 2 at random and tries to create a connection. When the client makes future requests, the load balancer applies the algorithm selected in Load_Balancing_Algorithm to decide which server to use. (The client continues to use tier 2 until tier 1 is available.) The client cycles through all of the servers on all tiers.

  7. The client obtains the connection from server 3 on tier 2.

  8. The client uses the connection to send a cryptographic request to server 3.

  9. Server 3 sends the response.

  10. The client receives the response. If persistent connections are enabled, the load balancer keeps the connection in the pool; otherwise, the connection is closed.

  11. The client requests another connection. The load balancer uses the algorithm selected in Load_Balancing_Algorithm to determine which server to use. If persistent connections are enabled, the load balancer searches that server’s connection pool for an existing connection.

To connect to a multi-tier load balancing group, you need to set the following parameters in the properties file:

  • NAE_IP

  • KMIP_IP

  • NAE_Port

  • KMIP_Port

  • Protocol

  • Load_Balancing_Algorithm

  • Connection_Timeout

  • Connection_Retry_Interval

To know more about these properties, refer to Network Configuration Parameters and Connection Configuration Parameters.

Examples

Example 1 - Default Values As delivered, the CADP_CAPI.properties file uses the following values:
Connection_Timeout=30000
Connection_Retry_Interval=600000
For this example, let’s set NAE_IP.1=alpha:beta:gamma, NAE_IP.2=psi:omega, and look at the Connection Configuration Parameters one by one:
Connection_Timeout: The client gets an error if it takes longer than 30 seconds to get a response from a server.
Connection_Retry_Interval: If the client can’t connect to a server within the duration specified by Connection_Timeout, then the client takes that server out of the round-robin rotation for 10 minutes (600000 milliseconds).
Example 2 - Setting Connection_Timeout We’ll still use NAE_IP.1=alpha:beta:gamma, and NAE_IP.2=psi:omega, but this time, we’ll set a Connection_Timeout.
Connection_Timeout=2000
Connection_Retry_Interval=600000
Connection_Retry_Interval is unchanged.
Connection_Timeout: The client gets an error if it takes more than two seconds to get a response from a server. If the server (or your network) is under a heavy load, then you could get a timeout even for a running server. In this case, if you set Connection_Retry_Interval too low, you just end up bombarding an already overloaded server.

On this page