*Redundancy
- Tom Polman
Configuration Article | CA-20220907-TP-06 VDG Sense | API | Usage  |  |
in the scheme for a redundant system interface, we assume that all elements, the management server, server and the client manager application, are implemented twice. The primary parts normally communicates with eachother. The secondary parts takes over when the primary fails. When the primary part comes back, it takes
Types of commands
For the further story it is important to distinguish between the two types of API commands.The first type are commands that retrieve data such as getDivaList, getAbsolutePosition etc. These commands perform no actions on the server and only request data. The second type are commands that can execute an action on the server. These are commands like setPreset, executeAction, selectCamera etc. These action commands can change the status of the server.
Primary server
The primary management server is the server who is normally active. This server is checked by the secondary (fail-over) server (connection J). The primary server can have connections to clients and managers. The server does not know in principle what kind of client is connected to it.
Secondary server
The secondary server is the fail-over server. It checks if the server(s) no longer runs (J) and takes over on failure. Then the secundary server makes sure that all of the clients are informed of this acquisition. The clients will then disconnect from the primary server (F and H) and connect to the secondary server (G and I).
Primary manager
The primary manager has a connection with the server (primary (F) or secondary (G)). This manager sends all actions to the server and sends all status information to (manager) clients (A and C). Multiple clients can send action and status commands to the manager. The manager performs them all.
Unique commands
If multiple clients are setup as redundant or failover Client, they can send the same commands to the manager (A and C). It can happen that the same action is send twice to the server. This can lead to unforeseen results. To prevent this, the commands can be provided with a unique ID by the UID parameter in the URL. This value can be anything as long as it is unique. Example:
command=selectLayout&layoutid=1&divaid=7015498111931795223&uid=AUniqueValue1234
The manager only performs the first action command. Second and subsequent action commands with the same UID will not be forwarded to the server. A normal response will be returned.
Secondary manager
The secondary manager works in failover mode. In this mode the manager connects to the primary manager (E) and asks for status updates of all handled messages. A status message is sent by the primary manager after finishing a command. Each incoming command of a client is queued by the secundary manager. If a status message from the primary manager comes with the same UID as a command in the queue then this command is executed. This command does not sent any action servers but does give an answer and/or status information back. When commands stay too long in the queue the secundary manager will switch to normal mode. This manager then behaves more like a primary manager. Once the secundary manager starts to receive status messages from the primary manager it switches back to failover mode.
Primary client
The primary client has a normal connection to the primary manager (A). It can also be connected to the secondary manager (B). To prevent executing double action commands on the server a unique ID can be sent with each command. This UID prevents the secundary manager (in failover mode) to send actions to the server. All status messages are handled by both the primary and secondary manager. If the primary manager fails it will no longer give answers and there may be no connections anymore. Verifying if the manager is still working can be done by asking for a certain status, e.g. with getEvents.
Secondary client
The secondary client seeks to replace the primary client should it fail. The primary and secondary client must be controlled so that they send the same commands to the managers with the same UIDs. The secondary client can be omitted. When connected to multiple managers a client must send UID’s with each message.