Reference Architecture for Pivotal Cloud Foundry on OpenStack
Page last updated:
This guide presents a reference architecture for Pivotal Cloud Foundry (PCF) on OpenStack. This architecture is valid for most production-grade PCF deployments in a single project using three availability zones (AZs).
The following diagram provides an overview of a reference architecture deployment of PCF on OpenStack using three AZs.
To view a larger version of this diagram, click here.
The following table lists the components that are part of a base reference architecture deployment on OpenStack with three AZs.
|Component||Reference Architecture Notes|
|Domains & DNS||CF Domain zones and routes in use by the reference architecture include:
|Ops Manager||Deployed on the infrastructure network and accessible by FQDN or through an optional Jumpbox.|
|BOSH Director||Deployed on the infrastructure network.|
|Application Load Balancer||Required. Load balancer that handles incoming HTTP, HTTPS, TCP, and SSL traffic and forwards them to the Gorouter(s). Load balancers are outside the scope of this document.|
|SSH Load Balancer||Optional. Load balancer that provides SSH access to application containers for developers. Load balancers are outside the scope of this document.|
|Gorouters||Accessed through the Application Load Balancer. Deployed on the ERT network, one per AZ.|
|Diego Brains||This component is required. However, the SSH container access functionality is optional and enabled through the SSH Load Balancers. Deployed on the ERT network, one per AZ.|
|TCP Routers||Optional feature for TCP routing. Deployed on the ERT network, one per AZ.|
|CF Database||Reference architecture uses internal MySQL.|
|Storage Buckets||Reference architecture uses customer provided blobstore. Buckets are needed for BOSH & Elastic Runtime.|
|Service Tiles||Deployed on the services network.|
|Service Accounts||Two service accounts are recommended: one for OpenStack “paving,” and the other for Ops Manager and BOSH. Consult the following list:
|OpenStack Quota||The default compute quota on a new OpenStack subscription is typically not enough to host a multi-AZ deployment. The recommended quota for instances is 100. Your OpenStack network quotas may also need to be increased.|
The following table lists the network objects in this reference architecture.
|Network Object||Notes||Estimated Number|
|Floating IPs||Two per deployment, one assigned to Ops Manager, the other to your Jumpbox.||2|
|Project||One per deployment. A PCF deployment exists within a single project and a single OpenStack region, but should distribute PCF jobs and instances across three OpenStack AZs to ensure a high degree of availability.||1|
|Networks||The reference architecture requires the following Tenant Networks:
Note: In many cases, the public network is an “under the cloud” network that is shared across projects.
|Routers||This reference architecture requires one router attached to all networks:
|Security Groups||The reference architecture requires one Security Groups. The following table describes the Security Group ingress rules:
|Load Balancers||PCF on OpenStack requires a load balancer, which can be configured with multiple listeners to forward HTTP/HTTPS/TCP traffic. Two load balancers are recommended: one to forward the traffic to the Gorouters,
The following table describes the required listeners for each load balancer:
Note: In many cases, the load balancers are provided as an “under the cloud” service that is shared across projects.
|Jumpbox||Optional. Provides a way of accessing different network components. For example, you can configure it with your own permissions and then set it up to access to Pivotal Network to download tiles. Using a Jumpbox is particularly useful in IaaSes where Ops Manager does not have a public IP. In these cases, you can SSH into Ops Manager or any other component through the Jumpbox.||1|