[DISCUSS] Deprecate colocated configuration in Artemis

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Deprecate colocated configuration in Artemis

jbertram
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Deprecate colocated configuration in Artemis

christopher.l.shannon
+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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Deprecate colocated configuration in Artemis

ryeats
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" <[hidden email]> 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 <[hidden email]> 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
    >
   

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Deprecate colocated configuration in Artemis

nigro_franz
In reply to this post by jbertram
+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 <[hidden email]> 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
>