forked from cloudfoundry/docs-cloudfoundry-concepts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathhigh-availability.html.md.erb
99 lines (55 loc) · 5.35 KB
/
high-availability.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
---
title: High Availability in Cloud Foundry
owner: Release Integration
---
<strong><%= modified_date %></strong>
This topic describes the components used to ensure high availability in Cloud Foundry, vertical and horizontal scaling, and the infrastructure required to support scaling component VMs for high availability.
## <a id='components'></a> Components of a High Availability Deployment
This section describes the system components needed to ensure high availability.
### <a id='azs'></a> Availability Zones
During product updates and platform upgrades, the VMs in a deployment restart in succession, rendering them temporarily unavailable. During outages, VMs go down in a less orderly way. Spreading components across Availability Zones (AZs) and scaling them to a sufficient level of redundancy maintains high availability during both upgrades and outages and can ensure zero downtime.
Deploying Cloud Foundry across three or more AZs and assigning multiple component instances to different AZ locations lets a deployment operate uninterrupted when entire AZs become unavailable. Cloud Foundry maintains its availability as long as a majority of the AZs remain accessible. For example, a three-AZ deployment stays up when one entire AZ goes down, and a five-AZ deployment can withstand an outage of up to two AZs with no impact on uptime.
### <a id='external-lbs'></a> External Load Balancers
Production environments should use a highly-available customer-provided load balancing solution that does the following:
* Provides load balancing to each of the Cloud Foundry 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
If you are deploying in lab and test environments, the `use-haproxy.yml` ops file enables HAProxy for your foundation.
<%= vars.external_lb %>
### <a id='blobstore'></a> Blob Storage
For storing blobs, large binary files, the best approach for high availability is to use external storage such as Amazon S3 or an S3-compatible service.
If you 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. <%= vars.contact_support %>
<%= vars.collector_singleton %>
## <a id='vert-and-horiz'></a> Vertical and Horizontal Scaling for High Availability
You can scale platform capacity vertically by adding memory and disk, or horizontally by adding more VMs running instances of Cloud Foundry components. The nature of the applications you host on Cloud Foundry should determine whether you should scale vertically or horizontally.
<%= image_tag("scale_cf.png", :height => "450px", :width => "475px") %>
For more information about scaling applications and maintaining app uptime, see [Scaling an Application 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> Scale Vertically
Scaling vertically means adding memory and disk to your component VMs.
To scale vertically, ensure that you allocate and maintain enough of 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 such 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> Scale Horizontally
Scaling horizontally means increasing the number of VM instances dedicated to running a functional component of the system.
You can horizontally scale most Cloud Foundry components to multiple instances to achieve the redundancy required for high availability.
You should also distribute the instances of multiply-scaled components across different AZs to minimize downtime during ongoing operation, product updates, and platform upgrades. If you use more than three AZs, ensure that you use an odd number of AZs.
<%= vars.scaling_ert %>
<%= partial vars.scale_table %>
## <a id='supporting-scaling'></a> Configure Support for High Availability Components
This section describes the surrounding infrastructure required to support scaling component VMs for high availability.
<% if vars.product_name == 'CF' %>
<%= vars.max_in_flight_header %>
<%= partial 'max_in_flight_text' %>
<% end %>
<%= vars.om_resurrector_header%>
<%= vars.om_resurrector_text%>
### <a id='resource-pools'></a> Resource Pools
To configure your resource pools according to the requirements of your deployment, see <%=vars.pools_link%>
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, will be available when scaling.
<%=vars.pcf_pools%>
### <a id='databases'></a> Databases
For database services deployed outside Cloud Foundry, plan to leverage your infrastructure's high availability features and to configure backup and restore where possible. <%= vars.scaling_ert_db %>
<p class="note"><strong>Note:</strong> Data services may have single points of failure depending on their configuration.</p>
<%= vars.contact_support %>