3.7. JBoss EAP for OpenShift イメージのデプロイメントに関する考慮事項

3.7.1. スケールアップおよび永続ストレージのパーティショニング

永続ストレージを用いて JBoss EAP をデプロイする方法は、単一ノードのパーティショニングと複数ノードのパーティショニングの 2 つがあります。

単一ノードのパーティショニングは、トランザクションデータを含む JBoss EAP データストアディレクトリーをストレージボリュームに格納します。

マルチノードのパーティショニングは、追加の独立した split-n ディレクトリーを作成し、各 JBoss EAP Pod のトランザクションデータを格納します。n は、増分整数です。JBoss EAP Pod が更新された場合、予期せず停止した場合、または再デプロイされた場合、この通信は変更されません。JBoss EAP Pod が再度操作可能になると、関連する split ディレクトリーに再接続し、以前と同様に続行されます。新しい JBoss EAP Pod が追加されると、対応する split-n ディレクトリーがその Pod に作成されます。

複数ノードの設定を有効にするには、SPLIT_DATA パラメーターを true に設定する必要があります。これにより、データストアとして使用される永続ボリューム内の各インスタンスに対して、サーバーが独立した split-n ディレクトリーを作成します。

警告

EAP オペレーターを使用しているときに SPLIT_DATA などの環境変数を使用すると、一貫性の問題が発生する可能性があります。EAP オペレーターを使用して、OpenShift 4 以降のバージョンでトランザクション検出を管理する必要があります。

これは、トランザクションリカバリーテンプレート (JDK 8 の場合は eap73-tx-recovery-s2i、JDK 11 の場合は eap73-openjdk11-tx-recovery-s2i) のデフォルト設定となりました。

重要

単一ノードと複数ノードのパーティショニングではストレージの方法が異なるため、デプロイメントを単一ノードから複数ノードに変更すると、data ディレクトリーにこれまで保存されたすべてのデータ (メッセージやトランザクションログを含む) がアプリケーションから失われます。ストレージパスが一致しないため、デプロイメントを複数ノードから単一ノードに変更した場合でも同様です。

3.7.2. スケールダウンおよびトランザクションリカバリー

JBoss EAP for OpenShift イメージが 複数ノード 設定を使用してデプロイされると、クラスターがスケールダウンした場合に、終了する Pod の data ディレクトリーに、予期せず終了したトランザクションが残る場合があります。

クラスターが次回スケールアップするまで、終了する Pod のデータストア内にトランザクションが残らないようにするため、JBoss EAP トランザクションリカバリーテンプレート (JDK 8 の場合は eap73-tx-recovery-s2i、JDK 11 の場合は eap73-openjdk11-tx-recovery-s2i ) はトランザクションの移行を管理する移行 Pod を含む次のデプロイメントを作成します。マイグレーション Pod は、JBoss EAP 永続ボリューム内の独立した各 split-n ディレクトリーをスキャンし、終了する Pod と関連するデータストアを特定し、終了する Pod のすべてのトランザクションが完了するまで実行を継続します。

重要

永続ボリュームは JBoss EAP アプリケーション Pod と移行 Pod の両方によって読み書きモードでアクセスする必要があるため、ReadWriteMany アクセスモードで作成する必要があります。このアクセスモードは、GlusterFS および NFS プラグインを使用する永続ボリュームでのみサポートされています。詳細は、永続ボリュームのサポート対象アクセスモード表 を参照してください。

詳細は、クラスターを スケールダウンするときの JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行するワークフローの例： クラスターをスケールダウンするときの自動化トランザクションリカバリー機能を参照してください。