Pivotal Cloud Foundry v1.9

Deploying Elastic Runtime on Azure

Page last updated:

This topic describes how to install and configure Elastic Runtime on Azure.

Before you perform the procedures in this topic, you must have completed the procedures in the Preparing to Deploy PCF on Azure topic, either the Launching an Ops Manager Director Instance with an ARM Template topic or the Launching an Ops Manager Director Instance on Azure without an ARM Template topic, and the Configuring Ops Manager Director on Azure topic.

Note: If you plan to install the PCF IPsec add-on, you must do so before installing any other tiles. Pivotal recommends installing IPsec immediately after Ops Manager, and before installing the Elastic Runtime tile.

Note: The Azure portal sometimes displays the names of resources with incorrect capitalization. Always use the Azure CLI to retrieve the correctly capitalized name of a resource.

Step 1: Add Elastic Runtime to Ops Manager

  1. Download Elastic Runtime from the Pivotal Network.

  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click Import a Product and select the downloaded .pivotal file. For more information, refer to the Adding and Deleting Products topic.

  4. Click the plus button next to the imported tile to add it to the Installation Dashboard.

    Add ert

  5. Click the Elastic Runtime tile in the Installation Dashboard.

    Er tile

Step 2: Assign Networks

  1. Select Assign Networks.

  2. From the Network dropdown menu, select the network on which you want to run Elastic Runtime.

    Assign networks

  3. Click Save.

Step 3: Configure Domains

  1. Select Domains.


  2. Enter the system and application domains.

    • The System Domain defines your target when you push apps to Elastic Runtime. For example,
    • The Apps Domain defines where Elastic Runtime should serve your apps. For example,

    Note: Pivotal recommends that you use the same domain name but different subdomain names for your system and app domains. Doing so allows you to use a single wildcard certificate for the domain while preventing apps from creating routes that overlap with system routes.

  3. Navigate to your DNS provider to create A records that point from your wildcard system and apps domains to the public IP address of your load balancer. For example, if the IP address of your load balancer is, then create an A record that points * to that address and another A record that points * to that address.

    Note: To retrieve the IP address of your load balancer, navigate to the Azure portal, click All resources, and click the Public IP address resource that ends with pcf-lb-ip.

  4. Click Save.

Step 4: Configure Networking

  1. Select Networking.

  2. Leave the Router IPs, SSH Proxy IPs, HAProxy IPs, and TCP Router IPs fields blank. You do not need to complete these fields when deploying PCF to Azure.

    Note: You specify load balancers in the Resource Config section of Elastic Runtime later on in the installation process. See the Configuring Resources section.

  3. Under Select one of the following point-of-entry options, select the Forward SSL to Elastic Runtime Router option. This sets the external Azure Load Balancer (ALB) you created as the point of entry for your environment.

  4. Complete the fields required to terminate SSL/TLS at the external ALB. For example, you must provide a SSL Certificate and Private Key. Ert lb encrypted certs
    For details on generating certificates for your wildcard system domains, see the Providing a Certificate for Your SSL/TLS Termination Point topic.

  5. If you are not using SSL encryption or if you are using self-signed certificates, select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Note: For production deployments, Pivotal does not recommend disabling SSL certificate verification.

  6. Select the Disable insecure cookies on the Router checkbox to set the secure flag for cookies generated by the router.

  7. To disable the addition of Zipkin tracing headers on the Gorouter, deselect the Enable Zipkin tracing headers on the router checkbox. Zipkin tracing headers are enabled by default. For more information about using Zipkin trace logging headers, see the Zipkin Tracing in HTTP Headers topic.

    Ert disable ssl cookies zipkin

  8. In the Choose whether or not to enable route services section, choose either Enable route services or Disable route services. Route services are a class of marketplace services that perform filtering or content transformation on application requests and responses. See the Route Services topic for details.

  9. The Loggregator Port defaults to 443 if left blank. Leave this field blank.

  10. (Optional) Use the Applications Subnet field if you need to avoid address collision with a third-party service on the same subnet as your apps. Enter a CIDR subnet mask specifying the range of available IP addresses assigned to your app containers. The IP range must be different from the network used by the system VMs.

  11. (Optional) You can change the value in the Applications Network Maximum Transmission Unit (MTU) field. Pivotal recommends setting the MTU value for your application network to 1454. Some configurations, such as networks that use GRE tunnels, may require a smaller MTU value.

    Ert log port mtu

  12. (Optional) Increase the number of seconds in the Router Timeout to Backends field to accommodate larger uploads over connections with high latency. Set this value to less than or equal to the idle timeout value of the Azure load balancer, which defaults to 4 minutes.

    Note: If the router timeout value exceeds the Azure LB timeout, you may experience intermittent TCP resets. For more information about configuring Azure load balancer idle timeout, see the Azure documentation.

  13. (Optional) Increase the value of Load Balancer Unhealthy Threshold to specify the amount of time, in seconds, that the router continues to accept connections before shutting down. During this period, healthchecks may report the router as unhealthy, which causes load balancers to failover to other routers. Set this value to an amount greater than or equal to the maximum time it takes your load balancer to consider a router instance unhealthy, given contiguous failed healthchecks.

  14. (Optional) Modify the value of Load Balancer Healthy Threshold. This field specifies the amount of time, in seconds, to wait until declaring the Router instance started. This allows an external load balancer time to register the Router instance as healthy.

    Router lb thresholds

  15. TCP Routing is disabled by default. To enable this feature, perform the following steps:

    1. Select the Enable TCP Routing radio button.
    2. In TCP Routing Ports, enter a range of ports to be allocated for TCP Routes.

      For each TCP route you want to support, you must reserve a range of ports. This is the same range of ports you configured your load balancer with in the Pre-Deployment Steps, unless you configured DNS to resolve the TCP domain name to the TCP router directly.

      The TCP Routing Ports field accepts a comma-delimited list of individual ports and ranges, for example 1024-1099,30000,60000-60099. Configuration of this field is only applied on the first deploy, and update updates to the port range are made using the cf CLI. For details about modifying the port range, see the Router Groups topic. Ert tcp routing enable

    3. For Azure, you also need to specify the name of Azure load balancer in the LOAD BALANCER column of TCP Router job of the Resource Config screen. You configure this later on in Elastic Runtime. See Configuring Resources.

  16. To disable TCP routing, select the Select this option if you prefer to enable TCP Routing at a later time radio button. For more information, see the Configuring TCP Routing in Elastic Runtime topic.

  17. Click Save.

Step 5: Configure Application Containers

  1. Select Application Containers.

    Er config app containers

  2. The Enable Custom Buildpacks checkbox governs the ability to pass a custom buildpack URL to the -b option of the cf push command. By default, this ability is enabled, letting developers use custom buildpacks when deploying apps. Disable this option by disabling the checkbox. For more information about custom buildpacks, refer to the buildpacks section of the PCF documentation.

  3. The Allow SSH access to app containers checkbox controls SSH access to application instances. Enable the checkbox to permit SSH access across your deployment, and disable it to prevent all SSH access. See the Application SSH Overview topic for information about SSH access permissions at the space and app scope.

  4. You can configure Elastic Runtime to run app instances in Docker containers by supplying their IP address range(s) in the Private Docker Insecure Registry Whitelist textbox. See the Using Docker Registries topic for more information.

  5. Select your preference for Docker Images Disk-Cleanup on Cell VMs. If you choose Clean up disk-space once threshold is reached, enter a Threshold of Disk-Used in megabytes.

  6. Click Save.

Step 6: Configure Application Developer Controls

  1. Select Application Developer Controls.

    Er17 config appdevctrl

  2. Enter your intended maximum file upload size.

  3. Enter your default RAM memory allocation per app.

  4. Enter your default total RAM memory (RAM) quota per Org. You can change this in the CLI.

  5. Enter your maximum and default disk quotas per app.

  6. Enter your default service instances quota per Org. You can change this in the CLI.

  7. Click Save.

Step 7: Review Application Security Group

Setting appropriate Application Security Groups is critical for a secure deployment. Type X in the box to acknowledge that once the Elastic Runtime deployment completes, you will review and set the appropriate application security groups. See Restricting App Access to Internal PCF Components for instructions.


Step 8: Configure Authentication and Enterprise SSO

  1. Select Authentication and Enterprise SSO.

    Er17 config authsso uaa

  2. To authenticate user sign-ons, your deployment can use one of three types of user database: the UAA server’s internal user store, an external SAML identity provider, or an external LDAP server.

    • To use the internal UAA, select the Internal option and follow the instructions in the Configuring UAA Password Policy topic to configure your password policy.
    • To connect to an external identity provider through SAML, scroll down to select the SAML Identity Provider option and follow the instructions in the Configuring PCF for SAML section of the Configuring Authentication and Enterprise SSO for Elastic Runtime topic.
    • To connect to an external LDAP server, scroll down to select the LDAP Server option and follow the instructions in the Configuring LDAP section of the Configuring Authentication and Enterprise SSO for Elastic Runtime topic.
  3. (Optional) In the Apps Manager Access Token Lifetime, Apps Manager Refresh Token Lifetime, Cloud Foundry CLI Access Token Lifetime, and Cloud Foundry CLI Refresh Token Lifetime fields, change the lifetimes of tokens granted for Apps Manager and Cloud Foundry Command Line Interface (cf CLI) login access and refresh. Most deployments use the defaults.

  4. (Optional) Customize the text prompts used for username and password from the cf CLI and Apps Manager login popup.

  5. (Optional) The Proxy IPs Regular Expression field contains a pipe-delimited set of regular expressions that UAA considers to be reverse proxy IP addresses. UAA respects the x-forwarded-for and x-forwarded-proto headers coming from IP addresses that match these regular expressions. To configure UAA to respond properly to Router or HAProxy requests coming from public IP address(es), append a regular expression or regular expressions to match the public IP address(es).

    Authsso uaa bottom

  6. Click Save.

Step 9: Configure System Databases

You can configure Elastic Runtime to use the internal MySQL database provided with PCF, or you can configure an external database provider for the databases required by Elastic Runtime.

Note: If you are performing an upgrade, do not modify your existing internal database configuration or you may lose data. You must migrate your existing data first before changing the configuration. Contact Pivotal Support for help. See Upgrading Pivotal Cloud Foundry for additional upgrade information.

Internal Database Configuration

If you want to use internal databases for your deployment, perform the following steps:

  1. Select Databases.

  2. Select Internal Databases - MySQL. Sys db

  3. Click Save.

Then proceed to Step 10: (Optional) Configure Internal MySQL to configure high availability and automatic backups for your internal MySQL databases.

External Database Configuration

Note: The exact procedure to create databases depends upon the database provider you select for your deployment. The following procedure uses AWS RDS as an example. You can configure a different database provider that provides MySQL support, such as Google Cloud SQL.

Warning: Protect whichever database you use in your deployment with a password.

To create your Elastic Runtime databases, perform the following steps:

  1. Add the ubuntu account key pair from your IaaS deployment to your local SSH profile so you can access the Ops Manager VM. For example, in AWS, you add a key pair created in AWS:

    ssh-add aws-keypair.pem
  2. SSH in to your Ops Manager using the Ops Manager FQDN and the username ubuntu:

    ssh ubuntu@OPS_MANAGER_FQDN
  3. Log in to your MySQL database instance using the appropriate hostname and user login values configured in your IaaS account. For example, to log in to your AWS RDS instance, run the following MySQL command:

    mysql --host=RDSHOSTNAME --user=RDSUSERNAME --password=RDSPASSWORD

  4. Run the following MySQL commands to create databases for the seven Elastic Runtime components that require a relational database:

    CREATE database uaa;
    CREATE database ccdb;
    CREATE database notifications;
    CREATE database autoscale;
    CREATE database app_usage_service;
    CREATE database routing;
    CREATE database diego;

  5. Type exit to quit the MySQL client, and exit again to close your connection to the Ops Manager VM.

  6. In Elastic Runtime, select Databases.

  7. Select the External Databases option.

    Sys db

  8. Complete the following fields in Elastic Runtime:

    Elastic Runtime Field Notes
    Hostname Specify the hostname of the database server.
    TCP Port Specify the port of the database server.
    DATABASE-NAME database username Specify a unique username that can access this specific database on the database server.
    DATABASE-NAME database password Specify a password for the provided username.

  9. Click Save.

Step 10: (Optional) Configure Internal MySQL

Note: You only need to configure this section if you have selected Internal Databases - MySQL in the Databases section.

  1. Select Internal MySQL.

  2. In the MySQL Proxy IPs field, enter one or more comma-delimited IP addresses that are not in the reserved CIDR range of your network. If a MySQL node fails, these proxies re-route connections to a healthy node. See the Proxy section of the MySQL for PCF topic for more information.

    Mysql config

  3. For MySQL Service Hostname, enter an IP address or hostname for your load balancer. If a MySQL proxy fails, the load balancer re-routes connections to a healthy proxy. If you leave this field blank, components are configured with the IP address of the first proxy instance entered above.

  4. In the Replication canary time period field, leave the default of 30 seconds or modify the value based on the needs of your deployment. Lower numbers cause the canary to run more frequently, which means that the canary reacts more quickly to replication failure but adds load to the database.

  5. In the Replication canary read delay field, leave the default of 20 seconds or modify the value based on the needs of your deployment. This field configures how long the canary waits, in seconds, before verifying that data is replicating across each MySQL node. Clusters under heavy load can experience a small replication lag as write-sets are committed across the nodes.

  6. (Required): In the E-mail address field, enter the email address where the MySQL service sends alerts when the cluster experiences a replication issue or when a node is not allowed to auto-rejoin the cluster.

    Mysql replication canary

  7. Under Automated Backups Configuration, choose one of three options for MySQL backups:

    • Disable automatic backups of MySQL
    • Enable automated backups from MySQL to an S3 bucket or other S3-compatible file store saves your backups to an existing Amazon Web Services (AWS) or Ceph S3-compatible blobstore. Mysql backups s3 This option requires the following fields:
      • For S3 Bucket Name, enter the name of your S3 bucket. Do not include an s3:// prefix, a trailing /, or underscores. If the bucket does not already exist, it will be created automatically.
      • For Bucket Path, specify a folder within the bucket to hold your MySQL backups. Do not include a trailing /.
      • For AWS Access Key ID and AWS Secret Access Key, enter your AWS or Ceph credentials.
      • For Cron Schedule, enter a valid cron expression to schedule your automated backups. Cron uses your computer’s local time zone.
    • Enable automated backups from MySQL to a remote host via SCP saves your backups to a remote host using secure copy protocol (SCP). Mysql backups scp This option requires the following fields:
      • For Hostname, enter the name of your SCP host.
      • For Port, enter your SCP port. This should be the TCP port that your SCP host uses for SSH. The default port is 22.
      • For Username, enter your SSH username for the SCP host.
      • For Private key, paste in your SSH private key.
      • For Destination directory, enter the directory on the SCP host where you want to save backup files.
      • For Cron Schedule, enter a valid cron expression to schedule your automated backups. Cron uses your computer’s local time zone.
      • Enable Backup All Nodes to make unique backups from each instance of the MySQL server rather than just the first MySQL server instance.

        Note: If you choose to enable automated MySQL backups, set the number of instances for the Backup Prepare Node under the Resource Config section of the Elastic Runtime tile to 0.

  8. If you want to log audit events for internal MySQL, select Enable server activity logging under Server Activity Logging.

    1. For the Event types field, you can enter the events you want the MySQL service to log. By default, this field includes connect and query, which tracks who connects to the system and what queries are processed. For more information, see the Logging Events section of the MariaDB documentation.

      Audit Event Logging Config

  9. Click Save.

Step 11: Configure File Storage

  1. Select File Storage.

  2. Select the Internal WebDAV option and click Save.

Step 12: (Optional) Configure System Logging

If you are forwarding logging messages to an external Reliable Event Logging Protocol (RELP) server, complete the following steps:

  1. Select System Logging. Sys logging
  2. If you want to include security events in your log stream, select the Enable Cloud Controller security event logging checkbox. This logs all API requests, including the endpoint, user, source IP address, and request result, in the Common Event Format (CEF).
  3. Enter the IP address of your syslog server in External Syslog Aggregator Hostname and its port in External Syslog Aggregator Port. The default port for a syslog server is 514.

    Note: The host must be reachable from the Elastic Runtime network, accept TCP connections, and use the RELP protocol. Ensure your syslog server listens on external interfaces.

  4. Select an External Syslog Network Protocol to use when forwarding logs.
  5. For the Syslog Drain Buffer Size, enter the number of messages the Doppler server can hold from Metron agents before the server starts to drop them. See the Loggregator Guide for Cloud Foundry Operators topic for more details.
  6. Click Save.

Step 13: (Optional) Customize Apps Manager

The Custom Branding and Apps Manager sections customize the appearance and functionality of Apps Manager. Refer to Custom Branding Apps Manager for descriptions of the fields on these pages and for more information about customizing Apps Manager.

  1. Select Custom Branding. Use this section to configure the text, colors, and images of the interface that developers see when they log in, create an account, reset their password, or use Apps Manager. Custombranding

  2. Click Save to save your settings in this section.

  3. Select Apps Manager. Use this section to configure page names and sidebar links in the Apps Manager and Marketplace pages. Config apps man

  4. Click Save to save your settings in this section.

Step 14: (Optional) Configure Email Notifications

Elastic Runtime uses SMTP to send invitations and confirmations to Apps Manager users. You must complete the Email Notifications page if you want to enable end-user self-registration.

  1. Select Email Notifications.


  2. Enter your reply-to and SMTP email information

  3. Verify your authentication requirements with your email administrator and use the SMTP Authentication Mechanism drop-down menu to select None, Plain, or CRAMMD5. If you have no SMTP authentication requirements, select None.

  4. Click Save.

Note: If you do not configure the SMTP settings using this form, the administrator must create orgs and users using the cf CLI. See Creating and Managing Users with the cf CLI for more information.

Step 15: (Optional) Add CCDB Restore Key

Perform this step if all of the following are true:

  • You deployed Elastic Runtime previously.
  • You then stopped Elastic Runtime or it crashed.
  • You are re-deploying Elastic Runtime with a backup of your Cloud Controller database.
  1. Click Restore CCDB Encryption Key.

  2. Enter your Cloud Controller DB Encryption Key.

Er18 config ccdb closeup

See Backing Up Pivotal Cloud Foundry for more information.

Step 16: Configure Smoke Tests

The Smoke Tests errand runs basic functionality tests against your Elastic Runtime deployment after an installation or update. In this section, choose where to run smoke tests. In the Errands section, you can choose whether or not to run the Smoke Tests errand.

  1. Select Smoke Tests.

  2. If you have a shared apps domain, select Temporary org and space, which creates an ad-hoc org and space for running smoke tests and deletes them afterwards. Otherwise, select Specified org and space and complete the fields to specify where you want to run smoke tests.

    Smoke test er config

  3. Click Save.

Step 17: (Optional) Enable Advanced Features

The Advanced Features section of Elastic Runtime includes new functionality that may have certain constraints. Although these features are fully supported, Pivotal recommends caution when using them in production environments.

Diego Cell Memory and Disk Overcommit

If your apps do not use the full allocation of disk space and memory set in the Resource Config tab, you might want use this feature. These fields control the amount to overcommit disk and memory resources to each Diego Cell VM.

For example, you might want to use the overcommit if your apps use a small amount of disk and memory capacity compared to the amounts set in the Resource Config settings for Diego Cell.

Note: Due to the risk of app failure and the deployment-specific nature of disk and memory use, Pivotal has no recommendation about how much, if any, memory or disk space to overcommit.

To enable overcommit, follow these steps:

  1. Select Advanced Features.

    Disk memory overcommit

  2. Enter the total desired amount of Diego cell memory value in the Cell Memory Capacity (MB) field. Refer to the Diego Cell row in the Resource Config tab for the current Cell memory capacity settings that this field overrides.

  3. Enter the total desired amount of Diego cell disk capacity value in the Cell Disk Capacity (MB) field. Refer to the Diego Cell row in the Resource Config tab for the current Cell disk capacity settings that this field overrides.

  4. Click Save.

Note: Entries made to each of these two fields set the total amount of resources allocated, not the overage.

Whitelist for Non-RFC-1918 Private Networks

Some private networks require extra configuration so that internal file storage (WebDAV) can communicate with other PCF processes.

The Whitelist for non-RFC-1918 Private Networks field is provided for deployments that use a non-RFC 1918 private network. This is typically a private network other than,, or

Most PCF deployments do not require any modifications to this field.

To add your private network to the whitelist, perform the following steps:

  1. Select Advanced Features.

  2. Append a new allow rule to the existing contents of the Whitelist for non-RFC-1918 Private Networks field. Nonrfc whitelist Include the word allow, the network CIDR range to allow, and a semi-colon (;) at the end. For example:


  3. Click Save.

CF CLI Connection Timeout

The CF CLI Connection Timeout field allows you to override the default five second timeout of the Cloud Foundry Command Line Interface (cf CLI) used within your PCF deployment. This timeout affects the cf CLI command used to push Elastic Runtime errand apps such as Notifications, Autoscaler, and Apps Manager.

Set the value of this field to a higher value, in seconds, if you are experiencing domain name resolution timeouts when pushing errands in Elastic Runtime.

To modify the value of the CF CLI Connection Timeout, perform the following steps:

  1. Select Advanced Features.

  2. Add a value, in seconds, to the CF CLI Connection Timeout field. Cf cli connection timeout

  3. Click Save.

Step 18: Configure Errands

Errands are scripts that Ops Manager runs to automate tasks. By default, Ops Manager runs the post-install errands listed below when you deploy Elastic Runtime. However, you can prevent a specific post-install errand from running by deselecting its checkbox on the Errands page.

Note: Several errands deploy apps that provide services for your deployment, such as Autoscaling and Notifications. Once one of these apps is running, deselecting the checkbox for the corresponding errand on a subsequent deployment does not stop the app.


  • Run Smoke Tests verifies that your deployment can do the following:

    • Push, scale, and delete apps
    • Create and delete orgs and spaces
  • Push Apps Manager deploys the Apps Manager, a dashboard for managing apps, services, orgs, users, and spaces. Until you deploy Apps Manager, you must perform these functions through the cf CLI. After Apps Manager has been deployed, Pivotal recommends deselecting the checkbox for this errand on subsequent Elastic Runtime deployments. For more information about the Apps Manager, see the Getting Started with the Apps Manager topic.

  • Notifications deploys an API for sending email notifications to your PCF platform users.

    Note: The Notifications app requires that you configure SMTP with a username and password, even if you set the value of SMTP Authentication Mechanism to none.

  • Notifications-UI deploys a dashboard for users to manage notification subscriptions.

  • Push Pivotal Account deploys Pivotal Account, a dashboard that allows users to create and manage their accounts. In the Pivotal Account dashboard, users can launch applications, manage their profiles, manage account security, manage notifications, and manage approvals. See the Enabling Pivotal Account topic for more information.

  • Push Autoscaling enables you to configure your apps to automatically scale in response to changes in their usage load. See the Scaling an Application Using Autoscaler topic for more information.

  • Register Autoscaling Service Broker makes the Autoscaling service available to your applications. Without this errand, you cannot bind the Autoscaling app to your apps.

Step 19: Configure Resources

  1. Select Resource Config. Resource config
  2. Locate the HAProxy job in the Resource Config pane and click the dropdown menu under Instances to change the number of instances to 0.
  3. Retrieve the name(s) of your external ALB by navigating to the Azure portal, clicking All resources, and locating your Load balancer resource. The name of the load balancer should be pcf-lb.

    Note: The Azure portal sometimes displays the names of resources with incorrect capitalization. Always use the Azure CLI to retrieve the correctly capitalized name of a resource.

  4. Locate the Router job in the Resource Config pane and enter the name of your external ALB in the field under Load Balancers.

    Note: Do not enter a load balancer for the Diego Brain component.

  5. Ensure that the Internet Connected checkboxes are selected for all jobs. This gives all VMs a public IP address that enables outbound Internet access.

    Note: If you want to provision a Network Address Translation (NAT) box to provide Internet connectivity to your VMs instead of providing them with public IP addresses, deselect the Internet Connected checkboxes. Azure offers a managed source NAT (SNAT) service. However, Pivotal does not recommend using this service because Elastic Runtime deployments may fail due to SNAT performance bottlenecks.

  6. Scale the number of instances as appropriate for your deployment.

    Note: For a high availability deployment of PCF on Azure, Pivotal recommends scaling the number of each Elastic Runtime job to a minimum of three (3) instances. Using three or more instances for each job creates a sufficient number of availability sets and fault domains for your deployment. For more information, see Reference Architecture for Pivotal Cloud Foundry on Azure.

Step 20: (Optional) Disable Unused Resources

By default, Elastic Runtime uses an internal filestore and internal databases. If you configure Elastic Runtime to use external resources, you can disable the corresponding system-provided resources in Ops Manager to reduce costs and administrative overhead.

For more information regarding scaling instances, see the Zero Downtime Deployment and Scaling in CF and the Scaling Instances in Elastic Runtime topics.

Complete the following procedures to disable specific VMs in Ops Manager:

  1. Click Resource Config.

  2. If you configure Elastic Runtime to use an external S3-compatible filestore, edit the following fields:

    • File Storage: Enter 0 in Instances.
  3. If you configure Elastic Runtime to use an external Relational Database Service (RDS), edit the following fields:

    • MySQL Proxy: Enter 0 in Instances.
    • MySQL Server: Enter 0 in Instances.
    • Cloud Controller Database: Enter 0 in Instances.
    • UAA Database: Enter 0 in Instances.
  4. Click Save.

Step 21: Configure Stemcell

  1. Select Stemcell. Stemcell
  2. Download the Ubuntu Trusty stemcell version 3262.16 or greater for Azure from Pivotal Network.
  3. Click Import Stemcell to import the downloaded stemcell.

Step 22: Complete the Elastic Runtime Installation

  1. Click the Installation Dashboard link to return to the Installation Dashboard.

  2. Click Apply Changes. If the following ICMP error message appears, click Ignore errors and start the install.

    Install error

    The install process generally requires a minimum of 90 minutes to complete. The image shows the Changes Applied window that displays when the installation process successfully completes.

    Ops manager complete

Create a pull request or raise an issue on the source for this page in GitHub