forked from pivotal-cf/docs-pcf-install
-
Notifications
You must be signed in to change notification settings - Fork 0
/
_pcf_scale_table.html.md.erb
95 lines (93 loc) · 5.32 KB
/
_pcf_scale_table.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
The following table provides recommended instance counts for a high-availability deployment and the minimum instances for a functional deployment:
<table border="1" class="nice">
<tr>
<th><strong>Elastic Runtime Job</strong></th>
<th><strong>Recommended Instance Number for HA</strong></th>
<th><strong>Minimum Instance Number</strong></th>
<th><strong>Notes</strong></th>
</tr>
<tr>
<td>Diego Cell</td>
<td>≥ 3</td>
<td>1</td>
<td>The optimal balance between CPU/memory sizing and instance count depends on the performance characteristics of the apps that run on Diego cells. Scaling vertically with larger Diego cells makes for larger points of failure, and more apps go down when a cell fails. On the other hand, scaling horizontally decreases the speed at which the system rebalances apps. Rebalancing 100 cells takes longer and demands more processing overhead than rebalancing 20 cells.</td>
</tr>
<tr>
<td>Diego Brain</td>
<td>≥ 2</td>
<td>1</td>
<td>For high availability, use at least one per AZ, or at least two if only one AZ.</td>
</tr>
<tr>
<td>Diego BBS</td>
<td>≥ 3</td>
<td>1</td>
<td>Set this to an odd number equal to or one greater than the number of AZs you have, in order to maintain quorum. Distribute the instances evenly across the AZs, at least one instance per AZ.</td>
</tr>
<tr>
<td>Consul</td>
<td>≥ 3</td>
<td>1</td>
<td>Set this to an odd number equal to or one greater than the number of AZs you have, in order to maintain quorum. Distribute the instances evenly across the AZs, at least one instance per AZ.</td>
</tr>
<tr>
<td>MySQL Server</td>
<td>3</td>
<td>1</td>
<td>If you use an <a href="./../customizing/pcf-aws-manual-er-config.html#sys-db">external database</a> in your deployment, then you can set the MySQL Server instance count to <code>0</code>. For instructions about scaling down an internal MySQL cluster, see <a href="../opsguide/scaling-down-mysql.html">Scaling Down Your MySQL Cluster</a>.</td>
</tr>
<tr>
<td>MySQL Proxy</td>
<td>2</td>
<td>1</td>
<td>If you use an <a href="./../customizing/pcf-aws-manual-er-config.html#sys-db">external database</a> in your deployment, then you can set the MySQL Proxy instance count to <code>0</code>.</td>
</tr>
<tr>
<td>NATS Server</td>
<td>≥ 2</td>
<td>1</td>
<td>In a high availability deployment, you might run a single NATS instance if your deployment lacks the resources to deploy two stable NATS servers. Components using NATS are resilient to message failures and the BOSH resurrector recovers the NATS VM quickly if it becomes non-responsive.</td>
</tr>
<tr>
<td>Cloud Controller</td>
<td>≥ 2</td>
<td>1</td>
<td>Scale the Cloud Controller to accommodate the number of requests to the API and the number of apps in the system.</td>
</tr>
<tr>
<td>Clock Global</td>
<td>≥ 2</td>
<td>1</td>
<td>For a high availability deployment, scale the Clock Global job to a value greater than 1 or to the number of AZs you have.
</tr>
<tr>
<td>Router</td>
<td>≥ 2</td>
<td>1</td>
<td>Scale the router to accommodate the number of incoming requests. Additional instances increase available bandwidth. In general, this load is much less than the load on Diego cells.</td>
</tr>
<tr>
<td>HAProxy</td>
<td>0 or ≥ 2</td>
<td>0 or 1</td>
<td>For environments that require high availability, you can scale HAProxy to <code>0</code> and then configure a high-availability load balancer (LB) to point directly to each Gorouter instance. Alternately, you can also configure the high availability LB to point to HAProxy instance scaled at <code>≥ 2</code>. Either way, an LB is required to host Cloud Foundry domains at a single IP address.</td>
</tr>
<tr>
<td>UAA</td>
<td>≥ 2</td>
<td>1</td>
<td></td>
</tr>
<tr>
<td>Doppler Server</td>
<td>≥ 2</td>
<td>1</td>
<td>Deploying additional Doppler servers splits traffic across them. For a high availability deployment, Pivotal recommends at least two per Availability Zone.</td>
</tr>
<tr>
<td>Loggregator Trafficcontroller</td>
<td>≥ 2</td>
<td>1</td>
<td>Deploying additional Loggregator Traffic Controllers allows you to direct traffic to them in a round-robin manner. For a high availability deployment, Pivotal recommends at least two per Availability Zone.</td>
</tr>
</table>