This topic tells you about the architecture for on-demand VMware Tanzu RabbitMQ for Tanzu Application Service.
For information about architecture of the older, pre-provisioned service, see Deploying the Tanzu RabbitMQ for Tanzu Application Service Service.
Service Network Requirement
When you deploy VMware Tanzu Application Service for VMs (TAS for VMs), you must create a statically defined network to host the component VMs that make up the infrastructure. Components, such as Cloud Controller and UAA, run on this infrastructure network.
On-Demand services might require you to host them on a separate network from the default network. You can also deploy on-demand services on a separate service networks to meet your own security requirements.
TAS for VMs supports dynamic networking. You can use dynamic networking with asynchronous service provisioning to define dynamically-provisioned service networks. For more information, see Default network and service network.
On-Demand services are enabled by default on all networks. You can create separate networks to host services in BOSH Director, if required. You can select which network hosts on-demand service instances when you configure the tile for that service.
Default Network and Service Network
On-Demand Tanzu RabbitMQ for Tanzu Application Service services use BOSH to dynamically deploy VMs and create single-tenant service instances in a dedicated network. On-Demand services use the dynamically-provisioned service network to host single-tenant worker VMs. These worker VMs run as service instances within development spaces.
This on-demand architecture has the following advantages:
- Developers can provision IaaS resources for their services instances when the instances are created. This removes the need for operators to pre-provision a fixed amount of IaaS resources when they deploy the service broker.
- Service instances run on a dedicated VM and do not share VMs with unrelated processes. This removes the "noisy neighbor" problem, where an app monopolizes resources on a shared cluster.
- Single-tenant services can support regulatory compliances where sensitive data must be separated across different machines.
An on-demand service separates operations between the default network and the service network. Shared service components, such as executive controllers and databases, Cloud Controller, UAA, and other on-demand components, run on the default network. Worker pools deployed to specific spaces run on the service network.
The diagram shows worker VMs in an on-demand service instance running on a separate services network, while other components run on the default network.
Required Networking Rules for On-Demand Services
Before deploying a service tile that uses the on-demand service broker (ODB), you must create networking rules to enable components to communicate with ODB. For instructions for creating networking rules, see the documentation for your IaaS.
The following table lists key components and their responsibilities in the on-demand architecture.
| Key Components | Component Responsibilities |
|---|---|
| BOSH Director | Creates and updates service instances as instructed by ODB. |
| BOSH Agent | Adds an agent on every VM that it deploys. The agent listens for instructions from the BOSH Director and executes those instructions. The agent receives job specifications from the BOSH Director and uses them to assign a role or job to the VM. |
| BOSH UAA | Issues OAuth2 tokens for clients to use when they act on behalf of BOSH users. |
| VMware Tanzu Application Service for VMs | Contains the apps that consume services. |
| ODB | Instructs BOSH to create and update services. Connects to services to create bindings. |
| Deployed service instance | Runs the given service. For example, a deployed Tanzu RabbitMQ for Tanzu Application Service service instance runs the Tanzu RabbitMQ for Tanzu Application Service service. |
Regardless of the specific network layout, the operator must set up network rules so that connections are open as described in the following table.
| Source Component | Destination Component | Default TCP Port | Notes |
|---|---|---|---|
| ODB | BOSH Director BOSH UAA |
25555 (BOSH Director) 8443 (UAA) 8844 (CredHub) |
The default ports are not configurable. |
| ODB | Deployed service instances | 15672 (RabbitMQ Management UI) 15671 (RabbitMQ Management UI over TLS) |
This connection is for administrative tasks. Avoid opening general use, app-specific ports for this connection. |
| ODB | VMware Tanzu Application Service for VMs (TAS for VMs) | 8443 (UAA) | The default port is not configurable. |
| Errand VMs | TAS for VMs ODB Deployed Service Instances |
8443 (UAA) 8080 15672 (RabbitMQ Management UI) 15671 (RabbitMQ Management UI over TLS) 5672 (AMQP) 5671 (AMQPS) |
The default port is not configurable. |
| BOSH Agent | BOSH Director | 4222 | The BOSH Agent runs on every VM in the system, including the BOSH Director VM. The BOSH Agent initiates the connection with the BOSH Director. The default port is not configurable. The communication between these components is two-way. |
| Deployed apps on TAS for VMs | Deployed service instances | 15672 (RabbitMQ Management UI) 15671 (RabbitMQ Management UI over TLS) 5672 (AMQP) 5671 (AMQPS) 61613 (STOMP) 61614 (STOMPS) 15674 (Web STOMP) 15673 (Web STOMPS) 1883 (MQTT) 8883 (MQTTS) 15675 (Web MQTT) 15676 (Web MQTTS) |
This connection is for general use, app-specific tasks. Avoid opening administrative ports for this connection. |
| TAS for VMs | ODB | 8080 | This port might be different for individual services. This port might also be configurable by the operator if allowed by the tile developer. |
| Deployed apps on TAS for VMs | Runtime CredHub | 8844 (CredHub) | This port is needed if secure binding credentials are enabled. |
| TAS for VMs | Deployed service instances | 15692 (RabbitMQ Prometheus Plug-in) |
This connection is enables Prometheus to collect metrics from RabbitMQ nodes. For more information, see the RabbitMQ documentation. |
