mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-05 16:57:59 +00:00
Re-levelization: move non-docs content, rename content→docs
For better URLs, the content folder has been renamed 'docs' and all other files have been moved up a level. Also, non-docs images have been moved to the static folder at the top level where they belong. Many relative paths had to be fixed to make this work.
This commit is contained in:
mDuo13
@@ -0,0 +1,72 @@
|
||||
---
|
||||
html: configure-amendment-voting.html
|
||||
parent: configure-rippled.html
|
||||
seo:
|
||||
description: プロトコル修正に伴うサーバーの投票を設定する。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- ブロックチェーン
|
||||
---
|
||||
# Amendment投票機能の設定
|
||||
|
||||
バリデーターとして設定されたサーバーは、[feature メソッド][]を使ってXRP Ledgerプロトコルの[Amendment](../../concepts/networks-and-servers/amendments.md)に投票することができます。(この方法には[管理者アクセス](../../tutorials/get-started/get-started-using-http-websocket-apis.md#管理者アクセス権限)が必要です).
|
||||
|
||||
例えば、「SHAMapV2」Amendmentに反対票を投じるには、以下のコマンドを実行します。
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": "any_id_here",
|
||||
"command": "feature",
|
||||
"feature": "SHAMapV2",
|
||||
"vetoed": true
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "feature",
|
||||
"params": [
|
||||
{
|
||||
"feature": "SHAMapV2",
|
||||
"vetoed": true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```sh
|
||||
rippled feature SHAMapV2 reject
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
**注記:** Amendmentの省略名は大文字と小文字が区別されます。また、AmendmentのIDを16進数で指定することもできますが、この場合は大文字と小文字が区別されません。
|
||||
|
||||
## 設定ファイルを使用する
|
||||
|
||||
もし、Amendmentの設定に設定ファイルを使いたい場合は、`[rpc_startup]` 節に行を追加して、起動時に各明示票のために自動的にコマンドを実行させることができます。例えば
|
||||
|
||||
```
|
||||
[rpc_startup]
|
||||
{ "command": "feature", "feature": "SHAMapV2", "vetoed": true }
|
||||
```
|
||||
|
||||
変更を有効にするには、必ずサーバーを再起動してください。
|
||||
|
||||
**注意事項:** `[rpc_startup]` 節にあるコマンドは、サーバが起動するたびに実行され、サーバが動作している間に構成された投票設定を上書きすることができます。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Amendment](../../concepts/networks-and-servers/amendments.md)
|
||||
- [既知のAmendment](/resources/known-amendments.md)
|
||||
- [feature メソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
58
@i18n/ja/docs/infrastructure/configuration/configure-grpc.md
Normal file
58
@i18n/ja/docs/infrastructure/configuration/configure-grpc.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
html: configure-grpc.html
|
||||
parent: configure-rippled.html
|
||||
seo:
|
||||
description: gRPC APIを有効にして設定します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# gRPCの設定
|
||||
|
||||
`rippled`サーバは[P2Pモードサーバ](../../concepts/networks-and-servers/rippled-server-modes.md)が提供できる限定的な[gRPC API](https://grpc.io/)を持っています。レポートモードのサーバはこのAPIを使って、最新の有効なレジャーやトランザクションに関するデータを取得します。新しい設定を使って、サーバ上でgRPC APIを有効にすることができます。
|
||||
|
||||
**注意:** gRPCのサポートは、特にP2Pモードサーバからレポートモードサーバにデータを提供することを目的としています。gRPC APIは予告なく変更される可能性がありますし、将来のバージョンで完全に削除される可能性もあります。
|
||||
|
||||
## 前提条件
|
||||
|
||||
gRPCを有効にするには、次の前提条件を満たす必要があります。
|
||||
|
||||
- [rippledのインストール](../installation/index.md)が必要です。.
|
||||
|
||||
- サーバは選択したポートに接続できる必要があります。
|
||||
|
||||
## 手順
|
||||
|
||||
サーバでgRPCを有効にするには、以下の手順を実行します。
|
||||
|
||||
1. `[port_grpc]`が`rippled`設定ファイルにあることを確認してください。
|
||||
|
||||
```
|
||||
[port_grpc]
|
||||
port = 50051
|
||||
ip = 127.0.0.1
|
||||
```
|
||||
|
||||
- `port`はサーバがクライアントアプリケーションからのgRPC接続を待ち受けるポートを定義します。推奨されるポートは`50051`です。
|
||||
- ip`はサーバが待ち受けるインタフェースを定義します。127.0.0.1`はローカルループバックネットワーク(同じマシン)への接続を制限し、デフォルトで有効になっています。この値を`0.0.0.0`に変更すると、利用可能なすべてのネットワークインターフェイスを待ち受けます。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. `rippled`サービスを開始（または再起動）します。
|
||||
|
||||
```
|
||||
sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](/about/)
|
||||
- [`rippled`サーバのモード](../../concepts/networks-and-servers/rippled-server-modes.md)
|
||||
- **チュートリアル:**
|
||||
- [HTTP / WebSocketAPIを使ってみる](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
|
||||
- [信頼できるトランザクションの送信](../../concepts/transactions/reliable-transaction-submission.md)
|
||||
- [rippledサーバの管理](../installation/install-rippled-on-ubuntu.md)
|
||||
- **リファレンス:**
|
||||
- [HTTP / WebSocket APIリファレンス](../../references/http-websocket-apis/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
html: configure-statsd.html
|
||||
parent: configure-rippled.html
|
||||
seo:
|
||||
description: StatsDの統計データでrippledサーバを監視します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# StatsDの設定
|
||||
|
||||
`rippled`は自分自身に関するヘルスや動作情報を[StatsD](https://github.com/statsd/statsd)フォーマットでエクスポートできます。これらの情報は、[`rippledmon`](https://github.com/ripple/rippledmon)やStatsDフォーマットの統計情報を受け付ける他のコレクターを通して取得し、可視化することができます。
|
||||
|
||||
## 設定の手順
|
||||
|
||||
`rippled`サーバでStatsDを有効にするには、以下の手順を実行します。
|
||||
|
||||
1. 別のマシンで`rippledmon`インスタンスをセットアップし、統計情報を受信して集計します。
|
||||
|
||||
```
|
||||
$ git clone https://github.com/ripple/rippledmon.git
|
||||
$ cd rippledmon
|
||||
$ docker-compose up
|
||||
```
|
||||
|
||||
上記の手順を実行する際には、[Docker](https://docs.docker.com/)と[DockerCompose](https://docs.docker.com/compose/install/)がマシンにインストールされていることを確認してください。`rippledmon`の設定については、[`rippledmon`リポジトリ](https://github.com/ripple/rippledmon)をご覧ください。
|
||||
|
||||
0. `[insight]`を`rippled`の設定ファイルに追加します。
|
||||
|
||||
```
|
||||
[insight]
|
||||
server=statsd
|
||||
address=192.0.2.0:8125
|
||||
prefix=my_rippled
|
||||
```
|
||||
|
||||
- `address`には`rippledmon`が接続しているIPアドレスとポートを指定します。デフォルトでは、このポートは8125です。
|
||||
- `prefix`には設定する`rippled`サーバを識別する名前を指定します。prefixには、空白、コロン":"、または縦棒"|"を含めてはいけません。このprefix(接頭辞)は、このサーバからエクスポートされるすべてのStatsDの統計情報に表示されます。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
1. `rippled`サービスを再起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
2. 統計情報がエクスポートされていることを確認します。
|
||||
|
||||
```
|
||||
$ tcpdump -i en0 | grep UDP
|
||||
```
|
||||
|
||||
`en0`をあなたのマシンの適切なネットワークインターフェースに置き換えてください。あなたのマシンのインターフェースの完全なリストを取得するには`$ tcpdump -D`を使ってください。
|
||||
|
||||
出力の例:
|
||||
|
||||
```
|
||||
00:41:53.066333 IP 192.0.2.2.63409 > 192.0.2.0.8125: UDP, length 196
|
||||
```
|
||||
|
||||
`rippledmon`インスタンスの設定されたアドレスとポートへの送信トラフィックを示すメッセージが定期的に表示されるはずです。
|
||||
|
||||
StatsDの各データの説明については、[`rippledmon`リポジトリ](https://github.com/ripple/rippledmon)をご覧ください。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](/about/)
|
||||
- [`rippled`サーバ](../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`のインストール](../installation/index.md)
|
||||
- [容量の計画](../installation/capacity-planning.md)
|
||||
- **リアファレンス:**
|
||||
- [server_infoメソッド](../../references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md)
|
||||
- [printメソッド](../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/print.md)
|
||||
@@ -0,0 +1,233 @@
|
||||
---
|
||||
html: connect-your-rippled-to-the-xrp-test-net.html
|
||||
parent: configure-rippled.html
|
||||
seo:
|
||||
description: rippledサーバーをTest Netに接続して、模造の資金を使って新しい機能を試したり、機能をテストしたりします。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- ブロックチェーン
|
||||
- 開発
|
||||
---
|
||||
# rippledを並列ネットワークに接続
|
||||
|
||||
様々な[テスト用・開発用の代替ネットワーク](../../concepts/networks-and-servers/parallel-networks.md)が存在しており、開発者は実際の資金をリスクにさらすことなく、アプリのテストや機能の実験を行うことができます。**これらのネットワークで使用される資金は実際の資金ではなく、テスト専用です。**あなたの[`rippled`サーバ](../../concepts/networks-and-servers/index.md)をこれらのテストネットワークのいずれかに接続することができます。
|
||||
|
||||
**警告:** 新機能や実験的な機能を持つテストネットワークでは、ネットワークと同期するためにサーバの本番リリース前のリリースを実行することが必要になる場合があります。各ネットワークに必要なコードのバージョンについては、[並列ネットワークのページ](../../concepts/networks-and-servers/parallel-networks.md)をご覧ください。
|
||||
|
||||
## 手順
|
||||
|
||||
あなたの`rippled`サーバをXRPテストネットまたは開発ネットに接続するには、次の手順に従ってください。また、テストネットや開発ネットに接続した後、本番用メインネットに切り替えることもできます。
|
||||
|
||||
## 1. 適切なハブに接続するようにサーバを設定します。
|
||||
|
||||
`rippled.cfg`ファイルを編集します。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
<!--{_ }-->
|
||||
|
||||
1. `[ips]`に接続したいネットワークのハブを設定します。
|
||||
|
||||
{% tabs %}
|
||||
|
||||
```{% label="Testnet" %}
|
||||
[ips]
|
||||
s.altnet.rippletest.net 51235
|
||||
```
|
||||
|
||||
```{% label="Devnet" %}
|
||||
[ips]
|
||||
s.devnet.rippletest.net 51235
|
||||
```
|
||||
|
||||
```{% label="Mainnet" %}
|
||||
# No [ips] stanza. Use the default hubs to connect to Mainnet.
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[ips]
|
||||
sidechain-net2.devnet.rippletest.net 51235
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
2. 以前の `[ips]`があれば、コメントアウトしてください。
|
||||
|
||||
```
|
||||
# [ips]
|
||||
# r.ripple.com 51235
|
||||
# zaphod.alloy.ee 51235
|
||||
# sahyadri.isrdc.in 51235
|
||||
```
|
||||
|
||||
3. `[network_id]`に適切な値を追加します。
|
||||
|
||||
{% tabs %}
|
||||
|
||||
```{% label="Testnet" %}
|
||||
[network_id]
|
||||
testnet
|
||||
```
|
||||
|
||||
```{% label="Devnet" %}
|
||||
[network_id]
|
||||
devnet
|
||||
```
|
||||
|
||||
```{% label="Mainnet" %}
|
||||
[network_id]
|
||||
main
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[network_id]
|
||||
262
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
カスタムネットワークの場合、そのネットワークに接続する全員が、そのネットワークに固有の値を使用する必要があります。新しいネットワークを作成するときは、ネットワークIDを11から4,294,967,295までの整数からランダムに選択します。
|
||||
|
||||
**注記:** この設定はサーバが同じネットワーク上にいる仲間を見つけるのに役立ちますが、サーバがどのネットワークに従うかを厳密に制御するものではありません。UNL/信頼できるバリデータの設定(次のステップ)はサーバが従うネットワークを定義するものです。
|
||||
|
||||
## 2. 信頼できるバリデータリストの設定
|
||||
|
||||
`validators.txt`ファイルを編集します。このファイルは`rippled.cfg`ファイルと同じフォルダにあり、どのバリデータが共謀しないと信頼するかを定義します。
|
||||
|
||||
1. 接続したいネットワークの`[validator_list_sites]`と`[validator_list_keys]`コメントを解除するか、追加します。
|
||||
|
||||
{% tabs %}
|
||||
|
||||
```{% label="Testnet" %}
|
||||
[validator_list_sites]
|
||||
https://vl.altnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
```
|
||||
|
||||
```{% label="Devnet" %}
|
||||
[validator_list_sites]
|
||||
https://vl.devnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
|
||||
```
|
||||
|
||||
```{% label="Mainnet" %}
|
||||
[validator_list_sites]
|
||||
https://vl.ripple.com
|
||||
|
||||
[validator_list_keys]
|
||||
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[validator_list_sites]
|
||||
https://vlsidechain-net2.devnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
**ヒント:** プレビュー版パッケージには必要な項目があらかじめ設定されている場合がありますが、念のため確認してください。
|
||||
|
||||
2. 以前の`[validator_list_sites]`,`[validator_list_keys]`,または`[validators]`をコメントアウトします。
|
||||
|
||||
例えば:
|
||||
|
||||
```
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
|
||||
# Old hard-coded List of Devnet Validators
|
||||
# [validators]
|
||||
# n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
|
||||
# n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
|
||||
# n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
|
||||
# n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
|
||||
# n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
|
||||
# n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
|
||||
# n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
|
||||
```
|
||||
|
||||
## 3. 機能を有効化(無効化)する
|
||||
|
||||
実験的な機能を使用するテストネットワークでは、設定ファイルで該当する機能を強制的に有効にする必要があります。その他のネットワークでは、`[features]`を使用しないでください。設定ファイルの`[features]`を以下のように追加または変更します。
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="Testnet" %}
|
||||
```
|
||||
# [features]
|
||||
# Delete or comment out. Don't force-enable features on Testnet.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Devnet" %}
|
||||
```
|
||||
# [features]
|
||||
# Delete or comment out. Don't force-enable features on Devnet.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Mainnet" %}
|
||||
```
|
||||
# [features]
|
||||
# Delete or comment out. Don't force-enable features on Mainnet.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Sidechain-Devnet" %}
|
||||
```
|
||||
[features]
|
||||
XChainBridge
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
**警告:** メインネットまたはテストネットに接続するときは、`[features]`を使用しないでください。他のネットワークと異なる機能を強制的に有効にすると、サーバがネットワークから分断される可能性があります。
|
||||
|
||||
## 4. サーバーを再起動する
|
||||
|
||||
```sh
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
## 5. サーバの同期を確認します。
|
||||
|
||||
再起動後、ネットワークに同期するのに約5分から15分かかります。サーバの同期が完了すると、[server_infoメソッド][]は接続しているネットワークに基づいた`validated_ledger`オブジェクトを表示します。
|
||||
|
||||
自分の`rippled`が正しいネットワークに接続されていることを確認するには、自分のサーバの結果をTestnetまたはDevnet上の[公開サーバ][public servers]と比較してください。`validated_ledger`オブジェクトの`seq`フィールドはどちらのサーバーでも同じはずです（チェックしている間に変更された場合は、1つか2つずれている可能性があります）。
|
||||
|
||||
次の例は、コマンドラインからサーバーの最新の検証済みレジャーをチェックする方法を示しています。
|
||||
|
||||
```sh
|
||||
rippled server_info | grep seq
|
||||
```
|
||||
|
||||
WebSocketツールの[server_info](/resources/dev-tools/websocket-api-tool#server_info)を使って、対象のネットワーク上の最新のレジャーインデックス(`seq`)を調べることができます。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ツール:**
|
||||
- [XRP Faucets](/resources/dev-tools/xrp-faucets)
|
||||
- [WebSocket APIツール](/resources/dev-tools/websocket-api-tool) - 接続オプションで「Testnet Public Server」または「Devnet Public Server」を選択します。
|
||||
- **コンセプト:**
|
||||
- [並列ネットワーク](../../concepts/networks-and-servers/parallel-networks.md)
|
||||
- [コンセンサス](../../concepts/consensus-protocol/index.md)
|
||||
- **チュートリアル:**
|
||||
- [バリデータとしてのrippledの実行](server-modes/run-rippled-as-a-validator.md)
|
||||
- [オフラインで`rippled`をスタンドアロンモードでテストする](../testing-and-auditing/index.md)
|
||||
- [`rippled`のトラブルシューティング](../troubleshooting/index.md)
|
||||
- **References:**
|
||||
- [server_infoメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
html: configure-advisory-deletion.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: 指示による削除を使用して、新しい履歴ができたときではなく、スケジュールで古いレジャー履歴を削除します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- データ保持
|
||||
---
|
||||
# 指示による削除の設定
|
||||
|
||||
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
|
||||
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
|
||||
|
||||
- `cron`デーモンがインストールされており、実行されている。
|
||||
|
||||
Ubuntu Linuxではデフォルトで`cron`デーモンが実行されます。
|
||||
|
||||
RHELまたはCentOSでは、以下の`cronie`パッケージをインストールできます。
|
||||
|
||||
```
|
||||
$ sudo yum install cronie
|
||||
```
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバーにある。
|
||||
|
||||
各種設定で必要なストレージの容量についての詳細は、[容量計画](../../installation/capacity-planning.md)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバーに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
|
||||
|
||||
- サーバーの使用率が最も低い時間帯を把握している。
|
||||
|
||||
## 設定手順
|
||||
|
||||
日次スケジュールで指示による削除は以下の手順で設定します。
|
||||
|
||||
1. `rippled`の構成ファイルの`[node_db]`スタンザで`advisory_delete`を有効にします。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
# Other settings unchanged ...
|
||||
online_delete=300000
|
||||
advisory_delete=1
|
||||
```
|
||||
|
||||
- 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
|
||||
- `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
|
||||
|
||||
このコマンドの実行には[`rippled`コマンドラインインターフェイス](../../../tutorials/get-started/get-started-using-http-websocket-apis.md#コマンドライン)を使用できます。例:
|
||||
|
||||
```
|
||||
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
|
||||
```
|
||||
|
||||
レスポンスは、サーバーがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"can_delete": 43633667,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
サーバー内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
|
||||
|
||||
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
|
||||
|
||||
`cron` 設定を編集します。
|
||||
|
||||
```
|
||||
$ crontab -e
|
||||
```
|
||||
|
||||
以下の例では、サーバー時刻で毎日1:05 AMにサーバーが削除を実行するように設定されています。
|
||||
|
||||
```
|
||||
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
|
||||
```
|
||||
|
||||
サーバーで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
|
||||
|
||||
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバーの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
|
||||
|
||||
4. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
5. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
|
||||
|
||||
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
|
||||
|
||||
サーバーの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。
|
||||
|
||||
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバーを実行できる権限があることを確認します。
|
||||
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
|
||||
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
|
||||
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
html: configure-full-history.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: 完全履歴サーバーは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- データ保持
|
||||
---
|
||||
# 全履歴の設定
|
||||
|
||||
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバーが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバーでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバーが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
|
||||
|
||||
## 警告
|
||||
|
||||
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバーパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
|
||||
|
||||
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバーが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバーオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバーをオペレーターのサーバーに明示的にピア接続することができます。サーバーはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
|
||||
|
||||
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバーは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバーを利用する必要があります。
|
||||
|
||||
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.md)すれば、レジャー履歴のグループをランダムに選択して保管できます。
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーが全履歴を取得して保管するように構成するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`サーバーが稼働中の場合は停止します。
|
||||
|
||||
```
|
||||
$ sudo systemctl stop rippled
|
||||
```
|
||||
|
||||
0. サーバーの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/nudb
|
||||
#online_delete=300000
|
||||
#advisory_delete=0
|
||||
```
|
||||
|
||||
全履歴が記録されるサーバーでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](../../installation/capacity-planning.md)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
|
||||
|
||||
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](../../troubleshooting/server-wont-start.md#状態dbエラー)可能性があります。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
|
||||
|
||||
```
|
||||
[ledger_history]
|
||||
full
|
||||
```
|
||||
|
||||
0. 全履歴が保管されている1台以上のサーバーと明示的にピア接続するように、サーバーの構成ファイルで`[ips_fixed]`スタンザを設定します。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
169.55.164.20
|
||||
50.22.123.215
|
||||
```
|
||||
|
||||
サーバーのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバーはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバーとピア接続することです。
|
||||
|
||||
**ヒント:** Rippleは、すべての履歴が記録されるサーバーのプールを公開しています。これらのサーバーのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバーは公開サービスとして提供されているため、他のサーバーとのピア接続での可用性は限られており、またこれらのサーバーを悪用するとブロックされる可能性があることに注意してください。
|
||||
|
||||
0. 全履歴が記録されている別のサーバーからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバーの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
|
||||
|
||||
```
|
||||
[import_db]
|
||||
type=NuDB
|
||||
path=/tmp/full_history_dump/
|
||||
```
|
||||
|
||||
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバーにある場合は、そのデータベースファイルを削除します。
|
||||
|
||||
オンライン削除を無効にすると、サーバーはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
|
||||
|
||||
```
|
||||
rm -r /var/lib/rippled/db/*
|
||||
```
|
||||
|
||||
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバーのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
|
||||
|
||||
0. `rippled`サーバーを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
|
||||
|
||||
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](../../commandline-usage.md#デーモンモードのオプション)を指定してサーバーを明示的に起動します。
|
||||
|
||||
```
|
||||
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
|
||||
```
|
||||
|
||||
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバーは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバーログを参照してください。
|
||||
|
||||
データベースダンプをインポートしない場合は、サーバーを通常の方法で起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl start rippled
|
||||
```
|
||||
|
||||
0. `[import_db]`スタンザをサーバーの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
|
||||
|
||||
このようにしないと、次回の再起動時にサーバーが同じデータを再びインポートしようとします。
|
||||
|
||||
0. [server_infoメソッド][]を使用して、サーバーの利用可能な履歴を監視します。
|
||||
|
||||
`complete_ledgers`フィールドに表示される利用可能なレジャーの範囲は、時間の経過とともに増加します。
|
||||
|
||||
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバーのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
html: configure-history-sharding.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: XRP Ledgerの履歴データのシャードを保存するようにサーバを設定します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# 履歴シャーディングの設定
|
||||
|
||||
[履歴シャーディング](history-sharding.md)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
|
||||
|
||||
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバーの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバーの経費を抑えるために、バリデータサーバーでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバーを実行することが推奨されます。
|
||||
|
||||
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
|
||||
|
||||
## 1. シャードストアーに割り当てる容量を決めます。
|
||||
|
||||
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
|
||||
|
||||
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
|
||||
- レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
|
||||
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
|
||||
- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
|
||||
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
|
||||
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
|
||||
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
|
||||
|
||||
## 2. rippled.cfgの編集
|
||||
|
||||
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
以下のスニペットに、`[shard_db]`スタンザの例を示します。
|
||||
|
||||
```
|
||||
[shard_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/shards/nudb
|
||||
max_size_gb=50
|
||||
```
|
||||
|
||||
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}新規: rippled 1.3.1{% /badge %}
|
||||
|
||||
**注意:** `rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](../../troubleshooting/server-wont-start.md)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー（`rippled` 1.2.x以前）を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。
|
||||
|
||||
詳細は、[rippled.cfgの設定例](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
|
||||
|
||||
## 3. サーバーの再起動
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
## 4. シャードのダウンロードの待機
|
||||
|
||||
サーバーはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
|
||||
|
||||
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
|
||||
|
||||
[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
|
||||
|
||||
サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を使用します。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [レジャー履歴](../../../concepts/networks-and-servers/ledger-history.md)
|
||||
- [オンライン削除](online-deletion.md)
|
||||
- **チュートリアル:**
|
||||
- [オンライン削除の設定](configure-online-deletion.md)
|
||||
- [ピアクローラーの設定](../peering/configure-the-peer-crawler.md)
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- **リファレンス:**
|
||||
- [download_shardメソッド][]
|
||||
- [crawl_shardsメソッド][]
|
||||
- [レジャーデータフォーマット](../../../references/protocol/ledger-data/index.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
html: configure-online-deletion.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: サーバーでどこまで古いトランザクション履歴を保持するかを設定します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# オンライン削除の設定
|
||||
|
||||
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.md)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
|
||||
推奨されるプラットフォームのインストール手順に従えば、オンライン削除はデフォルトで有効となります。
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](../../installation/capacity-planning.md)がサーバーにある。
|
||||
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーに保管する履歴の量を変更するには、以下の手順を実行します。
|
||||
|
||||
1. 保管する履歴に相当するレジャーバージョンの数を決定します。
|
||||
|
||||
新しいレジャーバージョンは通常3～4秒間隔で検証されます。このため、レジャーバージョンの数は、保管する期間におおむね対応しています。各種構成で必要なストレージの容量についての詳細は、[容量計画](../../installation/capacity-planning.md)を参照してください。
|
||||
|
||||
オンライン削除は、履歴の削除 _後_ に維持するレジャーバージョンの数に基づいておこなわれるので、設定した維持するレジャー数の2倍を保管するのに十分なディスク容量が必要です。
|
||||
|
||||
0. `rippled`の構成ファイルで`[node_db]` スタンザの`online_delete`フィールドを編集します。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
# Other settings unchanged ...
|
||||
online_delete=300000
|
||||
advisory_delete=0
|
||||
```
|
||||
|
||||
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
0. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
0. サーバーがネットワークと同期するまで待ちます。
|
||||
|
||||
ネットワークとシステムの能力と、サーバーがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
|
||||
|
||||
サーバーとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
|
||||
|
||||
0. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
|
||||
|
||||
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバーに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
|
||||
|
||||
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
|
||||
この状況が定期的に発生する場合は、サーバーのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバーがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
|
||||
|
||||
- システムスペックを強化する。推奨事項については、[システム要件](../../installation/system-requirements.md)を参照してください。
|
||||
- 設定を変更し、保管する履歴の量を減らす。（このチュートリアルのステップ2）
|
||||
- サーバーの[`node_size`パラメーター](../../installation/capacity-planning.md)を変更する。
|
||||
- レジャーストアーに[RocksDBの代わりにNuDB](../../installation/capacity-planning.md)を使用する。
|
||||
- [指示による削除を使用してオンライン削除をスケジュールする](configure-advisory-deletion.md)。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [オンライン削除](online-deletion.md)
|
||||
- [指示による削除の設定](configure-advisory-deletion.md)
|
||||
- [履歴シャーディングの設定](configure-history-sharding.md)
|
||||
- [完全な履歴の設定](configure-full-history.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
html: history-sharding.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバー間で分担するようにします。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# 履歴シャーディング
|
||||
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.90.0" %}導入: rippled 0.90.0{% /badge %}
|
||||
|
||||
稼働中のサーバーは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバーは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
|
||||
|
||||
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバー全体に分散します。シャードは、一連のレジャーです。`rippled`サーバーは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
|
||||
|
||||
履歴シャーディング機能を使用すると、個々の`rippled`サーバーが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
|
||||
|
||||
[](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)
|
||||
|
||||
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
|
||||
|
||||
## 履歴シャードの取得と共有
|
||||
|
||||
`rippled` サーバーは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバーでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバー が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
|
||||
|
||||
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバーがローカルでデータを確認します。取得できないデータについては、サーバーはピア`rippled`サーバーにデータをリクエストします。リクエストされた期間のデータを供給できるサーバーは、履歴でレスポンスします。リクエスト側サーバーはこれらのレスポンスを結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
|
||||
|
||||
`rippled`サーバーが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバーはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
|
||||
|
||||
## XRP Ledgerネットワークデータの整合性
|
||||
|
||||
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバー間で共有されます。これにより、各サーバーは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバーは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [履歴シャーディングの設定](configure-history-sharding.md)
|
||||
- [download_shardメソッド][]
|
||||
- [crawl_shardsメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
html: data-retention.html
|
||||
parent: configure-rippled.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: サーバが保存するデータの量と、古いデータを削除するタイミングを制御します。
|
||||
---
|
||||
# データの保存
|
||||
|
||||
サーバが保存するデータの量と、古いバージョンのレジャーステートや過去のトランザクションを含む古いデータを削除するタイミングを制御します。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
html: online-deletion.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: オンライン削除は古いトランザクションと状態の履歴を消去します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# オンライン削除
|
||||
[[ソース]<br/>](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
|
||||
オンライン削除機能により、`rippled`サーバーはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}新規: rippled 0.27.0{% /badge %}
|
||||
|
||||
サーバーは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
|
||||
|
||||
デフォルトの構成ファイルは、`rippled`サーバーが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
|
||||
|
||||
**ヒント:** オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](../../installation/capacity-planning.md)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
`rippled`サーバーでは[レジャー履歴](../../../concepts/networks-and-servers/ledger-history.md)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
|
||||
|
||||
レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
|
||||
|
||||
|
||||
## オンライン削除の動作
|
||||
|
||||
オンライン削除の設定では、`rippled`サーバーがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
|
||||
|
||||
- サーバーでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバーが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバーに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバーは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](../../../concepts/networks-and-servers/ledger-history.md#履歴の取得)を参照してください。）
|
||||
- オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。）
|
||||
|
||||
ＰＣサーバーがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバー内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
|
||||
|
||||
- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバーが取得および作成したすべてのレジャーバージョンがサーバーに保存されます。
|
||||
|
||||
サーバーに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
|
||||
|
||||
- `online_delete`の間隔よりも頻繁に`can_delete`を呼び出す場合、サーバーには最大で **`online_delete`の値の2倍** にほぼ相当するレジャーバージョンが保存されます。（削除後には、この数はほぼ`online_delete`の値まで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`に値50,000を指定している場合、削除実行前のサーバーには通常、最大100,000のレジャーバージョンが蓄積されます。削除実行後は、少なくとも50,000のレジャーバージョン（約 2日分）がサーバーに保持されます。この設定では、約1回おきに`can_delete`を呼び出しした場合、変更が生じません。これは、削除するのに十分な数のレジャーバージョンがサーバーにないためです。
|
||||
|
||||
- `online_delete`の間隔 _よりも少ない頻度で_ `can_delete`を呼び出す場合、最大で **`can_delete`呼び出しの間隔のほぼ2倍** の期間にわたりレジャーバージョンがサーバーに保管されます。（削除後には、この数は約1間隔分のデータまで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバーでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバーには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
|
||||
|
||||
|
||||
オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバーに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
|
||||
|
||||
オンライン削除が実行されても、ディスク上のSQLiteデータベースファイルのサイズは減少しません。これらのファイルの中に新しいデータを入れるのに再利用できるスペースが確保されるだけです。オンライン削除によって、レジャーストアーが含まれるRocksDB または NuDB データベースファイルのサイズは _減少します_ 。
|
||||
|
||||
サーバーでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバーが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバーには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバーに保持される _検証済み_ レジャーの数には影響しません。
|
||||
|
||||
### オンライン削除の中断
|
||||
|
||||
[サーバーの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバーはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバーは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
|
||||
|
||||
サーバーを停止した場合や、オンライン削除の実行中にサーバーがクラッシュした場合には、サーバーが再起動し、完全に同期されれば、オンライン削除が再開されます。
|
||||
|
||||
オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド][]を使用できます。この変更は、[can_delete][can_delete method] をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#指示による削除)を参照してください。
|
||||
|
||||
|
||||
## 設定
|
||||
|
||||
オンライン削除に関連する設定は以下のとおりです。
|
||||
|
||||
- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバーは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
|
||||
|
||||
デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](../../../concepts/consensus-protocol/fee-voting.md)や[Amendmentプロセス](../../../concepts/networks-and-servers/amendments.md#amendmentプロセス)などのイベントで一度に更新されるレジャーの数が256であるためです。
|
||||
|
||||
**注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバーを再起動すると、`online_delete`が無効の間にサーバーがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバーを再起動する前に、既存の履歴を削除します。
|
||||
|
||||
- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバーの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
|
||||
|
||||
この設定のデフォルト値はレジャー256個です。
|
||||
|
||||
次の図は、`online_delete`設定と`ledger_history`設定の関係を示します。
|
||||
|
||||
|
||||
|
||||
- **`advisory_delete`** - 有効な場合、オンライン削除は自動的にスケジュールされません。代わりに管理者が手動でオンライン削除をトリガーする必要があります。無効にするには値`0`を使用し、有効にするには`1`を使用します。
|
||||
|
||||
この設定はデフォルトで無効になっています。
|
||||
|
||||
- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバーは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得リクエストを受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
|
||||
|
||||
`fetch_depth`のデフォルトは`full`です（使用可能なすべてのデータを提供します）。
|
||||
|
||||
`fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバーは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
|
||||
|
||||
次の図は、fetch_depthの仕組みを示します。
|
||||
|
||||
|
||||
|
||||
さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、[容量の計画](../../installation/capacity-planning.md#ディスク容量)を参照してください。
|
||||
|
||||
### 指示による削除
|
||||
|
||||
デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド][]を使用してオンライン削除をトリガーしたときにのみ実行されます。
|
||||
|
||||
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバーの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバーの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
|
||||
|
||||
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバーにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
|
||||
|
||||
`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバーの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバーを再起動しても維持されます。
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバーはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバーに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバーは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
|
||||
|
||||
オンライン削除を実行する場合、サーバーはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバーは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバーは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [can_deleteメソッド][] - APIリファレンス資料
|
||||
- [オンライン削除の設定](configure-online-deletion.md)
|
||||
- [指示による削除の設定](configure-advisory-deletion.md)
|
||||
- [完全な履歴の設定](configure-full-history.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
html: enable-public-signing.html
|
||||
parent: configure-rippled.html
|
||||
seo:
|
||||
description: 他の人があなたのサーバーを使ってトランザクションに署名できるようにします。（非推奨）
|
||||
labels:
|
||||
- コアサーバー
|
||||
- セキュリティ
|
||||
---
|
||||
# パブリック署名の有効化
|
||||
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}新規: rippled 1.1.0{% /badge %}デフォルトでは、`rippled`の署名メソッドは管理者接続に限定されています。v1.1.0以前のバージョンの`rippled`のように、署名メソッドをパブリックAPIメソッドとして使用できるようにするには、構成を変更することで、これを使用できるようにします。
|
||||
|
||||
これにより、サーバーが「パブリック」[JSON-RPC接続およびWebSocket接続](../../tutorials/get-started/get-started-using-http-websocket-apis.md)を受け入れる場合は、これらのパブリック接続で以下のメソッドが使用できるようになります。
|
||||
|
||||
- [sign][signメソッド]
|
||||
- [sign_for][sign_forメソッド]
|
||||
- [submit][submitメソッド]("sign-and-submit"モード)
|
||||
|
||||
これらのメソッドを使用するにあたり、管理者接続からパブリック署名を有効にする必要は**ありません**。
|
||||
|
||||
**注意:** パブリック署名を有効にすることは推奨されません。[wallet_proposeメソッド][]と同様に、署名コマンドでは管理レベルの権限を必要とするアクションは実行されませんが、署名コマンドを管理者接続に制限することにより、ユーザーが安全ではない通信経由で、またはユーザーの管理下にないサーバーとの間でシークレットキーを無責任に送受信することを防止します。
|
||||
|
||||
パブリック署名を有効にするには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の構成ファイルを編集します。
|
||||
|
||||
```
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. 以下のスタンザを構成ファイルに追加し、変更を保存します。
|
||||
|
||||
```
|
||||
[signing_support]
|
||||
true
|
||||
```
|
||||
|
||||
3. `rippled`サーバーを再起動します。
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
14
@i18n/ja/docs/infrastructure/configuration/index.md
Normal file
14
@i18n/ja/docs/infrastructure/configuration/index.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
html: configure-rippled.html
|
||||
parent: infrastructure.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: rippledサーバーの構成をカスタマイズします。
|
||||
---
|
||||
# rippledの設定
|
||||
|
||||
rippledサーバーの構成をカスタマイズします。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
html: cluster-rippled-servers.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: サーバーのグループで処理を分担するように設定して効率化します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# rippledサーバーのクラスター化
|
||||
|
||||
1つのデータセンターで複数の`rippled`サーバーを稼働している場合は、これらのサーバーを[クラスター](../../../concepts/networks-and-servers/clustering.md)に構成して、効率を最大化できます。クラスター構成の設定は次のとおりです。
|
||||
|
||||
1. 各サーバーのIPアドレスをメモします。
|
||||
|
||||
2. [validation_createメソッド][]を使用して各サーバーの一意のシードを生成します。
|
||||
|
||||
コマンドラインインターフェイスを使用する場合の例を以下に示します。
|
||||
|
||||
```
|
||||
$ 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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
各レスポンスの`validation_seed`パラメーターと`validation_public_key`パラメーターを安全な場所に保存します。
|
||||
|
||||
3. 各サーバーで[構成ファイル](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)を編集し、以下のセクションを変更します。
|
||||
|
||||
1. `[ips_fixed]`セクションに、クラスターの _その他の_ 各メンバーのIPアドレスとポートを記入します。各サーバーのポート番号は、サーバーの `rippled.cfg`に指定されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例:
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
192.168.0.1 51235
|
||||
192.168.0.2 51235
|
||||
```
|
||||
|
||||
この例では、このサーバーがダイレクトピアツーピア接続の維持を常に試みる先のピアサーバーを特定しています。
|
||||
|
||||
2. `[node_seed]`セクションでは、サーバーのノードシードを、ステップ2で[validation_createメソッド][]を使用して生成した`validation_seed`の値の1つに設定します。各サーバーは一意のノードシードを使用する必要があります。例:
|
||||
|
||||
```
|
||||
[node_seed]
|
||||
ssZkdwURFMBXenJPbrpE14b6noJSu
|
||||
```
|
||||
|
||||
この例では、ピアツーピア通信（検証メッセージを除く）の署名にサーバーが使用するキーペアを定義しています。
|
||||
|
||||
3. `[cluster_nodes]`セクションでは、サーバーのクラスターのメンバーを設定します。これらのメンバーは`validation_public_key`の値で識別されます。各サーバーのクラスターの _その他の_ すべてのメンバーをここに記入する必要があります。任意で、各サーバーのカスタム名を追加します。例:
|
||||
|
||||
```
|
||||
[cluster_nodes]
|
||||
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
|
||||
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
|
||||
```
|
||||
|
||||
この例は、サーバーがクラスターのメンバーを認識するために使用するキーペアを定義しています。
|
||||
|
||||
4. 構成ファイルを保存した後、各サーバーで`rippled`を再起動します。
|
||||
|
||||
```
|
||||
# systemctl restart rippled
|
||||
```
|
||||
|
||||
5. 各サーバーがクラスターのメンバーになっていることを確認するには、[peersメソッド][]を使用します。`cluster`フィールドに、各サーバーの公開鍵とカスタム名（構成している場合）のリストが表示されます。
|
||||
|
||||
コマンドラインインターフェイスを使用する場合の例を以下に示します。
|
||||
|
||||
```
|
||||
$ 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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
html: configure-a-private-server.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: サーバーが特定の信頼できるピアのみに接続するように設定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- セキュリティ
|
||||
---
|
||||
# プライベートサーバーの設定
|
||||
|
||||
[プライベートサーバー](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)は、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続する`rippled`サーバーです。この種の構成は、[バリデータ](../server-modes/run-rippled-as-a-validator.md)に一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。
|
||||
|
||||
## 前提条件
|
||||
|
||||
プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。
|
||||
|
||||
- [`rippled`をインストール](../../installation/index.md)して最新バージョンにアップデートし、まだ実行していない状態である必要があります。
|
||||
- 自社で運用している**プロキシ**を通じて接続するか、**公開ハブ**を通じて接続するかを決める必要があります。これらの選択肢の違いについては、[ピアリング構成のメリットとデメリット](../../../concepts/networks-and-servers/peer-protocol.md#ピア接続設定のメリットとデメリット)を参照してください。
|
||||
- プロキシを使用している場合、`rippled`がインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
|
||||
- どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。
|
||||
|
||||
## 手順
|
||||
|
||||
特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。
|
||||
|
||||
1. `rippled`の構成ファイルを編集します。
|
||||
|
||||
```
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. プライベートピアリングを有効にします。
|
||||
|
||||
構成ファイルに以下のスタンザを追加するか、コメントを解除します。
|
||||
|
||||
```
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
|
||||
3. 固定数のピアを追加します。
|
||||
|
||||
構成ファイルに`[ips_fixed]`スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。
|
||||
|
||||
例えば、**公開ハブ**を使用して接続する場合は、以下のスタンザを使用できます。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
r.ripple.com 51235
|
||||
zaphod.alloy.ee 51235
|
||||
```
|
||||
|
||||
サーバーが**プロキシ**を使用して接続している場合は、IPアドレスとポートが、プロキシとして使用している`rippled`サーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
192.168.0.1 51235
|
||||
192.168.0.2 51235
|
||||
```
|
||||
|
||||
4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。
|
||||
|
||||
公開ハブを使用している場合は、このステップをスキップします。
|
||||
|
||||
プロキシを使用している場合、プライベートピアを含む[クラスターとしてプロキシを構成](cluster-rippled-servers.md)します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした`[ips_fixed]`スタンザを持っている必要があります。ただし、`[peer_private]`スタンザを持つのは**プライベートサーバーのみ**とします。
|
||||
|
||||
各プロキシで`rippled`を再起動します。各プロキシサーバーで、次のようにします。
|
||||
|
||||
```
|
||||
sudo service systemctl restart rippled
|
||||
```
|
||||
|
||||
5. プライベートサーバーで`rippled`を起動します。
|
||||
|
||||
```
|
||||
sudo service systemctl start rippled
|
||||
```
|
||||
|
||||
6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに _のみ_ 接続していることを確認します。
|
||||
|
||||
レスポンスの`peers`配列に、構成済みのピアのいずれでもない`address`を持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。
|
||||
|
||||
|
||||
## 次のステップ
|
||||
|
||||
追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシに[ピアポートを転送](forward-ports-for-peering.md)するようにします。ただし、プライベートピアで**ない**ものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。
|
||||
|
||||
ファイアウォールがポート80で発信HTTP接続を**ブロックしない**ことを確認します。デフォルトの設定では、このポートを使用して**vl.ripple.com**から最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- [コンセンサス](../../../concepts/consensus-protocol/index.md)
|
||||
- [並列ネットワーク](../../../concepts/networks-and-servers/parallel-networks.md)
|
||||
- **チュートリアル:**
|
||||
- [ピアクローラーの設定](configure-the-peer-crawler.md)
|
||||
- **リファレンス:**
|
||||
- [peersメソッド][]
|
||||
- [connectメソッド][]
|
||||
- [fetch_infoメソッド][]
|
||||
- [ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
html: configure-the-peer-crawler.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: rippledサーバーがステータスとピアについてどの程度の情報を公表するか設定します。
|
||||
labels:
|
||||
- Core Server
|
||||
- Security
|
||||
---
|
||||
# ピアクローラの設定
|
||||
|
||||
デフォルトでは、[`rippled`サーバ](../../../concepts/networks-and-servers/index.md)は、[ピアクローラAPI](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を使ってリクエストしてきた人に統計を公開し、[XRP Ledgerのピアツーピアネットワーク](../../../concepts/networks-and-servers/peer-protocol.md)の健全性と状況を追跡しやすくしています。より多くの情報を提供したり、より少ない情報を提供したり、あるいはピアクローラーのリクエストを完全に拒否するように、サーバを設定することができます。
|
||||
|
||||
このドキュメントには、2つのオプションについて説明しています。
|
||||
|
||||
- [ピアクローラが報告する情報の変更](#ピアクローラが報告する情報の変更)
|
||||
- [ピアクローラの無効化](#ピアクローラの無効化)
|
||||
|
||||
## ピアクローラが報告する情報の変更
|
||||
|
||||
ピアクローラからのリクエストに対してサーバが提供する情報量を設定するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の設定ファイルを編集します。
|
||||
|
||||
```
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. 設定ファイルに`[crawl]`を追加または更新し、変更を保存します。
|
||||
|
||||
```
|
||||
[crawl]
|
||||
overlay = 1
|
||||
server = 1
|
||||
counts = 0
|
||||
unl = 1
|
||||
```
|
||||
|
||||
このスタンザのフィールドは、サーバが[peer crawlerレスポンス](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md#レスポンスのフォーマット)で返すフィールドを制御します。設定フィールドの名前はAPIレスポンスのフィールドと一致します。値が`1`の設定は、レスポンスにそのフィールドを含めることを意味します。0`の値は、そのフィールドをレスポンスから省略することを意味します。この例では、各設定のデフォルト値を示しています。
|
||||
|
||||
3. 設定ファイルに変更を保存したら、`rippled`サーバを再起動して、更新された設定を適用します。
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
|
||||
## ピアクローラの無効化
|
||||
|
||||
サーバのピアクローラAPIを無効にして、ピアクローラーリクエストにまったくレスポンスしないようにするには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の設定ファイルを編集します。
|
||||
|
||||
```
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. 設定ファイルに`[crawl]`を追加または更新し、変更を保存します。
|
||||
|
||||
```
|
||||
[crawl]
|
||||
0
|
||||
```
|
||||
|
||||
`[crawl]`の他のすべての内容を削除するか、コメントアウトしてください。
|
||||
|
||||
3. 設定ファイルに変更を保存したら、`rippled`サーバを再起動して、更新された設定を適用します。
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバの管理](../../installation/install-rippled-on-ubuntu.md)
|
||||
- **リファレンス:**
|
||||
- [server_infoメソッド][]
|
||||
- [peersメソッド][]
|
||||
- [ピアクローラ](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
html: enable-link-compression.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: ピアツーピア通信を圧縮して帯域幅を節約します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# 回線圧縮の有効化
|
||||
|
||||
`rippled`サーバは[ピアツーピア通信](../../../concepts/networks-and-servers/peer-protocol.md)を圧縮することで帯域幅を節約できますが、その代償としてCPU使用率が高くなります。回線圧縮を有効にすると、サーバーは回線圧縮を有効にしているピアサーバとの通信を自動的に圧縮します。
|
||||
|
||||
## 手順
|
||||
|
||||
サーバで回線圧縮を有効にするには、以下の手順を実行します。
|
||||
|
||||
### 1. `rippled`サーバの設定ファイルを編集します。
|
||||
|
||||
```sh
|
||||
$ vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
### 2. 設定ファイルに`[compression]`を追加またはコメントアウトします。
|
||||
|
||||
圧縮を有効にするには
|
||||
|
||||
```text
|
||||
[compression]
|
||||
true
|
||||
```
|
||||
|
||||
圧縮を無効にするには`false`を使用します（デフォルト）。
|
||||
|
||||
### 3. `rippled` サーバを再起動します。
|
||||
|
||||
```sh
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
再起動後、サーバは回線圧縮を有効にしている他のピアとの間で自動的に回線圧縮を使用します。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
html: forward-ports-for-peering.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: 受信ピアがrippledサーバーに接続できるようにファイアウォールを設定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ピアリングのポート転送
|
||||
|
||||
XRP Ledgerのピアツーピアネットワーク内にあるサーバーは、[ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)を介して通信します。セキュリティとネットワークの他の部分との接続を両立させるために、ファイアウォールを使用して、サーバーをほとんどのポートから保護し、ピアプロトコルポートだけを開放するか転送するようにする必要があります。
|
||||
|
||||
`rippled`サーバーの稼動中に、[server_infoメソッド][]を実行すると、いくつのピアがあるか確認することができます。`info`オブジェクトの`peers`フィールドは、サーバーに現在接続しているピアの数を示します。この数が10または11の場合、通常はファイアウォールが着信接続をブロックしていることを示します。
|
||||
|
||||
ファイアウォールが着信ピア接続をブロックしていると思われるためピアが10個しかないことを示している`server_info`の結果の例（一部省略）は次のとおりです。
|
||||
|
||||
```json
|
||||
$ ./rippled server_info
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
...（省略）...
|
||||
"load_factor" : 1,
|
||||
"peer_disconnects" : "0",
|
||||
"peer_disconnects_resources" : "0",
|
||||
"peers" : 10,
|
||||
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
|
||||
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
|
||||
"published_ledger" : "none",
|
||||
"server_state" : "connected",
|
||||
...（省略）...
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
着信接続を許可するために、ピアプロトコルポートを転送するようにファイアウォールを設定します。ピアプロトコルポートは、デフォルトの構成ファイルでは**ポート51235**で提供されます。ポートの転送の手順はファイアウォールによって異なります。例えば、Red Hat Enterprise Linuxで`firewalld`ソフトウェアファイアウォールを使用している場合は、[`firewall-cmd`ツールを使用](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding)して、TCPトラフィックを次のように転送します。
|
||||
|
||||
```sh
|
||||
$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
|
||||
```
|
||||
|
||||
その他のソフトウェアファイアウォールとハードウェアファイアウォールについては、メーカー公式のドキュメントを参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- [`rippled`サーバー](../../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [`rippled`サーバーのトラブルシューティング](../../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [connectメソッド][]
|
||||
- [peersメソッド][]
|
||||
- [printメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
19
@i18n/ja/docs/infrastructure/configuration/peering/index.md
Normal file
19
@i18n/ja/docs/infrastructure/configuration/peering/index.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
html: configure-peering.html
|
||||
name: ピアリング
|
||||
parent: infrastructure.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: サーバをピアツーピアネットワークに接続する方法を設定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ピアリングの設定
|
||||
|
||||
XRP Ledgerのピアツーピアプロトコルは、ほとんどの場合、ピア接続を自動的に管理します。場合によっては、サーバーが接続するピアを手動で調整して、サーバーの可用性とネットワークの他の部分との接続性を最大限に高めたいというケースがあります。
|
||||
|
||||
同じデータセンター内で複数のサーバーを稼動させている場合は、[クラスター化](cluster-rippled-servers.md)して効率を向上させたいケースがあります。ピアツーピアネットワークのトポロジー内の重要なハブなど、稼動していないが接続を維持したいサーバー用の予約済みピアスロットを使うことができます。他のピアについては、サーバーはピアを自動検出し、その接続を管理しますが、望ましくない動作をするピアをブロックするように手動で介入することもできます。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
html: manually-connect-to-a-specific-peer.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: rippledサーバーを特定のピアに接続します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# 特定のピアへの手動接続
|
||||
|
||||
サーバーをXRP Ledgerネットワーク内の特定の[ピア](../../../concepts/networks-and-servers/peer-protocol.md)に手動で接続するには、次の手順を実行します。
|
||||
|
||||
**ヒント:** サーバーが起動時にこのサーバーに自動的に接続して、以降も接続を維持するようにするには、そのピアに対して[ピアリザベーション](use-a-peer-reservation.md)を設定することができます。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 接続先のピアのIPアドレスを把握しておく必要があります。
|
||||
- 接続先のピアがXRP Ledger[ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)に使用するポートを把握しておく必要があります。デフォルトでは、ポート51235です。
|
||||
- サーバーからピアへのネットワーク接続を用意する必要があります。例えば、ピアサーバーは[ファイアウォールを通じて適切なポートを転送する](forward-ports-for-peering.md)必要があります。
|
||||
- ピアサーバーに使用可能なピアスロットがある必要があります。ピアがすでにピアの最大数に達している場合、ピアサーバーのオペレーターに依頼して、サーバーの[ピアリザベーション](use-a-peer-reservation.md)を追加してもらいます。
|
||||
|
||||
## 手順
|
||||
|
||||
接続するには、[connectメソッド][]を使用します。例:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```
|
||||
{
|
||||
"command": "connect",
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```
|
||||
{
|
||||
"method": "connect",
|
||||
"params": [
|
||||
{
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```
|
||||
rippled connect 169.54.2.151 51235
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- [`rippled`サーバー](../../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [`rippled`サーバーのトラブルシューティング](../../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [connectメソッド][]
|
||||
- [peersメソッド][]
|
||||
- [printメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
html: set-max-number-of-peers.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: rippledサーバーが接続するピアの最大数を設定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ピアの最大数の設定
|
||||
|
||||
`rippled`サーバーには、接続先の[ピア](../../../concepts/networks-and-servers/peer-protocol.md)の数を定める設定可能なソフト最大数があります。ピアのデフォルトの最大数は**21**です。
|
||||
|
||||
**注記:** 内部的に、サーバーは受信ピアと送信ピアのおおよそのクォータを生成します。[固定ピアやピアリザベーション](../../../concepts/networks-and-servers/peer-protocol.md#固定ピアとピアリザベーション)を使用している場合、あるいは[connectメソッド][]を使用して追加のピアに手動で接続している場合は、このソフト最大数を超える可能性があります。
|
||||
|
||||
サーバーが許可するピアの最大数を変更するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の構成ファイルを編集します。
|
||||
|
||||
```
|
||||
$ vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
|
||||
|
||||
```
|
||||
[peers_max]
|
||||
30
|
||||
```
|
||||
|
||||
スタンザの内容は、許可するピアの合計数を示す整数のみである必要があります。デフォルトでは、サーバーは受信ピアが約85%、送信ピアが約15%という比率を維持するように試みますが、送信ピアの最小数が10であるため、68未満の値にしても、サーバーが行う送信ピア接続の数は増えません。
|
||||
|
||||
`[peers_max]`値を10未満にした場合でも、サーバーはハードコーディングされた最小数である10台の送信ピアを許可するため、ネットワークとの接続を維持できます。すべての送信ピア接続をブロックするには、[サーバーをプライベートピアとして設定](../server-modes/run-rippled-as-a-validator.md#プロキシを使用した接続)します。
|
||||
|
||||
**注意:** 接続先のピアサーバーが増えると、`rippled`サーバーが使用するネットワーク帯域幅も増えます。`rippled`サーバーに良好なネットワーク接続があり、使用する帯域幅のコストを許容できる場合にのみ、ピアサーバーの数に大きな値を設定してください。
|
||||
|
||||
3. `rippled`サーバーを再起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- [`rippled`サーバー](../../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [`rippled`サーバーのトラブルシューティング](../../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [connectメソッド][]
|
||||
- [peersメソッド][]
|
||||
- [printメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
html: use-a-peer-reservation.html
|
||||
parent: configure-peering.html
|
||||
seo:
|
||||
description: ピアリザベーションを使用して特定のピアへのより信頼できる接続を設定します。
|
||||
lables:
|
||||
- コアサーバー
|
||||
---
|
||||
# ピアリザベーションの使用
|
||||
|
||||
[ピアリザベーション][]を使用すると、`rippled`サーバーが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバー間のピアツーピア通信を、各サーバーの管理者の協力のもと一貫して維持する方法について説明します。
|
||||
|
||||
ピアリザベーションは、2台のサーバーが異なる組織によって運用されていて、着信接続を受信するサーバーが、多くのピアを持つ[ハブサーバー](../../../concepts/networks-and-servers/rippled-server-modes.md#公開ハブ)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。
|
||||
|
||||
- **ストックサーバー**は発信接続を行うサーバーです。このサーバーは、ハブサーバー上のピアリザベーションを _使用_ します。
|
||||
- **ハブサーバー**は着信接続を受信するサーバーです。管理者は、このサーバーにピアリザベーションを _追加_ します。
|
||||
|
||||
ただし、一方または両方のサーバーがハブ、バリデータ、ストックサーバーのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバーから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。
|
||||
|
||||
## 前提条件
|
||||
|
||||
これらの手順を実行するには、次の前提条件を満たしている必要があります。
|
||||
|
||||
- 両方のサーバーの管理者が`rippled`を[インストール](../../installation/index.md)して実行している。
|
||||
- 両方のサーバーの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
|
||||
- ハブサーバーが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](forward-ports-for-peering.md)を参照してください。
|
||||
- 両方のサーバーが、同じ[XRP Ledgerネットワーク](../../../concepts/networks-and-servers/parallel-networks.md)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。
|
||||
|
||||
## 手順
|
||||
|
||||
ピアリザベーションを使用するには、以下の手順に従います。
|
||||
|
||||
### 1.（ストックサーバー）永続ノードキーペアを設定する
|
||||
|
||||
ストックサーバーの管理者が、以下の手順を実行します。
|
||||
|
||||
永続ノードキーペア値をすでにサーバーに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2ストックサーバーのノード公開鍵を連絡する)に進んでください。（例えば、各サーバーの永続ノードキーペアは[サーバークラスターの設定](cluster-rippled-servers.md)の一環として設定します。）
|
||||
|
||||
**ヒント:** 永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバーのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド][]のレスポンスの`pubkey_node`フィールドに表示される、サーバーが自動生成したノード公開鍵を使用できます。
|
||||
|
||||
1. [validation_createメソッド][]を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
|
||||
|
||||
例:
|
||||
|
||||
```
|
||||
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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
|
||||
|
||||
2. `rippled`の構成ファイルを編集します。
|
||||
|
||||
```
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
|
||||
|
||||
例:
|
||||
|
||||
```
|
||||
[node_seed]
|
||||
ssZkdwURFMBXenJPbrpE14b6noJSu
|
||||
```
|
||||
|
||||
**警告:** すべてのサーバーの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバーにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバーを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
|
||||
|
||||
4. `rippled`サーバーを再起動します。
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
### 2.ストックサーバーのノード公開鍵を連絡する
|
||||
|
||||
ストックサーバーの管理者が、ハブサーバーの管理者にストックサーバーのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバーの管理者はこの値を以降のステップで使用する必要があります。
|
||||
|
||||
### 3.（ハブサーバー）ピアリザベーションを追加する
|
||||
|
||||
ハブサーバーの管理者が、以下の手順を実行します。
|
||||
|
||||
[peer_reservations_addメソッド][]を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:
|
||||
|
||||
```sh
|
||||
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
|
||||
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result": {
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**ヒント:** 説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。
|
||||
|
||||
### 4.ハブサーバーの現在のIPアドレスとピアポートを連絡する
|
||||
|
||||
ハブサーバーの管理者は、サーバーの現在のIPアドレスとピアポートをストックサーバーの管理者に伝える必要があります。ハブサーバーが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバーの _外部_ IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。
|
||||
|
||||
### 5.（ストックサーバー）ピアサーバーに接続する
|
||||
|
||||
ストックサーバーの管理者が、以下の手順を実行します。
|
||||
|
||||
[connectメソッド][]を使用して、サーバーをハブサーバーに接続します。例:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```
|
||||
{
|
||||
"command": "connect",
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```
|
||||
{
|
||||
"method": "connect",
|
||||
"params": [
|
||||
{
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="コマンドライン" %}
|
||||
```
|
||||
rippled connect 169.54.2.151 51235
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
ハブサーバーの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。
|
||||
|
||||
|
||||
## 次のステップ
|
||||
|
||||
サーバーの管理者は、サーバーに設定された他のピアへの予約を管理できます。（他のサーバーからの予約は確認できません。）次のことを実行できます。
|
||||
|
||||
- [peer_reservations_addメソッド][]を使用して、ピアリザベーションの追加や説明の更新を行う。
|
||||
- [peer_reservations_listメソッド][]を使用して、予約先のサーバーを確認する。
|
||||
- [peer_reservations_delメソッド][]を使用して、予約を削除する。
|
||||
- [peersメソッド][]を使用して、現在接続しているピアと使用している帯域幅の量を確認する。
|
||||
|
||||
**ヒント:** 不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバーへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](../../../concepts/networks-and-servers/peer-protocol.md)
|
||||
- [コンセンサス](../../../concepts/consensus-protocol/index.md)
|
||||
- [並列ネットワーク](../../../concepts/networks-and-servers/parallel-networks.md)
|
||||
- **チュートリアル:**
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- [`rippled`のトラブルシューティング](../../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [peersメソッド][]
|
||||
- [peer_reservations_addメソッド][]
|
||||
- [peer_reservations_delメソッド][]
|
||||
- [peer_reservations_listメソッド][]
|
||||
- [connectメソッド][]
|
||||
- [fetch_infoメソッド][]
|
||||
- [ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
html: server-modes.html
|
||||
parent: configure-rippled.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: コアサーバを用途別に適した様々なモードで運用する方法を紹介します。
|
||||
---
|
||||
# サーバの種類
|
||||
|
||||
XRP Ledgerのコアサーバは、用途別に適した様々なモードで実行することができます。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
html: run-rippled-as-a-stock-server.html
|
||||
parent: server-modes.html
|
||||
seo:
|
||||
description: XRPを統合する人のための汎用的な構成。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ウォレットサーバーとしてのrippledの実行
|
||||
|
||||
ストックサーバは`rippled`用の汎用的な設定です。ストックサーバを利用することで、XRP Ledgerにトランザクションを送信したり、レジャーの履歴にアクセスしたり、XRPやXRP Ledgerと統合するための最新の[ツール](../../../introduction/software-ecosystem.md)を利用したりすることができます。このサーバを使って、クライアントアプリケーションをXRP Ledgerに接続することができます。
|
||||
|
||||
|
||||
ウォレットサーバーは、次のすべてのことを行います。
|
||||
|
||||
- [ピアネットワーク](../../../concepts/networks-and-servers/peer-protocol.md)に接続
|
||||
|
||||
- 暗号署名された[トランザクション](../../../concepts/transactions/index.md)を中継
|
||||
|
||||
- 完全な共有グローバル[レジャー](../../../concepts/ledgers/index.md)のローカルコピーを維持
|
||||
|
||||
|
||||
バリデータとして[コンセンサスプロセス](../../../concepts/consensus-protocol/index.md)に参加するには、代わりに[バリデータとしてrippledを実行](run-rippled-as-a-validator.md)してください。
|
||||
|
||||
|
||||
## `rippled`のインストールと実行
|
||||
|
||||
デフォルトのパッケージインストールでは、取引履歴の少ないストックサーバーがインストールされます。インストール手順については、[`rippled`のインストール](../../installation/index.md)をご覧ください。
|
||||
|
||||
インストール後、サーバーが一度に保存する履歴の量を調整することができます。この方法については、[オンライン削除の設定](../data-retention/configure-online-deletion.md)をご覧ください。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
詳しくは、[`rippled`のトラブルシューティング](../../troubleshooting/index.md)をご覧ください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](/about/)
|
||||
- [`rippled`サーバ](../../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバのクラスター化](../peering/cluster-rippled-servers.md)
|
||||
- [`rippled`のインストール](../../installation/index.md)
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- **リファレンス:**
|
||||
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
|
||||
- [consensus_infoメソッド][]
|
||||
- [validator_list_sitesメソッド][]
|
||||
- [validatorsメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -0,0 +1,342 @@
|
||||
---
|
||||
html: run-rippled-as-a-validator.html
|
||||
parent: server-modes.html
|
||||
seo:
|
||||
description: サーバーがコンセンサスレジャーで投票できるようにします。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- ブロックチェーン
|
||||
top_nav_grouping: 人気ページ
|
||||
top_nav_name: UNLに参加しよう
|
||||
---
|
||||
# バリデータとしてのrippledの実行
|
||||
|
||||
[バリデータモード](../../../concepts/networks-and-servers/rippled-server-modes.md)で実行されている[`rippled`サーバー](../../../concepts/networks-and-servers/index.md)は、ストックサーバーが実行するあらゆる処理を実行します。
|
||||
|
||||
- [ピアのネットワーク](../../../concepts/networks-and-servers/peer-protocol.md)への接続
|
||||
|
||||
- 暗号署名された[トランザクション](../../../concepts/transactions/index.md)の中継
|
||||
|
||||
- 完全な共有グローバル[レジャー](../../../concepts/ledgers/index.md)のローカルコピーの維持
|
||||
|
||||
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](../../../concepts/consensus-protocol/consensus-principles-and-rules.md#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
|
||||
|
||||
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバーがバリデータ（モードのサーバー）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバーからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバーによってコンセンサスプロセスで検討されます。
|
||||
|
||||
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
|
||||
|
||||
**注意:** バリデータは外部からはアクセスするべきものではありません。バリデータサーバへの一般からのWebSocketアクセスやその他の一般からのアクセスを許可してはいけません。
|
||||
|
||||
|
||||
|
||||
## 1. 優れたバリデータの特徴の理解
|
||||
|
||||
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者やバリデータリスト発行者(https://vl.ripple.com や https://vl.xrplf.orgなど)が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
|
||||
|
||||
- **可用性**
|
||||
|
||||
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
|
||||
|
||||
- **合意**
|
||||
|
||||
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/XRPLF/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/XRPLF/rippled/releases)してください。
|
||||
|
||||
- **適時の投票**
|
||||
|
||||
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](../../installation/system-requirements.md)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
|
||||
|
||||
バリデータを使って新しいトランザクションを送信したりデータを検索したりすることは可能ですが、APIクエリの負荷が高くなるとバリデータがコンセンサスに追いつけなくなる可能性があります。APIの負荷が十分軽ければ、サーバを両方の目的に使うことができます。理想的には、バリデータはコンセンサスに参加するために特化したものであるべきです。
|
||||
|
||||
- **身元の確さ**
|
||||
|
||||
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
|
||||
|
||||
運用者は[exampleファイル](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt)に存在するバリデータリストを使用することを強くお勧めします。
|
||||
|
||||
|
||||
|
||||
## 2. `rippled`サーバーのインストール
|
||||
|
||||
詳細は、[`rippled`のインストール](../../installation/index.md)を参照してください。
|
||||
|
||||
|
||||
|
||||
## 3. `rippled`サーバーで検証を有効化
|
||||
|
||||
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
|
||||
|
||||
バリデータ（サーバー）**以外の**場所で、以下の手順に従います。
|
||||
|
||||
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
|
||||
|
||||
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
|
||||
|
||||
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
|
||||
|
||||
```
|
||||
$ validator-keys create_keys
|
||||
```
|
||||
|
||||
Ubuntuでの出力の例:
|
||||
|
||||
```
|
||||
Validator keys stored in /home/my-user/.ripple/validator-keys.json
|
||||
|
||||
This file should be stored securely and not shared.
|
||||
```
|
||||
|
||||
macOSでの出力の例:
|
||||
|
||||
```
|
||||
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
|
||||
|
||||
This file should be stored securely and not shared.
|
||||
```
|
||||
|
||||
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
|
||||
|
||||
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
|
||||
|
||||
3. `create_token`コマンドを使用して、バリデータトークンを生成します。
|
||||
|
||||
```
|
||||
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
|
||||
```
|
||||
|
||||
出力の例:
|
||||
|
||||
```
|
||||
Update rippled.cfg file with these values:
|
||||
|
||||
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
|
||||
|
||||
[validator_token]
|
||||
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
|
||||
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
|
||||
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
|
||||
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
|
||||
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
|
||||
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
|
||||
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
|
||||
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
|
||||
```
|
||||
|
||||
バリデータ（サーバー）で、以下の手順に従います。
|
||||
|
||||
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
|
||||
|
||||
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
|
||||
|
||||
2. `rippled`を再起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
|
||||
|
||||
```
|
||||
$ rippled server_info
|
||||
```
|
||||
|
||||
- レスポンスに含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
|
||||
|
||||
- `server_state`の値は、 _**proposing**_ にする必要があります。
|
||||
|
||||
**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。
|
||||
|
||||
## 4. ネットワークへの接続
|
||||
|
||||
このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。
|
||||
|
||||
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
|
||||
|
||||
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
|
||||
|
||||
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
|
||||
|
||||
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](../../../concepts/networks-and-servers/peer-protocol.md#ピア接続設定のメリットとデメリット)を参照してください。
|
||||
|
||||
|
||||
### 検出されたピアを使用した接続
|
||||
|
||||
この構成では、[検出されたピア](../../../concepts/networks-and-servers/peer-protocol.md#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
|
||||
|
||||
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/XRPLF/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。
|
||||
|
||||
|
||||
### プロキシを使用した接続
|
||||
|
||||
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
|
||||
|
||||
_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_
|
||||
|
||||
1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](../../installation/index.md)を参照してください。
|
||||
|
||||
2. バリデータとストック`rippled`サーバーを設定して、[クラスター](../peering/cluster-rippled-servers.md)内で実行します。
|
||||
|
||||
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
|
||||
|
||||
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
|
||||
|
||||
4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
|
||||
|
||||
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
|
||||
|
||||
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
|
||||
|
||||
5. `rippled`を再起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
6. いずれかのストック`rippled`サーバーにある[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)エンドポイントを使用します。レスポンスには、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
|
||||
|
||||
```
|
||||
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
|
||||
```
|
||||
|
||||
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
|
||||
|
||||
|
||||
### 公開ハブを使用した接続
|
||||
|
||||
この構成では、2つの[公開ハブ](../../../concepts/networks-and-servers/rippled-server-modes.md#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。
|
||||
|
||||
_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_
|
||||
|
||||
1. バリデータの`rippled.cfg`ファイルに、次の`[ips_fixed]`スタンザを含めます。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`がデフォルトの公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
r.ripple.com 51235
|
||||
zaphod.alloy.ee 51235
|
||||
```
|
||||
|
||||
**注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
|
||||
|
||||
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
|
||||
|
||||
- メッセージを検閲することなく中継する。
|
||||
- オンライン状態を常に維持する。
|
||||
- サーバーに対するDDoS攻撃を実行しない。
|
||||
- サーバーをクラッシュさせようとしない。
|
||||
- 未知の相手にバリデータのIPアドレスを公開しない。
|
||||
|
||||
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
|
||||
|
||||
```
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
|
||||
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
|
||||
|
||||
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に _**限ります**_ 。
|
||||
|
||||
3. `rippled`を再起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 5. ネットワーク接続の確認
|
||||
|
||||
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
|
||||
|
||||
- [`peers`](../../../references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
|
||||
|
||||
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
|
||||
|
||||
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
|
||||
|
||||
- [`server_info`](../../../references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
|
||||
|
||||
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)および[`server_info`の取得](../../troubleshooting/diagnosing-problems.md#server_infoの取得)を参照してください。
|
||||
|
||||
- [`validators`](../../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
|
||||
|
||||
|
||||
|
||||
## 6. ドメイン検証の提供
|
||||
|
||||
検証リスト発行者およびXRP Ledgerネットワーク内のその他の参加者がバリデータの運用元を把握しやすいようにするには、バリデータのドメイン検証を提供します。ドメイン検証とは、ハイレベルでは双方向リンクを指します。
|
||||
|
||||
- ドメインを使用して、バリデータキーの所有権を主張します。
|
||||
|
||||
- バリデータキーを使用して、ドメインの所有権を主張します。
|
||||
|
||||
このリンクを作成すると、バリデータキーとドメインの両方を所有しているという確固たる証拠が確立されます。この証拠を提供することは、[優れたバリデータであること](#1-優れたバリデータの特徴の理解)の側面の1つにすぎません。
|
||||
|
||||
ドメイン検証を提供するには、以下の手順に従います。
|
||||
|
||||
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。
|
||||
|
||||
2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。
|
||||
|
||||
3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するためのリクエストを送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
|
||||
|
||||
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
|
||||
|
||||
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
|
||||
|
||||
```
|
||||
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
|
||||
```
|
||||
|
||||
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
|
||||
|
||||
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
|
||||
|
||||
```
|
||||
出力の例:
|
||||
|
||||
4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
|
||||
|
||||
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
|
||||
```
|
||||
|
||||
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
|
||||
|
||||
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
|
||||
|
||||
```
|
||||
出力の例:
|
||||
|
||||
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
|
||||
|
||||
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
|
||||
```
|
||||
|
||||
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
|
||||
|
||||
<!--{ ***TODO: For the future - add a new section or separate document: "Operating a Trusted Validator" -- things that you need to be aware of once your validator has been added to a UNL and is participating in consensus. We should tell the user what to expect once they are listed in a UNL. How to tell if your validator is participating in the consensus process? How to tell if something isn't right with your validator - warning signs that they should look out for? How to tell if your validator has fallen out of agreement - what is the acceptable vs unacceptable threshold? Maybe provide a script that will alert them when something is going wrong.*** }-->
|
||||
|
||||
|
||||
|
||||
## バリデータキーの破棄
|
||||
|
||||
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
|
||||
|
||||
`validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](/about/)
|
||||
- [`rippled`サーバー](../../../concepts/networks-and-servers/index.md)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバーのクラスター化](../peering/cluster-rippled-servers.md)
|
||||
- [`rippled`のインストール](../../installation/index.md)
|
||||
- [容量の計画](../../installation/capacity-planning.md)
|
||||
- **リファレンス:**
|
||||
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
|
||||
- [consensus_infoメソッド][]
|
||||
- [validator_list_sitesメソッド][]
|
||||
- [validatorsメソッド][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
Reference in New Issue
Block a user