Does this mean that I we have to plan for a possible future topology in 
advance? As far as I understand, we won't be able to add more DNS names once 
these external clients are deployed.

If static connectors with disabled topology are the only option I'm thinking to 
create 6 or maybe even 12 external DNS names which at the moment would resolve 
to the same 2 IP addresses our cluster currently uses. All external clients 
will be preconfigured with these DNS names. Later, when we will need to 
increase node count, we just add new node and adjust DNS accordingly. Does this 
sound like a feasible plan?

-- 
    Vilius

-----Original Message-----
From: Domenico Francesco Bruscino <bruscin...@gmail.com> 
Sent: Tuesday, January 4, 2022 8:02 PM
To: users@activemq.apache.org
Subject: Re: Artemis cluster topology and external clients

Hi Vilius,

the clients should disable topology for load balancing and use static 
connectors, i.e.

(tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false

Regards,
Domenico

On Mon, 3 Jan 2022 at 10:00, Vilius Šumskas <v.sums...@advantes.tech.invalid>
wrote:

> Hello list,
>
> we are trying to use Artemis HA shared storage cluster which our SaaS 
> application. In addition to consumers/producers internal to SaaS 
> application itself, we also have thousands of external 
> consumers/producers which are installed on client’s premises .
>
> As broadcast is not possible on Google Cloud we are using static 
> discovery configuration with these connectors:
>
>     <connectors>
>         <!-- Connector used to be announced through cluster 
> connections and notifications -->
>         <connector
> name="artemis-master">tcp://internal-cluster-dns-1:61616</connector>
>         <connector
> name="artemis-slave">tcp://internal-cluster-dns2:61616</connector>
>     </connectors>
>
> Our acceptors are also configured to use internal DNS of the hosts on 
> both cluster nodes:
>
> <acceptor
> name="artemis">tcp://internal-cluster-dns-1:61616?tcpSendBufferSize=10
> 48576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;prot
> ocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=
> 10
>
> 00;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=fals
> e;suppressInternalManagementObjects=false</acceptor>
>
> We don’t have issues with internal consumers/producers, however when 
> we try to connect external consumers (via external IP), they are 
> trying to connect via internal DNS which is probably set in the 
> cluster topology packet.
>
> This is probably expected and by design, but my question is how do we 
> correctly handle such case? We obviously do not want internal clients 
> to be served via external IP because external traffic is expensive in 
> the cloud and the performance would decrease dramatically. Even with 
> static discovery we would like to have a possibility to expand our 
> cluster in the future, i.e. use the topology so that clients are configured 
> automatically.
>
> Do we need to have a split-DNS server so that external and internal 
> clients will see different IP addresses? Or maybe it is possible to 
> have the same node serving different acceptors on different ports and 
> different DNS names?
>
> Any pointers are much appreciated.
>
> --
>    Best Regards,
>
>     Vilius Šumskas
>     Advantes technologies
>     IT manager
>     +370 614 75713
>
>

Reply via email to