第7章 上級者向けチュートリアル

7.1. ワークフローの例: クラスターをスケールダウンするときの自動化トランザクションリカバリー機能

重要

この機能はテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は本番環境での使用はサポートされず、今後大きな変更がある場合があります。テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの テクノロジープレビュー機能のサポート範囲 を参照してください。

注記

このチュートリアルでは、OpenShift 3 と、EAP オペレーターを使用せずにトランザクションを復元する場合にのみ該当します。

このチュートリアルでは、クラスターをスケールダウンするときに JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行します。このチュートリアルでは、jta-crash-rec-eap クイックスタートサンプルと eap73-tx-recovery-s2i アプリケーションテンプレートを使用して、クラスターのスケールダウンによって OpenShift Pod で終了されたときに XA トランザクションがどのように専用の移行 Pod によってリカバリーされるかを示します。JDK 11 イメージのアプリケーションテンプレートは eap73-openjdk11-tx-recovery-s2i です。

このチュートリアルでは、amq-broker-72-openshift:1.1 イメージストリームを使用して JMS 準拠のメッセージブローカーを提供します。初期ブローカー Pod を設定すると、OpenShift Container Platform 機能を使用してクイックスタートを迅速にデプロイできます。

注記

クイックスタートを使用するための前提条件として、AMQ Long Term Support (LTS)イメージからイメージストリームを作成し、イメージストリーム amq-broker-72-openshift:1.1 という名前を指定する必要があります。Red Hat Ecosystem Catalog から amq7/amq-broker-lts-rhel7:7.4 コンテナーイメージをダウンロードして LTS イメージにアクセスできます。AMQ Broker のインストールに関する詳細は、基本ブローカーのデプロイ を参照してください。

注記

jta-crash-rec-eap7 クイックスタートは、JBoss EAP に含まれる H2 データベースを使用します。これは、例でのみ使用される、ライトウェイトなリレーショナルデータソースのサンプルです。堅牢でもスケーラブルでもなく、サポートされないため、本番環境では使用しないでください。

その他のリソース

7.1.1. デプロイメントの準備

  1. oc login コマンドを使用して、OpenShift インスタンスにログインします。
  2. 新しいプロジェクトを作成します。

    $ oc new-project eap-tx-demo
  3. 基盤の Pod の実行に使用される default サービスアカウントに view ロールを追加します。これにより、サービスアカウントが eap-tx-demo namespace のすべてのリソースを確認できるようになります。 これは、クラスターの管理に必要です。

    $ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
  4. 自動化トランザクションリカバリーが機能するには、JBoss EAP アプリケーションは ReadWriteMany 永続ボリューム を使用する必要があります。

    ${APPLICATION_NAME}-eap-claim 永続ボリュームクレーム のデータを保持するため eap73-tx-recovery-s2i アプリケーションテンプレートによって想定される永続ボリュームのプロビジョニングを行います。

    この例は、以下の定義で NFS メソッドを使用してプロビジョニングされる永続ボリュームオブジェクトを使用します。

    $ cat txpv.yaml
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: txpv
    spec:
      capacity:
        storage: 1Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      nfs:
        path: /mnt/mountpoint
        server: 192.168.100.175
  5. 上記の定義の path および server フィールドを環境に合わせて更新し、以下のコマンドを使用して永続ボリュームのプロビジョニングを行います。

    $ oc create -f txpv.yaml
    persistentvolume "txpv" created
    $ oc get pv
    NAME      CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
    txpv      1Gi        RWX           Retain         Available                                      26s
    重要

    NFS メソッドを使用して eap73-tx-recovery-s2i アプリケーションテンプレートの永続ボリュームオブジェクトのプロビジョニングを行う場合、適切なパーミッションがある状態でマウントポイントをエクスポートするようにしてください。マウントポイントのエクスポート元となるホストで以下を実行します。

    # chmod -R 777 /mnt/mountpoint
    # cat /etc/exports
    /mnt/mountpoint *(rw,sync,anonuid=185,anongid=185)
    # exportfs -va
    exporting *:/mnt/mountpoint
    # setsebool -P virt_use_nfs 1

    上記の /mnt/mountpoint パスは、環境に合わせて変更してください。

7.1.2. デプロイメント

  1. eap73-tx-recovery-s2i アプリケーションテンプレートを使用して、jta-crash-rec-eap7 クイックスタートをデプロイします。以下を指定します。

    例: eap73-tx-recovery-s2i アプリケーションテンプレート (JDK 8)

    $ oc new-app --template=eap73-tx-recovery-s2i \
    --name=eap-app

    例: eap73-openjdk11-tx-recovery-s2i アプリケーションテンプレート (JDK 11)

    $ oc new-app --template=eap73-openjdk11-tx-recovery-s2i \
    --name=eap-app

  2. ビルドが完了するまで待ちます。oc logs -f bc/eap-app コマンドを使用すると、ビルドの状態を確認できます。
  3. JAVA_OPTS_APPEND および JBOSS_MODULES_SYSTEM_PKGS_APPEND 環境変数の定義で eap-app デプロイメント設定を編集します。

    $ oc get dc
    NAME                REVISION   DESIRED   CURRENT   TRIGGERED BY
    eap-app             1          1         1         config,image(eap-app:latest)
    eap-app-amq         1          1         1     config,image(amq-broker-72-openshift:1.1)
    eap-app-migration   1          1         1         config,image(eap-app:latest)
    $ oc set env dc/eap-app \
    -e JBOSS_MODULES_SYSTEM_PKGS_APPEND="org.jboss.byteman" \
    -e JAVA_OPTS_APPEND="-javaagent:/tmp/src/extensions/byteman/byteman.jar=script:/tmp/src/src/main/scripts/xa.btm"
    deploymentconfig "eap-app" updated

    この設定は、以下のように XA トランザクションの処理を変更するよう、Byteman のトレースおよび監視ツールに通知します。

    • 最初のトランザクションは成功するように常に許可されます。
    • XA トラザクションが 2 つ目のトランザクションのフェーズ 2 を実行するとき、特定の Pod の JVM プロセスが停止されます。

7.1.3. JTA クラッシュリカバリーアプリケーションの使用

  1. 現在の namespace で実行中の Pod をリストします。

    $ oc get pods | grep Running
    NAME                        READY     STATUS      RESTARTS   AGE
    eap-app-2-r00gm             1/1       Running     0          1m
    eap-app-amq-1-mws7x         1/1       Running     0          2m
    eap-app-migration-1-lvfdt   1/1       Running     0          2m
  2. 新しい XA トラザクションを発行します。

    1. ブラウザーを開き、http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec にアクセスして、アプリケーションを起動します。
    2. MercedesKey フィールド、BenzValue フィールドに入力します。Submit ボタンをクリックします。
    3. しばらく待ち、Refresh Table リンクをクリックします。
    4. Mercedes エントリーが含まれるテーブル行がどのように updated via JMS. で更新されるか注意してください。まだ更新されない場合は、Refresh Table リンクを数回クリックしてください。この代わりに、eap-app-2-r00gm Pod のログを調べ、トランザクションが適切に処理されたことを確認することもできます。

      $ oc logs eap-app-2-r00gm | grep 'updated'
      INFO  [org.jboss.as.quickstarts.xa.DbUpdaterMDB] (Thread-0 (ActiveMQ-client-global-threads-1566836606)) JTA Crash Record Quickstart: key value pair updated via JMS.
  3. ブラウザーを使用し、http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec で 2 つ目の XA トラザクションを発行します。

    1. LandKey フィールドに、RoverValue フィールドに入力します。Submit ボタンをクリックします。
    2. しばらく待ち、Refresh Table リンクをクリックします。
    3. Land Rover エントリーが updated via …​ 接尾辞なしでどのように追加されたかに注目してください。
  4. クラスターをスケールダウンします。

    $ oc scale --replicas=0 dc/eap-app
    deploymentconfig "eap-app" scaled
    1. eap-app-2-r00gm Pod の終了がどのようにスケジュールされたかを確認します。

      $ oc get pods
      NAME                        READY     STATUS        RESTARTS   AGE
      eap-app-1-build             0/1       Completed     0          4m
      eap-app-2-r00gm             1/1       Terminating   0          2m
      eap-app-amq-1-mws7x         1/1       Running       0          3m
      eap-app-migration-1-lvfdt   1/1       Running       0          3m
  5. マイグレーション Pod のログを確認し、トランザクションリカバリーがどのように実行されるかを確認します。リカバリーの終了まで待機します。

    $ oc logs -f eap-app-migration-1-lvfdt
    Finished Migration Check cycle, pausing for 30 seconds before resuming
    ...
    Finished, recovery terminated successfully
    Migration terminated with status 0 (T)
    Releasing lock: (/opt/eap/standalone/partitioned_data/split-1)
    Finished Migration Check cycle, pausing for 30 seconds before resuming
    ...
  6. クラスターを元にスケールアップします。

    $ oc scale --replicas=1 dc/eap-app
    deploymentconfig "eap-app" scaled
  7. ブラウザーを使用して再度 http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec にアクセスします。
  8. テーブルに両方のトランザクションのエントリーが含まれることに注意してください。以下の出力と似たものになります。

    表7.1 例: データベーステーブルの内容

    データベーステーブルの内容 

    Key

    Value

    Mercedes

    Benz updated via JMS.

    Land

    Rover updated via JMS.

    上記のテーブルの内容は、2 つ目の XA トラザクションが終了する前にクラスターがスケールダウンしたものの、マイグレーション Pod がトランザクションリカバリーを実行し、トランザクションが正常に完了したことを示しています。