-
Notifications
You must be signed in to change notification settings - Fork 12
/
installing.html.md.erb
222 lines (131 loc) · 8.58 KB
/
installing.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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
---
title: Installing and Configuring Crunchy PostgreSQL for VMware Tanzu
owner: Crunchy Data
---
This topic describes how to install and configure Crunchy PostgreSQL for VMware Tanzu Tile.
If performing an upgrade of the Tile, please refer to the [Upgrading](#upgrading) section before proceeding.
<p class="warning">
<strong>Warning: </strong>
If upgrading the Tile, an Upgrade Token must be obtained from Crunchy Data
prior to beginning an upgrade action.
The upgrade process will not be able to complete without an Upgrade Token.
Failure to obtain an Upgrade Token prior to the upgrade process will result in broker errors.
</p>
## <a id='import'></a> Import the Tile to Ops Manager
1. Download the Crunchy PostgreSQL for VMware Tanzu Tile file from [Pivotal Network](https://network.pivotal.io/products/crunchy-postgresql/).
1. Navigate to the Ops Manager Installation Dashboard and click **Import a Product** to upload the product file.
1. Under the **Import a Product** button, click **+** next to the version number of Crunchy PostgreSQL for VMware Tanzu. This adds the tile to your staging area.
## <a id='configure'></a> Configuring the Service
Click the newly added **Crunchy PostgreSQL** tile on the Ops Manager Installation Dashboard to open the configuration panes.
![Crunchy PostgreSQL tile](images/tile.png)
If necessary, import a stemcell as required by the service.
Configure each section as described below.
### <a id='az-net'></a> Configure AZ and Network Assignments
To make Crunchy PostgreSQL highly available, you must balance the service across multiple availability zones (AZs).
![Assign AZs and Networks pane](assign-azs.png)
1. Click **Assign AZs and Networks**.
1. Choose an AZ to deploy singleton jobs. This is a private service network with a route to a public gateway.
1. Choose AZ to balance jobs. This should be a private service network with a route to a public gateway. Crunchy Data recommends two or more AZs when possible.
1. Choose the primary network where the On-Demand Broker will be deployed.
1. Choose the service network that On-Demand Broker will use to deploy VMs. This is a private service network with a route to a public gateway.
1. Click **Save**.
### <a id='global-properties'></a> Configure Global Properties
![Global Properties](global-properties.png)
1. Click **Global Properties**.
1. Configure a username and passphrase for a UAA Client.
- Requires an UAA account that has client login and either BOSH read or BOSH admin access.
- If the account has BOSH client admin login, select the check box labeled `Account Has Admin`.
- Example with BOSH read: `<ops manager url>/api/v0/deployed/director/credentials/uaa_login_client_credentials`
1. Configured the maximum number of upgrades that can be processed at a given time.
1. Choose an AZ in which to deploy these services.
1. Configure the availability of the Standalone PostgreSQL plan for organizations.
1. Configure the number of Standalone PostgreSQL instances permitted in the environment.
1. Configure the availability of the Replica PostgreSQL plan for organizations.
1. Configure the number of Replica PostgreSQL instances permitted in the environment.
1. Configure the availability of the General PostgreSQL plan for organizations.
1. Configure the number of General PostgreSQL instances permitted in the environment.
1. Configure the availability of the General-Monitored PostgreSQL plan for organizations.
1. Configure the number of General-Monitored PosgreSQL instances permitted in the environment.
1. Configure the availability of the Custom PostgreSQL plan for organizations.
1. Configure the number of Custom PostgreSQL instances permitted in the environment.
1. Configure the availability of the Custom-Monitored PostgreSQL plan for organizations.
1. Configure the number of Custom-Monitored PosgreSQL instances permitted in the environment.
1. Click **Save**.
### <a id='standalone-properties'></a> Configure Standalone Properties
The standalone plans made available to developers must be configured prior to deployment.
![Standalone Properties](standalone-properties.png)
1. Click **Standalone Properties**.
1. Select a default size for the standalone instances.
1. Select a default disk size for the standalone instances.
1. Optionally enable backups by default for all standalone instances.
1. Select a default maximum connections per standalone instance.
<p class="note">
<strong>Note: </strong>
Do not set any PostgreSQL VMs to less than 4 GB of memory.
</p>
<p class="note">
<strong>Note: </strong>
Do not set any PostgreSQL VMs to fewer than 2 cores.
</p>
### <a id='cluster-properties'></a> Configure Cluster Properties
The standard plans made available to developers must be configured prior to deployment.
![Cluster Properties](cluster-properties.png)
1. Select the default system specification for General plans.
1. Select the default disk size for the General plans.
1. Select the default number of PostgreSQL instances in a General plan.
1. Select the default maximum number of connections to the PostgreSQL instances.
1. Select the system specifications and disk types for the Consul, HAProxy, and errand Virtual Machines.
<p class="note">
<strong>Note: </strong>
Do not set any plan which uses PostgreSQL or pgBackrest VMs to less than 4 GB of memory.
</p>
<p class="note">
<strong>Note: </strong>Do not set any plan which uses PostgreSQL or pgBackrest VMs to fewer than 2 cores.
</p>
### <a id='cluster-properties'></a> Configure PostgreSQL Properties
The standard plans made available to developers must be configured prior to deployment.
![PostgreSQL Properties](postgresql-properties.png)
1. Select the Log File Name Pattern by which PostgreSQL will rotate the logs.
1. Select the frequency with which PostgreSQL will rotate the logs.
1. Select the size by which PostgreSQL will rotate the logs.
1. Select the default Archive Mode for instances. If "S3" or "local&S3" are selected, enter the associated S3 bucket info.
- Repo Path Prefix setting allows for defining a 'subfolder' within the bucket.
- pgBackRest repositories can be stored in the bucket root by setting this value to `/`, but it is usually best to specify a prefix, such as `/repo`, so logs and other AWS generated content can also be stored in the bucket.
- Services will be archived to this path, each with their own folder based on the service GUID.
1. Select the PostgreSQL configuration parameters developers will be allowed to set while using a Crunchy PostgreSQL service instance.
![Configuration Parameters](postgresql-configurations.png)
1. Select the PostgreSQL extensions developers will be allowed to create while using a Crunchy PostgreSQL service instance.
![Extensions](postgresql-extensions.png)
<p class="note">
<strong>Note: </strong>
If Standalone Replica plans are to be used in the environment, only use "local" or "local&S3" options.
Selecting S3 only archive mode will cause serious configuration issues on Standalone Replica instances.
</p>
### <a id='extended-features'></a> Extended Features
Optionally, configure extended service features
![Extended Features](extended-features.png)
1. Either enable or disable the option to allow developers to use MD5 authentication when binding applications to the service instances.
1. Either enable or disable the option to allow developers to create bindings with superuser visibility of stats tables with the `stats_access` checkbox.
### <a id='errands'></a> Configure Errands
![Errands](errands.png)
1. Click **Errands**.
1. Configure the errands that should be run after deployment of the service. Crunchy Data recommends the defaults.
1. Click **Save**.
### <a id='Resource Config'></a> Configure Resources
![Resource Config](resource-config.png)
1. Click **Resource Config**.
1. Review the pre-populated recommended server sizes and make any necessary changes. Crunchy Data recommends the defaults.
1. Click **Save**.
## <a id='install'></a> Install the Tile
1. Return to the Ops Manager Installation Dashboard.
1. Click **Apply Changes** to install the Crunchy PostgreSQL for VMware Tanzu tile.
## <a id='upgrading'></a> Upgrading the Tile
![Upgrade Token](upgrade-token.png)
1. Obtain the Upgrade Code from Crunchy Data's Customer Access Portal.
- Log in to the Customer Access Portal and select VMware Tanzu Tile Upgrade Token
- Select the version to which you wish to upgrade
- Select the Generate Token button to receive the Upgrade Token
![Token Generator](token-generator.png)
1. Enter the Upgrade Code, exactly as provided, into the associated field on the
Upgrade Token page of the Tile Installer
1. Continue the steps as necessary from the [Errands](#errands) section.