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).
See OpenStack on PCF Requirements for general requirements for running PCF and specific requirements for running PCF on OpenStack.
A PCF reference architecture describes a proven approach for deploying Pivotal Cloud Foundry on a specific IaaS, such as OpenStack, that meets the following requirements:
- Includes common PCF-managed services such as MySQL, RabbitMQ, and Spring Cloud Services
- Can host at least 100 app instances, or far more
Pivotal provides reference architectures to help you determine the best configuration for your PCF deployment.
The following diagram provides an overview of a reference architecture deployment of PCF on OpenStack using three AZs.
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 Gorouters. 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 Pivotal Application Service (PAS) 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 PAS network, one per AZ.|
|TCP Routers||Optional feature for TCP routing. Deployed on the PAS network, one per AZ.|
|CF Database||Reference architecture uses internal MySQL.|
|Storage Buckets||Reference architecture uses customer provided blobstore. Buckets are needed for BOSH and PAS.|
|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 IP addresses||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 address. In these cases, you can SSH into Ops Manager or any other component through the jumpbox.||1|