Corda Firewallの冗長構成について理解できる。
はじめに
本稿について
本稿は、Corda Enterpriseの機能である「Corda Firewall」に高可用性を持たせた構築方法について説明したものです。コンセプトに関する英語のドキュメントはこちらをご覧ください。また、具体的な設定方法に関してはこちらをご覧ください。
Corda Firewallの基本概念およびシングル構成の構築例を知りたい方は、こちらの記事をご覧くださいませ。
※Corda FirewallはCorda Enterpriseのみに含まれるコンポーネントです。
HA構成構築に向けて
基本用語
Corda Firewallの基本用語について知りたい方はこちらの記事も併せてご覧くださいませ。
Apache ZooKeeper
Apache ZooKeeperは、複数のクラスタを一元管理することができるオープンソースソフトウェアです。Corda Firewallにおいてはクラスタリング化したbridgeのリーダーを自動的に管理するために使用します。今回の構築では、3.5.4-betaを使用します。
Corda Firewallの設定
システム構成図
以下はCorda FirewallのHA構成図です。bridgeやfloatを冗長化しています。
以下はCorda FirewallのHA物理構成図です。真ん中に構成するhostnameは「vmInfra1」、「vmInfra2」にはbridgeインスタンス、artemisインスタンス、ZooKeeperクラスタを含みます。
キーストアの生成
Corda Firewallの各コンポーネントはSSL暗号化通信によってメッセージの送受信を行います。そのSSL暗号化通信を実現するためにはキーストアが必要です。このキーストアはCorda Enterpriseのモジュール「corda-tools-ha-utilities-X.X.jar」にて簡単に生成できます。
- Bridge ⇔ Float間のSSL暗号化通信BridgeとFloat間のトンネリングを実現するためには、以下のコマンドを実行します。パラメータの-pや-eはキーストアや秘密鍵のパスワードなので、任意に変更可能です。
- コマンドが正常終了すると、同階層に「tunnel」ディレクトリが作成され、「float.jks」「tunnel-truststore.jks」「bridge.jks」ファイルが格納されます。
- Bridge ⇔ Artemis MQ間のSSL暗号化通信BridgeとArtemis 間の通信を行うためには、以下のコマンドを実行します。パラメータは「Bridge ⇔ Float間のSSL暗号化通信」と似ていますが、Artemisには「キーストアのパスワードは、ストア内の秘密鍵のパスワードと同じでないといけない」という制約があるため、-eのパラメータは設定できません。
Nodeの設定
Nodeを任意のネットワークに参加させますが、今回は1つのサーバーに2つのNode(EntityA, EntityB)を配置して「corda-tools-ha-utilities-X.X.jar」を用いて登録してみます。
- network-root-truststore.jksの配置参加したいネットワークから「network-root-truststore.jks」を取得します。一般的なNode登録の場合、このファイルは「certificates」ディレクトリに格納しますが、今回は「corda-tools-ha-utilities-X.X.jar」の配置先と同階層のディレクトリに配置します。
- node.confの修正EntityAとEntityBにそれぞれnode.confを用意します。以下EntityAのnode.conf例です。(EntityBのnode.confにも流用できますが、※のコンフィグは適宜変更してください。
- Nodeをネットワークに登録複数のNodeを一度にネットワークに登録してみます。
上記コマンドが正常終了した場合、実行階層に以下のディレクトリやファイルが生成・配布されています。
これらのjksやnetwork-parametersを各Nodeにコピーします。現状のNodeのディレクトリは以下のような構成になっているはずです。
- Nodeの設定に関しては他にもCorDappsやDBドライバーの配置も行いますが、今回の記事では割愛します。
- 集約されたSSLキーストアの設定今回は、1つのサーバーに複数のノードを配置するシナリオになっています。その外側に窓口になる1つのBridgeインスタンスを配置するため、すべてのノードを代表する役割の集約されたSSLキーストアが必要になります。このような集約されたキーストアを作成ために以下のコマンドを実行します。
上記コマンドが正常終了した場合、実行階層に以下のディレクトリやファイルが生成・配布されています。
- 上記の「nodesUnitedSslKeystore.jks」は後でBridgeインスタンスに配布します。
Floatの設定
floatは冗長構成のために2つ(vmFloat1、vmFloat2)用意します
- firewall.confの設定vmFloat1とvmFloat2にそれぞれfirewall.confを用意します。以下vmFloat1のfirewall.conf例です。(vmFloat2のfirewall.confにも流用できますが、※のコンフィグは適宜変更してください。
- jksファイルおよびnetwork-parametersの配置。floatのベースディレクトリ直下に「tunnel」ディレクトリを作成し、その中に「キーストアの生成」の手順で生成した「float.jks」「tunnel-truststore.jks」を配置します。また、「Nodeの設定」で生成された「network-parameters」をベースディレクトリに配置します。
- corda-firewall.jarの配置ベースディレクトリに「corda-firewall.jar」を配置します。
現時点でfloatのベースディレクトリは以下のような構成になっています。
Apache ZooKeeperの設定
Apache ZooKeeperのインスタンス(vmInfra1、vmInfra2、vmZkWitness)を3つ用意します。ダウンロードした3.5.4-betaを任意のディレクトリに解凍します。
解凍したディレクトリのconf配下に格納されている「zoo_sample.cfg」をコピーして、「zoo.cfg」を作ります。zoo.cfgは以下のコンフィグを設定します。
また、zoo.cfg.dynamicを設定します。配置先は「zoo.cfg」に設定した「dynamicConfigFile」のパスを設定します。ZooKeeperのサーバーのアドレスおよびポートを任意に設定します。
最後に「myid」というファイルを同ディレクトリに配置します。各々にはサーバーの識別子となる数値を設定します。例えばvmInfra1のmyidには「1」とだけ設定します。同様にvmInfra2のmyidには「2」、vmZkWitnessのmyidには「3」と設定します。
Bridgeの設定
bridgeも冗長構成のために2つ(vmInfra1、vmInfra2)用意します。
- firewall.confの設定vmInfra1とvmInfra2にそれぞれfirewall.confを用意します。以下vmInfra1のfirewall.conf例です。(vmInfra2のfirewall.confにも流用できますが、一部修正が必要です。以下の例中のコメントをご参考ください)
- jksファイルおよびnetwork-parametersの配置。bridgeのベースディレクトリ直下に「tunnel」ディレクトリを作成し、その中に「キーストアの生成」の手順で生成した「bridge.jks」「tunnel-truststore.jks」を配置します。また、「Nodeの設定」で生成された「network-parameters」をベースディレクトリに配置します。また、「artemis」ディレクトリを作成し、「キーストアの生成」の手順で生成した「artemis.jks」および「artemis-truststore.jks」を配置します。また「nodesCertificates」ディレクトリを作成し、「Nodeの設定」の「集約されたSSLキーストアの設定」を「nodesUnitedSslKeystore.jks」および「network-root-truststore.jks」を配置します。corda-firewall.jarの配置ベースディレクトリに「corda-firewall.jar」を配置します。
- 現時点でbridgeのベースディレクトリは以下のような構成になっています。
Artemisの設定
artemisはNodeとbridgeの通信に使用されます。artemisはこちらからダウンロードして任意のフォルダに解凍します。(本稿では2.6.3のバージョンを使用します)
次にartemisのmasterディレクトリを生成します。以下のコマンドを実行することでartemis-masterフォルダが生成されます。
${ARTEMIS_DISTRIBUTION_DIR}はartemisの解凍先、${WORKING_DIR}はartemis-masterディレクトリを生成するディレクトリを設定します。
生成された「artemis-master/etc」配下に、「artemis」ディレクトリを作成し、「キーストアの生成」で作成した「artemis-truststore.jks」および「artemis.jks」を配置します。
またvmInfra2ではmaster-slaveを作成します。
こちらも生成した「artemis-slave/etc」配下に、「artemis」ディレクトリを作成し、「キーストアの生成」で作成した「artemis-truststore.jks」および「artemis.jks」を配置します。
各インスタンスの起動
floatの起動
floatのベースディレクトリに移動し、以下のコマンドを実行します。
ログ中に以下のようなメッセージがでていれば、正常に起動しています。
ZooKeeperの起動
3つのサーバー(vmInfra1、vmInfra2、vmZkWitness)に配置したZooKeeperをそれぞれ起動します。以下、サーバー1の起動例です。
起動した場合以下のようなメッセージが表示されます。
また、以下のコマンドでZooKeeperのステータスを確認できます。
この時、「Mode」が「leader」のインスタンスが1つ「follower」のInstanceが2つできていれば正常に起動しています。
一つだけインスタンスを起動した場合にZooKeeperのステータスを確認してしまうと、「Error contacting service. It is probably not running.」というエラーが表示されますが、これはZooKeeperクラスタが起動するための最低起動台数を満たしていことに起因します。
かならず全てのインスタンスを起動してからstatusコマンドを実行してください。
Artemisの起動
artemis-masterおよびartemis-slaveを起動します。
正常に起動した場合、artemis-masterのnohup.outには以下のメッセージが出力します。
Bridgeの起動
bridgeを起動します。bridgeのベースディレクトリに移動して、以下のコマンドを実行します。
bridgeのlog上に「Session created」というメッセージが出力すると正しくセッションが確立しています。
Nodeの起動
最後にNodeを起動します。これは、通常通り以下のコマンドで起動できます。
おわりに
各インスタンスを冗長化することで単一障害点をなくすことができ、システムの可用性向上が期待できます。また構築や運用に関することでご不明点等ありましたら、弊社のプロフェショナルサービスのご利用もご検討くださいませ。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部所属
ソリューションアーキテクト/PoC支援
This is the way. みんなでキャズムを超えていきましょう！