The Logical Architecture article illustrates the conceptual components of Trigger-it, which can be found at the following link: http://content.sysgravity.com/kb/kb/trigger-it-logical-architecture/
To achieve high-availability (HA) configuration, you can configure each component as following:
| Item | HA Configuration |
| SQL Database | High Availability (HA) configuration can be achieved using either SQL AlwaysOn or SQL Clustering. Although mirroring is technically possible, it is not a supported configuration. We recommend SQL AlwaysOn or SQL Clustering as superior options for HA. |
| Mongo DB | MongoDB is utilized to store inventory data, which is subsequently normalized into an SQL Database. In the event of data loss, the data will automatically be repopulated by agents. For High Availability (HA), the only supported option is a MongoDB cluster. |
| RabbitMQ | RabbitMQ serves as the central communication channel between agents and the server. High Availability (HA) is achieved through the Console by configuring multiple RabbitMQ endpoints in the Options tab. Agents attain RabbitMQ HA by employing a policy with multiple RabbitMQ servers, cycling through them to ensure HA.. |
| Web Services | Agents utilize web services to retrieve Tags/Policies. The HQ can be configured by setting up multiple web service endpoints, which will be used by agents to look up Tags/Policies |
How HA Works for Agent to server communication (RabbitMQ):
Agents achieve HA to backend services (RMQ) when a policy is configured Advanced Agent Configuration elements:
The element allows Internal Servers/External Servers lists to be configured, each list is a group of IPs seperated by (#) e.g. (x.x.x.x#y.y.y.y).
Upon receipt by the agent, the agent will populate both the internal and external servers list. These lists will be used as follows::Each server will be tested separately for outbound RMQ and inbound RMQ connections. For each RMQ connection type, each internal host entry will be used. If a connection fails, a 60-second backoff will occur, and each server will be tested three times before moving to the next internal host entry. If none of the internal servers respond, each external host will be used in the same manner. If none of the external hosts respond, a 1-minute backoff will occur before looping through the internal host list again. This process will continue indefinitely until a server responds. During backoffs and in the absence of RMQ connections, the agent will continue collecting data, which will be queued on the agent side until an RMQ connection is established. However, all data will be lost if the agent is restarted, whether it's the service or the operating system.
How HA Works for Console to server communication (RabbitMQ):
Console to RMQ HA will be achieved by configuring multiple RMQ servers as server side option in the Settings section:
The list is configured as a series of servers (IP or FQDNs) separated by a “#” symbol, for example, “x.x.x.x#y.y.y.y”.
When configured, the console will look up the list when sending execution commands to agents and will send the command to each RMQ server.
If there are two servers, both servers will receive the execution commands for the agent, waiting to be picked up by the agent.
On the agent side, the agent will always be connected to one server at any point in time. So, if the agent is connected to Server #1, it will execute the command.
If Server #1 fails, the agent will connect to Server #2 and will receive the command again. However, a server-side execution duplicate prevention mechanism exists to prevent this.
When the agent receives the command, it will store the command GUID in the commandslog.txt file and load them upon each service restart. This is stored in an internal InMemory DB for fast lookup, so when the command is received again from Server #2, it will be checked against the DB and will not run.
All these events are stored in the event viewer for troubleshooting purposes.
How HA Configuration works for Web Services:
Agents will use the configured internal and external RMQ servers as a list of web services candidates. During agent startup, the agent will loop through each host to look up tags.
The loop will process internal servers first, then loop through external servers. If any server responds, it will be set as the current web services host and will be used for subsequent web services lookups (without looping) unless the service is restarted or the host is not responding.