Merge branch 'doc_high_availability' into 'master'

HA Design Document

See merge request gitlab-org/gitaly!1058

2 files changed, 137 insertions, 0 deletions

diff --git a/changelogs/unreleased/ha-design-doc.yml b/changelogs/unreleased/ha-design-doc.yml
new file mode 100644
index 000000000..d87155e69
--- /dev/null
+++ b/changelogs/unreleased/ha-design-doc.yml
@@ -0,0 +1,5 @@
+---
+title: Initial design document for High Availability
+merge_request: 1058
+author:
+type: other
diff --git a/doc/design_ha.md b/doc/design_ha.md
new file mode 100644
index 000000000..531e731ff
--- /dev/null
+++ b/doc/design_ha.md
@@ -0,0 +1,132 @@
+# Gitaly High Availability (HA) Design
+Gitaly HA is an active-active cluster configuration for resilient git operations. [Refer to our specific requirements](https://gitlab.com/gitlab-org/gitaly/issues/1332).
+
+Refer to epic &289 for current issues and discussions revolving around HA MVC development.
+
+## Terminology
+The following terminology may be used within the context of the Gitaly HA project:
+
+- Shard - partition of the storage for all repos. Each shard will require redundancy in the form of multiple Gitaly nodes (at least 3 when optimal) to maintain HA.
+- Praefect - a transparent front end to all Gitaly shards. This reverse proxy ensures that all gRPC calls are forwarded to the correct shard by consulting the coordinator. The reverse proxy also ensures that write actions are performed transactionally when needed.
+    - etymology: from Latin praefectus for _a person appointed to any of various positions of command, authority, or superintendence, as a chief magistrate in ancient Rome or the chief administrative official of a department of France or Italy._
+    - [pronounced _pree-fect_](https://www.youtube.com/watch?v=MHszCZjPmTQ)
+- Node (TODO: we probably need a similar latin name here) - performs the actual git read/write operations to/from disk. Has no knowledge of shards/prafects/coordinators just as the Gitaly service existed prior to HA.
+
+## Design
+The high level design takes a reverse proxy approach to fanning out write requests to the appropriate nodes:
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vRl7WS-6RBOWxyLSBbBBAoV9MupmTh5vTqMOw_AX9axlboqkybTbFqGqExLyyYOilqEW7S9euXdBHzX/pub?w=960&amp;h=720">
+
+## Phases
+An iterative low risk approach needs to be devised to add functionality and verify assumptions at a sustainable pace while not impeding the existing functionality.
+
+### 1. Simple pass-through proxy - no added functionality
+- allows us to set up telemetry for observability of new service
+- allows us to evaluate a gRPC proxy library
+
+### 2. Introduce State
+The following details need to be persisted in Postgres:
+- [x] Primary location for a project
+- [ ] Redundant locations for a project
+- [ ] Available storage locations (initially can be configuration file)
+
+Initially, the state of the shard nodes will be static and loaded from a configuration file. Eventually, this will be made dynamic via a data store (Postgres).
+
+### Resolving Location
+The following existing interaction will remain intact for the first iteration of the HA feature:
+
+```mermaid
+sequenceDiagram
+    Client->>Rails: Modify repo X
+	Rails-->>Datastore: Where is Repo X?
+	Datastore-->> Rails: Repo X is at location A
+    Rails-->>Gitaly: Modify repo X at location A
+	Gitaly-->>Rails: Request succeeded/failed
+```
+
+Once the Rails app has resolved the primary location for the project, the request is made to the praefect. The praefect then resolves the redundant locations via the coordinator before applying the changes.
+
+```mermaid
+sequenceDiagram
+	Rails->>Praefect: Modify repo X at A
+	Praefect->>Coordinator: Which locations complement A for X?
+	Coordinator->>Praefect: Locations B and C complement A
+	Praefect->>Nodes ABC: Modify repo X
+	Nodes ABC->>Praefect: Modifications successful!
+```
+
+*Note: the above interaction between the praefect and nodes A-B-C is an all-or-nothing transaction. All nodes must complete in success, otherwise a single node failure will cause the entire transaction to fail. This will be improved when replication is introduced.*
+
+### 3. Replication
+The next phase is to enable replication of data between nodes. This makes transactions more efficient and fault tolerant. This could be done a few ways:
+
+#### Node Orchestrated [👎]
+Node orchestrated puts the intelligence of replication into one of the nodes being modified:
+
+```mermaid
+sequenceDiagram
+	Praefect->>Node A: Modify repo X
+	activate Node A
+	Node A->>Node B: Modify repo X
+	Node A->>Node C: Modify repo X
+	Node A->>Praefect: Modification successful!
+```
+
+Orchestration requires designating a leader node for the transaction. This leader node becomes a critical path for all nodes involved. Ideally, we want several simpler (less riskier) operations that can succeed/fail independently of each other. This way, failure and recovery can be handled externally of the nodes.
+
+#### Praefect Orchestrated [👍]
+With the praefect orchestrating replication, we are isolating the critical path to a stateless service. Stateless services are preferred for the critical path since another praefect can pick up the task after a praefect failure.
+
+```mermaid
+sequenceDiagram
+	Praefect->>Node A: Modify repo X
+	Node A->>Praefect: Success!
+	Praefect->>Node B: Replicate From A
+	Praefect->>Node C: Replicate From A
+	Node B->>Praefect: Success!
+	Node C->>Praefect: Success!
+```
+
+*Note: Once Node-A propagates changes to a peer, Node-A is no longer the critical path for subsequent propagations. If Node-A fails after a second peer is propagated, that second peer can become the new leader and resume replications.*
+
+## Notes
+* Existing discussions
+	* Requirements: https://gitlab.com/gitlab-org/gitaly/issues/1332
+	* Design: https://gitlab.com/gitlab-org/gitaly/issues/1335
+* Prior art
+	* Stemma by Palantir
+		* [Announcement](https://medium.com/palantir/stemma-distributed-git-server-70afbca0fc29)
+		* Extends jgit (java git implementation)
+	* Spokes by GitHub
+		* Application layer approach: uses underlying git software to propagate changes to other locations.
+	* Bitbucket Data Center (BDC)
+		* [BDC FAQ](https://confluence.atlassian.com/enterprise/bitbucket-data-center-faq-776663707.html)
+	* Ketch by Google (no longer maintained)
+		* [Sid's comment on performance issue](https://news.ycombinator.com/item?id=13934698)
+		* Also jgit based
+* gRPC proxy considerations
+	* [gRPC Proxy library](https://github.com/mwitkow/grpc-proxy)
+		* Pros
+			* Handles all gRPC requests generically
+		* Cons
+			* Lack of support
+				* [See current importers of project](https://godoc.org/github.com/mwitkow/grpc-proxy/proxy?importers)
+			* Low level implementation requires knowledge of gRPC internals
+	* Custom code generation
+		* Pros
+			* Simple and maintainable
+			* Allows us to handwrite proxy code and later automate with lessons learned via code generation
+		* Cons
+			* Process heavy; requires custom tooling
+			* Requires a way to tell which methods are read/write
+				* [See WIP for marking modifying RPCs](https://gitlab.com/gitlab-org/gitaly-proto/merge_requests/228)
+	* See also:
+		* [nRPC](https://github.com/nats-rpc/nrpc) - gRPC via NATS
+		* [grpclb](https://github.com/bsm/grpclb) - gRPC load balancer
+* Complications
+	* Existing Rails app indicates the Gitaly instance that a request is destined for (e.g. request to modify repo X should be directed to gitaly #1).
+		* This means that rails app must be kept in the loop about any changes made to the location of a repo.
+		* This may be mitigated by changing the proxy implementation to intepret the destination address as a reference to a shard rather than a specific host. This might open the door to allowing for something like consistent hashing.
+    * While Git is distributed in nature, some write operations need to be serialized to avoid race conditions. This includes ref updates.
+	* How do we coordinate proxies when applying ref updates? Do we need to?
+