You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by André van der Heijden <va...@gmail.com> on 2021/03/09 19:47:51 UTC

Inter-cloud linkrouting (over TLS route)

Dear qpid developers,

I am wondering if it's possible to use linkrouting when you connect a mesh
in ZoneA (for example in Azure) to a mesh in ZoneB (for example in AWS). We
have established such a network and connect the two meshes via a connector
that looks like this:

connector {
    name: remote-amq-mesh
    host: zone-b.example.azure.address.io
    port: 443
    saslMechanisms: EXTERNAL PLAIN

    sslProfile: client_tls
    saslUsername: remote_connection@amq-interconnect-mesh
    saslPassword: *****

    role: route-container
    verifyHostname: false
    idleTimeoutSeconds: 0
    messageLoggingComponents: all
}

When trying to connect to an address:queue that is in the other Zone and is
exposed via linkrouting, we get the following error:

java.util.concurrent.ExecutionException:
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)

So at first sight, it seems that the above solution isn't working and we
cannot use linkrouting in a inter-cloud setup with the meshes connected
over a TLS route. Do you think this is plausible or do you have other
experiences?

If the above is indeed impossible, would creating some routes that expose
AMQPS directly between different cloud environments, so that we can connect
the meshes inter-cloud via AMQPS directly be a good idea? Are there any
obvious downsides to this approach?

Thanks a lot for your time.

Kind regards,

André van der Heijden

Re: Inter-cloud linkrouting (over TLS route)

Posted by André van der Heijden <va...@gmail.com>.
Hi Ted,

Thanks for your response, the problem has been solved. You were right
indeed about the need for setting up linkRoutes in _both_zones. I will
further clarify the initial problem and what we did wrong, so that others
reading this might benefit. The setup we have looks like:

   - Azure
      - Mesh (connected via route-container connector to AWS mesh)
      - Edge
   - AWS
      - Mesh
      - Edge --> Broker

So what we were trying to do is:

   - produce messages to the AWS broker to an address
   *called telemetry.example*
   - consume from this address by consuming via the Azure Edge router that
   would ultimately establish a link with the AWS Broker via linkRouting.
   - The reason we want to use linkRouting is that we want to create a
   durable consumer for multiple clients.
      - In our case to consume we subscribe to topics like
*telemetry.example::sub1
      *and *telemetry.example::sub2* and so on.
      - In this way each consumer would get its own dedicated queue on the
      AWS Edge broker

In order to achieve this we had set up linkroutes from the AWS Edge --> AWS
Broker like:











*linkRoute { prefix: telemetry direction: in connection:
edge-amq-broker}linkRoute { prefix: telemetry direction: out connection:
edge-amq-broker }*

However, with only this config it didn't work. The culprit was that we also
needed linkRoutes setup for the *telemetry *prefix between:

   - AWS Mesh <---> AWS Edge
   - Azure Mesh <---> AWS Edge

Thanks for your help again.

Kind regards,

André van der Heijden


Op di 9 mrt. 2021 om 21:15 schreef Ted Ross <tr...@apache.org>:

> Hi Andre,
>
> I'm not very clear on exactly what you're trying to do, but a few thoughts
> and questions come to mind.
>
> Did you consider joining the two zones into a single network using an
> inter-router connection instead of a route-container connection?  This
> would provide link-route access from both zones to your destinations.
>
> Assuming you have good reasons for using a route-container connection
> between the zones:
>
> Does your remote-amq-mesh connection successfully connect?
>
> If so, did you create a link-route configuration in _both_ zones?
>
> I don't believe that the router normally issues an "amqp:not-found" error.
> Is it possible that the "address:queue" node does not exist on your
> destination and that your destination (broker?) is issuing the error?
>
> -Ted
>
> On Tue, Mar 9, 2021 at 2:48 PM André van der Heijden <
> vanderheijden86@gmail.com> wrote:
>
> > Dear qpid developers,
> >
> > I am wondering if it's possible to use linkrouting when you connect a
> mesh
> > in ZoneA (for example in Azure) to a mesh in ZoneB (for example in AWS).
> We
> > have established such a network and connect the two meshes via a
> connector
> > that looks like this:
> >
> > connector {
> >     name: remote-amq-mesh
> >     host: zone-b.example.azure.address.io
> >     port: 443
> >     saslMechanisms: EXTERNAL PLAIN
> >
> >     sslProfile: client_tls
> >     saslUsername: remote_connection@amq-interconnect-mesh
> >     saslPassword: *****
> >
> >     role: route-container
> >     verifyHostname: false
> >     idleTimeoutSeconds: 0
> >     messageLoggingComponents: all
> > }
> >
> > When trying to connect to an address:queue that is in the other Zone and
> is
> > exposed via linkrouting, we get the following error:
> >
> > java.util.concurrent.ExecutionException:
> > javax.jms.InvalidDestinationException: Node not found [condition =
> > amqp:not-found]
> > at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> > at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> >
> > So at first sight, it seems that the above solution isn't working and we
> > cannot use linkrouting in a inter-cloud setup with the meshes connected
> > over a TLS route. Do you think this is plausible or do you have other
> > experiences?
> >
> > If the above is indeed impossible, would creating some routes that expose
> > AMQPS directly between different cloud environments, so that we can
> connect
> > the meshes inter-cloud via AMQPS directly be a good idea? Are there any
> > obvious downsides to this approach?
> >
> > Thanks a lot for your time.
> >
> > Kind regards,
> >
> > André van der Heijden
> >
>

Re: Inter-cloud linkrouting (over TLS route)

Posted by Ted Ross <tr...@apache.org>.
Hi Andre,

I'm not very clear on exactly what you're trying to do, but a few thoughts
and questions come to mind.

Did you consider joining the two zones into a single network using an
inter-router connection instead of a route-container connection?  This
would provide link-route access from both zones to your destinations.

Assuming you have good reasons for using a route-container connection
between the zones:

Does your remote-amq-mesh connection successfully connect?

If so, did you create a link-route configuration in _both_ zones?

I don't believe that the router normally issues an "amqp:not-found" error.
Is it possible that the "address:queue" node does not exist on your
destination and that your destination (broker?) is issuing the error?

-Ted

On Tue, Mar 9, 2021 at 2:48 PM André van der Heijden <
vanderheijden86@gmail.com> wrote:

> Dear qpid developers,
>
> I am wondering if it's possible to use linkrouting when you connect a mesh
> in ZoneA (for example in Azure) to a mesh in ZoneB (for example in AWS). We
> have established such a network and connect the two meshes via a connector
> that looks like this:
>
> connector {
>     name: remote-amq-mesh
>     host: zone-b.example.azure.address.io
>     port: 443
>     saslMechanisms: EXTERNAL PLAIN
>
>     sslProfile: client_tls
>     saslUsername: remote_connection@amq-interconnect-mesh
>     saslPassword: *****
>
>     role: route-container
>     verifyHostname: false
>     idleTimeoutSeconds: 0
>     messageLoggingComponents: all
> }
>
> When trying to connect to an address:queue that is in the other Zone and is
> exposed via linkrouting, we get the following error:
>
> java.util.concurrent.ExecutionException:
> javax.jms.InvalidDestinationException: Node not found [condition =
> amqp:not-found]
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>
> So at first sight, it seems that the above solution isn't working and we
> cannot use linkrouting in a inter-cloud setup with the meshes connected
> over a TLS route. Do you think this is plausible or do you have other
> experiences?
>
> If the above is indeed impossible, would creating some routes that expose
> AMQPS directly between different cloud environments, so that we can connect
> the meshes inter-cloud via AMQPS directly be a good idea? Are there any
> obvious downsides to this approach?
>
> Thanks a lot for your time.
>
> Kind regards,
>
> André van der Heijden
>