-
Notifications
You must be signed in to change notification settings - Fork 110
/
configure-lb-healthcheck.html.md.erb
129 lines (107 loc) · 5.23 KB
/
configure-lb-healthcheck.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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
---
title: Configuring load balancer health checks for Cloud Foundry routers
owner: CF for VMs Networking
---
<%# Reset page title based on platform type %>
<% if vars.platform_code != 'CF' %>
<% set_title("Configuring load balancer health checks for", vars.app_runtime_abbr, "routers") %>
<% end %>
You can configure load balancer health checks for <%= vars.app_runtime_abbr %> routers so requests go only to healthy
router instances.
In environments that require high availability, you must configure your redundant load balancer to forward traffic
directly to the <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>) routers. In environments that do not require high availability, you can skip the load balancer and configure DNS to resolve the <%= vars.app_runtime_abbr %> domains directly to a single instance of a router.
## <a id="load-balancer"></a> Add health check endpoints for routers
You can configure your load balancer to use either HTTP or HTTPS for checking the health of `gorouter`
and `tcp_router` processes.
<% if vars.platform_code == 'CF' %>
To deactivate the HTTP health check endpoints, set the following properties to `false`:
- The `router.status.enable_nontls_health_checks` property on the `gorouter` job
- The `tcp_router.enable_nontls_health_checks` property on the `tcp_router` job
<% else %>
To disable the HTTP health check endpoints, deselect the **Enable HTTP load balancer health checks** check boxes
in the **Networking** pane of the <%= vars.app_runtime_abbr %> and <%= vars.segment_runtime_full %> tiles.
<% end %>
### <a id="load-balancer-https"></a> Using HTTPS health check endpoints
To configure your load balancer to use HTTPS health check endpoints, add the IP addresses of all router instances,
along with their corresponding port and path:
* Gorouter (HTTP router): `https://GOROUTER_IP:8443/health`
* TCP router: `https://TCP_ROUTER_IP:443/health`
### <a id="load-balancer-http"></a> Using HTTP health check endpoints
To configure your load balancer to use HTTP health check endpoints, add the IP addresses of all router instances,
along with their corresponding port and path:
* Gorouter (HTTP router): `http://GOROUTER_IP:8080/health`
* TCP router: `http://TCP_ROUTER_IP:80/health`
<% if vars.platform_code == 'CF' %>
The preceding configuration assumes the default health check ports for the <%= vars.app_runtime_abbr %> routers. To modify these
ports, see the following sections.
<%= partial 'go_tcp_routers_health_check_oss' %>
<% end %>
## <a id="router_upgrade"></a> Set the healthy and unhealthy threshold properties for the Gorouter
To maintain high availability during upgrades to the Gorouter, each router is upgraded on a rolling basis. During upgrade of a
highly available environment with multiple routers, each router is shut down, upgraded, and restarted before the next router is
upgraded. This ensures that any pending HTTP requests passed to the Gorouter are handled correctly.
<% if vars.platform_code == 'CF' %>
<%= partial 'lb_health_check_oss' %>
<% else %>
<%= partial "/pcf/core/lb_health_check" %>
<% end %>
The following table describes the behavior of the load balancer health checks when a router shuts down and is restarted.
<table>
<thead>
<tr>
<th>Step</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>A shutdown request is sent to the router.</td>
</tr>
<tr>
<td>2</td>
<td>The router receives shutdown request, which causes the following:
<ul>
<li>The router begins sending Service Unavailable responses to the load balancer health checks.</li>
<li>The load balancer continues sending HTTP request to the router</li>
</td>
</tr>
<tr>
<td>3</td>
<td>The load balancer considers the router to be in an unhealthy state, which causes the load balancer to stop sending HTTP requests to the router.
<p>
The time between step 2 and 3 is defined by the values of the health check interval and threshold configured on the load balancer.
</p>
</td>
</tr>
<tr>
<td>4</td>
<td>The router shuts down.
<p>The interval between step 2 and 4 is defined by the <%= vars.lb_health_chk_healthy %> property of the Gorouter. In general, the value of this property should be longer than the value of the interval and threshold values (interval x threshold) of the load balancer. This additional interval ensures that any remaining HTTP requests are handled before the router shuts down.</p>
</td>
</tr>
<tr>
<td>5</td>
<td>If the router shutdown is initiated by an upgrade, the Gorouter software is upgraded.</td>
</tr>
<tr>
<td>6</td>
<td>The router restarts. The router returns Service Unavailable responses for load balancer health checks for 20 seconds; during this time the routing table is preloaded.
<%= vars.healthcheck_duration %>
</td>
</tr>
<tr>
<td>7</td>
<td>The routers begins returning Service Available responses to the load balancer health check.</td>
</tr>
<tr>
<td>8</td>
<td>The load balancer considers the router to be in a healthy state.
The time between step 7 and 8 is specified by the health check interval and threshold configured for your load balancer (health check threshold x health check interval).</td>
</tr>
<tr>
<td>9</td>
<td>Shut down and upgrade of the other router begins.</td>
</tr>
</tbody>
</table>