forked from pivotal-cf/docs-pcf-install
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathazure-troubleshooting.html.md.erb
114 lines (65 loc) · 4.98 KB
/
azure-troubleshooting.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
---
title: Troubleshooting Pivotal Platform on Azure
owner: Ops Manager, Release Integration
---
<% current_page.data.title = "Troubleshooting " + vars.platform_name + " on Azure" %>
<html class="list-style-none"></html>
This topic describes how to troubleshoot known issues when deploying or running <%= vars.platform_name %> on Azure.
## <a id="install-issues"></a> Installation Issues
This section describes how to troubleshoot known installation issues.
### <a id="cannot-copy-om"></a> Cannot Copy the Pivotal Ops Manager Image
#### Symptom
You cannot copy the Ops Manager image into your storage account as part of the _Step 4: Boot Ops Manager_ section of the [Deploying Ops Manager on Azure Manually](/platform/ops-manager/<%= vars.current_major_version.sub('.', '-') %>/azure/deploy-manual.html#boot) topic.
#### Explanation
You have an outdated version of the Azure CLI. You need Azure CLI v2.0.0 or later. Run `az --version` from the command line to display your current Azure CLI version.
#### Solution
Install the Azure CLI v2.0 by following the instructions for your operating system in the [Azure documentation](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli).
<hr>
### <a id="create-env-fails"></a> Deployment Fails at "create-env"
#### Symptom
After clicking **Review Pending Changes**, then **Apply Changes** to install Ops Manager and PAS, the deployment fails at `create-env` with an error message similar to the following:
```
Command 'deploy' failed:
Deploying:
Creating instance 'bosh/0':
Waiting until instance is ready:
Starting SSH tunnel:
Parsing private key file '/tmp/bosh_ec2_private_key.pem':
asn1: structure error: tags don't match (16 vs {class:3 tag:28 length:127
isCompound:false}) {optional:false explicit:false application:false
defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pkcs1PrivateKey @2
===== 2016-09-29 16:28:22 UTC Finished "<%= vars.bosh_deploy %>"
/var/tempest/workspaces/default/deployments/bosh.yml";
Duration: 328s; Exit Status: 1
Exited with 1.
```
#### Explanation
You provided a passphrase when creating your key pair in the _Step 4: Boot Ops Manager_ section of the [Deploying Ops Manager on Azure Manually](/platform/ops-manager/<%= vars.current_major_version.sub('.', '-') %>/azure/deploy-manual.html#boot) topic.
#### Solution
Create a new key pair with no passphrase and redo the installation. For more information, see the _Step 4: Boot Ops Manager_ section of [Deploying Ops Manager on Azure Manually](/platform/ops-manager/<%= vars.current_major_version.sub('.', '-') %>/azure/deploy-manual.html#boot).
<hr>
### <a id="database-permissions"></a> Insufficient External Database Permissions
Upgrade issues can be caused when the external database user used for the network policy database is given insufficient permissions. To avoid this upgrade issue, ensure that the network policy server database user has the `ALL PRIVILEGES` permission.
## <a id="operation-issues"></a> Operation Issues
This section describes how to troubleshoot known operation issues.
### <a id="timeouts"></a> Slow Performance or Timeouts
#### Symptom
Developers suffer from slow performance or timeouts when pushing or managing apps, and end users suffer from slow performance or timeouts when accessing apps
#### Explanation
The Azure Load Balancer (ALB) disconnects active TCP connections lying idle for over four minutes.
#### Solution
To mitigate slow performance or timeouts, the default value of the **Router timeout to back ends** field is set to 900 seconds. This default value is set high to mitigate performance issues but operators should tune this parameter to fit their infrastructure.
To edit the **Router timeout to back ends** field:
1. Go to the Installation Dashboard and click the Pivotal Application Service (PAS) tile.
1. Select **Networking**.
1. Enter your desired time, in seconds, in the **Router timeout to back ends** field.
1. Click **Save**.
<hr>
### <a id="service-create-fail"></a> Service Instance Creation Times Out
#### Symptom
You are unable to provision a service instance of a Java or Go service. `cf create-service` fails with error `Failure provisioning service instance... Timed out after 8 minutes...` or similar.
#### Explanation
HTTP libraries for Java and Go, running with default settings, prune idle (for 240 seconds) connections from their connection pool without sending a TCP reset message back to the client service broker. This removes the ability of the broker to provision new service instances.
#### Solution
In the **Configure Networking** pane of the PAS tile, set **Front end idle timeout** to 240 seconds or less, so that <%= vars.platform_name %> regenerates the front end connection before it times out.
For more information, see [Azure Networking Connection Idle for more than Four minutes](https://community.pivotal.io/s/article/Azure-Networking-Connection-Idle-for-more-than-Four-minutes) in the Pivotal Knowledge Base.