[ 
https://issues.apache.org/jira/browse/QPID-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7263:
-----------------------------
    Description: 
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed, host down etc) and direct traffic to another target instead.  In our 
case, this feature cannot be used become the Broker continues to listen on the 
AMPQ Port even if the Virtualhost is not the master.  (This is because in the 
model a Port services many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for AMQP Port associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 

  was:
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed, host down etc) and direct traffic to another target instead.  In our 
case, this feature cannot be used become the Broker continues to listen on the 
AMPQ Port even if the Virtualhost is not the master.  (This is because in the 
model a Port services many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for Ports associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 


> Make HA feature integrate more nicely with clients referencing the group via 
> a VIP
> ----------------------------------------------------------------------------------
>
>                 Key: QPID-7263
>                 URL: https://issues.apache.org/jira/browse/QPID-7263
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Keith Wall
>
> One possible deployment pattern for HA is that clients reference the HA group 
> via a VIP rather than utilising a failover url.  This isolates the client 
> from knowledge of the individual node addresses.  This deployment pattern is 
> currently possible but it needs a relatively deep integration: custom 
> scripting is required to track the location of the master node (using the 
> Java Broker's REST API) with changes causing the VIP's target to be updated.
> VIPs usually have a feature which is able to detect when a target is down 
> (port closed, host down etc) and direct traffic to another target instead.  
> In our case, this feature cannot be used become the Broker continues to 
> listen on the AMPQ Port even if the Virtualhost is not the master.  (This is 
> because in the model a Port services many virtual hosts).
> It would be desirable if a cleanly integration could be found:
> * somehow arranging for AMQP Port associated with HA to become unbound when 
> the mastership goes away.
> * perhaps by providing an additional 'ping' port related to the virtualhost 
> that is only bound when the master is present at the node.
>  
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to