More Related Content
Similar to Hyperledger Fabric のプラットフォームおよびインフラ運用 (20)
More from Hyperleger Tokyo Meetup (20)
Hyperledger Fabric のプラットフォームおよびインフラ運用
- 1. IBM Blockchain
Hyperledger Fabric の
プラットフォームおよび
インフラ運⽤
2020年9⽉30⽇(⽔)
⽇本アイ・ビー・エム株式会社
ブロックチェーン事業部
エグゼクティブITスペシャリスト
紫関 昭光
Hyperledger Tokyo Meetup
© 2020 IBM Corporation
- 8. 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
© 2020 IBM Corporation
- 11. 11
Deployment Controllerが Peer_A1, CA_Aの Podを Node_2, 3に再配置
Peer の⾼可⽤性 (HA) 3/4
OrgA
Linux
Node_1
Kubernetes
File
Storage
Peer_A2
Peer_A1 CA_A
Linux
Node_2
Peer_A3
Linux
Node_3
データ
センター
© 2020 IBM Corporation
- 13. 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
© 2020 IBM Corporation
- 14. 14
データセンター_1でネットワーク障害発⽣ (10:40)
Peer の⾼可⽤性 (HA+) 2/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:40
9⽉30⽇
10:40
9⽉30⽇
10:40
© 2020 IBM Corporation
- 15. 15
データセンター_2, 3 でサービス続⾏ (10:40~12:10)
Peer の⾼可⽤性 (HA+) 3/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:40
9⽉30⽇
12:10
9⽉30⽇
12:10
© 2020 IBM Corporation
- 16. 16
データセンター_1が復旧 (12:15)、ブロックチェーンファイルの同期が始まる
Peer の⾼可⽤性 (HA+) 4/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:40
9⽉30⽇
12:15
9⽉30⽇
12:15
© 2020 IBM Corporation
- 17. 17
同期されたブロックチェーンファイルからPeer_A1のステートDBが最新状態に追いつく (13:00)
Peer の⾼可⽤性 (HA+) 5/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⽇
13:00
9⽉30⽇
13:00
9⽉30⽇
13:00
ブロック
チェーン
ファイルから
ステートDBを再⽣
© 2020 IBM Corporation
- 18. 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
© 2020 IBM Corporation
- 19. 19
データセンター_1で電源障害発⽣、RaftによりOrderer_1, 2を分離、Orderer_X3, 4, 5で続⾏
Orderer の⾼可⽤性 (HA+) 2/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
© 2020 IBM Corporation
- 20. 20
データセンター_1が復旧、Orderer_X1, 2が再スタート、Raftによりデータ同期
Orderer の⾼可⽤性 (HA+) 3/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
RaftRaft
© 2020 IBM Corporation
- 21. 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のバージョン管理
© 2020 IBM Corporation
- 23. 23
Orderer_X1を停⽌する。Orderer_X2~5によりオーダリングサービスは継続される。
$ docker stop $ORDERER_CONTAINER
v1.4からv2.2へのバージョンアップ 2/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 Stop
Running Running
Running
Running
v1
v1
v1
v1
© 2020 IBM Corporation
- 24. 24
Orderer_X1を削除する。削除する前に台帳データとMSPをバックアップする。
$ docker rm –f $ORDERER_CONTAINER
v1.4からv2.2へのバージョンアップ 3/13
サーバー
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
© 2020 IBM Corporation
- 25. 25
Orderer_X1をFabric v2.2のイメージとバックアップデータから開始する。Capabilityはまだ変更しない。
$ docker run hyperledger-orderer:2.2 orderer
v1.4からv2.2へのバージョンアップ 4/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
2.2.0
1.4.8
Running
Running Running
Running
Running
Running
v1
v1
v1
v1
© 2020 IBM Corporation
- 27. 27
Peer_A1を停⽌する。OrgAのエンドースメント処理はPeer_A2によって継続される。
$ docker stop $PEER_CONTAINER
v1.4からv2.2へのバージョンアップ 6/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
2.2.0
2.2.0
Running Running
Running
Running
RunningStop
v1
v1
v1
v1
© 2020 IBM Corporation
- 28. 28
Peer_A1のデータベース(CouchDBのステートDB等)をドロップし、フォーマットをv2にする。
$ docker run hyperledger-fabric-peer:2.2 peer node upgrade-dbs
v1.4からv2.2へのバージョンアップ 7/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
2.2.0
2.2.0
Running Running
Running
Running
RunningStop
v1
v1
v2
v1
© 2020 IBM Corporation
- 29. 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
© 2020 IBM Corporation
- 30. 30
Peer_A1を Fabric v2.2のイメージから開始し、DBを再構築する。Capabilityはまだ変更しない。
$ docker run hyperledger-fabric-peer:2.2 peer node start
v1.4からv2.2へのバージョンアップ 9/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
Peer_A1
2.2.0
Running
© 2020 IBM Corporation
- 33. 33
Application capability, Channel capability, Orderer capability をv2.2へ更新する。
v1.4からv2.2へのバージョンアップ 12/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
:
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
© 2020 IBM Corporation
- 34. 34
Fabric CA サーバー、Node SDK クライアントをアップグレードする。
v1.4からv2.2へのバージョンアップ 13/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
:
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
© 2020 IBM Corporation
- 47. 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社または
他社のクラスター
…
①
②③
④
⑤
⑥
© 2020 IBM Corporation
ブロックチェーン管理者クラウド管理者
アプリ
利⽤者
- 50. 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
同じコンポーネントが同⼀ゾーンに偏ってしまわないようにゾーン指定配置が可能
© 2020 IBM Corporation
- 51. 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
© 2020 IBM Corporation
- 54. 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
© 2020 IBM Corporation