Merge branch 'master' of https://github.com/zalando/spilo

zalando · Apr 24, 2015 · 679d560 · 679d560
2 parents 1b7a001 + 251a0e4
commit 679d560
Show file tree

Hide file tree

Showing 13 changed files with 142 additions and 103 deletions.
diff --git a/README.md b/README.md
@@ -0,0 +1 @@
+docs/README.md
diff --git a/docs/DESIGN.md b/docs/DESIGN.md
@@ -0,0 +1,115 @@
+Overview
+========
+We use PostgreSQL for this appliance because it provides a very robust RDBMS with a huge feature set. By using PostgreSQL we are also limited to its inherent limitations. One of those limitiations is that there can be only 1 master, it doesn't do multi-master replication (yet). Because of this limitation we decide to build an appliance that has 1 master cluster and n-slave clusters.
+
+Having a single master inside this appliance means there will be a single point of failure (SPOF): the master. During an issue with the master the slaves will however be available for querying: it will not be a full outage. To reduce the impact of losing this SPOF we want to promote one of the slaves to a master as soon as is possible if we determine the master is lost.
+
+Spilo was designed to be deployed on AWS.
+
+Architecture: VPC
+=================
+
+	VPC                                                              
+	+---------------------------------------------------------------+
+	|                                                               |
+	|                 etcd                                          |
+	|                   O            DNS Service Record (SRV)       |
+	|         +-----> O   O +-------> _etcd+server._tcp.example.com |
+	|         |        O O<+                                        |
+	|         |        ^   |                                        |
+	|         |        |   |            +-----+                     |
+	|         |        +---------------->     |                     |
+	|         |  +----------------------> DDS |                     |
+	|         |  |         |   +-------->     |                     |
+	|         |  |         |   |        +-----+                     |
+	| +--------------+  +--------------+                            |
+	| |-------v------|  |--v-----------|                            |
+	| ||            ||  ||            ||                            |
+	| ||HA Cluster 1||  ||HA Cluster 2||                            |
+	| ||            ||  ||            ||                            |
+	| |--------------|  |--------------|                            |
+	| +--------------+  +--------------+                            |
+	|                                                               |
+	+---------------------------------------------------------------+
+
+Considerations
+--------------
+When considering what to build we had to determine which problems we want to solve or prevent.
+The following points are important for us:
+
+- automatic failover
+- deploying a new HA-cluster can be done very quickly (< 15 minutes)
+- human interaction for creating a HA-cluster is minimal
+- sane defaults for a HA-cluster (security, configuration, backup)
+
+High Available cluster (HA-cluster)
+-----------------
+A set of machines serving PostgreSQL databases. Its architecture is explained in more detail further on.
+
+etcd
+----
+We were pointed towards etcd in combination with PostgreSQL by compose with their [governor](https://github.com/compose/governor). By using an external service which is specialized in solving the problem of distributed consencus we don't have to write our own. We will use one etcd per environment.
+
+To find out more about etcd: [coreos.com/etcd](https://coreos.com/etcd/)
+
+dds
+---
+A dynamic discovery service could be running which will gather information about the running HA-clusters. To find out which HA-clusters are running it will consult etcd.
+The results of its discovery will also be stored in etcd, so other tools can easily use the discovered information.
+
+
+
+Architecture: PostgreSQL High Available cluster
+================
+
+							+-----------------------+
+							| Elastic Load Balancer |
+							+-----------+-----------+
+										|
+								+-------+----------------------------+
+	 EC2 Instance				|          EC2 Instance              |
+	+--------------------------------+    +--------------------------------+
+	|                           |    |    |                          |     |
+	|  +--------------+         |    |    |  +--------------+        |     |
+	|  |              |         |    |    |  |              |        |     |
+	|  | etcd (proxy) |         |    |    |  | etcd (proxy) |        |     |
+	|  |              +----+    |    |    |  |              +----+   |     |
+	|  +--^-----------+    |    |    |    |  +--^-----------+    |   |     |
+	|     |                |    |    |    |     |                |   |     |
+	|     |                |    |    |    |     |                |   |     |
+	|     |                |    |    |    |     |                |   |     |
+	|  +--v-------+      +-v----v--+ |    |  +--v-------+      +-v---v---+ |
+	|  |          |      |         | |    |  |          |      |         | |
+	|  | Governor |      | HAProxy | |    |  | Governor |      | HAProxy | |
+	|  |          |      |         | |    |  |          |      |         | |
+	|  +--+-------+      +-+-------+ |    |  +--+-------+      +-+-------+ |
+	|     |                |         |    |     |                |         |
+	|     |                |         |    |     |                |         |
+	|     |                |         |    |     |                |         |
+	| +---v--------+       |         |    | +---v--------+       |         |
+	| | PostgreSQL |       |         |    | | PostgreSQL |       |         |
+	| +------------+       |         |    | +------------+       |         |
+	| |   Slave    |       +---------------->   Master   <-------+         |
+	| +------------+                 |    | +------------+                 |
+	| |            |                 |    | |            |                 |
+	| +------------+                 |    | +------------+                 |
+	|                                |    |                                |
+	+--------------------------------+    +--------------------------------+
+
+
+
+etcd proxy
+====
+We assume a Higly Available etcd-cluster to be available for spilo when it is bootstrapped; we will use a etcd-proxy running on localhost to be a bridge between a HA-cluster member and the etcd-cluster.
+
+HAProxy
+====
+
+Governor
+====
+
+PostgreSQL
+====
+
+
+
diff --git a/docs/README.md b/docs/README.md
@@ -0,0 +1,3 @@
+Introduction
+============
+Spilo (სფილო, small elephants) is a Highly Available PostgreSQL cluster (HA-cluster). It will run a number of clusters with one cluster being a master and the others being slaves. Its purpose is to provide a very resilient, highly available PostgreSQL cluster which can be configured and started within minutes.
diff --git a/docs/components/Governor.md b/docs/components/Governor.md
@@ -0,0 +1,4 @@
+Introduction
+============
+Governor is the process that "governs" PostgreSQL. It uses information from PostgreSQL to determine its health. It uses etcd to determine what role this PostgreSQL instance has within the HA-cluster.
+It can start, restart, promote, rebuild a PostgreSQL instance.
diff --git a/docs/components/HAProxy.md b/docs/components/HAProxy.md
@@ -0,0 +1,3 @@
+Introduction
+============
+We use HA-Proxy to route traffic to the right PostgreSQL instance. It uses etcd to determine which ip-address to route the requests to.
diff --git a/docs/components/dns-sync.md b/docs/components/dns-sync.md
@@ -0,0 +1,4 @@
+Introduction
+============
+To enable other tools to quickly discover and connect to the etcd-cluster we will update a DNS SRV record that points to the etcd-members.
+We need some sort of process to update this record if it is outdated.
diff --git a/docs/components/etcd-proxy.md b/docs/components/etcd-proxy.md
@@ -0,0 +1,3 @@
+Introduction
+============
+The etcd-proxy is the bridge between a HA-Cluster member and the etcd-cluster. By using a etcd-proxy we do not unnecessarily increase the quorum or the write performance of an etcd cluster, but we do have an etcd interface which knows about the etcd-cluster.
diff --git a/docs/components/etcd.md b/docs/components/etcd.md
@@ -0,0 +1,9 @@
+Introduction
+============
+For creating an etcd-cluster you need something to discover other members: a (public) etcd server, a valid DNS SRV record, or a static list of other members.
+This is needed to solve the chicken-egg problem: Before the cluster is functional, how do I know about the other cluster members.
+
+To help in solving this issue, we do not start etcd directly; we use a python script that forks an etcd process, after it has established what its peers are.
+It uses immutage AWS tags to gather this information.
+
+The script also takes caring of adding members later on and cleaning up members.
diff --git a/etcd-appliance/Dockerfile b/etcd-appliance/Dockerfile
diff --git a/etcd-appliance/README.md b/etcd-appliance/README.md
diff --git a/etcd-appliance/TODO b/etcd-appliance/TODO
diff --git a/etcd-appliance/etcd-wrapper.sh b/etcd-appliance/etcd-wrapper.sh
diff --git a/etcd-appliance/update-dns-from-etcd.py b/etcd-appliance/update-dns-from-etcd.py