6 インスタンスのプロビジョニング

Oracle Blockchain Platformインスタンスを作成する前に

Oracle Blockchain Platformをプロビジョニングする前に、開発者またはエンタープライズ・インスタンスがニーズを満たしているかどうかを判断します。

使用するプロビジョニング・シェイプの決定

インスタンスをプロビジョニングする際に、2つの構成から選択します。これらのオプション間の移行は現在サポートされていません。

構成 特徴
開発者

このスタータ・シェイプは、開発および評価に使用することをお薦めします。

  • デフォルト構成は、他のすべてのブロックチェーン機能(ピア、オーダラ、CA、コンソール、RESTプロキシ、内部ロード・バランサなど)を実行する1つのプラットフォームVMと、チェーンコードを実行するための1つのチェーンコード・ランタイム・コンテナVMですオプションで、チェーンコードを別個のVMで実行するように選択できます。
  • 1つのFabric-CAノード
  • 1つのノードの単一VM Raft/Zookeeperクラスタ
  • 最大14のピア・ノード
  • 動的に管理されるチェーンコード実行コンテナ
  • 操作Webユーザー・インタフェース用のコンソール・サービス
  • RESTful API用のRESTプロキシ・サービス
  • 認証およびロール管理のためのLDAPサーバー統合
  • ロード・バランサ
エンタープライズ

数十トランザクション/秒(TPS)の1桁のTPSレートというパフォーマンス要件を持つファウンダおよび参加者インスタンスの小規模から中規模の本番デプロイメントに適した高可用インスタンス構成。

  • デフォルト構成は、他のすべてのブロックチェーン機能(ピア、オーダラ、CA、コンソール、RESTプロキシ、内部ロード・バランサなど)を実行する3つのプラットフォームVMです
  • チェーンコードを実行するための1つのチェーンコード・ランタイム・コンテナVM
  • 2つのFabric-CAノード
  • 高可用性のための3つのVM Raft/Zookeeperクラスタ。オプションで、これらに他のVMを再利用することもできます。
  • 個別の仮想マシンに分散された最大14のピア・ノード
  • 分離された仮想マシン内で動的に管理されるチェーンコード実行コンテナ
  • 高可用性のために個別の仮想マシン間でレプリケートされる操作Webユーザー・インタフェース用のコンソール・サービス
  • RESTful API用のRESTプロキシ・サービス
  • 認証およびロール管理のためのLDAPサーバー統合
  • ロード・バランサ

Blockchain Platform Managerを使用したインスタンスのプロビジョニング

Blockchain Platform Managerでブロックチェーン・ファウンダまたは参加者インスタンスを作成するには、新規インスタンスの作成ウィザードを使用します。

プロビジョニングできるOracle Blockchain Platformインスタンスには、次の2つのタイプがあります:
  • ファウンダ組織: 参加者が後から参加できる新しいネットワークを含む、完全なブロックチェーン環境。

  • 参加者インスタンス: 参加先のファウンダ組織がすでにある場合、資格証明によってネットワークへのアクセス権が付与される場合は参加者インスタンスを作成できます。

ハードウェア・セキュリティ・モジュール(HSM)を使用してキーを管理する場合は、インスタンスをプロビジョニングする前に、各VMでHSMクライアントを構成する必要があります。詳細は、「ハードウェア・セキュリティ・モジュール・クライアントの構成」を参照してください。

  1. Blockchain Platform Managerで、インスタンス・ページを開きます。
  2. インスタンスの作成を選択します。
  3. 次のフィールドを指定します。
    セクション フィールド 説明
    全般 インスタンス名

    Oracle Blockchain Platformインスタンスの名前を入力します。

    サービス・インスタンス名:

    • 1つ以上の文字が含まれている必要があります。
    • 15文字以下である必要があります。
    • ASCII文字(aからz)で始まる必要があります。
    • ASCII文字または数字のみを使用する必要があります。
    • ハイフンを含めることはできません。
    • その他すべての特殊文字を含めることはできません。
    • アイデンティティ・ドメイン内で一意である必要があります。
    説明

    オプション。

    Oracle Blockchain Platformインスタンスの簡単な説明を入力します。

    ロール

    ファウンダは、完全なブロックチェーン環境を作成する場合に選択します。このインスタンスはファウンダ組織になり、後で新しい参加者をネットワークに組み込むことができます。

    参加者は、このインスタンスを使用する前に別の場所で作成された既存のブロックチェーン・ネットワークに参加するインスタンスを作成する場合に選択します。

    構成
    デプロイメントのニーズを満たすプロビジョニング・シェイプを選択します:
    • 開発者
    • エンタープライズ
    ピア

    このサービス・インスタンスに初期作成されるピア・ノードの数を指定します。1から14のピア・ノードを作成できます。後で、Oracle Blockchain Platformコンソールで追加のピア・ノードを作成できます。

    クラスタ構成 プラットフォーム・ホスト Oracle Blockchain PlatformをホストするVMの完全修飾ホスト名を追加します。開発者インスタンスの場合、VMを1つ指定する必要があります。エンタープライズ・インスタンスの場合、高可用性クラスタを作成するために3つのVMを指定する必要があります。
    チェーンコード・ホスト チェーンコードをホストするVMの完全修飾ホスト名を追加します。
    追加の構成 外部ロード・バランサを使用する Oracle Blockchain Platform Enterprise Editionに付属するものではなく、外部ロード・バランサを使用する場合に選択します。

    ロード・バランサの完全修飾ドメイン名およびポートを入力します。

    TLSルートCA証明書をアップロードします。TLSルートCA証明書の名前はrootCA.zipとし、tls-ca.pemという名前の単一ファイルが格納されている必要があります

    サード・パーティのCAアーカイブ

    オプション。

    Oracle Blockchain Platformには、認証局(CA)が組み込まれており、インスタンス内のすべてのブロックチェーン・ノードの自己署名証明書を作成するために使用されます

    独自の認証局からの証明書を使用し、Oracle Blockchain Platform認証局を中間CAとして使用する場合は、CAアーカイブをアップロードできます。アップロードする証明書は、Oracle Blockchain Platformノードの中間証明書の署名に使用されるため、ルートCAチェーン下に組み込まれます。

    アーカイブは、次のファイルが含まれるzipファイルです:
    • CAチェーン - xxxca-chain.pemという名前です。署名CAから最上位レベルのCAまでのCAファイル・シーケンス全体が存在する必要があります。
    • キー - xxxca-key.pemという名前です。キーは、256ビットの楕円曲線のキーである必要があります。prime256v1曲線をお薦めします。キーは、PKCS #8形式の暗号化されていない秘密キーである必要があります。
    • 証明書 - xxxca-cert.pemという名前です。Base64形式である必要があります。サブジェクト・キー識別子の拡張子を含める必要があります。
    ここで、xxxは任意の識別子です。アーカイブは2MB未満にする必要があります。
    HSM暗号化サービスの有効化 ハードウェア・セキュリティ・モジュール(HSM)を使用してインスタンスのキー・ペアを管理する場合に選択します。HSMを使用するには、インスタンスの作成時にこれを有効にする必要があります。インスタンスの作成後は構成できません。選択すると、次の追加フィールドが表示されます:
    • ライブラリ・パス: 適切なライブラリ・ファイルへのパスを指定します:
      • Luna DPoDクライアントを選択する場合: libCryptoki2.so
      • Safenet Luna Network HSMクライアント32-bitを選択する場合: libCryptoki2.so
      • Safenet Luna Network HSMクライアント64-bitを選択する場合: libCryptoki2_64.so
      指定されたインストール・スクリプトを使用してHSMクライアントをインストールした場合は、デフォルトの場所を受け入れます。
    • パーティション・ラベル: キー管理に使用するパーティションのラベルを指定します。
    • PIN: パーティションの暗号化担当者のロールのユーザーPINを指定します。
    • Chrystoki構成パス: Chrystoki.conf構成ファイルを含むディレクトリへのパスを指定します。指定されたインストール・スクリプトを使用してHSMクライアントをインストールした場合は、デフォルトの場所を受け入れます。
    HSM接続のテストをクリックして、すべての定義済ホストへのHSM接続を確認します。
  4. 外部ロード・バランサを使用している場合、「ポート・マッピング」ダイアログが表示されます。これには、ロード・バランサで構成する必要があるすべてのポートのリストが含まれます。
    1. ポートのリストを.csvファイルにエクスポートするには、ポート・マッピングのエクスポートをクリックします。
    2. ロード・バランサの構成に必要なすべてのアクセス権と権限がある場合は、次のステップに進むことができます。または、「遅延」をクリックして、ロード・バランサの構成中にインスタンスの作成を一時停止し、後でインスタンス・プロビジョニングに戻ることもできます。
    3. ロード・バランサで、次のNginx構文の例に示すようにマッピングを実行します(my.blockchain.example.comはブロックチェーン・インスタンス(内側)のFQDNです):
      ...stream {
          upstream port1 {
          server my.blockchain.example.com:10001;
        }
        server {
              listen *:10003 ssl;
              ssl_certificate /etc/nginx/server.pem; # use your own certificate/key
              ssl_certificate_key /etc/nginx/serverkey.pem;
              proxy_pass port1;
        }
      ...
    4. ポート・マップに示されているすべてのポートについて繰り返します。

      ノート:

      将来のある時点で、新しいピアを追加してインスタンスをスケール・アウトする場合は、前述のステップを使用してその新しいピアを忘れずにマップしてください。
  5. ロード・バランサの構成が完了したら、構成されていることを確認するチェック・ボックスを選択し、「インスタンスの作成」をクリックします。
インスタンスが作成され、インスタンス・リストに表示されたら、インスタンス名の横にあるメニューからサービス・コンソールを起動できます。『Oracle Blockchain Platformの使用』の説明に従って、コンソールを使用してネットワークを構成します。

REST APIを使用したインスタンスのプロビジョニング

REST APIを使用してOracle Blockchain Platformインスタンスをプロビジョニングできます。

次の例では、REST APIを使用して、ハードウェア・セキュリティ・モジュール(HSM)を使用するOracle Blockchain Platformインスタンスを作成する方法を示します。HSMを使用しないインスタンスの場合、useHSMfalseに設定し、hsmConfigurationオブジェクトを指定しないでください。

HSMを使用するインスタンスの場合、インスタンスをプロビジョニングする前に、すべてのホストからHSMへの接続を確認します。詳細は、HSM接続のテストに関する項を参照してください。
curl -X POST \ 
-u <username>:<password> \ 
https://localhost:7443/api/v1/blockchainPlatforms/instances \
-H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \ 
-F 'payload={
"name": "obpinstance1",
"desc": "test instance",
"platformRole": "founder",
"configuration": "Developer",
"peer": 4,
"cluster": {
"platformHosts": [
"10.182.73.23",
"10.182.73.20"
],
"crcHosts": [
"10.182.73.23",
"10.182.73.20"
]
},
"additionalConfiguration": {
"instanceFQDN": "domain.host.com"
"startPort": 0,
"enableTLS": true,
"useHSM": true,
"hsmConfiguration": {
"library": "/etc/hyperledger/fabric/dpod/fabric/libs/64/libCryptoki2.so",
"label": "fabric",
"pin": "password",
"chrystokiConf": "/etc/hyperledger/fabric/dpod/fabric"
}
}
}'
  • name
    • 1つ以上の文字が含まれている必要があります。
    • 15文字以下である必要があります。
    • ASCII文字(aからz)で始まる必要があります。
    • ASCII文字または数字のみを使用する必要があります。
    • ハイフンを含めることはできません。
    • その他すべての特殊文字を含めることはできません。
    • アイデンティティ・ドメイン内で一意である必要があります。
  • desc
    • オプション: インスタンスの説明を入力します
  • platformRole
    • developerまたはfounderに設定する必要があります
  • configuration
    • Developer: 3つのRaftオーダラ、および1つのVMに合計3つのOCPU
    • Enterprise: 3つのノードのRaftクラスタおよび3つのX VM
  • peer
    • このサービス・インスタンスに初期作成されるピア・ノードの数を指定します。
    • 1から14のピア・ノードを作成できます。
  • cluster
    • クラスタの情報を入力します:
      • platformHosts: プラットフォーム・クラスタをホストするVM
      • crcHosts: チェーンコードをホストするVM
  • additionalConfiguration
    • ロード・バランサまたはハードウェア・セキュリティ・モジュールをサポートするための追加情報を入力します。
      • instanceFQDN: 外部ロード・バランサの完全修飾ドメイン名。これは外部ロード・バランサのみに使用されます - 外部ロード・バランサを使用していない場合、このパラメータを指定する必要はありません。
      • startPort
      • enableTLS
      • useHSM: ハードウェア・セキュリティ・モジュールを使用してキーを管理する場合はtrueに設定します。
      • hsmconfiguration: library (libCryptoki2.soまたはlibCryptoki2_64.soファイルへのパス)、label (キー管理に使用するパーティション・ラベル)、pin (暗号化担当者のPIN)およびchrystokiConf (Chrystoki.confファイルが含まれているディレクトリ)を指定します。

外部ロード・バランサを使用する際の追加条件

21.1.2以降のバージョンでは、インスタンスをプロビジョニングする前にロード・バランサをインストールし、TLSルートCA証明書をアップロードし、Oracle Blockchain Platformインスタンスを作成する前にロード・バランサでポートを構成する必要があります。プロビジョニング後、ロード・バランサを高可用性用に構成できます。

高可用性の構成

エンタープライズ対応のインスタンスで、異なるVMを使用して高可用性を実現するには、外部ロード・バランサを構成してクラスタ内のすべてのプラットフォームVMのリストを追加します(RaftとZooKeeper VMは、アップストリーム(バックエンド)リストとしてすでに可用性が高くなっています)。

たとえば、次のホスト名を持つVMのクラスタがあるとします
  • a.example.com
  • b.example.com
  • c.example.com
構成スニペットは次のようになります。
...
stream {
upstream rest_proxy_backend_servers
{ 
    server a.example.com:10001; 
    server b.example.com:10001; 
    server c.example.com:10001; 
}
server
{ 
    listen *:10003 ssl; 
    ssl_certificate /etc/nginx/server.pem; # use your own certificate/key 
    ssl_certificate_key /etc/nginx/serverkey.pem; 
    proxy_pass rest_proxy_backend_servers; 
}
...
stream { 
upstream peer0_backend_servers
{
    server a.example.com:10036;
    server b.example.com:10036;
    server c.example.com:10036;
} 
server {
    listen *:10036 ssl;
    ssl_certificate /etc/nginx/server.pem; # use your own certificate/key
    ssl_certificate_key /etc/nginx/serverkey.pem;
    proxy_pass peer0_backend_servers; 
}
...

インスタンス・クラスタ内の外部で使用可能な各ポートが各VMで公開され、適切なサービスに自動的にルーティングされます(コンソール、メンバーシップ/CA、オーダラ、ピア、RESTプロキシ)。

LBRポート・マップ・ボタンを使用してリストされたすべてのポートが、この方法でルーティングされることを確認します。

VMが3つのクラスタをプロビジョニング後、コントロール・プレーンとコンポーネント・マネージャが実行されるswarmマネージャ(クラスタ内の最初のマシン)で次のコマンドを実行します。
$ docker node ls 
これにより、クラスタ内のノードのリストが返されます。たとえば:
 [oracle@dhcp-10-144-63-180 ~]$ docker node ls
ID                            HOSTNAME                                   STATUS   AVAILABILITY  MANAGER STATUS  ENGINE VERSION
fz1ksoxysyorz754x0hswnird     dhcp-10-144-62-149.usdhcp.oraclecorp.com   Ready    Active                        18.09.1-ol
rayhna7vdiup5p7tkmxxepyex *   dhcp-10-144-63-180.usdhcp.oraclecorp.com   Ready    Active        Leader          18.09.1-ol
マネージャ・ステータスを持たないノードごとに、次の例のようなコマンドを使用してノードをプロモートします。
$ docker node promote dhcp-10-144-62-149.usdhcp.oraclecorp.com

少なくとも3つのノードがこの方法でプロモートされることを確認してください。