Document toolboxDocument toolbox

(4.4.12) 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

http://Finesse-2/finesse/api/

SERVER_ADDRESS_1

Finesse-2

Finesse_2

http://Finesse-1/finesse/api/

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 priorityPriority 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