Merge pull request #1388 from bigchaindb/update-docs-on-clusters

Updated the Docs about Clusters

docs/server/source/appendices/index.rst

@@ -22,5 +22,6 @@ Appendices
    firewall-notes
    ntp-notes
    rethinkdb-reqs
+   rethinkdb-backup
    licenses
    install-with-lxd

docs/server/source/appendices/rethinkdb-backup.md

@@ -1,6 +1,6 @@
-# Backing Up & Restoring Data
+# Backing Up and Restoring Data
 
-There are several ways to backup and restore the data in a BigchainDB cluster.
+This page was written when BigchainDB only worked with RethinkDB, so its focus is on RethinkDB-based backup. BigchainDB now supports MongoDB as a backend database and we recommend that you use MongoDB in production. Nevertheless, some of the following backup ideas are still relevant regardless of the backend database being used, so we moved this page to the Appendices.
 
 
 ## RethinkDB's Replication as a form of Backup

docs/server/source/clusters-feds/aws-testing-cluster.md

@@ -1,6 +1,6 @@
-# Deploy a Testing Cluster on AWS
+# Deploy a RethinkDB-Based Testing Cluster on AWS
 
-This section explains a way to deploy a cluster of BigchainDB nodes on Amazon Web Services (AWS) for testing purposes.
+This section explains a way to deploy a _RethinkDB-based_ cluster of BigchainDB nodes on Amazon Web Services (AWS) for testing purposes.
 
 ## Why?
 

docs/server/source/clusters-feds/index.rst

@@ -5,6 +5,5 @@ Clusters
    :maxdepth: 1
 
    set-up-a-cluster
-   backup
    aws-testing-cluster
    

docs/server/source/clusters-feds/set-up-a-cluster.md

@@ -3,7 +3,9 @@
 This section is about how to set up a BigchainDB cluster where each node is operated by a different operator. If you want to set up and run a testing cluster on AWS (where all nodes are operated by you), then see [the section about that](aws-testing-cluster.html).
 
 
-## Initial Checklist
+## Initial Questions
+
+There are many questions that must be answered before setting up a BigchainDB cluster. For example:
 
 * Do you have a governance process for making consortium-level decisions, such as how to admit new members?
 * What will you store in creation transactions (data payload)? Is there a data schema?
@@ -15,14 +17,12 @@ This section is about how to set up a BigchainDB cluster where each node is oper
 
 The consortium must decide some things before setting up the initial cluster (initial set of BigchainDB nodes):
 
-1. Who will operate a node in the initial cluster?
-2. What will the replication factor be? (It must be 3 or more for [RethinkDB failover](https://rethinkdb.com/docs/failover/) to work.)
-3. Which node will be responsible for sending the commands to configure the RethinkDB database?
+1. Who will operate each node in the initial cluster?
+2. What will the replication factor be? (It should be 3 or more.)
+3. Who will deploy the first node, second node, etc.?
 
-Once those things have been decided, each node operator can begin setting up their BigchainDB (production) node.
+Once those things have been decided, the cluster deployment process can begin. The process for deploying a production node is outlined in [the section on production nodes](../production-nodes/index.html).
 
-Each node operator will eventually need two pieces of information from all other nodes:
-
-1. Their RethinkDB hostname, e.g. `rdb.farm2.organization.org`
-2. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK`
+Every time a new BigchainDB node is added, every other node must update their [BigchainDB keyring](../server-reference/configuration.html#keyring) (one of the BigchainDB configuration settings): they must add the public key of the new node.
 
+To secure communications between BigchainDB nodes, each BigchainDB node can use a firewall or similar, and doing that will require additional coordination.