A 自己回復性のベスト・プラクティス

このトピックでは、Oracle Blockchain Platformのエンタープライズ・シェイプ・インスタンスの単一の仮想マシン(VM)をメンテナンスのためにオフラインにするか、予期しない障害が発生した場合に、操作を継続するためのベスト・プラクティスについて説明します。

次のステップは、エンタープライズ・シェイプに基づくOracle Blockchain Platformのインスタンスにのみ適用されます(標準シェイプには適用されません)。また、このガイダンスは、次のデプロイメント・モデルにのみ適用されます。

• 単一の創業者組織
• 1つ以上の参加者組織を持つファウンダ

標準シェイプに基づくOracle Blockchain Platformのインスタンスは、単一のVMですべてのコンポーネント(ピア、オーダラおよびプラットフォーム・サービス)を実行するため、VMに障害が発生した場合や、メンテナンスのために停止する必要がある場合、インスタンス全体は使用できなくなります。可用性ドメインまたはフォルト・ドメイン間の分離はありません。本番環境では、標準シェイプに基づくインスタンスを使用しないでください。

かわりに、本番環境のエンタープライズ・シェイプに基づくインスタンスを使用してください。これらのインスタンスは、Hyperledger Fabricコンポーネントと大容量構成を個別にスケーリングします。エンタープライズ・シェイプ・インスタンスは、ピア、オーダラおよびプラットフォーム・コンポーネントをアベイラビリティ・ドメインおよびフォルト・ドメインにわたって自動的に分散し、インフラストラクチャ・レベルのフォルト分離を提供します。この動作を利用して高可用性を確保するには、次の項で説明するベスト・プラクティスを使用します。

エンドースメント・ポリシー

単一の(ファウンダ)組織を持つネットワークの場合は、使用可能なピアがトランザクション(OR('Founder.member')やOutOf(1, 'Founder.member')など)を承認できるようにするエンドースメント・ポリシーを使用します。ファウンダ組織に少なくとも2つのピアをデプロイします。

ファウンダ組織と1つの参加者組織を持つネットワークの場合、通常、OutOf(1, 'Founder.member', 'Participant1.member')ポリシーを使用できます。より厳密な構成では、冗長性が存在する場合にのみ、OutOf(2, 'Founder.member', 'Participant1.member')を使用できます。両方の組織に十分なピア冗長性がないかぎり、AND('Founder.member', 'Participant1.member')などの厳密なポリシーは避けてください。

詳細は、「エンドースメント・ポリシーの指定」に関する項を参照してください。

ピア・デプロイ

組織ごとに少なくとも2つのピアをデプロイします。Oracle Blockchain Platformは、可用性ドメインおよびフォルト・ドメインにピアを自動的に分散して、VMの障害後も少なくとも1つのピアが使用可能であることを保証します。

プライベート・データ・コレクション

プライベート・データ・コレクションを使用する場合は、「ピア必須」値(requiredPeerCount)を1以上に設定し、プライベート・データ・コレクションの定義で「最大ピア数」値(maxPeerCount)を2以上に設定します。少なくとも2つのピアが各プライベート・データ収集のメンバーであり、プライベート・データが少なくとも2つのピア間でコミットされていることを確認します。「ピア必須」の値は、トランザクションの提案が完了したとみなされる前にプライベート・データを正常に受信する必要があるピア(エンドース・ピアを除く)の最小数です。

組織間プライベート・データ収集の場合は、必要なピア数を単一の組織のピア数より多く構成し、複数の組織および仮想マシンに分散します。

詳細は、プライベート・データ・コレクションの追加に関する項を参照してください。

ラフトオーダーサービス

デフォルトの3ノードRaft注文サービスを使用します。Oracle Blockchain Platformは、オーダラを可用性ドメインおよびフォルト・ドメインに分散させるため、オーダリング・サービスは単一ノードの障害を処理できます。

アンカー・ピア

複数の組織を持つネットワークでは、組織ごとに少なくとも1つのアンカーピアを構成します。レジリエンスを向上させるには、組織ごとに少なくとも2つのアンカー・ピアを構成します。アンカー・ピアが必要なのは、ネットワークに複数のOracle Blockchain Platform組織インスタンスが存在する場合のみです。アンカー・ピアは、異なる組織間でゴシップベースの通信とピア検出を可能にするためです。

詳細は、アンカー・ピアの追加に関する項を参照してください。

チェーンコード・デプロイメント

ピアが使用できなくなった場合に継続性を確保するには、組織ごとに少なくとも2つのピアにチェーンコードをインストールして承認します。プライバシ要件で許可されている場合は、これらのデプロイメントをネットワーク内のOracle Blockchain Platformインスタンスに分散できます。

クライアントの接続性

特定のピアにラッチしないようにクライアント・アプリケーションを構成します。代わりに、基になるクライアントライブラリがピアの選択を処理できるようにします。

フォールバック状態データベース

状態データベースは、ピアが結合されているすべてのチャネルの各ピアに格納されます。VMに障害が発生すると、ピアが復元されるまで、そのピア上のローカル状態データベースが使用できなくなります。Oracle Blockchain Platformは、外部Oracle Databaseがフォールバック(セカンダリ)状態データベースとして機能するハイブリッド状態データベース・モデルをサポートしています。フォールバック状態データベースが有効化されている場合、状態データは、必要に応じてプライマリ状態データベースとして引き継ぐことができるデータベース内のピアVMの外部に保持されるため、耐久性とリカバリが向上します。

この関数を使用して回復力を向上させるには、次のステップを実行します。

• 本番ワークロードまたはクリティカル・ワークロードのフォールバック状態データベースの有効化
• ピア仮想マシンとは無関係にOracle Databaseをデプロイします。
• 高可用性のためにOracle Databaseを構成します。

これらのステップを実行すると、状態データが単一のVMのライフサイクルに関連付けられていないことを確認できます。フォールバック状態データベースは、単一のVMに障害が発生した場合のピア冗長性を補完して動作します。

詳細は、フォールバック状態データベースの作成を参照してください。