High-Level Architecture
The following diagram provides a high-level overview of the architecture for high availability for cloud licensing.
The elements in this diagram are described below.
Client Application
The client (protected) application integrates with the Sentinel LDK Licensing API. You can configure the Licensing API (or License Manager) INI file to set serveraddr with the DNS address.
The Licensing API (or License Manager) always attempts to contact all of the available License Managers in parallel, and it uses the one that responds.
The Licensing API for cloud licensing uses HTTP with a proprietary cryptographic algorithm. This protocol is similar to TLS-PSK.
DNS Service
When two license manager services bring redundancy capability, the load balancer (NGINX) itself can still leave a single point of failure. High availability for the load balancer layer can be improved using one of the following options:
>Using DNS with single floating IP address
Floating IP is a static public IPv4 address that can be attached to both reverse proxy instances. It directs traffic to one instance at the time and can be switched between multiple instances immediately. For this option, the DNS record only needs to contain one static IP address.
>Using DNS with multiple IP addresses
You can create a DNS “A” record to store multiple IP addresses of reverse proxy instances.
Reverse Proxy
The reverse proxy should be configured as active-active mode. As a result, license requests will be redirected to one of License Managers based on the load balancing policy. For example, round-robin or least-connected load balancing can be used. If one of the License Managers is down, a "retry login" mechanism implementation is not required in the client application code for active-active deployment.
The reverse proxy can perform an active health check via the following License Manager health check end point: /sentinel/ldk/v1/healthz
When a load balancer is used, it should be configured to use the same License Manager service instance for a given client or session. For more information, see Requirements for the License Server Machines.
Load Balancer Policy
Sentinel Licensing API is not a stateless API. When using this API, you must configure a sticky session policy in the load balancer or reverse proxy to ensure that a client request is redirected to a specific network server for the duration of a session.
In general, cloud licensing supports three sticky session policies:
>IP hash – The IP address of the client is used to determine which server receives the request.
>Consistent hash – The client generates a unique ID. Sentinel LicensingAPI has a special HTTP header (X-LDK-Instance).
>Session cookies – The load balancer assigns a unique cookie ID back to client, and the next request from the client carries this cookie back to the load balancer.
License Manager Service (LMS)
The high-availability solution is only valid for an LMS based on trusted license storage. To enable this type of storage, you must first set environment variables or use the License Manager INI file to enable the License Managers to connect to the MySQL database. Next, you use Sentinel EMS to generate an authorization file, and apply the file to one of the License Manager instance. This enables the License Managers to use the MySQL database as a trusted license storage.
The Implementation section demonstrates how to set up active-active license servers using Docker Compose and NGINX to handle License Manager failover.
MySQL Cluster
Machine on which a MySQL database or database cluster for license storage resides. The vendor has complete control over this database and is responsible for the security of the database. This machine serves as the trusted license storage unit.
Note that with trusted license storage, the database is readable and accessible by the vendor, but the internal blobs in the database are still encrypted with the Vlib secrets.
Summary of Differences Between Active-Active and Active-Passive Configuration
The table that follows summarizes considerations when you are changing from the active-passive configuration to the active-active configuration.
| Active-Passive | Active-Active | |
|---|---|---|
| Client Application | Retry must be implemented. | Retry is not required. |
| DNS | Use a DNS with a single floating IP address. Or Configure your DNS record as failover type (active-passive) to return only one healthy IP address at a time to avoid potential license abuse. |
Configure the DNS record as active-active type with two IP addresses of reverse proxy. |
| Reverse Proxy | Reverse proxy should be configured for active-passive mode. | Reverse proxy should be configured for active-active mode. |
| License Manager Service | Run-time Environment on each cloud license server must be version 8.31 or later. | Run-time Environment on each cloud license server must be version 8.41 or later. |
| MySQL Cluster | There is no difference between active-active and active-passive configuration. | |