mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
New top-level section of docs: Clusters & Federations
This commit is contained in:
troymc
@@ -124,7 +124,7 @@ fab --fabfile=fabfile-monitor.py --hosts=<EC2 hostname> run_monitor
|
||||
|
||||
For more information about monitoring (e.g. how to view the Grafana dashboard in your web browser), see the [Monitoring](monitoring.html) section of this documentation.
|
||||
|
||||
To configure a BigchainDB node to send monitoring data to the monitoring server, change the statsd host in the configuration of the BigchainDB node. The section on [Configuring a BigchainDB Node](configuration.html) explains how you can do that. (For example, you can change the statsd host in `$HOME/.bigchaindb`.)
|
||||
To configure a BigchainDB node to send monitoring data to the monitoring server, change the statsd host in the configuration of the BigchainDB node. The section on [Configuring a BigchainDB Node](../nodes/configuration.html) explains how you can do that. (For example, you can change the statsd host in `$HOME/.bigchaindb`.)
|
||||
|
||||
|
||||
## Deploy a BigchainDB Cluster
|
||||
38
docs/source/clusters-feds/federation-set-up.md
Normal file
38
docs/source/clusters-feds/federation-set-up.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Set Up and Run a Federation
|
||||
|
||||
This section is about how to set up and run a BigchainDB _federation_, where each node is operated by a different operator. If you want to set up and run a BigchainDB cluster on AWS (where all nodes are operated by you), then see [the section about that](deploy-on-aws.html).
|
||||
|
||||
|
||||
## Initial Checklist
|
||||
|
||||
* Do you have a governance process for making federation-level decisions, such as how to admit new members?
|
||||
* What will you store in creation transactions (data payload)? Is there a data schema?
|
||||
* Will you use transfer transactions? Will they include a non-empty data payload?
|
||||
* Who will be allowed to submit transactions? Who will be allowed to read or query transactions? How will you enforce the access rules?
|
||||
|
||||
|
||||
## Set Up the Initial Cluster
|
||||
|
||||
When you first start a federation cluster, the initial nodes will all start at roughly the same time.
|
||||
|
||||
The steps to set up a cluster node are outlined in the section titled [Set Up and Run a Node](../nodes/setup-run-node.html). You'll need two pieces of information from all other nodes in the federation:
|
||||
|
||||
1. Their RethinkDB hostname, e.g. `rdb.farm2.organization.org`
|
||||
2. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK`
|
||||
|
||||
|
||||
## Documentation to Come
|
||||
|
||||
* Backing Up & Restoring data
|
||||
* Adding a node (including resharding etc.)
|
||||
* Removing a node
|
||||
* Logging
|
||||
* Node monitoring & crash recovery
|
||||
* Node Security
|
||||
* Securing your OS
|
||||
* Firewalls and security groups. Remember to open port 123 for NTP.
|
||||
* (Private) key management
|
||||
* RethinkDB security
|
||||
* Cluster monitoring
|
||||
* Internal watchdogs
|
||||
* External watchdogs
|
||||
13
docs/source/clusters-feds/index.rst
Normal file
13
docs/source/clusters-feds/index.rst
Normal file
@@ -0,0 +1,13 @@
|
||||
.. You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
BigchainDB Clusters & Federations
|
||||
=================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
federation-set-up
|
||||
deploy-on-aws
|
||||
monitoring
|
||||
|
||||
@@ -28,7 +28,7 @@ You can view the Grafana dashboard in your web browser at:
|
||||
|
||||
(You may want to replace `localhost` with another hostname in that URL, e.g. the hostname of a remote monitoring server.)
|
||||
|
||||
The login and password are `admin` by default. If BigchainDB is running and processing transactions, you should see analytics—if not, [start BigchainDB](setup-run-node.html#run-bigchaindb) and load some test transactions:
|
||||
The login and password are `admin` by default. If BigchainDB is running and processing transactions, you should see analytics—if not, [start BigchainDB](../nodes/setup-run-node.html#run-bigchaindb) and load some test transactions:
|
||||
```text
|
||||
$ bigchaindb load
|
||||
```
|
||||
@@ -13,6 +13,7 @@ Table of Contents
|
||||
introduction
|
||||
topic-guides/index
|
||||
nodes/index
|
||||
clusters-feds/index
|
||||
drivers-clients/index
|
||||
release-notes
|
||||
appendices/index
|
||||
|
||||
@@ -60,7 +60,7 @@ environment variables available are:
|
||||
- `BIGCHAINDB_KEYPAIR_PUBLIC` defines the public key of the BigchainDB node.
|
||||
- `BIGCHAINDB_KEYPAIR_PRIVATE` defines the private key of the BigchainDB node.
|
||||
- `BIGCHAINDB_KEYRING` is a colon-separated list of the public keys of all _other_ nodes in the cluster.
|
||||
- `BIGCHAINDB_STATSD_HOST` defines the hostname of the statsd server for [monitoring](monitoring.html).
|
||||
- `BIGCHAINDB_STATSD_HOST` defines the hostname of the statsd server for [monitoring](../clusters-feds/monitoring.html).
|
||||
- `BIGCHAINDB_STATSD_PORT` defines the port of the statsd server for monitoring.
|
||||
- `BIGCHAINDB_STATSD_RATE` is a float between `0` and `1` that defines the fraction of transaction operations sampled.
|
||||
- `BIGCHAINDB_API_ENDPOINT` defines the API endpoint to use (e.g. `http://localhost:9984/api/v1`).
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
# Set Up and Run a Federation
|
||||
|
||||
This section is about how to set up and run a BigchainDB _federation_, where each node is operated by a different operator. If you want to set up and run a BigchainDB cluster on AWS (where all nodes are operated by you), then see [the section about that](deploy-on-aws.html).
|
||||
|
||||
|
||||
## Answer Basic Questions
|
||||
|
||||
* Do you have a governance process for making federation-level decisions, such as how to admit new members?
|
||||
* What will you store in creation transactions (data payload)? Is there a data schema?
|
||||
* Will you use transfer transactions? Will they include a non-empty data payload?
|
||||
* Who will be allowed to submit transactions? Who will be allowed to read or query transactions? How will you enforce the access rules?
|
||||
|
||||
|
||||
## Set Up the Initial Cluster
|
||||
|
||||
When you first start a federation cluster, the initial nodes will all start at roughly the same time. Here are the steps to be taken by each node operator:
|
||||
|
||||
**Create a RethinkDB Cluster**
|
||||
|
||||
* Go through the steps of [Set Up and Run a Node](setup-run-node.html), up to "Configure RethinkDB Server"
|
||||
* Determine the hostname of the server running RethinkDB (e.g. `rethinkdb2.farm3.organization5.com`)
|
||||
* Share your RethinkDB hostname with all other members of the federation
|
||||
* Once you have all the RethinkDB hostnames, add them to your local RethinkDB configuration file as explained in [Configure RethinkDB Server](setup-run-node.html#configure-rethinkdb-server)
|
||||
* (TODO: Section with steps to make RethinkDB more secure)
|
||||
|
||||
**Install, Configure and Run BigchainDB**
|
||||
|
||||
* Continue with the steps of [Set Up and Run a Node](setup-run-node.html)
|
||||
* You will generate a default `.bigchaindb` config file at some point. It contains your public/private keypair.
|
||||
* Send your **public** key to all other federation members. If you accidentally send your private key, then delete your `.bigchaindb` config file, generate a new one, and send your new public key to all other federation members.
|
||||
* Once you have the public keys of all other federation members, put them in the `keyring` (list) in your `.bigchaindb` file. (Your keyring should _not_ include your public key.)
|
||||
|
||||
* TODO: Are there other things they should change in their `.bigchaindb` file?
|
||||
|
||||
* Make sure RethinkDB is Running (TODO: say how)
|
||||
* Start BigchainDB
|
||||
|
||||
```text
|
||||
$ bigchaindb start
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Documentation to Come
|
||||
|
||||
* Backing Up & Restoring data
|
||||
* Adding a node (including resharding etc.)
|
||||
* Removing a node
|
||||
* Logging
|
||||
* Node monitoring & crash recovery
|
||||
* Node Security
|
||||
* Securing your OS
|
||||
* Firewalls and security groups. Remember to open port 123 for NTP.
|
||||
* (Private) key management
|
||||
* RethinkDB security
|
||||
* Cluster monitoring
|
||||
* Internal watchdogs
|
||||
* External watchdogs
|
||||
@@ -1,31 +1,16 @@
|
||||
.. You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
BigchainDB Nodes, Clusters & Federations
|
||||
========================================
|
||||
|
||||
A **BigchainDB node** is a server or set of closely-linked servers running RethinkDB Server, BigchainDB Server, and other BigchainDB-related software. Each node is controlled by one person or organization.
|
||||
|
||||
A set of BigchainDB nodes can connect to each other to form a **cluster**. Each node in the cluster runs the same software. A cluster contains one logical RethinkDB datastore. A cluster may have additional servers to do things such as cluster monitoring.
|
||||
|
||||
The people and organizations that run the nodes in a cluster belong to a **federation** (i.e. another organization). A federation must have some sort of governance structure to make decisions. If a cluster is run by a single company, then the federation is just that company.
|
||||
|
||||
**What's the Difference Between a Cluster and a Federation?**
|
||||
|
||||
A cluster is just a bunch of connected nodes (computers). A cluster might be operated by just one person. A federation is an organization which has a cluster, and where each node in the cluster has a different operator.
|
||||
|
||||
Confusingly, we sometimes call a federation's cluster its "federation." You can probably tell what we mean from context.
|
||||
BigchainDB Nodes
|
||||
================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
node-requirements
|
||||
federation-set-up
|
||||
setup-run-node
|
||||
run-with-docker
|
||||
running-unit-tests
|
||||
configuration
|
||||
bigchaindb-cli
|
||||
python-server-api-examples
|
||||
deploy-on-aws
|
||||
monitoring
|
||||
|
||||
@@ -14,3 +14,4 @@ Topic guides give background and explain concepts at a high level.
|
||||
immutable
|
||||
assets
|
||||
models
|
||||
node-cluster-fed
|
||||
|
||||
13
docs/source/topic-guides/node-cluster-fed.md
Normal file
13
docs/source/topic-guides/node-cluster-fed.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Nodes, Clusters & Federations
|
||||
|
||||
A **BigchainDB node** is a server or set of closely-linked servers running RethinkDB Server, BigchainDB Server, and other BigchainDB-related software. Each node is controlled by one person or organization.
|
||||
|
||||
A set of BigchainDB nodes can connect to each other to form a **cluster**. Each node in the cluster runs the same software. A cluster contains one logical RethinkDB datastore. A cluster may have additional servers to do things such as cluster monitoring.
|
||||
|
||||
The people and organizations that run the nodes in a cluster belong to a **federation** (i.e. another organization). A federation must have some sort of governance structure to make decisions. If a cluster is run by a single company, then the federation is just that company.
|
||||
|
||||
**What's the Difference Between a Cluster and a Federation?**
|
||||
|
||||
A cluster is just a bunch of connected nodes (computers). A cluster might be operated by just one person. A federation is an organization which has a cluster, and where each node in the cluster has a different operator.
|
||||
|
||||
Confusingly, we sometimes call a federation's cluster its "federation." You can probably tell what we mean from context.
|
||||
Reference in New Issue
Block a user