Quantcast

No route to host with Artemis HA scale down

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

No route to host with Artemis HA scale down

Pascal Gillet
Hi,
We are testing Artemis HA in our cloud environment, with UDP discovery and with Live servers only (scale down).Indeed, we want our JMS client to failover automatically when a server is stopped or decommisioned, and we consider that we are more concerned with servers being stopped than server crashes.Our JMS client is configured with the broadcast address of the servers' group to discover the list of servers to which it can connect (i.g. connectionFactory.myConnectionFactory=udp://231.7.7.7:9876).
As a result, everything works fine and the client switches automatically when a server is stopped (then restarted), BUT THIS is true as long as the servers remain the same, i.e. with the same IP address: once the client has discovered the list of the servers, it keeps the list of IP addresses forever.In our cloud, IP addresses are ephemeral (they are allocated from a predefined range of IP addresses): an Artemis server can be destroyed then recreated with a different address. In this case, the list of IPs on the client side is not consistent anymore, and the client will fail if all the servers are stopped then recreated.
Is it not possible to replay the discovery process on the client side when such conditions occur? Periodically, or when a number of servers are unreachable (limit / total number of servers in the cluster)? Or to keep a list of hostnames instead of IP addresses?

Thank you in advance for your answer.
Pascal GILLET 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: No route to host with Artemis HA scale down

clebertsuconic
Why you need failover on cloud?

You get a lot from the infra-structure. If you actual server died but
if you had the data stored, you could have the server restarting on
another machine, maybe with the same DNS, which will be the same as
another server taking over the load.

That is you use the cloud infra-structure.

Anyways, using infra-structure is always better to deal with failover.
Things like shared storage, persistent nodes are always better than
using the CPU to replicate data. Replication is a valid scenario but
with if you have an option on cloud is always a better choice.


On Tue, Feb 21, 2017 at 3:31 PM, Pascal Gillet
<[hidden email]> wrote:
> Hi,
> We are testing Artemis HA in our cloud environment, with UDP discovery and with Live servers only (scale down).Indeed, we want our JMS client to failover automatically when a server is stopped or decommisioned, and we consider that we are more concerned with servers being stopped than server crashes.Our JMS client is configured with the broadcast address of the servers' group to discover the list of servers to which it can connect (i.g. connectionFactory.myConnectionFactory=udp://231.7.7.7:9876).
> As a result, everything works fine and the client switches automatically when a server is stopped (then restarted), BUT THIS is true as long as the servers remain the same, i.e. with the same IP address: once the client has discovered the list of the servers, it keeps the list of IP addresses forever.In our cloud, IP addresses are ephemeral (they are allocated from a predefined range of IP addresses):


> an Artemis server can be destroyed then recreated with a different address. In this case, the list of IPs on the client side is not consistent anymore, and the client will fail if all the servers are stopped then recreated.


Clients should get an updated list when you restart the server, right?


> Is it not possible to replay the discovery process on the client side when such conditions occur? Periodically, or when a number of servers are unreachable (limit / total number of servers in the cluster)? Or to keep a list of hostnames instead of IP addresses?


The server should send topology updates to the clients...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: No route to host with Artemis HA scale down

Pascal Gillet
Hi,
Clients should get an updated list when you restart the server, right?
The server should send topology updates to the clients...

Yes, but they don't. Must we make something special to achieve that!?

I agree with you on using infrastructure to perform failover...There is no problem with that.


Thanks,

Pascal

    Le Mercredi 22 février 2017 21h11, Clebert Suconic <[hidden email]> a écrit :
 

 Why you need failover on cloud?

You get a lot from the infra-structure. If you actual server died but
if you had the data stored, you could have the server restarting on
another machine, maybe with the same DNS, which will be the same as
another server taking over the load.

That is you use the cloud infra-structure.

Anyways, using infra-structure is always better to deal with failover.
Things like shared storage, persistent nodes are always better than
using the CPU to replicate data. Replication is a valid scenario but
with if you have an option on cloud is always a better choice.


On Tue, Feb 21, 2017 at 3:31 PM, Pascal Gillet
<[hidden email]> wrote:
> Hi,
> We are testing Artemis HA in our cloud environment, with UDP discovery and with Live servers only (scale down).Indeed, we want our JMS client to failover automatically when a server is stopped or decommisioned, and we consider that we are more concerned with servers being stopped than server crashes.Our JMS client is configured with the broadcast address of the servers' group to discover the list of servers to which it can connect (i.g. connectionFactory.myConnectionFactory=udp://231.7.7.7:9876).
> As a result, everything works fine and the client switches automatically when a server is stopped (then restarted), BUT THIS is true as long as the servers remain the same, i.e. with the same IP address: once the client has discovered the list of the servers, it keeps the list of IP addresses forever.In our cloud, IP addresses are ephemeral (they are allocated from a predefined range of IP addresses):


> an Artemis server can be destroyed then recreated with a different address. In this case, the list of IPs on the client side is not consistent anymore, and the client will fail if all the servers are stopped then recreated.


Clients should get an updated list when you restart the server, right?


> Is it not possible to replay the discovery process on the client side when such conditions occur? Periodically, or when a number of servers are unreachable (limit / total number of servers in the cluster)? Or to keep a list of hostnames instead of IP addresses?


The server should send topology updates to the clients...

   
Loading...