@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Provide SSH host documentation, tweak/supplement cluster documentation
Summary: Ref T10751. I think this mostly brings us up to date with the state of the world.
Test Plan: Read documentation.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10751
Differential Revision: https://secure.phabricator.com/D15897
+104
-27
+45
-8
src/docs/user/cluster/cluster.diviner
+45
-8
src/docs/user/cluster/cluster.diviner
···
4
4
Guide to configuring Phabricator across multiple hosts for availability and
5
5
performance.
6
6
7
+
7
8
Overview
8
9
========
9
10
10
-
WARNING: This feature is a very early prototype; the features this document
11
-
describes are mostly speculative fantasy.
11
+
WARNING: This feature is a prototype. Installs should expect a challening
12
+
adventure when deploying clusters. In the best of times, configuring a
13
+
cluster is complex and requires significant operations experience.
12
14
13
15
Phabricator can be configured to run on multiple hosts with redundant services
14
16
to improve its availability and scalability, and make disaster recovery much
···
19
21
network failures.
20
22
21
23
Each Phabricator service has an array of clustering options that can be
22
-
configured independently. Configuring a cluster is inherently complex, and this
23
-
is an advanced feature aimed at installs with large userbases and experienced
24
-
operations personnel who need this high degree of flexibility.
24
+
configured somewhat independently. Configuring a cluster is inherently complex,
25
+
and this is an advanced feature aimed at installs with large userbases and
26
+
experienced operations personnel who need this high degree of flexibility.
25
27
26
28
The remainder of this document summarizes how to add redundancy to each
27
29
service and where your efforts are likely to have the greatest impact.
28
30
29
31
For additional guidance on setting up a cluster, see "Overlaying Services"
30
32
and "Cluster Recipes" at the bottom of this document.
33
+
34
+
35
+
Clusterable Services
36
+
====================
37
+
38
+
This table provides an overview of clusterable services, their setup
39
+
complexity, and the rough impact that converting them to run on multiple hosts
40
+
will have on availability, resistance to data loss, and scalability.
41
+
42
+
| Service | Setup | Availability | Loss Resistance | Scalability
43
+
|---------|-------|--------------|-----------|------------
44
+
| **Databases** | Moderate | **High** | **High** | Low
45
+
| **Repositories** | Complex | Moderate | **High** | Moderate
46
+
| **Daemons** | Minimal | Low | No Risk | Low
47
+
| **SSH Servers** | Minimal | Low | No Risk | Low
48
+
| **Web Servers** | Minimal | **High** | No Risk | Moderate
49
+
| **Notifications** | Minimal | Low | No Risk | Low
50
+
51
+
See below for a walkthrough of these services in greater detail.
31
52
32
53
33
54
Preparing for Clustering
···
146
167
Configuring multiple daemon hosts is straightforward, but you must configure
147
168
repositories first.
148
169
149
-
With daemons running on multiple hosts, you can transparently survive the loss
170
+
With daemons running on multiple hosts you can transparently survive the loss
150
171
of any subset of hosts without an interruption to daemon services, as long as
151
172
at least one host remains alive. Daemons are stateless, so spreading daemons
152
173
across multiple hosts provides no resistance to data loss.
···
161
182
For details, see @{article:Cluster: Daemons}.
162
183
163
184
185
+
Cluster: SSH Servers
186
+
====================
187
+
188
+
Configuring multiple SSH hosts is straightforward, but you must configure
189
+
repositories first.
190
+
191
+
With multiple SSH hosts you can transparently survive the loss of any subset
192
+
of hosts without interruption to repository services, as long as at last one
193
+
host remains alive. SSH services are stateless, so putting multiple hosts in
194
+
service provides no resistance to data loss because no data is at risk.
195
+
196
+
SSH hosts are very rarely a scalability bottleneck.
197
+
198
+
For details, see @{article:Cluster: SSH Servers}.
199
+
200
+
164
201
Cluster: Web Servers
165
202
====================
166
203
167
204
Configuring multiple web hosts is straightforward, but you must configure
168
205
repositories first.
169
206
170
-
With multiple web hosts, you can transparently survive the loss of any subset
171
-
of hosts as long as at least one host remains alive. Web hosts are stateless,
207
+
With multiple web hosts you can transparently survive the loss of any subset
208
+
of hosts as long as at least one host remains alive. Web services are stateless,
172
209
so putting multiple hosts in service provides no resistance to data loss
173
210
because no data is at risk.
174
211
+2
-4
src/docs/user/cluster/cluster_daemons.diviner
+2
-4
src/docs/user/cluster/cluster_daemons.diviner
···
6
6
Overview
7
7
========
8
8
9
-
WARNING: This feature is a very early prototype; the features this document
10
-
describes are mostly speculative fantasy.
11
-
12
9
You can run daemons on multiple hosts. The advantages of doing this are:
13
10
14
11
- you can completely survive the loss of multiple daemon hosts; and
···
18
15
details, see @{article:Cluster: Repositories}.
19
16
20
17
Since repository hosts must run daemons anyway, you usually do not need to do
21
-
any additional work and can skip this entirely.
18
+
any additional work and can skip this entirely if you have already configured
19
+
multiple repository hosts.
22
20
23
21
24
22
Adding Daemon Hosts
+1
-1
src/docs/user/cluster/cluster_devices.diviner
+1
-1
src/docs/user/cluster/cluster_devices.diviner
-3
src/docs/user/cluster/cluster_notifications.diviner
-3
src/docs/user/cluster/cluster_notifications.diviner
-5
src/docs/user/cluster/cluster_repositories.diviner
-5
src/docs/user/cluster/cluster_repositories.diviner
···
6
6
Overview
7
7
========
8
8
9
-
WARNING: This feature is a very early prototype; the features this document
10
-
describes are mostly speculative fantasy.
11
-
12
9
If you use Git, you can deploy Phabricator with multiple repository hosts,
13
10
configured so that each host is readable and writable. The advantages of doing
14
11
this are:
···
294
291
295
292
**Last Write At**: When the most recent write started. If the write lock is
296
293
currently held, this shows when the lock was acquired.
297
-
298
-
299
294
300
295
301
296
Cluster Failure Modes
+47
src/docs/user/cluster/cluster_ssh.diviner
+47
src/docs/user/cluster/cluster_ssh.diviner
···
1
+
@title Cluster: SSH Servers
2
+
@group cluster
3
+
4
+
Configuring Phabricator to use multiple SSH servers.
5
+
6
+
Overview
7
+
========
8
+
9
+
You can run Phabricator on multiple SSH servers. The advantages of doing this
10
+
are:
11
+
12
+
- you can completely survive the loss of multiple SSH hosts.
13
+
14
+
This configuration is simple, but you must configure repositories first. For
15
+
details, see @{article:Cluster: Repositories}.
16
+
17
+
SSH servers accept SSH requests from commands like `git clone` and relay them
18
+
to hosts that can serve the requests.
19
+
20
+
21
+
Adding SSH Hosts
22
+
================
23
+
24
+
After configuring repositories in cluster mode, you can add more web hosts
25
+
at any time.
26
+
27
+
First, deploy the Phabricator software and configuration to a host, then
28
+
register the host as a cluster device if it is not already registered (for
29
+
help, see @{article:Cluster: Devices}.
30
+
31
+
Once the host is registered, start the SSH server, and then add the host to the
32
+
SSH load balancer pool.
33
+
34
+
Phabricator SSH servers are stateless, so you can pull them in and out of
35
+
production freely.
36
+
37
+
You may also want to run web services on these hosts, since the service is very
38
+
similar to SSH, also stateless, and it may be simpler to load balance the
39
+
services together. For details, see @{cluster: Web Servers}.
40
+
41
+
42
+
Next Steps
43
+
==========
44
+
45
+
Continue by:
46
+
47
+
- returning to @{article:Clustering Introduction}.
+9
-6
src/docs/user/cluster/cluster_webservers.diviner
+9
-6
src/docs/user/cluster/cluster_webservers.diviner
···
6
6
Overview
7
7
========
8
8
9
-
WARNING: This feature is a very early prototype; the features this document
10
-
describes are mostly speculative fantasy.
11
-
12
9
You can run Phabricator on multiple web servers. The advantages of doing this
13
10
are:
14
11
···
23
20
================
24
21
25
22
After configuring repositories in cluster mode, you can add more web hosts
26
-
at any time: simply deploy the Phabricator software and configuration to a
27
-
host, start the web server, and then add the host to the load balancer pool.
23
+
at any time.
24
+
25
+
First, deploy the Phabricator software and configuration to a host, then
26
+
register the host as a cluster device if it is not already registered (for
27
+
help, see @{article:Cluster: Devices}.
28
+
29
+
Once the host is registered, start the web server, and then add the host to the
30
+
load balancer pool.
28
31
29
32
Phabricator web servers are stateless, so you can pull them in and out of
30
33
production freely.
31
34
32
35
You may also want to run SSH services on these hosts, since the service is very
33
36
similar to HTTP, also stateless, and it may be simpler to load balance the
34
-
services together.
37
+
services together. For details, see @{cluster:SSH Servers}.
35
38
36
39
37
40
Next Steps