Generic Connector Deployment Models
For Generic Connector we support 2 modes of deployment, Non - Redundant / Simplex Mode and High Availability Duplex Mode
Non-Redundant / Simplex Mode Deployment
In simplex deployment, the application is installed on a single server with no failover support of EF Connector. However, the same EF Connector can still communicate with primary and secondary Finesse servers.
Simplex mode is useful for lab tests and commercial deployments at a smaller scale. Figure below explains the simplex mode of Generic Connector.
High Availability (HA) / Duplex Deployment
In Duplex mode, there are two types of supported configurations.
Active-Passive | A primary/secondary configuration setup where one Connector works as a primary server while the other (secondary) is available as a stand-by server (from a Disaster Recovery site) |
Active-Active | In this mode, both Connector instances are active and serving clients and one instance serves as the backup / secondary for the other. |
Active-Passive (Primary / Secondary) Setup
To configure the Connector in Active-Passive mode, set the value of attribute “GRC_CONSUMER_PRIORITY” in Connector configuration. For the Primary Connector, set the value of this attribute to “127” (without quotes). For the Secondary Connector, set the value of this attribute to “100” (without quotes).
The active-Passive mode has the following configurations.
Configurations for Site-1
Primary-AMQ: broker-1, Secondary-AMQ: broker-2
Generic Connector Configuration should look like this, For a detailed description of the GC please consult properties
Property | Value |
ActiveMq_Timeout | 10000 |
GRC_CONSUMER_PRIORITY | 127 |
RANDOMIZE | false |
PRIORITY_BACKUP | true |
ActiveMq_URL_1 | primary-url-of-amq:port |
ActiveMq_URL_2 | secondary-url-of-amq:port |
Configurations for Site-2
Primary-AMQ: broker-1, Secondary-AMQ: broker-2, For a detailed description of the GC please consult properties.
Property | Value |
ActiveMq_Timeout | 10000 |
GRC_CONSUMER_PRIORITY | 100 |
RANDOMIZE | false |
PRIORITY_BACKUP | true |
ActiveMq_URL_1 | primary-url-of-amq:port |
ActiveMq_URL_2 | secondary-url-of-amq:port |
Failover Scenarios
The following table shows different failover scenarios and their impact on the Connector Clients.
No. | Scenario | Behavior |
1 | AMQ-1 is down while GC-1 is active | AMQ-2 will take over. GC-1 will automatically connect to AMQ-2 and all client requests will be processed by the same GC-1 instance because of its higher consumer priority. Request Flow: Client-App → AMQ-2 → GC-1 Response Flow: GC-1 → AMQ-2 → Client-App |
2 | AMQ-2 and GC-1 are down while AMQ-1 and GC-2 are up | AMQ-1 will take over and all client requests will be processed by GC-2 because it has the second-highest priority after GC-1. Request Flow: Client-App → AMQ-1 → GC-2 Response Flow: GC-2 → AMQ-1 → Client-App |
3 | Both AMQ-1 and GC-1 are down | AMQ-2 and GC-2 will start receiving requests. GC-2 will acquire all agent’s XMPP subscriptions and will start processing requests. Request Flow: Client-App → AMQ-2 → GC-2 Response Flow: GC-2 → AMQ-2 → Client-App |
4 | GC-1 restores | GC-1 will start receiving requests and will grab the XMPP connection of all the active agents because of its higher consumer priority. GC-2 will again be in stand-by mode. |
5 | The link between Connector-1 and Connector-2 is down | In this case, the AMQ network of brokers will not be functional and GCs won’t be able to communicate to sync agents either. So, both GCs will be functioning independently |
6 | AMQ-1 restores while GC-1 is still down | If AMQ-2 is active and the client application is connected to AMQ-2 then all requests will be processed by GC-2 even though GC-1 is active and connected to AMQ-1. Request Flow: Client-App → AMQ-2 → GC-2 Response Flow: GC-2 → AMQ-2 → Client-App |
7 | GC-1 is down while both AMQs are active | Requests will be processed by GC-2 going through the network of brokers. Request Flow: Client-App → AMQ-1 → AMQ-2 → GC-2 Response Flow: GC-2 → AMQ-2 → AMQ-1 → Client-App |
8 | GC-2 is down while both AMQ are active | In active-passive mode, it will have no effect on request and response flow. Because AMQ-2 doesn’t get any request from Client-App until AMQ-1 goes down. |
Failover is handled in a way if any component goes down, passive components take over in a seamless way.
Active-Active Setup
For an Active-Active deployment, the Failover URL is set to use the local AMQ as primary and remote AMQ as secondary.
For GC-1, the configuration would look like this, For a detailed description of the GC please consult properties
Property | Value |
ActiveMq_URL_1 | [AMQ-1]:61616 |
ActiveMq_URL_2 | [AMQ-2]:61616 |
GRC_CONSUMER_PRIORITY | 127 |
PRIORITY_BACKUP | true |
Finesse_1 | http://Finesse-1/finesse/api/ |
SERVER_ADDRESS_1 | Finesse-1 |
Finesse_2 | http://Finesse-2/finesse/api/ |
SERVER_ADDRESS_2 | Finesse-2 |
For GC-2, the configuration would look like this, For a detailed description of the GC please consult properties
Property | Value |
ActiveMq_URL_1 | [AMQ-2]:61616 |
ActiveMq_URL_2 | [AMQ-1]:61616 |
GRC_CONSUMER_PRIORITY | 100 |
PRIORITY_BACKUP | true |
Finesse_1 | |
SERVER_ADDRESS_1 | Finesse-2 |
Finesse_2 | |
SERVER_ADDRESS_2 | Finesse-1 |
Where [AMQ-1] should be replaced with the IP / machine-name of ActiveMQ-1 and [AMQ-2] should be replaced with the IP / machine-name of ActiveMQ-2. Finesse-1 is the IP/name of the Finesse-1 server and Finesse-2 is the IP/name of the Finesse-2 server.
Both Connectors will have its local AMQ as primary brokers and both Connector instances will be serving agents' requests in parallel. All client requests received by Connector-1 are handled by Connector-1 and all requests received by Connector-2 will be handled by Connector-2. In case of failure of any component at any Connector instance, the other Connector instance will take over and handle the request.
We have achieved it using ActiveMQ configurable properties specifically Consumer priority, Priority Backup, and building a Connector Sync mechanism in Generic Connector.
Failover Scenarios
No. | Scenario | Behavior |
1 | AMQ-1 is down while GC-1 is active | AMQ-2 will take over and all client requests will be processed by the same GC-1 instance because of its higher consumer priority. |
2 | Both AMQ-1 and GC-1 is down | AMQ-2 and GC-2 will start receiving requests. GC-2 will acquire all agent’s XMPP subscriptions and will start processing requests. |
3 | GC-1 restores | Connector-2 will continue to process requests until connectivity between the Client application and Connector-2 is lost or Connector-2 is down. |
4 | The link between Connector-1 and Connector-2 is down | Both connector instances serve requests independently. |
5 | AMQ-1 restores while GC-1 is still down and AMQ-2 is also down | The client will send a request to AMQ-1. AMQ-1 will send the request to GC-2 because GC-1 is down. Request Flow: Client-App-1 → AMQ-1 → GC-2 Response Flow: CGC-2 → AMQ-1 → Client-App-1 |
6 | GC-1 is down while both AMQ are active | The request flow will be the same as no. 5 |
7 | GC-2 is down while both AMQ are active | AMQ-2 requests will be redirected to AMQ-1 and GC-1 will handle all requests. Request Flow: Client-App-2 → AMQ-2 → AMQ-1 → GC-1 Response Flow: GC-1 → AMQ-1 → AMQ-2 → Client-App-2 |