Service-Gateway Access

Note: Pivotal Platform is now part of VMware Tanzu. In v1.20 and later, VMware Tanzu RabbitMQ [VMs] is named VMware Tanzu RabbitMQ for VMs.

Service-gateway access enables a VMware Tanzu RabbitMQ for VMs on-demand service instance to connect to external components that are not on the same foundation as the service instance. These components could be on another foundation or hosted outside of the foundation.

For related procedures, see:

Note: Service-gateway access is no longer in the beta stage. It works with Advanced Message Queuing Protocol (AMQP), MQ Telemetry Transport (MQTT), Simple (or Streaming) Text Orientated Messaging Protocol (STOMP), STOMP over a WebSocket connection (Web STOMP), and AMQP 1.0.

Overview

There are multiple use cases for service-gateway access. For example:

  • Accessing RabbitMQ from apps deployed to VMware Tanzu Application Service for VMs (TAS for VMs) in a different foundation
  • Replicating messages between RabbitMQ clusters in different foundations, for example, to set up federation for disaster recovery
  • Enabling apps running outside the foundation to communicate, through RabbitMQ, with TAS for VMs-deployed apps
  • Using RabbitMQ as a service for apps that are not deployed to TAS for VMs

Architecture

Service-gateway access to Tanzu RabbitMQ instances leverages the TCP router in TAS for VMs.

Any RabbitMQ requests that an app makes are forwarded through DNS to a load balancer that can route traffic from outside to inside the foundation. This load balancer opens a range of ports that are reserved for RabbitMQ traffic. When an app developer creates a service instance on a plan with service-gateway access enabled, a port from the range is provisioned for that service instance. The load balancer then forwards the requests for this Tanzu RabbitMQ service instance to the TCP router. The TCP router internally load balances between the Tanzu RabbitMQ service instance nodes.

The diagram below shows how the traffic is routed from apps to the RabbitMQ nodes in this case. All apps using this Tanzu RabbitMQ service instance follow the same route, irrespective of whether they are hosted on the foundation or are hosted outside of the foundation.

Diagram showing an app that is external to the foundation sending traffic to the external load balancer. The load balancer sends the traffic to a RabbitMQ tile port in the TCP router. The TCP router is inside the foundation. The TCP router balances the load among the RabbitMQ nodes in the RabbitMQ service instance.

Was this helpful?
What can we do to improve?