1. Oracle Blockchain Platformの管理
  2. バージョン21へのアップグレード

4 バージョン21へのアップグレード

アップグレード・プロセスを開始する前に、仮想マシン(VM)の現在の状態のスナップショットを作成します。バージョン21.1.2からのロールバックはサポートされていません。

トピック

Transport Layer Securityの有効化

Oracle Blockchain Platform Enterprise Editionバージョン21にバンドルされている組込みLDAPサーバーでは、ポート636でのTransport Layer Security (TLS)接続のみをサポートしています。

ノート:

現在、TLSを無効にして組込みLDAPサーバーを使用している場合は、バージョン21にアップグレードする前に、次のステップを実行してTLSを有効にする必要があります。
  1. 「構成」タブを開きます。
  2. 認証サーバーで、「デフォルト」を選択し、「TLS有効」を「True」に設定します。
  3. 「テスト構成」をクリックして、設定が機能することを確認します。
  4. 「保存」、「アクティブに設定」の順にクリックします。
  5. 「インスタンス」タブを開きます。
  6. 組込みLDAPサーバーを使用するインスタンスごとに、インスタンス名をクリックして「インスタンスの詳細」ページを開きます。「アクション」メニューから、「更新」オプションを使用して認証サーバー構成の更新を選択し、更新を完了します。

v19.3.6へのパッチ適用

インスタンスにバージョン19.3.6のパッチを適用します。

バージョン21にアップグレードする前に、Blockchain Platform Managerと、ファウンダおよび参加者のすべてのインスタンスにバージョン19.3.6へのパッチを適用する中間ステップを完了する必要があります。詳細は、「v19.3.5以降へのインスタンスのパッチ適用」を参照してください。

使用可能なディスク領域の確認

各インスタンスでは、バージョン21.1.2にアップグレードするために約35 GBの使用可能なディスク領域が必要です。

  1. /dev/mapper/vg00-varディレクトリで、次のコマンドを実行して使用可能なディスク領域を確認します:
    df -h

    バージョン21にアップグレードするには、約35 GBの使用可能なディスク領域が必要です。

  2. 使用可能なディスク領域を増やすには、次のステップを実行します。rootとしてログインします。
    sudo su
  3. vgdisplayを実行して、/dev/mapper/vg00-varディレクトリに使用できる空き領域を確認します。
    たとえば、次の出力は、約24 GBを使用できることを示しています:

    Alloc PE / Size 18241 / 71.25 GiB Free PE / Size 6504 / <25.41 GiB

    この場合、次のコマンドは24 GBを/dev/mapper/vg00-varディレクトリに追加します。
    lvextend /dev/mapper/vg00-var -L +24G
resize2fs /dev/mapper/vg00-var
resize2fs /dev/mapper/vg00-home
  4. /dev/mapper/vg00-varディレクトリに領域を追加した後、df -hコマンドを再度実行して、少なくとも約35 GBの領域があることを確認します。

バージョン21へのインスタンスのアップグレード

インスタンスにパッチを適用して、バージョン19からバージョン21にアップグレードします。ただし、パッチを登録した後、パッチを適用する前にスクリプトを実行する必要もあります。

バージョン21.1.2にアップグレードすると、すべてのカスタム登録が移行されますが、ユーザーと登録の関連付けは移行されません。インスタンスをバージョン21.1.2にアップグレードした後、コンソールからカスタム登録にユーザーの関連付けを追加する必要があります。
  1. バージョン21.1.2のパッチを登録します。詳細は、「v19.3.4へのインスタンスのパッチ適用」を参照してください。パッチの登録に関する項のステップのみを実行します。
  2. sudo モードで/u01/blockchain/cp/config/scripts-21.1.2ディレクトリに移動し、 sh patchUpdates.sh -VMType bpmコマンドを実行します。
    このステップは、完了までに約20分かかることがあります。
  3. Blockchain Platform Managerおよびインスタンスにパッチを適用します。詳細は、「v19.3.4へのインスタンスのパッチ適用」を参照してください。「Blockchain Platform Managerへのパッチ適用」および「インスタンスへのパッチ適用」のステップを完了します。
ユーザーをカスタム登録に再度関連付けるには、コンソールの「ノード」タブでrestproxyノードを見つけます。「アクション」メニューで、登録の表示または管理を選択します。登録管理ページで、「登録ID」の下の登録を選択し、新規ユーザーの関連付けを展開してユーザーIDを入力し、ユーザーを登録に追加します。すべてのユーザーを追加したら、「関連付け」をクリックします。

外部ロード・バランサのポート・マッピングの更新

外部ロード・バランサを使用するすべてのインスタンスは、バージョン21へのアップグレード後に再構成する必要があります。

バージョン21では、CAおよびRESTプロキシがコンソールと同じポートを共有するため、CAおよびRESTプロキシとPrometheusのポート・マッピングは不要になりました。また、オーダラのRaftポートはバージョン19のオーダラ問合せポートと同じですが、RaftポートはTLSに対して有効ではありません。外部ロード・バランサを使用する場合は、これらの変更を考慮して構成を更新する必要があります。
  1. nginx.confファイルの外部ロード・バランサ構成からCA、RESTプロキシおよびPrometheusセクションを削除します。
    たとえば、nginx.confファイルから次のセクションを削除します。
        upstream server_server1_restproxy_47201 {
        server server1.example.com:10001;
    }
    server {
        listen *:47201 ssl;
        proxy_pass server_server1_restproxy_47201;
        ssl_certificate     /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;
    }
    upstream server_server1_ca_47202 {
        server server1.example.com:10002;
    }
    server {
        listen *:47202 ssl;
        proxy_pass server_server1_ca_47202;
        ssl_certificate     /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;
    }
    upstream server_server1_prometheus_47203 {
        server server1.example.com:10003;
    }
    server {
        listen *:47203 ssl;
        proxy_pass server_server1_prometheus_47203;
        ssl_certificate     /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;
    }
  2. ネットワーク内のすべてのオーダラの2番目の(Raft)ポートでSSLが使用されていないことを確認します。
    次の例では、2番目のポートはSSLを使用しなくなりました。
    upstream server_server1_orderer0_47204 {
        server server1.example.com:10004;
    }
    server {
        listen *:47204 ssl;
        proxy_pass server_server1_orderer0_47204;
        ssl_certificate     /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;
    }
    upstream server_server1_orderer0_47205 {
        server server1.example.com:10005;
    }
    server {
        listen *:47205;
        proxy_pass server_server1_orderer0_47205;
        ssl_certificate     /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;
    }
  3. nginxを再起動します。

Raftコンセンサス・プロトコルの構成

バージョン21の製品では、Kafkaベースのオーダリングではなく、Raftベースのオーダリングが使用されています。チャネルおよびインスタンス情報を収集してスクリプトを実行することで、コンセンサス・タイプをKafkaからRaftに変更します。

すべてのファウンダおよび参加者インスタンスがバージョン21.1.2にアップグレードされた後にのみ、次のステップを実行します。
  1. Blockchain Platform Manager仮想マシン(VM)およびすべてのインスタンスVMで、/u01/blockchain/cp/config/scripts-21.1.2ディレクトリに移動し、rootアカウントからconfig-obplog.shスクリプトを実行してログを/var/log/messagesから/u01/obp-logs/にリダイレクトします。
  2. すべてのインスタンスVMで、次のステップを実行します。
    1. sshを使用してログインし、docker exec -it bcscm bashコマンドを実行してDockerコンテナでコマンド・プロンプトを開きます。
    2. mkdir /cm/instancesコマンドを実行して、/cm/instancesディレクトリを作成します。
    3. ファウンダ・インスタンスの/cm/instancesディレクトリで、チャネル名と参加者組織の名前にJSONファイルを作成します。
      たとえば、ファウンダ・インスタンスにdefaultとchannel1という名前のチャネルと、partner1とpartner2という名前の参加者組織がある場合は、次のテキストのようなJSONファイルを作成します。testchainidチャネルはデフォルトのシステム・チャネルであり、ファイルに含まれている必要があります。参加者組織がない場合は、空のparticipants配列を含めます。アクティブでなくなった参加者組織またはネットワークを離れた参加者組織がある場合は、それらの組織によって作成されたチャネルをdiscards配列に移動します。また、アクティブな組織が50パーセント未満のチャネルをdiscards配列に移動します。
      {
"channels": [
"testchainid",
"default",
"channel1"
],"discards": [
],
"participants": [
"partner1",
"partner2"
]
}
    4. 各参加者インスタンスで、参加者インスタンス名をパラメータとして、/u01/blockchain/cp/config/scripts-21.1.2ディレクトリのgetParticipantAdminCerts.shスクリプトを実行して、mspディレクトリ・アーカイブを生成します。
      たとえば、getParticipantAdminCerts.sh participant_instance_nameです。
      このスクリプトにより、participant_instance_name.msp.tar.gzファイルが作成されます。
    5. 各参加者インスタンスで、tar -xvf instance_name.msp.tar.gzコマンドを実行してmspディレクトリ・アーカイブを抽出します。
    6. 各参加者組織からファウンダ・インスタンスの/cm/instancesディレクトリにmspディレクトリをコピーします。サブディレクトリ名として参加者組織の名前を指定します。
      たとえば、参加者組織の名前がpartner1の場合、mspディレクトリをパートナのディレクトリから/cm/instances/partner1にコピーします。
    7. ファウンダ・インスタンスで、/cm/scriptディレクトリに移動し、次のコマンドを実行してコンセンサス・タイプをKafkaからRaftに変更します。以前に作成したJSONファイルの名前がchannels.jsonの場合は、./kafka2raft.sh -c /cm/instances/channels.json -a /cm/instancesコマンドを実行します
      スクリプトが完了すると、インスタンスはアクティブになり、Kafkaコンテナは実行されません。
    8. すべての参加者インスタンスで、/cm/scriptディレクトリに移動し、./kafka2raft.shコマンドを実行してコンセンサス・タイプをKafkaからRaftに変更します
  3. すべての参加者インスタンスで、ファウンダ・インスタンスからオーダリング・サービス設定をインポートします。
    1. ファウンダ・コンソールの「ネットワーク」タブでファウンダ組織を見つけます。ファウンダ組織の「アクション」メニューを選択し、オーダラ設定のエクスポートを選択します。
      これにより、設定を含むJSONファイルが生成され、ファイルが保存されます。
    2. 各参加者コンソールで、「ネットワーク」タブを開きます。オーダラ設定、「インポート」の順にクリックします。ファウンダから提供されたJSONファイルの場所の入力を求めるウィンドウが開きます。ファイルをアップロードすることを選択し、「追加」をクリックします。
  4. 各データ・プレーンVMで、/u01/blockchain/cp/config/scripts-21.1.2に移動し、sudoモードでsh patchUpdates.sh -VMType instanceコマンドを実行します。
  5. Blockchain Platform Managerの「インスタンス」タブを開き、アップグレードしたインスタンスごとにインスタンス名をクリックして「インスタンスの詳細」ページを開きます。
デフォルトでは、バージョン19の開発者インスタンスには2つのオーダラしか含まれていませんでした。バージョン21.1.2へのアップグレードとRaftコンセンサス・プロトコルの変更を完了したら、少なくとも3つのオーダラが使用できるように別のオーダラを追加します。詳細は、「インスタンスのスケール・インまたはスケール・アウト」を参照してください。