Overview of Three-Server Redundancy
Using the three-server redundancy capability in FlexNet Publisher, all three license servers operate to form a triad. The license servers send periodic messages to each other to make sure that at least two servers are running and communicating. A quorum is formed when at least two of the three license servers are running and communicating with each other.
The license servers are identified as either primary, secondary, or tertiary. One license server is also designated as the master [m] and is responsible for:
| • | Serving licenses to FlexEnabled applications |
| • | Recording information into the debug log. |
| • | Recording information into the report log. |
If the master fails, then another license server becomes the master.
In the following figure, the primary license server is the master [m]. When a FlexEnabled application sends a checkout request for a license, the master responds and then serves the license to the FlexEnabled application.
Three-Server Redundancy Overview
If the master fails, then the secondary license server becomes the master (see the following figure) and will serve licenses to FlexEnabled applications. The tertiary license server can never be the master. If both the primary and secondary license servers go down, licenses are no longer served to FlexEnabled applications. The master will not serve licenses unless there are at least two license servers in the triad running and communicating. 
Three-Server Redundancy Backup Failover
Understanding How License Servers Communicate
When started, each license server reads the license file and checks that it can communicate with the other license servers. Until each license server establishes this first connection with the others, it will continue to send messages periodically.
Once the initial communication has been established, each license server periodically sends a heartbeat to the others. Heartbeats are messages sent over TCP/IP. Each license server sends a heartbeat and waits for a response from the other license servers. If a license server does not receive a response, it shuts down the vendor daemon so that it cannot serve licenses. A publisher or license administrator can configure the amount of time a license server waits to receive a heartbeat using the HEARTBEAT_INTERVAL property.
Poor network communication causes system performance to slow. Slow network communication can also cause a delay in the transmission of heartbeats between license servers.