high-availability.html.md.erb

---
title: High Availability in Cloud Foundry
owner: Release Integration
---

<%# Reset page title based on product title %>

This topic tells you about the components used to ensure high availability in <%= vars.app_runtime_first %>, vertical and horizontal scaling, and the infrastructure
required to support scaling component VMs for high availability.

A system with high availability provides higher than typical uptime through redundancy of apps and component VMs. You can create the redundancy required for
high availability in several ways, such as running VMs in multiple availability zones and using external blob storage solutions.

This topic provides you guidance on configuring
your <%= vars.app_runtime_abbr %> deployment for high availability.


## <a id='high-availability'></a> Components of high availability deployments

You can use availability zones, external load balancers, and
external blob storage to ensure high availability for your deployment.

### <a id='azs'></a> Availability zones

Availability Zones (AZs) are locations where public cloud services offer data centers.

You can assign and scale components in multiple AZs to help maintain high availability through redundancy. To configure sufficient redundancy, deploy
<%= vars.app_runtime_abbr %> across three or more AZs and assign multiple component instances to different AZs.

Always use an odd number of AZs. This ensures that your deployment remains available as long as greater than half of the AZs are available.

For example, a deployment with three AZs stays available when one AZ is unavailable. A deployment with five AZs stays available when two AZs are unavailable.

### <a id='external-lbs'></a> External load balancers

External load balancers distribute traffic coming from the internet to your internal network.

To ensure high availability for production environments, use a highly available customer provided external load balancing solution that does the following:

* Provides load balancing to each of the <%= vars.app_runtime_abbr %> router IP addresses.

* Supports SSL termination with wildcard DNS location.

* Adds appropriate `x-forwarded-for` and `x-forwarded-proto HTTP` headers to incoming requests.

* (Optional) Supports WebSockets.

<%= vars.external_lb %>

### <a id='blobstore'></a> External blob storage

Blobs are large binary files, such as PDFs or images. To store blobs for high availability, use external storage such as Amazon S3 or an S3-compatible
service.

You can also store blobs internally using WebDAV or NFS. These components run as single instances and you cannot scale them. For these deployments, use the
high availability features of your IaaS to immediately recover your WebDAV or NFS server VM if it fails.

If you need assistance,
contact <a href="https://www.vmware.com/support/services.html">Support.</a>

<%= vars.collector_singleton %>

## <a id='vert-and-horiz'></a> Scaling platform capacity

You can scale platform capacity in the following ways:

* **Vertical scaling:** Add memory and disk to each VM.

* **Horizontal scaling:** Add more VMs that run instances of <%= vars.app_runtime_abbr %> components.

The type of apps you host on <%= vars.app_runtime_abbr %> determines whether you scale vertically or horizontally.

For more information about scaling apps and maintaining app uptime, see [Scaling an app using cf scale](../devguide/deploy-apps/cf-scale.html) and [Using
Blue-Green Deployment to Reduce Downtime and Risk](../devguide/deploy-apps/blue-green.html)

### <a id='vert-scaling'></a> Scaling vertically

Scaling vertically means adding memory and disk to your component VMs.

To scale vertically, allocate and maintain the following:

* Free space on host Diego Cell VMs so that apps expected to deploy can successfully be staged and run.

* Disk space and memory in your deployment so that if one host VM is down, all instances of apps can be placed on the remaining host VMs.

* Free space to handle one AZ going down if deploying in multiple AZs.

### <a id='horiz-scaling'></a> Scaling horizontally

Scaling horizontally means increasing the number of instances of VMs that run a functional component of a system.

You can horizontally scale most <%= vars.app_runtime_abbr %> component VMs to multiple instances for high availability.

You must also distribute the instances of components across different AZs to minimize downtime during ongoing operation, product updates, and platform
upgrades. For more information about using AZs, see [Availability Zones](#azs).


## <a id='instance-counts'></a> Recommended instance counts for high availability

<%= vars.scaling_ert %>

<%= partial 'oss_scale_table' %>

## <a id='supporting-scaling'></a> Infrastructure for component scaling

The ability to scale component VMs is important for high availability. To scale component VMs, you must make sure that the surrounding infrastructure of your
deployment supports VM scaling.

Learn about the infrastructure required to support scaling component VMs for high availability.

<%= vars.max_in_flight_header %>
<%= partial 'max_in_flight_text' %>

<%= vars.om_resurrector_header %>

<%= vars.om_resurrector_text %>

### <a id='resource-pools'></a> Resource pools

Each IaaS has different ways of limiting resource consumption for scaling VMs. Consult with your IaaS administrator to ensure additional VMs and related
resources, like IPs and storage, are available to scale.

For more information about configuring your resource pools according to the requirements of your deployment, see <%= vars.pools_link %>

<%= vars.pcf_pools %>

### <a id='databases'></a> Databases

For database services deployed outside <%= vars.app_runtime_abbr %>, use the high availability features included with your infrastructure. Also, configure
backup and restore where possible. <%= vars.scaling_ert_db %>

Data services might have single points of failure depending on their configuration.