3.4. JBoss EAP for OpenShift イメージのデプロイメントに関する考慮事項
3.4.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 ディレクトリーを作成します。
現在、これが eap72-tx-recovery-s2i テンプレートのデフォルト設定です。
単一ノードと複数ノードのパーティショニングではストレージの方法が異なるため、デプロイメントを単一ノードから複数ノードに変更すると、data ディレクトリーにこれまで保存されたすべてのデータ (メッセージやトランザクションログを含む) がアプリケーションから失われます。ストレージパスが一致しないため、デプロイメントを複数ノードから単一ノードに変更した場合でも同様です。
3.4.2. スケールダウンおよびトランザクションリカバリー
JBoss EAP for OpenShift イメージが 複数ノード 設定を使用してデプロイされると、クラスターがスケールダウンした場合に、終了する Pod の data ディレクトリーに予期せず終了されたトランザクションが残される可能性があります。
クラスターが次回スケールアップするまで、終了する Pod のデータストア内にトランザクションが残らないようにするため、eap72-tx-recovery-s2i JBoss EAP テンプレートは、トランザクションの移行を管理するマイグレーション Pod が含まれる 2 つ目のデプロイメントを作成します。マイグレーション Pod は、JBoss EAP 永続ボリューム内の独立した各 split-n ディレクトリーをスキャンし、終了する Pod と関連するデータストアを特定し、終了する Pod のすべてのトランザクションが完了するまで実行を継続します。
永続ボリュームは JBoss EAP アプリケーション Pod と移行 Pod の両方によって読み書きモードでアクセスする必要があるため、ReadWriteMany アクセスモードで作成する必要があります。このアクセスモードは、GlusterFS および NFS プラグインを使用する永続ボリュームでのみサポートされています。詳細は、永続ボリュームのサポート対象アクセスモード表を参照してください。
詳細情報は、クラスターをスケールダウンするときの JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行する「ワークフローの例: クラスターをスケールダウンするときの自動化トランザクションリカバリー機能」を参照してください。
