Gary, so an HA solution for Artemis running on Kubernetes is not worth it, as we expect Kubernetes to recover anyway? If a producer loses connection to the Artemis instance would you not lose the data? Or would a typical client try to resubmit it, or would the client/application need to be designed for that? A multi-broker setup on Kubernetes would typically be for scalability, not for HA? Or when would you consider a cluster of brokers? Forgive me for my stupid questions, I'm pretty new to the message broker world. If the broker is using persistent storage I understand we don't expect to lose the data once it's on the broker (queue/topic).
Best Regards, Jo Op vr 11 feb. 2022 om 12:10 schreef Gary Tully <gary.tu...@gmail.com>: > Hello, > the reconnect issue? How are your clients configured? Do they get > topology from the pair of brokers on kube? > > -- > On re-connection: > > failover with the Artemis jms client will only occur between pairs. > It is restricted in that way to protect users of temp queues and > durable subs, b/c those resource will only be available on a replica. > Other clients (openwire or AMQP qpid jms) are not as protective by > default so will continue to try and reconnect. > > In any event, from an application perspective, it is often best to > hide the JMS connection with something like camel-jms or spring jms > template. In that way, the error handling can be separately controlled > and isolated from protocol specifics. It is an extra level of > indirection with sensible defaults that can be tweaked as needed. > If the broker url is behind a proxy/loadblancer/firewall or dns or > some other mechanism that is broker topology agnostic, it can help. > > > -- > On the replication vs single broker pod: > > these are very different, with replication there are two copies of > your data, with a single pod there is only one copy. > > - Single Pod: > Because kube does a good (if slow) job of auto restarting it makes > sense to leverage it to keep your single journal available. It is very > intuitive and simple. > If order is not important, cluster with a second broker and allow > client to use either. > If order is important, consider using multiple brokers and > partitioning data across them[1]. In that way, you can always be > partially available. > > - Replica Pods > If you need two copies of your data, then you need replication, and > this is more involved. > With replication, there is synchronous copy. There are two overheads > to consider. > First, at runtime the broker responds when the *replica* gets the > message, which is usually trivial b/c of a fast network; but it is > important to be aware of. > Second, is the overhead of coordination on activation. Because there > are two copies of the journal, only one can be active at a time. > - as part of [2] we introduced coordinated activation via zk. I think > we probably need a kube version of this that layers over a crd or some > other etcd primitive. An operator could server the role of an oracle > here also. I note that the operator sdk provides a leader election > primitive [3] that may be perfect. The only issue may be permissions. > There will still be some necessary delay, lease expiration time etc.. > but it should be possible to make this time limited and bounded. There > is a bit of work to do here. > In short, having a replica pod should reduce time to recover but at a cost. > > After putting these thoughts down, I think the short answer is yes, in > kubernetes a single pod is currently best. It was a good question :-) > > feedback welcome! > I hope this helps, > gary. > > [1] > https://activemq.apache.org/components/artemis/documentation/latest/broker-balancers.html#data-gravity > [2] > https://activemq.apache.org/components/artemis/documentation/latest/ha.html#Pluggable-Quorum-Vote-Replication-configurations > [3] https://github.com/operator-framework/operator-sdk/issues/784 >
