Understanding the Effects of Single Components on a Pivotal Cloud Foundry Upgrade
Page last updated:
The Resource Config page of Pivotal Application Service (PAS) tile in the Pivotal Cloud Foundry (PCF) Ops Manager shows the components that the BOSH 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.|
|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|
|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.|
|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.|
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.|
|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|
|26||Push Notifications UI|
|28||Register Autoscaling Service Broker|
|29||Destroy Autoscaling Service Broker|
|31||Push Pivotal Account|
|32||MySQL Rejoin Unsafe Errand|