ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #459 from mDuo13/clustering_ex

Browse Source 
Clustering: improve tutorial, revise related API methods
This commit is contained in:
Rome Reginelli
2018-10-05 16:14:08 -07:00
committed by GitHub
parent 98cd7417bd bbe36941e2
commit c32afaae95
5 changed files with 85 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
content/concepts/the-rippled-server/clustering.md
View File

@@ -8,19 +8,7 @@ If you are running multiple `rippled` servers in a single datacenter, you can co
If you are running a validator as a [private peer](peer-protocol.html#private-peers), Ripple recommends using a cluster of `rippled` servers as proxy servers.
## Configuring Clustering
To enable clustering, change the following sections of your [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) for each server:
1. List the IP address and port of each other server under the `[ips_fixed]` section. The port should be the one from the other servers' `protocol = peer` setting in their `rippled.cfg`. Example:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
2. Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
3. Add each node's peer-communication public key (generated in step 2) to the `[cluster_nodes]` section of each of your other servers' config files.
For a tutorial on how to set up your servers in a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

7
content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md
View File

@@ -1,10 +1,15 @@
# validation_create
[[Source]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
Use the `validation_create` command to generate the keys for a rippled [validator](rippled-server-modes.html#reasons-to-run-a-validator). Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
Use the `validation_create` command to generate cryptographic keys a `rippled` server can use to identify itself to the network. Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
_The `validation_create` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications (node key pair).
**Tip:** For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](run-rippled-as-a-validator.html#validator-setup).
### Request Format
An example of the request format:

4
content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md
View File

@@ -298,8 +298,8 @@ The `info` object may have some arrangement of the following fields:
| `load_factor_fee_queue` | Number | (May be omitted) The current multiplier to the [transaction cost][] that a transaction must pay to get into the queue, if the queue is full. [New in: rippled 0.32.0][] |
| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] |
| `peers` | Number | How many other `rippled` servers this one is currently connected to. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This key is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) |
| `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This _node key pair_ is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) You can set a persistent value in the config file using the `[node_seed]` config option, which is useful for [clustering](clustering.html). |
| `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. This _validation key pair_ is derived from the `[validator_token]` or `[validation_seed]` config field. |
| `server_state` | String | A string indicating to what extent the server is participating in the network. See [Possible Server States](rippled-server-states.html) for more details. |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |

4
content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
View File

@@ -265,8 +265,8 @@ The `state` object may have some arrangement of the following fields:
| `load_factor_fee_reference` | Integer | (May be omitted) The [transaction cost][] with no load scaling, in [fee levels][]. [New in: rippled 0.32.0][] |
| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] |
| `peers` | Number | How many other `rippled` servers this one is currently connected to. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This key pair is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) |
| `pubkey_validator` | String | _(Admin only)_ Public key of the keypair used by this server to sign proposed ledgers for validation. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This _node key pair_ is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) You can set a persistent value in the config file using the `[node_seed]` config option, which is useful for [clustering](clustering.html). |
| `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. This _validation key pair_ is derived from the `[validator_token]` or `[validation_seed]` config field. |
| `server_state` | String | A string indicating to what extent the server is participating in the network. See [Possible Server States](rippled-server-states.html) for more details. |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |

85
content/tutorials/manage-the-rippled-server/cluster-rippled-servers.md
View File

@@ -1,22 +1,85 @@
# Cluster rippled Servers
If you are running multiple `rippled` servers in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
If you run multiple `rippled` servers in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
* Clustered `rippled` servers share the work of cryptography. If one server has verified the authenticity of a message, the other servers in the cluster trust it and do not re-verify.
* Clustered servers share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all servers of the cluster at once.
* Clustered servers always propagate transactions throughout the cluster, even if the transaction does not meet the current load-based transaction fee on some of them.
1. For each of your servers, note the IP address of the server.
To enable clustering, change the following sections of your [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) for each server:
2. For each of your servers, generate a unique seed using the [validation_create method][].
* List the IP address and port of each other server under the `[ips_fixed]` section. The port should be the one from the other servers' `protocol = peer` setting in their `rippled.cfg`. Example:
For example, using the commandline interface:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
$ rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
Save the `validation_seed` and `validation_public_key` parameters from each response somewhere secure.
3. On each server, edit the [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg), modifying the following sections:
1. In the `[ips_fixed]` section, list the IP address and port of each _other_ member of the cluster. For each of those servers, the port number should match the `protocol = peer` port (usually 51235) from that server's `rippled.cfg`. For example:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
2. In the `[node_seed]` section, set the server's node seed to one of the `validation_seed` values you generated using the [validation_create method][] in step 2. Each server must use a unique node seed. For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
This defines the key pair the server uses to sign peer-to-peer communications, excluding validation messages.
3. In the `[cluster_nodes]` section, set the members of the server's cluster, identified by their `validation_public_key` values. Each server should list the public keys of all _other_ members of the cluster here. Optionally, add a custom name for each server. For example:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
This defines the key pairs the server uses to recognize members of its cluster.
4. After saving the config file, restart `rippled` on each server.
# systemctl restart rippled
5. To confirm that each server is now a member of the cluster, use the [peers method][]. The `cluster` field should list the public keys and (if configured) the custom names for each server.
For example, using the commandline interface:
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
... (omitted) ...
],
"status" : "success"
}
}
* Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
* Add the public keys (for peer communication) of each of your other servers under the `[cluster_nodes]` section.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}