search

vromero / activemq-artemis-helm

Helm chart for a cluster of ActiveMQ Artemis (Work in progress)
42 stars 68 forks source link

Remove Slave Nodes. #56

Open Namphibian opened 3 years ago

Namphibian commented 3 years ago

I came across an artcile by RedHat where they talk about Artemis in the OpenShift/Kubernetes world.

The article is located here: https://developers.redhat.com/blog/2020/01/10/architecting-messaging-solutions-with-apache-activemq-artemis/

A few of the sections make it quite clear that having a slave node for HA in Kuberenetes is not needed as HA is achieved by K8s itself.

In the orchestration section: For example, there is no master/slave failover (so no hot backup broker present). Instead, there is a single pod per broker instance that is health monitored and restarted by Kubernetes, which ensures broker HA

In the Broker section

On Kubernetes, broker HA is achieved through health checks and container restarts. On-premise, the broker HA is achieved through master/slave (shared store or replication).

I have removed it from the helm chart and busy testing will create a pull request if you are keen and we can simplify the cluster model a bit more.

tobias-zeptio commented 3 years ago

I used this chart as a basis for our deployment, and also made this change. After testing HA vs cluster performance, we also found a cluster configuration to give better fail over performance.

Namphibian commented 3 years ago

@tobias-zeptio I am looking into using jgroups and maybe making that configurable for the chart as well. Having the ability to scale up and down would be useful. However that is a bit of a longer term goal.

tobias-zeptio commented 3 years ago

I haven't implemented it yet, but I plan to use kubernetes autoscaler for that. Should be supported with the current static cluster implementation. I did some quick testing with manual scaling, and it seemed to work fine.