You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Justin Bertram <jb...@apache.org> on 2020/02/10 19:13:44 UTC
[DISCUSS] Deprecate colocated configuration in Artemis
Artemis currently has the ability to configure both a live and a backup
server in the same JVM. This is referred to as "colocated" brokers.
The original use-case for this functionality was very early cloud
infrastructure where durable, attached storage was not readily available.
However, since the development of this feature most (if not all) cloud
environments support durable storage separate from the broker so that if
the broker goes down a new, identical broker can be spun-up quickly and
attached to the same storage. This provides high availability without the
need for any idle backups or replication of any kind which functionally
nullifies this feature.
Aside from this, it turns out that (surprise!) configuring & running
multiple brokers in the same JVM is difficult and error-prone not to
mention dynamically coordinating the acquisition of backups in a running
cluster and protecting against split-brain. I was able to quickly search
and find 5 open Jiras for colocated issues (of course, there may be more):
ARTEMIS-452 - Scale down with colocated backup failing when using
replication
ARTEMIS-2165 - Not having backup available after restart in colocated
configuration
ARTEMIS-2609 - Ha-policy collocated not working.
ARTEMIS-2452 - group-name ignored in shared store colocated setup
ARTEMIS-1863 - Colocated Replicating Cluster Ends Up in an Infinite
Quorum Vote Loop After Failover and Restart
At this point I recommend that we deprecate this feature and steer users
who want this kind of functionality to either existing cloud infrastructure
options or multiple, distinct brokers on the same hardware (i.e. outside
the cloud).
What are your thoughts?
Justin
Re: [DISCUSS] Deprecate colocated configuration in Artemis
Posted by Francesco Nigro <ni...@gmail.com>.
+1 having worked on some of those issues I cannot deny this proposal makes
a lot of sense to me!
Il lun 10 feb 2020, 20:14 Justin Bertram <jb...@apache.org> ha scritto:
> Artemis currently has the ability to configure both a live and a backup
> server in the same JVM. This is referred to as "colocated" brokers.
>
> The original use-case for this functionality was very early cloud
> infrastructure where durable, attached storage was not readily available.
> However, since the development of this feature most (if not all) cloud
> environments support durable storage separate from the broker so that if
> the broker goes down a new, identical broker can be spun-up quickly and
> attached to the same storage. This provides high availability without the
> need for any idle backups or replication of any kind which functionally
> nullifies this feature.
>
> Aside from this, it turns out that (surprise!) configuring & running
> multiple brokers in the same JVM is difficult and error-prone not to
> mention dynamically coordinating the acquisition of backups in a running
> cluster and protecting against split-brain. I was able to quickly search
> and find 5 open Jiras for colocated issues (of course, there may be more):
>
> ARTEMIS-452 - Scale down with colocated backup failing when using
> replication
> ARTEMIS-2165 - Not having backup available after restart in colocated
> configuration
> ARTEMIS-2609 - Ha-policy collocated not working.
> ARTEMIS-2452 - group-name ignored in shared store colocated setup
> ARTEMIS-1863 - Colocated Replicating Cluster Ends Up in an Infinite
> Quorum Vote Loop After Failover and Restart
>
> At this point I recommend that we deprecate this feature and steer users
> who want this kind of functionality to either existing cloud infrastructure
> options or multiple, distinct brokers on the same hardware (i.e. outside
> the cloud).
>
> What are your thoughts?
>
>
> Justin
>
Re: [DISCUSS] Deprecate colocated configuration in Artemis
Posted by Ryan Yeats <ry...@connexta.com>.
I would like to mention the main reasons I had investigated colocated backups was to see if we could better utilize the resources of the hot backup and to simplify configuration and deployment with a single configuration vs maintaining separate live and backup configurations. I never successfully got colocation working so I am not partial to that particular feature but I did want to mention some of its merits despite its evident downsides.
Ryan Yeats
On 2/10/20, 12:21 PM, "Christopher Shannon" <ch...@gmail.com> wrote:
+1, it never really made a whole lot of sense to me to have a backup in the
same JVM when a new JVM can be spun up easily and is much easier to
support. Also many different errors that might cause a failover to be
needed would affect the JVM such as OOM, etc.
On Mon, Feb 10, 2020 at 2:14 PM Justin Bertram <jb...@apache.org> wrote:
> Artemis currently has the ability to configure both a live and a backup
> server in the same JVM. This is referred to as "colocated" brokers.
>
> The original use-case for this functionality was very early cloud
> infrastructure where durable, attached storage was not readily available.
> However, since the development of this feature most (if not all) cloud
> environments support durable storage separate from the broker so that if
> the broker goes down a new, identical broker can be spun-up quickly and
> attached to the same storage. This provides high availability without the
> need for any idle backups or replication of any kind which functionally
> nullifies this feature.
>
> Aside from this, it turns out that (surprise!) configuring & running
> multiple brokers in the same JVM is difficult and error-prone not to
> mention dynamically coordinating the acquisition of backups in a running
> cluster and protecting against split-brain. I was able to quickly search
> and find 5 open Jiras for colocated issues (of course, there may be more):
>
> ARTEMIS-452 - Scale down with colocated backup failing when using
> replication
> ARTEMIS-2165 - Not having backup available after restart in colocated
> configuration
> ARTEMIS-2609 - Ha-policy collocated not working.
> ARTEMIS-2452 - group-name ignored in shared store colocated setup
> ARTEMIS-1863 - Colocated Replicating Cluster Ends Up in an Infinite
> Quorum Vote Loop After Failover and Restart
>
> At this point I recommend that we deprecate this feature and steer users
> who want this kind of functionality to either existing cloud infrastructure
> options or multiple, distinct brokers on the same hardware (i.e. outside
> the cloud).
>
> What are your thoughts?
>
>
> Justin
>
Re: [DISCUSS] Deprecate colocated configuration in Artemis
Posted by Christopher Shannon <ch...@gmail.com>.
+1, it never really made a whole lot of sense to me to have a backup in the
same JVM when a new JVM can be spun up easily and is much easier to
support. Also many different errors that might cause a failover to be
needed would affect the JVM such as OOM, etc.
On Mon, Feb 10, 2020 at 2:14 PM Justin Bertram <jb...@apache.org> wrote:
> Artemis currently has the ability to configure both a live and a backup
> server in the same JVM. This is referred to as "colocated" brokers.
>
> The original use-case for this functionality was very early cloud
> infrastructure where durable, attached storage was not readily available.
> However, since the development of this feature most (if not all) cloud
> environments support durable storage separate from the broker so that if
> the broker goes down a new, identical broker can be spun-up quickly and
> attached to the same storage. This provides high availability without the
> need for any idle backups or replication of any kind which functionally
> nullifies this feature.
>
> Aside from this, it turns out that (surprise!) configuring & running
> multiple brokers in the same JVM is difficult and error-prone not to
> mention dynamically coordinating the acquisition of backups in a running
> cluster and protecting against split-brain. I was able to quickly search
> and find 5 open Jiras for colocated issues (of course, there may be more):
>
> ARTEMIS-452 - Scale down with colocated backup failing when using
> replication
> ARTEMIS-2165 - Not having backup available after restart in colocated
> configuration
> ARTEMIS-2609 - Ha-policy collocated not working.
> ARTEMIS-2452 - group-name ignored in shared store colocated setup
> ARTEMIS-1863 - Colocated Replicating Cluster Ends Up in an Infinite
> Quorum Vote Loop After Failover and Restart
>
> At this point I recommend that we deprecate this feature and steer users
> who want this kind of functionality to either existing cloud infrastructure
> options or multiple, distinct brokers on the same hardware (i.e. outside
> the cloud).
>
> What are your thoughts?
>
>
> Justin
>