LATEST VERSION: 1.10 - CHANGELOG
Pivotal Cloud Foundry v1.10

Understanding the Effects of Single Components on a Pivotal Cloud Foundry Upgrade

Page last updated:

The Resource Config page of Pivotal Elastic Runtime tile in the Pivotal Cloud Foundry (PCF) Ops Manager shows the components that the Ops Manager Director installs. You can specify the number of instances for some of the components. We deliver the remaining resources as single components, meaning that they have a preconfigured and unchangeable value of one instance.

In a single-component environment, upgrading can cause the deployment to experience downtime and other limitations because there is no instance redundancy. Although this behavior might be acceptable for a test environment, you should configure the scalable components with editable instance values, such as HAProxy, Router, and Diego cells, for optimal performance in a production environment.

Note: A full Ops Manager upgrade may take close to two hours, and you will have limited ability to deploy an application during this time.

Summary of Component Limitations

The table lists components in the order that Ops Manager upgrades each component and includes the following columns:

  • Scalable?: Indicates whether the component has an editable value or a preconfigured and unchangeable value of one instance.

    Note: For components marked with a checkmark in this column, we recommend that you change the preconfigured instance value of 1 to a value that best supports your production environment. For more information about scaling a deployment, refer to the Scaling Cloud Foundry topic.

  • Extended Downtime?: Indicates that if there is only one instance of the component, that component is unavailable for up to five minutes during an Ops Manager upgrade.
  • Other Limitations and Information: Provides the following information:
    • Component availability, behavior, and usage during an upgrade
    • Guidance on disabling the component before an upgrade

Note: The table does not include the Run Smoke Tests and Run CF Acceptance Tests errands and the Compilation job. Ops Manager runs the errands after it upgrades the components and creates compilation VMs as needed during the upgrade process.

Upgrade Order Component Scalable? Extended Downtime? Other Limitations and Information
1 Consul Many components rely upon Consul for service discovery. If Consul is unavailable, these components may fail in unexpected ways as they are not able to locate or communicate with other parts of the platform.
2 NATS
3 etcd Server Several components rely upon etcd for configuration and persistence. If etcd is unavailable, these components may fail in expected ways as they are not able to access their configuration or persisted data.
4 File Storage You cannot push, stage, or restart an app when an upgrade affects the file storage server.
5 MySQL Proxy The MySQL Proxy is responsible for managing failover of the MySQL Servers. If the Proxy becomes unavailable, then access to the MySQL Server could be broken.
6 MySQL Server The MySQL Server is responsible for persisting internal databases for the platform. If the MySQL Server becomes unavailable, then platform services that rely upon a database (Cloud Controller, UAA) will also become unavailable.
7 Backup Prepare Node
8 Cloud Controller Database (Postgres)
9 UAA Database (Postgres)
10 UAA If a user has an active authorization token prior to performing an upgrade, the user can still log in using either a UI or the CLI.
11 Cloud Controller Your ability to manage an app when an upgrade affects the Cloud Controller depends on the number of instances that you specify for the Cloud Controller and Diego components. If either of these components are single components, you cannot push, stage, or restart an app during the upgrade.
12 HAProxy HAProxy is used to load-balance incoming requests to the Router. If HAProxy is unavailable, you may lose the ability to make requests to applications unless there is another routing path from your load balancer to the Router.
13 Router The Router is responsible for routing requests to their application containers. If the Router is not available, then applications cannot receive requests.
14 MySQL Monitor
15 Clock Global
16 Cloud Controller Worker
17 Diego BBS Your ability to manage an app when an upgrade affects the Diego BBS depends on the number of instances that you specify for the Diego BBS, Cloud Controller, and other Diego components. If any of these components have only one instance, you may fail to push, stage, or restart an app during the upgrade.
18 Diego Brain Your ability to manage an app when an upgrade affects the Diego Brain depends on the number of instances that you specify for the Diego Brain, Cloud Controller, and other Diego components. If any of these components have only one instance, you may fail to push, stage, or restart an app during the upgrade.
19 Diego Cell Your ability to manage an app when an upgrade affects Diego Cells depends on the number of instances that you specify for the Diego Cells, Cloud Controller, and other Diego components. If any of these components have only one instance, you may fail to push, stage, or restart an app during the upgrade.
If you only have one Diego Cell, upgrading it causes downtime for the apps that run on it, including the Apps Manager app and the App Usage Service.
20 Doppler Server Ops Manager operators experience 2-5 minute gaps in logging.
21 Loggregator Trafficcontroller Ops Manager operators experience 2-5 minute gaps in logging.
22 TCP Router
23 Push Apps Manager errand This errand runs the script to deploy the Apps Manager application.
The Apps Manager application runs in a single Diego Cell.
24 Run Smoke Tests
25 Push Notifications
26 Push Notifications UI
27 Push Autoscaling
28 Register Autoscaling Service Broker
29 Destroy Autoscaling Service Broker
30 Bootstrap
31 Push Pivotal Account
32 MySQL Rejoin Unsafe Errand
Create a pull request or raise an issue on the source for this page in GitHub