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

Japanese translation progress

Browse Source 
- Add more translations ('Manage the rippled server' section,
  'Specialized Payment Types' etc.)
- Fix callouts in Japanese-language pages
This commit is contained in:
mDuo13
2019-10-28 18:34:51 -07:00
parent 0a7da4f3c7
commit 9432de96e5
34 changed files with 3205 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

170
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md Normal file
View File

@@ -0,0 +1,170 @@
# macOSでのrippledの構築と実行
現時点において、Rippleでは`rippled`の本番環境にmacOSの使用を推奨していません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。
しかしながら、macOSは多くの開発やテストの作業に適しています。 `rippled` は、10.13 High SierraまでのmacOSでテスト済みです。
開発目的の場合は、`sudo`を使用するのではなく、自身のユーザーとして`rippled`を実行することをお勧めします。
1. [Xcode](https://developer.apple.com/download/)をインストールします。
0. Xcodeコマンドラインツールをインストールします。
$ xcode-select --install
0. [Homebrew](https://brew.sh/)をインストールします。
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
0. Homebrewをアップデートします。
$ brew update
0. Homebrewを使用して依存関係をインストールします。
$ brew install git cmake pkg-config protobuf openssl ninja
0. Boost 1.70.0をインストールします。 `rippled` 1.3.1はBoost 1.70以上と互換性を持ちます。
1. [Boost 1.70.0](https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.bz2)をダウンロードします。
2. フォルダに抽出します。場所をメモしておいてください。
3. ターミナルで以下を実行します。
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
./bootstrap.sh
./b2 cxxflags="-std=c++14"
0. `BOOST_ROOT`環境変数が、Boostのインストールで作成されたディレクトリーを指すようにします。Boostのインストールディレクトリーを見つけるには、`brew info boost`を使用します。この環境変数を`.bash_profile`ファイルに追加すると、ログイン時に自動的に設定されます。例えば、次のようにします。
export BOOST_ROOT=/Users/my_user/boost_1_70_0
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、それを読み込みます。例:
$ source .bash_profile
0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://help.github.com/articles/set-up-git/)を参照してください。
$ git clone git@github.com:ripple/rippled.git
$ cd rippled
0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
$ git checkout master
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
$ git checkout release
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
$ mkdir my_build
$ cd my_build
0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
$ cmake --build .-- -j 4
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します） <!--{# ***TODO: We should provide info about what to do if you get failures. What should the user do? PM looking into this.*** #}-->
$ ./rippled --unittest
0. `rippled` は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ mkdir -p $HOME/.config/ripple
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
* `[node_db]`パスを、台帳データベースを保存する場所に設定します。
* `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
* `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[Additional Configurations](#追加構成)を参照してください。
0. `rippled` は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
**警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
$ ./rippled
以下は、ターミナルに表示される内容の抜粋です。
```
2018-Oct-26 18:21:39.593738 JobQueue:NFO Auto-tuning to 6 validation/transaction/proposal threads.
2018-Oct-26 18:21:39.599634 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
2018-Oct-26 18:21:39.599874 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
2018-Oct-26 18:21:39.599965 Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE is supported.
2018-Oct-26 18:21:39.600024 Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 is supported.
...
2018-Oct-26 18:21:39.603201 OrderBookDB:DBG Advancing from 0 to 3
2018-Oct-26 18:21:39.603291 OrderBookDB:DBG OrderBookDB::update>
2018-Oct-26 18:21:39.603480 OrderBookDB:DBG OrderBookDB::update< 0 books found
2018-Oct-26 18:21:39.649617 ValidatorList:DBG Loading configured trusted validator list publisher keys
2018-Oct-26 18:21:39.649709 ValidatorList:DBG Loaded 0 keys
2018-Oct-26 18:21:39.649798 ValidatorList:DBG Loading configured validator keys
2018-Oct-26 18:21:39.650213 ValidatorList:DBG Loaded 5 entries
2018-Oct-26 18:21:39.650266 ValidatorSite:DBG Loading configured validator list sites
2018-Oct-26 18:21:39.650319 ValidatorSite:DBG Loaded 0 sites
2018-Oct-26 18:21:39.650829 NodeObject:DBG NodeStore.main target size set to 131072
2018-Oct-26 18:21:39.650876 NodeObject:DBG NodeStore.main target age set to 120000000000
2018-Oct-26 18:21:39.650931 TaggedCache:DBG LedgerCache target size set to 256
2018-Oct-26 18:21:39.650981 TaggedCache:DBG LedgerCache target age set to 180000000000
2018-Oct-26 18:21:39.654252 TaggedCache:DBG TreeNodeCache target size set to 512000
2018-Oct-26 18:21:39.654336 TaggedCache:DBG TreeNodeCache target age set to 90000000000
2018-Oct-26 18:21:39.674131 NetworkOPs:NFO Consensus time for #3 with LCL AF8D8984A226AE7099D8A9749B09CE1D84360D5AF9FB86CE2F37500FE1009F9D
2018-Oct-26 18:21:39.674271 ValidatorList:DBG 5 of 5 listed validators eligible for inclusion in the trusted set
2018-Oct-26 18:21:39.674334 ValidatorList:DBG Using quorum of 4 for new set of 5 trusted validators (5 added, 0 removed)
2018-Oct-26 18:21:39.674400 LedgerConsensus:NFO Entering consensus process, watching, synced=no
2018-Oct-26 18:21:39.674475 LedgerConsensus:NFO Consensus mode change before=observing, after=observing
2018-Oct-26 18:21:39.674539 NetworkOPs:DBG Initiating consensus engine
2018-Oct-26 18:21:39.751225 Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:5005, admin IPs:127.0.0.1, http)
2018-Oct-26 18:21:39.751515 Server:NFO Opened 'port_peer' (ip=0.0.0.0:51235, peer)
2018-Oct-26 18:21:39.751689 Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:6006, admin IPs:127.0.0.1, ws)
2018-Oct-26 18:21:39.751915 Application:FTL Startup RPC:
{
"command" : "log_level",
"severity" : "warning"
}
2018-Oct-26 18:21:39.752079 Application:FTL Result: {}
2018-Oct-26 18:22:33.013409 NetworkOPs:WRN We are not running on the consensus ledger
2018-Oct-26 18:22:33.013875 LedgerConsensus:WRN Need consensus ledger 81804C95ADE119CC874572BAF24DB0C0D240AC58168597951B0CB64C4DA2C628
2018-Oct-26 18:22:33.883648 LedgerConsensus:WRN View of consensus changed during open status=open, mode=wrongLedger
2018-Oct-26 18:22:33.883815 LedgerConsensus:WRN 81804C95ADE119CC874572BAF24DB0C0D240AC58168597951B0CB64C4DA2C628 to 9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1
2018-Oct-26 18:22:33.884068 LedgerConsensus:WRN {"accepted":true,"account_hash":"BBA0E7273005D42E5548DD6456E5AD1F7C89B6EDCB01881E1EECD393E8545947","close_flags":0,"close_time":593893350,"close_time_human":"2018-Oct-26 18:22:30.000000","close_time_resolution":30,"closed":true,"hash":"9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1","ledger_hash":"9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1","ledger_index":"3","parent_close_time":593893290,"parent_hash":"AF8D8984A226AE7099D8A9749B09CE1D84360D5AF9FB86CE2F37500FE1009F9D","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
2018-Oct-26 18:23:03.034119 InboundLedger:WRN Want: D901E53926E68EFDA33172DDAC74E8C767D280B68EE68E3010AB0E3179D07B1C
2018-Oct-26 18:23:03.034334 InboundLedger:WRN Want: 1C01EE79083DE5CE76F3634519D6364C589C4D48631CB9CD10FC2408F87684E2
2018-Oct-26 18:23:03.034560 InboundLedger:WRN Want: 8CFE3912001BDC5B2C4B2691F3C7811B9F3F193E835D293459D80FBF1C4E684E
2018-Oct-26 18:23:03.034750 InboundLedger:WRN Want: 8DFAD21AD3090DE5D6F7592B3821C3DA77A72287705B4CF98DC0F84D5DD2BDF8
```
`rippled`ログメッセージの詳細については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
## 次のステップ
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
## 関連項目
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（本番環境用の、Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの`rippled`の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)

212
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.ja.md Normal file
View File

@@ -0,0 +1,212 @@
# Ubuntuでのrippledの構築と実行
`rippled` は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。
`rippled`の概要については、[Operating rippled Servers](install-rippled.html)を参照してください。
次の手順を使用し、16.04以降のUbuntu Linux上で、ソースバージョン1.2.0以上から、`rippled`実行可能ファイルを構築します。これらの手順は、Ubuntu 16.04 LTSでテスト済みです。
その他のプラットフォームでの`rippled`の構築については、`rippled` GitHubリポジトリの[Builds](https://github.com/ripple/rippled/tree/develop/Builds)を参照してください。
## 前提条件
`rippled`をコンパイルまたはインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
## 1. `rippled`の構築
次の手順では、UbuntuのAPT（Advanced Packaging Tool）を使用し、`rippled`の構築と実行に必要なソフトウェアをインストールします。
1. `apt-get`でインストールまたはアップグレードできるパッケージのリストを更新します。
sudo apt-get update
2. 現在インストールされているパッケージをアップグレードします。
sudo apt-get -y upgrade
3. 依存関係をインストールします。
sudo apt-get -y install git pkg-config protobuf-compiler libprotobuf-dev libssl-dev wget
4. CMakeをインストールします。
`rippled`のバージョン1.3.1は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
CMake 3.13.3をインストールするには、以下を実行します。
wget https://github.com/Kitware/CMake/releases/download/v3.13.3/cmake-3.13.3-Linux-x86_64.sh
sudo sh cmake-3.13.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
`cmake --version`を使用し、正常にインストールされたことを確認します。
5. Boostをコンパイルします。
`rippled` 1.3.1はBoost 1.70以上と互換性を持ちます。Ubuntu（18.04も16.04も）のソフトウェアリポジトリに、Boostバージョン1.70.0がないため、自分でコンパイルする必要があります。
以前に`rippled`用にBoost 1.70.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
1. Boost 1.70.0をダウンロードします。
wget https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.gz
2. `boost_1_70_0.tar.gz`を抽出します。
tar xvzf boost_1_70_0.tar.gz
3. 新しい`boost_1_70_0`ディレクトリーに移動します。
cd boost_1_70_0
4. 使用するBoost.Buildシステムを準備します。
./bootstrap.sh
5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
./b2 -j 4
**ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
6. `BOOST_ROOT`環境変数を、新しい`boost_1_70_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
export BOOST_ROOT=/home/my_user/boost_1_70_0
7. 更新した`.profile`ファイルを読み込みます。例:
source ~/.profile
6. 作業ディレクトリーから、`rippled`ソースコードを取得します。`master`ブランチに最新のリリースバージョンがあります。
git clone https://github.com/ripple/rippled.git
cd rippled
git checkout master
7. コミットログを調べ、正しいバージョンをコンパイルしていることを確認します。最新のコミットは、よく知られるRipple開発者によって署名され、バージョン番号が最新のリリースバージョンに設定されています。例:
$ git log -1
commit e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236
Author: Manoj doshi <mdoshi@ripple.com>
Date: Wed Jul 24 15:21:56 2019 -0700
Set version to 1.3.1
8. 以前に`rippled`を構築したことがある場合、または（そしてもっと重要なのは）構築しようとして失敗したことがある場合には、クリーンな状態から開始するために、次のステップに移る前に`my_build/`ディレクトリー（またはユーザーが付けた名前）を削除する必要があります。このディレクトリーを削除しないと、セグメンテーションエラー（segfault）が原因で`rippled`実行可能ファイルがクラッシュするなど、予期しない動作が発生することがあります。
`rippled`1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。
9. CMakeを使用して、ソースコードから`rippled`バイナリー実行可能ファイルを構築します。その結果、`my_build`ディレクトリーに`rippled`バイナリー実行可能ファイルが構築されます。
1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
mkdir my_build
cd my_build
cmake ..
**ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
cmake --build .
10. _（省略可能）_`rippled`ユニットテストを実行します。テストエラーがない場合には、`rippled`実行可能ファイルがほぼ確実に正しくコンパイルされています。
./rippled -u
## 2. `rippled`の構成
`rippled`を正常に起動させるために必要な以下の構成を行います。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。
1. `rippled`フォルダーに移動して、サンプル構成ファイルのコピーを作成します。構成ファイルをこの場所に保存すると、`rippled`を非ルートユーザーとして実行できます（推奨）。
mkdir -p ~/.config/ripple
cp cfg/rippled-example.cfg ~/.config/ripple/rippled.cfg
2. 構成ファイルを編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
3. `[debug_logfile]`を`rippled`がロギング情報を書き込めるパスに設定します。
3. サンプルの`validators.txt`ファイルを`rippled.cfg`と同じフォルダーに保存します。
cp cfg/validators-example.txt ~/.config/ripple/validators.txt
**警告:** Rippleは、安全を第一に考えて[分散プラン](https://ripple.com/dev-blog/decentralization-strategy-update/)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
## 3. `rippled`の実行
定義した構成を使用し、構築した実行可能ファイルからストック`rippled`サーバーを実行するには、以下を実行します。
```
cd my_build
./rippled
```
### ターミナルに表示される内容
`rippled`を実行するとターミナルに表示される内容の抜粋を以下に示します。
```
Loading: "/home/ubuntu/.config/ripple/rippled.cfg"
Watchdog: Launching child 1
2018-Jun-06 00:51:35.094331139 JobQueue:NFO Auto-tuning to 4 validation/transaction/proposal threads.
2018-Jun-06 00:51:35.100607625 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
2018-Jun-06 00:51:35.101226904 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
2018-Jun-06 00:51:35.101354503 Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE is supported.
2018-Jun-06 00:51:35.101503304 Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 is supported.
2018-Jun-06 00:51:35.101624717 Amendments:DBG Amendment 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 is supported.
...
2018-Jun-06 00:51:35.106970906 OrderBookDB:DBG Advancing from 0 to 3
2018-Jun-06 00:51:35.107158071 OrderBookDB:DBG OrderBookDB::update>
2018-Jun-06 00:51:35.107380722 OrderBookDB:DBG OrderBookDB::update< 0 books found
2018-Jun-06 00:51:35.168875072 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBARBMi2MC3LJYuvs9Rhp94WcfbxoQD5BGhwN3jaHBsPkbNpoZq;Seq: 1;
2018-Jun-06 00:51:35.172099325 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHB57Sey9QgaB8CubTPvMZLkLAzfJzNMWBCCiDRgazWJujRdnz13;Seq: 1;
2018-Jun-06 00:51:35.175302816 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHDsPCxoBHZS9KNNfsd7iVaQXBSitNtbqXfB6BS1iEmJwwEKLhhQ;Seq: 1;
2018-Jun-06 00:51:35.178486951 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBQ3CT3EWYZ4uzbnL3k6TRf9bBPhWRFVcK1F5NjtwCBksMEt5yy;Seq: 2;
2018-Jun-06 00:51:35.181681868 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHU5egMCYs1g7YRVKrKjEqVYFL12mFWwkqVFTiz2Zi4Z8jppPgxU;Seq: 2;
2018-Jun-06 00:51:35.184864291 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBbiP5ua5dUqCTz5i5vd3ia9jg3KJthohDjgKxnc7LxtmnauW7Z;Seq: 2;
...
2018-Jun-06 00:51:35.317972033 LedgerConsensus:NFO Entering consensus process, watching, synced=no
2018-Jun-06 00:51:35.318155351 LedgerConsensus:NFO Consensus mode change before=observing, after=observing
2018-Jun-06 00:51:35.318360468 NetworkOPs:DBG Initiating consensus engine
2018-Jun-06 00:51:35.358673488 Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:5005, admin IPs:127.0.0.1, http)
2018-Jun-06 00:51:35.359296222 Server:NFO Opened 'port_peer' (ip=0.0.0.0:51235, peer)
2018-Jun-06 00:51:35.359778994 Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:6006, admin IPs:127.0.0.1, ws)
2018-Jun-06 00:51:35.360240190 Application:FTL Startup RPC:
{
"command" : "log_level",
"severity" : "warning"
}
...
2018-Jun-06 00:52:32.385295633 NetworkOPs:WRN We are not running on the consensus ledger
2018-Jun-06 00:52:32.388552023 LedgerConsensus:WRN Need consensus ledger 84726E8C5B346E28C21ADE6AAD703E65F802322EDAA5B76446A4D0C5206AB2DB
2018-Jun-06 00:52:33.379448561 LedgerConsensus:WRN View of consensus changed during open status=open, mode=wrongLedger
2018-Jun-06 00:52:33.379541915 LedgerConsensus:WRN 84726E8C5B346E28C21ADE6AAD703E65F802322EDAA5B76446A4D0C5206AB2DB to 1720162AE3BA8CD953BFB40EB746D7B78D13E1C97905E8C553E0B573F1B6A517
2018-Jun-06 00:52:33.379747629 LedgerConsensus:WRN {"accepted":true,"account_hash":"CC1F1EC08E76BC9FE843BBF9C6068C5B73192E6957B9CC1174DCB2B94DD2025A","close_flags":0,"close_time":581561550,"close_time_human":"2018-Jun-06 00:52:30.000000000","close_time_resolution":30,"closed":true,"hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_index":"3","parent_close_time":581561490,"parent_hash":"80BF92A69F65F5C543E962DF4B41715546FDD97FC6988028E5ACBB46654756CA","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
...
2018-Jun-06 00:53:50.568965045 LedgerConsensus:WRN {"accepted":true,"account_hash":"A79E6754544F9C8FC74870C95A39CED1D45CC1206DDA4C113E51F9DB6DDB0E76","close_flags":0,"close_time":581561630,"close_time_human":"2018-Jun-06 00:53:50.000000000","close_time_resolution":10,"closed":true,"hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_index":"29","parent_close_time":581561623,"parent_hash":"5F57870CE5160D6B53271955F26E3BE63696D1127B91BC7943F9A199B313CB85","seqNum":"29","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
2018-Jun-06 0:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
2018-Jun-06 0:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
2018-Jun-06 00:53:53.576524564 LedgerConsensus:WRN View of consensus changed during establish status=establish, mode=wrongLedger
2018-Jun-06 0:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
2018-Jun-06 00:53:53.577079124 LedgerConsensus:WRN {"accepted":true,"account_hash":"5CAB3E4F5F2AC1A764106D7CC0729E6E7D1F7F93C65B7D8CB04C8DE2FC2C1305","close_flags":0,"close_time":581561631,"close_time_human":"2018-Jun-06 00:53:51.000000000","close_time_resolution":10,"closed":true,"hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_index":"30","parent_close_time":581561630,"parent_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","seqNum":"30","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
## 次のステップ
* これでストック`rippled`サーバーを実行できたので、次に検証サーバーとして実行してみましょう。検証サーバーの詳細について、そして検証サーバーを実行する理由については、[rippledのセットアップチュートリアル](install-rippled.html)を参照してください。
* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` API reference](rippled-api.html)を参照してください。
* 開発のベストプラクティスとして、`rippled` `.deb`ファイルを構築することをお勧めします。詳細は、_Ubuntu Packaging Guide_ の[Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html)を参照してください。
* また、`systemd`をインストールすることもできます。詳細については、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled-package-builder/blob/staging/rpm-builder/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。

188
content/tutorials/manage-the-rippled-server/installation/capacity-planning.ja.md Normal file
View File

@@ -0,0 +1,188 @@
# 容量の計画
このセクションでは、お使いの`rippled`サーバーのパフォーマンスを調整し、最適化するために使用できる、構成、ネットワーク、ハードウェアの推奨事項について説明します。これらの考慮事項を知っておくことにより、XRP Ledgerネットワークの現在および将来の容量を処理できるよう、お使いの`rippled`サーバーを準備するために役立ちます。
## 構成設定
Rippleでは、`rippled`サーバーのリソース利用およびパフォーマンスを最適化するために、これらの構成ガイドラインを使用することをお勧めします。
`rippled.cfg`ファイルで、`rippled`サーバーに使用する次のパラメーターを設定できます。サンプルの構成ファイル`rippled-example.cfg`は、`rippled` GitHubリポジトリの[`cfg`ディレクトリー](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)にあります。
### ノードサイズ
サーバーで予測される負荷と、`rippled`で使用できるメモリ量に基づいて`node_size`を設定します。
Rippleでは、お使いのRAMでサポートできる最大のノードサイズを常に使用することをお勧めします。以下の表は推奨設定をまとめたものです。
#### 推奨事項
各`node_size`には、それに対応する使用可能なRAMの要件があります。例えば、`node_size`を`huge`に設定すると、`rippled`がスムーズに稼働できるようにするため、最低でも32GBのRAMが必要です。
サーバーを調整するために、まず`tiny`から初め、ユースケースの要件に合わせてサイズを徐々に`small`、`medium`と増やしていくと便利です。
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|:----------------------------|:------------------|:---------------------------|
| 8GB未満 | `tiny` | テストサーバーにも実稼働サーバーにも推奨できません。`rippled.cfg`で値を指定しないと、これがデフォルト値になります。 |
| 8GB | `small` | テストサーバーに推奨。 |
| 16GB | `medium` | `rippled-example.cfg`ファイルではこの値が使用されます。 |
| 32GB | `huge` | 実稼働サーバーに推奨。 |
`large`も`[node_size]`の値として有効ですが、実際に使用するとほとんどの環境で`huge`よりもパフォーマンスが悪くなります。Rippleでは、`large`の代わりに、常に`huge`を使用することを推奨します。
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#bad-node-size-value)。
### ノードDBタイプ
`rippled.cfg`ファイルの`[node_db]`スタンザの`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。
この値は、`RocksDB`または`NuDB`に設定できます。
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#more-about-using-nudb)
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`スタンザの`type`フィールドが`RocksDB`に設定されています。
#### RocksDBの使用の詳細
[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。
RocksDBは、ソリッドステートディスクに最適です。回転式ディスクと共に使用した場合、RocksDBはパフォーマンスの点でNuDBよりも優れていますが、ソリッドステートディスクを使用しない限りパフォーマンス上の問題が発生する可能性があります。
RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
RocksDBを使用するようにバリデーターを構成し、レジャーストアに最大30万件（約2週間分に相当する[履歴データ](#ディスク容量)）までのレジャーを格納するように設定する必要があります。
最大のトランザクション処理スループットを達成するため、RocksDBには、`rippled.cfg`で設定できるパフォーマンス関連の構成オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
```
[node_db]
type=RocksDB
path=/var/lib/rippled/db/rocksdb
open_files=512
filter_bits=12
cache_mb=512
file_size_mb=64
file_size_mult=2
online_delete=2000
advisory_delete=0
```
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
#### NuDBの使用の詳細
[NuDB](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはソリッドステートドライブを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
バリデーター以外の実稼働サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`の推奨構成です。
```
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0
```
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
### ログレベル
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`スタンザでは、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
**注意:** `[rpc_startup]`スタンザで`log_level`コマンドを省略すると、`rippled`は`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
## ネットワークとハードウェア
XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワークのすべてのトランザクション処理を実行します。このため、実稼働用`rippled`サーバーのベースラインハードウェアはRippleの[パフォーマンステスト](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/)で使用されるものと類似している必要があります。
`rippled`サーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。
### 推奨事項
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
- オペレーティングシステム: Ubuntu 16.04以上
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
- ディスク速度: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
- ディスク容量: 場合により異なる。最低50GBを推奨。
- RAM: 32GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
#### CPU使用率および仮想化
ベアメタルを使用するとパフォーマンスが最大になりますが、ホストのハードウェアの仕様が十分であれば、仮想マシンでもほぼ同様のパフォーマンスが得られます。
#### ディスク速度
Rippleは、待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
- （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
- （専用のパフォーマンステストで）秒あたり7,000回の書き込み
#### ディスク容量
`rippled`が必要とするディスク容量は、ローカルで維持する予定の[レジャー履歴](ledger-history.html)の量によって異なります。コンセンサスプロセスに従い、レジャー全体の状態を報告するには、`rippled`サーバーは最新の256のレジャーバージョンのみを格納する必要があります。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。
保持するデータ量は、[オンライン削除](online-deletion.html)で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。
以下のテーブルは、本書の執筆時点（2018年12月13日）における、様々な履歴量の要件をまとめたものです。
| 実際の時間 | レジャーバージョンの数 | 必要なディスク容量（RocksDB） | 必要なディスク容量（NuDB） |
|:-----------------|:--------------------------|:------------------------------|:--|
| 2時間 | 2,000 | 250MB | 450MB |
| 1日 | 25,000 | 8GB | 12GB |
| 14日 | 350,000 | 112GB | 168GB |
| 30日 | 750,000 | 240GB | 360GB |
| 90日 | 2,250,000 | 720GB | 1TB |
| 1年 | 10,000,000 | 3TB | 4.5TB |
| 2年 | 20,000,000 | 6TB | 9TB |
| 完全な履歴（2018まで） | 43,000,000+ | （非推奨） | ~9TB |
これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。
`online_delete`設定は、古い履歴の削除後に保持するレジャーバージョンの数を指定するものです。オンライン削除が実行される直前レジャーの最大数の2倍を格納できるほどの十分な容量を計画する必要があります。
保持する履歴量の変更方法については、[オンライン削除の設定](configure-online-deletion.html)を参照してください。
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`スタンザで構成されます。これは`[node_db]`スタンザでレジャーストアに定義したものとは別のタイプのkey-valueストアを使用できます。
##### Amazon Web Services
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、`rippled`の最大負荷には不十分です。
AWSインスタンスストア（`ephemeral`ストレージ）にはこのような制約はありません。このため、Rippleでは、インスタンスストレージを備える`M3`などのホストタイプの`rippled`サーバーをデプロイすることをお勧めします。`database_path`パスと`node_db`パスの両方がインスタンスストレージに存在する必要があります。
**注意:** AWSインスタンスストレージは、ハードドライブが故障した場合に、必ずしもデータの保護を保証しません。また、インスタンスを停止、開始、またはリブートした場合にもデータが失われます。通常、個々のサーバーは失われたデータをピアサーバーから再取得できるため、後者のタイプのデータ損失は`rippled`サーバーでは容認できます。
#### RAM/メモリー
メモリー要件は、主に`node_size`構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、[ノードサイズ](#ノードサイズ)を参照してください。
#### ネットワーク
あらゆる企業または通信事業者クラスのデータセンターでは、`rippled`サーバーの実行をサポートするため、非常に大きなネットワーク帯域幅が必要です。
以下は、一般的な`rippled`タスクで使用されるネットワーク帯域幅の例です。
| タスク | 転送/受信 |
|:------------------------------------------------|:---------------------------|
| 現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
| 履歴レジャーとトランザクションレポートを提供する | 100Mbpsの転送 |
| `rippled`の起動 | 20Mbpsの受信 |

41
content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.ja.md Normal file
View File

@@ -0,0 +1,41 @@
# yumを使用したCentOS/Red Hatへのインストール
このページでは、Rippleの[yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified)リポジトリを使用して、**CentOS 7**または**Red Hat Enterprise Linux 7**に、`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
## 前提条件
`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
## インストール手順
1. Ripple RPMリポジトリをインストールします。
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
2. `rippled`ソフトウェアパッケージをインストールします。
$ sudo yum install --enablerepo=ripple-stable rippled
3. システム起動時に開始するように、`rippled`サービスを設定します。
$ sudo systemctl enable rippled.service
4. `rippled`サービスを開始します。
$ sudo systemctl start rippled.service
## 次のステップ
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
## 関連項目
- [CentOS/Red Hatでの自動更新](update-rippled-automatically-on-centos-rhel.html)
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの'rippled'の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)

30
content/tutorials/manage-the-rippled-server/installation/system-requirements.ja.md Normal file
View File

@@ -0,0 +1,30 @@
# システム要件
## 最小仕様
ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。
- オペレーティングシステム:
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、またはUbuntu （16.04以降）をサポート
- 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
- CPU: 64ビットx86_64、2つ以上のコア
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
- RAM: 8GB以上
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
## 推奨される仕様
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
- オペレーティングシステム: Ubuntu 16.04以上
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
- ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
- RAM:
- テスト用: 8GB以上
- 本番環境用: 32GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
## 関連項目
実稼働向けの推奨仕様および計画について詳しくは、[容量の計画](capacity-planning.html)を参照してください。