RabbitMQ for PCF v1.11

On-Demand Service Architecture

This topic describes the architecture for on-demand RabbitMQ® for Pivotal Cloud Foundry (PCF).

For information about architecture of the older, pre-provisioned service, see Deploying the RabbitMQ® Service.

Service Network Requirement

When you deploy PCF, you must create a statically defined network to host the component virtual machines that constitute the PCF infrastructure.

PCF components, like the Cloud Controller and UAA, run on this infrastructure network. In PCF v2.0 and earlier, on-demand PCF services require that you host them on a network that runs separately from this network.

Cloud operators pre-provision service instances from Ops Manager. Then, for each service, Ops Manager allocates and recovers static IP addresses from a pre-defined block of addresses.

To enable on-demand services in PCF v2.0 and earlier, operators must create a service networks in Ops Manager Director and select the Service Network checkbox. Operators then can select the service network to host on-demand service instances when they configure the tile for that service.

Default Network and Service Network

On-demand PCF services rely on the BOSH 2.0 ability to dynamically deploy VMs in a dedicated network. The on-demand service broker uses this capability to create single-tenant service instances in a dedicated service network.

On-demand services use the dynamically-provisioned service network to host the single-tenant worker VMs that run as service instances within development spaces. This architecture lets developers provision IaaS resources for their service instances at creation time, rather than the operator pre-provisioning a fixed quantity of IaaS resources when they deploy the service broker.

By making services single-tenant, where each instance runs on a dedicated VM rather than sharing VMs with unrelated processes, on-demand services eliminate the “noisy neighbor” problem when one application hogs resources on a shared cluster. Single-tenant services can also support regulatory compliance where sensitive data must be compartmentalized across separate machines.

An on-demand service splits its operations between the default network and the service network. Shared components of the service, such as executive controllers and databases, run centrally on the default network along with the Cloud Controller, UAA, and other PCF components. The worker pool deployed to specific spaces runs on the service network.

The diagram below shows worker VMs in an on-demand service instance running on a separate services network, while other components run on the default network.

ODB Architecture

Required Networking Rules for On-Demand Services

Prior to deploying any service tile that uses the on-demand broker (ODB), the operator must request the network connections needed to allow various components of Pivotal Cloud Foundry (PCF) to communicate with ODB. The specifics of how to open those connections varies for each IaaS.

The following table shows the responsibilities of the key components in an on-demand architecture.

Key Components Their Responsibility
BOSH Director Creates and updates service instances as instructed by ODB
BOSH Agent BOSH includes an Agent on every VM that it deploys. The Agent listens for instructions from the Director and carries out those instructions. The Agent receives job specifications from the Director and uses them to assign a role, or Job, to the VM.
BOSH UAA As an OAuth2 provider, BOSH UAA issues tokens for clients to use when they act on behalf of BOSH users.
ERT Contains the apps that are consuming services
ODB Instructs BOSH to create and update services, and connects to services to create bindings
Deployed service instance Runs the given data service (for example, the deployed Redis for PCF service instance runs the Redis for PCF data service)

Regardless of the specific network layout, the operator must ensure network rules are set up so that connections are open as described in the table below.

This component… Must communicate with… Default TCP Port Communication direction(s) Notes
  • BOSH Director
  • 25555
  • 8443
One-way The default ports are not configurable.
ODB Deployed service instances 15672 (RabbitMQ Management UI) One-way This connection is for administrative tasks. Avoid opening general use, app-specific ports for this connection.
ODB PAS (or Elastic Runtime) 8443 One-way The default port is not configurable.
Errand VMs
  • PAS (or Elastic Runtime)
  • ODB
  • Deployed Service Instances
  • 8443
  • 8080
  • 15672 (RabbitMQ Management UI)
  • 5671-2 (AMQP/AMQPS)
One-way The default port is not configurable.
BOSH Agent BOSH Director 4222 Two-way 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.
Deployed apps on PAS (or Elastic Runtime) Deployed service instances
  • 15672 (RabbitMQ Management UI)
  • 5671-2 (AMQP/AMQPS)
  • 61613-4 (STOMP/STOMPS)
  • 1883, 8883 (MQTT/MQTTS)
One-way This connection is for general use, app-specific tasks. Avoid opening administrative ports for this connection.
PAS (or Elastic Runtime) ODB 8080 One-way This port may be different for individual services. This port may also be configurable by the operator if allowed by the tile developer.
Create a pull request or raise an issue on the source for this page in GitHub