This section describes networking considerations for VMware Tanzu GemFire for VMs.
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. Operators can use dynamic networking with asynchronous service provisioning to define dynamically-provisioned service networks. For more information, see Default Network and Service Network below.
On-demand services are enabled by default on all networks. Operators can optionally create separate networks to host services in BOSH Director. Operators can select which network hosts on-demand service instances when they configure the tile for that service.
On-demand 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:
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 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), 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.|
|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 GemFire for VMs service instance runs the service.|
|This component...||Must communicate with...||Default TCP Port||Communication directions||Notes|
|GemFire for VMs cluster members||GemFire for VMs cluster members||49152-65535||Two-way||Inclusive range. GemFire for VMs servers and locators communicate with each other using UDP and TCP.|
|GemFire for VMs Service Instance 1||GemFire for VMs Service Instance 2||5000-5499||Two-way||Inclusive range. Gateway receivers and gateway senders communicate across WAN-separated service instances. Each GemFire for VMs service instance uses cluster 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||VMware Tanzu Application Service for VMs||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 VMware Tanzu Application Service for VMs||Deployed service instances||
||Two-way||These port numbers are not configurable.|
|Deployed apps on VMware Tanzu Application Service for VMs using GemFire for Redis Apps||Deployed service instances||6379||Two-way||There is no separate port for TLS. When TLS is enabled for the service instance this port will also be configured for TLS and all Redis communication (clients) must use TLS.|
|VMware Tanzu Application Service for VMs||
||8080||One-way||PAS communicates with service instances because the Gorouter proxies gfsh requests to clusters.|
|GemFire for VMs||GemFire for VMs||1053||Two-way||Allows DNS resolution for clusters communicating across a WAN-connected system.|
GemFire for VMs service instances running within distinct VMware Tanzu Application Service for VMs 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 providers.
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 in Platform Architecture and Planning Overview in the VMware Tanzu Ops Manager documentation.
1053 to allow DNS resolution of other WAN-connected clusters.