Networking for On-Demand Services
This section describes networking considerations for Pivotal Cloud Cache.
When you deploy , you must create a statically defined network to host the component virtual machines that constitute the infrastructure.
components, like the Cloud Controller and UAA, run on this infrastructure network. On-demand services may require that you host them on a network that runs separately from the default network. You can also deploy tiles on separate service networks to meet your own security requirement.
v2.1 and later include dynamic networking. Operators can use this dynamic networking with asynchronous service provisioning to define dynamically-provisioned service networks. For more information, see Default Network and Service Network.
In v2.1 and later, on-demand services are enabled by default on all networks. Operators can create separate networks to host services in BOSH Director, but doing so is optional. Operators select which network hosts on-demand service instances when they configure the tile for that service.
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 app 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.
Before deploying a service tile that uses the on-demand service broker (ODB), request the needed network connections to allow components of to communicate with ODB.
The specifics of how to open those connections varies for each IaaS.
See the following table for key components and their responsibilities in an on-demand architecture.
|Key Components||Their Responsibilities|
|BOSH Director||Creates and updates service instances as instructed by ODB.|
|BOSH Agent||Includes an agent on every VM that it deploys. The agent listens for instructions from the BOSH Director and carries out 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.|
|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 Pivotal Platform service instance runs the Redis for Pivotal Platform 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|
|PCC cluster members||PCC cluster members||49152-65535||Two-way||Inclusive range. PCC servers and locators communicate with each other using UDP and TCP.|
|PCC Service Instance 1||PCC Service Instance 2||5000-5499||Two-way||Inclusive range. Gateway receivers and gateway senders communicate across WAN-separated service instances. Each PCC service instance uses GemFire defaults for the gateway receiver ports.|
||One-way||The BOSH Director and BOSH UAA default ports are not configurable.
The CredHub default port is configurable.
|ODB||PAS||8443||One-way||The default port is not configurable.|
||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||Deployed service instances||
||Two-way||These port numbers are not configurable.|
||8080||One-way||PAS communicates with service instances because the Gorouter proxies gfsh requests to GemFire clusters.|
PCC service instances running within distinct PCF foundations may communicate with each other across a WAN. In a topology such as this, the members within one service instance use their own private address space, as defined in RFC1918.
A VPN may be used to connect the private network spaces that lay across the WAN. The steps required to enable the connectivity by VPN are dependent on the IaaS provider(s).
The private address space for each service instance’s network must be configured with non-overlapping CIDR blocks. Configure the network prior to creating service instances. Locate directions for creating a network on the appropriate IAAS provider within the section titled Architecture and Installation Overview.