狠狠撸

IBM Blockchain
Hyperledger Fabric の
プラットフォームおよび
インフラ運?
2020年9?30?(?)
?本アイ?ビー?エム株式会社
ブロックチェーン事業部
エグゼクティブITスペシャリスト
紫関昭光
Hyperledger Tokyo Meetup
? 2020 IBM Corporation

2
チームでDX
A社
既存パートナー企業
グループ企業
A社経済圏
?社の信??で
システムやデータの信頼性を保証
ブロックチェーンの信??で
システムやデータの信頼性を保証
顧客
取引先
APIア
ク
セ
ス
異業種パートナー企業
海外パートナー企業
新規パートナー企業
同業他社
当局
台帳
台帳
台帳
台帳
台帳
台帳
ブロックチェーン
?競争領域における課題解決や
業種や国境をまたがる協業を促進
データの真正性データの共有価値の移転処理の?動化
? 同じ台帳を関係者で共有
? 台帳間の同期やプログラム
／データの耐改竄性は実装済み

3
複数組織のピアの連携とチェーンコードの実?を確認出来る最?構成
PoCのコンポーネント配置例
サーバー
Linux
単?サーバー(またはVM)上に全ての組織を構成
OrgA OrgX OrgB
Peer_A1
HFC_A CA_A
Orderer _X1
CA_X
Peer_B1
HFC_BCA_B

4
組織ごとにインフラ（サーバー、OS）を分け、ピアとオーダラーを多ノード構成にする
開発テスト、QA環境のコンポーネント配置例
サーバー
Linux
組織ごとに、単?サーバ(またはVM)上に全てのコンポーネントを構成
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:

5
サーバー(Worker Node)をクラスター構成し、可?性とスケーラビリティを?める
本番サービスのコンポーネント配置例
OrgA OrgX OrgB
Linux
Node_4
Linux
Node_3
Linux
Node_2
Linux
Node_1
Linux
Node_6
Linux
Node_5
Kubernetes Kubernetes Kubernetes
File
Storage
File
Storage
File
Storage
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_5
:

6
サーバー(Worker Node)をデータセンターを跨いでクラスター構成し、可?性を更に?める
本番サービスのコンポーネント配置例
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
OrgA OrgX OrgB
Orderer_X5
:
Linux
Node_c,d
Linux
Node_3,4
Linux
Node_a,b
Linux
Node_1,2
Linux
Node_e,f
Linux
Node_5,6
Kubernetes Kubernetes Kubernetes
データ
センター
データ
センター
データ
センター
データ
センター
データ
センター
データ
センター
File
Storage
File
Storage
File
Storage
File
Storage
File
Storage
File
Storage

7
?般的なスケールアウトとスケールアップ
Peer, Orderer のスケールアップ
App
Storage
LB
App App
LB
AppApp
DBサーバー
4Core 4Core 4Core 4Core 4Core
Storage
DBサーバー
4Core 8Core

8
クラスターのノードをスケールアウトすることで Peer, Orderer をスケールアップ
Peer, Orderer のスケールアップ
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A1
HFC_A
Peer_A2
CA_A
OrgA
Linux
Node_2
Linux
Node_1
Kubernetes
File
Storage
Peer_A1
HFC_A
Peer_A2
CA_A
4Core
0.2Core
1Core
1Core
0.5Core
4Core x2
0.2Core
3Core
3Core
0.5Core

9
サーバー(Worker Node)障害に対するHA
Peer の?可?性 (HA) 1/4
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2Peer_A1
CA_A
Linux
Node_2
Peer_A3
Linux
Node_3
データ
センター

10
Node_1で障害発?、サーバーダウン
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2PEER_A1
CA_A
Linux
Node_2
Peer_A3
Linux
Node_3
データ
センター

11
Deployment Controllerが Peer_A1, CA_Aの Podを Node_2, 3に再配置
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2
Peer_A1 CA_A
Linux
Node_2
Peer_A3
Linux
Node_3
データ
センター

12
Node_1の代わりにNode_4をワーカープールに追加してクラスターを復旧
OrgA
Linux
Node_4
Kubernetes
File
Storage
Peer_A2
Peer_A1 CA_A
Linux
Node_2
Peer_A3
Linux
Node_3
データ
センター

13
データセンター障害に対するHA
Peer の?可?性 (HA+) 1/5
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2Peer_A1
CA_A
Linux
Node_2
Peer_A3
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
9?30?
10:35
9?30?
10:35
9?30?
10:35

14
データセンター_1でネットワーク障害発? (10:40)
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2PEER_A1
CA_A
Linux
Node_2
Peer_A3
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
9?30?
10:40
9?30?
10:40
9?30?
10:40

15
データセンター_2, 3 でサービス続? (10:40~12:10)
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2PEER_A1
CA_A
Linux
Node_2
Peer_A3
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
9?30?
10:40
9?30?
12:10
9?30?
12:10

16
データセンター_1が復旧 (12:15)、ブロックチェーンファイルの同期が始まる
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2Peer_A1
CA_A
Linux
Node_2
Peer_A3
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
ブロック
チェーン
ファイルを
同期
9?30?
10:40
9?30?
12:15
9?30?
12:15

17
同期されたブロックチェーンファイルからPeer_A1のステートDBが最新状態に追いつく (13:00)
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2Peer_A1
CA_A
Linux
Node_2
Peer_A3
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
9?30?
13:00
9?30?
13:00
9?30?
13:00
ブロック
チェーン
ファイルから
ステートDBを再?

18
データセンター障害に対するHA
Orderer の?可?性 (HA+) 1/3
OrgX
Linux
Node_1
Kubernetes
File
Storage
Orderer_X4Orderer_X2
Orderer_X1
Linux
Node_2
Orderer_X5
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
Orderer_X3 CA_X
Raft Raft

19
データセンター_1で電源障害発?、RaftによりOrderer_1, 2を分離、Orderer_X3, 4, 5で続?
OrgX
Linux
Node_1
Kubernetes
File
Storage
Orderer_X1
Linux
Node_2
Orderer_X5
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
Orderer_X3 CA_X
Raft

20
データセンター_1が復旧、Orderer_X1, 2が再スタート、Raftによりデータ同期
OrgX
Linux
Node_1
Kubernetes
File
Storage
Orderer_X1
Linux
Node_2
Orderer_X5
データ
センター_1
Linux
Node_3
File
Storage
Linux
Node_4
データ
センター_2
Linux
Node_5
File
Storage
Linux
Node_6
データ
センター_3
Orderer_X3 CA_X
RaftRaft

21
? セマンティックバージョニング
? Hyperledger Fabric Version Major.Minor.Patch (例: v2.2.0)
? Patch版は後?互換性を維持してバグ修正したバージョン
? Minor版は後?互換性を維持して機能追加したバージョン
? Major版は互換性が保たれないバージョン
? 新バージョンのリリースは、メーリングリスト、リリースノートで告知、Docで解説
? ネットワークに異なるバージョンの混在を許す
? ローリングアップグレードが可能
? Application Capability, Channel Capability, Orderer Capability で新機能を有効化
? LTS (Long Term Support)版はリリースから1年以上のサポートをコミット
? 2020年9?現在、v1.4, v2.2 がLTS
? バグ修正はPatch版のリリースで対応 (例: v1.4.8)
? バージョンアップはサービス無停?で?える
? v1.4からv2.xのメジャーバージョンアップではPeerのデータベースフォーマットに変更があった
ためデータベースの再構築が必要だが、バージョンアップはサービス無停?で?える
Hyperledger Fabricのバージョン管理

22
ローリングアップグレードをサービス無停?で?う
v1.4からv2.2へのバージョンアップ 1/13
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
1.4.8
1.4.8
Running
Running
Running
Running
Running
Running
v1
v1
v1
v1

23
Orderer_X1を停?する。Orderer_X2~5によりオーダリングサービスは継続される。
$ docker stop $ORDERER_CONTAINER
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
1.4.8
1.4.8
Running Stop
Running Running
Running
Running
v1
v1
v1
v1

24
Orderer_X1を削除する。削除する前に台帳データとMSPをバックアップする。
$ docker rm –f $ORDERER_CONTAINER
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.81.4.8
Running
Running Running
Running
Running
v1
v1
v1
v1

25
Orderer_X1をFabric v2.2のイメージとバックアップデータから開始する。Capabilityはまだ変更しない。
$ docker run hyperledger-orderer:2.2 orderer
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
2.2.0
1.4.8
Running
Running Running
Running
Running
Running
v1
v1
v1
v1

26
同様にOrderer_X5まで順番にアップグレードする。この間、オーダリングサービスは継続される。
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
2.2.0
2.2.0
Running
Running Running
Running
Running
Running
v1
v1
v1
v1

27
Peer_A1を停?する。OrgAのエンドースメント処理はPeer_A2によって継続される。
$ docker stop $PEER_CONTAINER
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
2.2.0
2.2.0
Running Running
Running
Running
RunningStop
v1
v1
v1
v1

28
Peer_A1のデータベース(CouchDBのステートDB等)をドロップし、フォーマットをv2にする。
$ docker run hyperledger-fabric-peer:2.2 peer node upgrade-dbs
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
1.4.8
2.2.0
2.2.0
Running Running
Running
Running
RunningStop
v1
v1
v2
v1

29
Peer_A1を削除する。チェーンコードコンテナ、チェーンコードイメージ、ピアコンテナを削除する。
$ docker rm –f $PEER_CONTAINER
V1.4からv2.2へのバージョンアップ 8/13
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
2.2.0
2.2.0
Running Running
Running
Running
Running
v1
v1
v2
v1

30
Peer_A1を Fabric v2.2のイメージから開始し、DBを再構築する。Capabilityはまだ変更しない。
$ docker run hyperledger-fabric-peer:2.2 peer node start
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
1.4.8
1.4.8
1.4.8
2.2.0
2.2.0
Running Running
Running
Running
Running
v1
v1
v2
v1
Peer_A1
2.2.0
Running

31
同様にPeer_A2をアップグレードする。OrgAのエンドースメント処理はPeer_A1により継続される。
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
2.2.0
2.2.0
1.4.8
1.4.8
2.2.0
2.2.0
Running Running
Running
Running
RunningRunning
v2
v2 v1
v1

32
同様にPeer_B1, 2をアップグレードする。OrgA, BのPeerアップグレードは並?して?える。
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
2.2.0
2.2.0
2.2.0
2.2.0
2.2.0
2.2.0
Running Running
Running
Running
RunningRunning
v2
v2 v2
v2

33
Application capability, Channel capability, Orderer capability をv2.2へ更新する。
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
2.2.2
2.2.2
2.2.2
2.2.2
2.2.0
2.2.0
Running Running
Running
Running
RunningRunning
v2
v2 v2
v2

34
Fabric CA サーバー、Node SDK クライアントをアップグレードする。
サーバー
Linux
OrgA OrgX OrgB
Linux
サーバー
Linux
サーバー
Peer_A1
HFC_A
Peer_A2
CA_A
Orderer _X1
CA_X
Peer_B1
HFC_B
Peer_B2
CA_B
Orderer_X5
:
2.2.2
2.2.2
2.2.2
2.2.2
2.2.0
2.2.0
Running Running
Running
Running
RunningRunning
v2
v2 v2
v2

35
実装例?IBM Blockchain Platform
3
5
Build
シームレスな開発ツール
Operate
直感的なコンソール
オープンソース、標準、ガバナンス
Kubernetes
コンテナ仮想化と
オーケストレーション
マルチクラウドオンプレミス
IBM Z
? VSCode extension, CodeReady Workspaces
? SDKs
? プラットフォームへのゲートウェイ
? Hyperledger Fabricコンポーネントの管理
? パッチとアップデートのライブ適?
? 参加者のガバナンスとスマートコントラクトの管理
35
intel
aws
vmware
Azure
Red Hat OpenShiftに最適化

47
IBP for IBM Cloud アーキテクチャ
IBM管理の
クラスター
お客様
アカウントの
クラスター
Cloud wizard
(IBPプロビジョニング画?
コントロール)
IBP
コンソール
IBP
コンソール
Tiller
Ingress
Ingress
IBP
コンソール…
Proxy
CA Peer Orderer
Proxy
A社のクラスター
Tiller
Ingress
Proxy
CA Peer Orderer
A社または
他社のクラスター
Ingress
Proxy
Tiller
Ingress
Proxy
CA Peer Orderer
A社または
他社のクラスター
…
①
②③
④
⑤
⑥
ブロックチェーン管理者クラウド管理者
アプリ
利?者

48
IBP プロビジョニング後のカスタムリソース定義
Kubernetesダッシュボード ? 2020 IBM Corporation

49
構成例
東京02
worker1
worker2
worker3
File StorageKUBERNETES
SERVICE
Peer1
Peer2 CA
CAPeer3
Orderer2Orderer1
Orderer3
LOG ANALYSIS
WITH LOGDNA
MONITORING
WITH SYSDIG
永続ボリューム
Argent
Argent
監視系サービス
Orderer5
Orderer4

50
マルチゾーン構成の場合の考慮ポイント
? IBP for IBM Cloud はマルチゾーン対応可能
? 同?地域（リージョン）でマルチゾーンを選択(Tokyo02,Tokyo04,Tokyo05等)
? ゾーンを跨いでBlockchainノードの?動ヒーリング機能を実装可能
? Peerは管理コンソールから構築時にゾーン指定して構築可能
? Orderer、CAはAPIからゾーン指定で構築可能
参考?https://cloud.ibm.com/docs/services/blockchain?topic=blockchain-ibp-console-hadr-mr
東京02 東京04 東京05
Multizone-cluster
worker1
worker2
worker1
worker2
worker1
worker2
Peer1
Orderer1
Orderer2 CA
Orderer3
Peer2 Peer3
Orderer4
Orderer5
同じコンポーネントが同?ゾーンに偏ってしまわないようにゾーン指定配置が可能

51
バックアップ&リカバリー
? IBM Blockchain Platform はKubernetes環境にデプロイされるので、バックアップは
Kubernetesの永続ボリューム（persistent volume）をバックアップすることで取得できます。
? 安定したバックアップデータを取得するためにノードを停止する必要がありますが、これは
Kubernetesのスケール機能を使って deployment のreplicaをゼロにすることで行います。
(kubectl scale deployment my-deployment --replicas=0)
? バックアップを取得したら replica を1に戻してノードを再開します。(kubectl scale
deployment my-deployment --replicas=1)
? 永続ボリュームのバックアップとリストアはバックアップ?リストア用のツールがDockerイ
メージ (ibmcloud-backup-restore) として提供されているのでこれをデプロイしてbackup pod
を作成すると (kubectl apply -f backuppod.yaml) 対象ノードのポッドからデータがIBM Cloud
Object Storageにバックアップされます。
? バックアップの詳細（ピアのポッドの永続ボリュームのPVC (persistent volume claim) な
ど）はyamlファイルに指定します。
? リストアも同様に、ibmcloud-backup-restoreからrestore podを作成して（kubectl apply -f
restorepod.yaml）IBM Cloud Object Storage からリストアします。リストアは全てのノード
に対して行います。
参考? https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-ha

52
マルチクラウド(1) IBP on any Kubernetes

53
マルチクラウド(2) IBP and Hyperledger Fabric

54
まとめ
? チームでDX (Digital Transformation)
? Hyperledger Fabric のコンポーネント配置
? スケールアップ、スケールアウト
? Peerの?可?性(HA)
? Ordererの?可?性(HA)
? バージョンアップ
? 実装例?IBM Blockchain Platform for IBM Cloud
参考? https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-ha

狠狠撸

Hyperledger Fabric のプラットフォームおよびインフラ運用

Recommended

More Related Content

What's hot (20)

Similar to Hyperledger Fabric のプラットフォームおよびインフラ運用 (20)

More from LFDT Tokyo Meetup (20)

Hyperledger Fabric のプラットフォームおよびインフラ運用