OpenStack Reference Architecture
Page last updated:
This topic describes a reference architecture for Pivotal Platform on OpenStack. This architecture is valid for most production-grade Pivotal Platform deployments in a single project using three availability zones (AZs).
For general requirements for running Pivotal Platform and specific requirements for running Pivotal Platform on OpenStack, see OpenStack on Pivotal Platform Requirements.
A Pivotal Platform reference architecture describes a proven approach for deploying Pivotal Platform on a specific IaaS, such as OpenStack, that meets these requirements:
- Includes common Pivotal Platform-managed services such as MySQL, RabbitMQ, and Spring Cloud Services
- Can host at least 100 app instances
Pivotal provides reference architectures to help you determine the best configuration for your Pivotal Platform deployment.
The diagram below illustrates a reference architecture of a deployment of Pivotal Platform on OpenStack using three AZs.
The table below lists the components that are part of a base reference architecture deployment on OpenStack with three AZs.
|Component||Reference Architecture Notes|
|Domains and DNS||Domain zones and routes in use by the reference architecture include:
|Ops Manager||Deployed on the infrastructure network and accessible by fully-qualified domain name (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 topic.|
|SSH Load Balancer||Optional. Load balancer that provides SSH access to app containers for developers. Load balancers are outside the scope of this topic.|
|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.|
|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||VMware recommends two service accounts: one for OpenStack “paving,” and the other for Ops Manager and BOSH.
|OpenStack Quota||The default compute quota on a new OpenStack subscription is typically not enough to host a multi-AZ deployment. VMware recommends a quota of 100 for instances. Your OpenStack network quotas may also need to be increased.|
The table below 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 Pivotal Platform deployment exists within a single project and a single OpenStack region, but should distribute Pivotal Platform jobs and instances across three OpenStack AZs to ensure high availability.||1|
|Networks||The reference architecture requires these 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 table below describes the Security Group ingress rules:
|Load Balancers||Pivotal Platform on OpenStack requires a load balancer, which can be configured with multiple listeners to forward HTTP, HTTPS, and TCP traffic. VMware recommends two load balancers: one to forward the traffic to the Gorouters,
The table below 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|