PAC 環境に対する Patch Update の実行

はじめに

中断のない継続的な運用を実現するためには、通常、PAC 環境が必要になります。Patch Update (パッチアップデート)、メンテナンス、またはその他のシステムアップグレードを実行する場合、PAC の管理に関する課題が生じることがあります。

本ドキュメントでは、PAC 環境に対して Patch Update を実行する際に採用すべきベストプラクティスについて説明します。

PAC 環境の特徴

パフォーマンス/可用性クラスター (PAC) 環境については、その使用目的が CICS サービスをサポートすることか JES サービスをサポートすることかを問わず、PAC へのアップグレードを行う前に理解しておく必要のある特性がいくつかあります。

PAC 環境とは、スケールアウトアーキテクチャで構成され、単一の論理エンティティとして連携する複数のマシンに分散されることがある、2 つ以上のエンタープライズサーバーリージョンと言うことができます。

各エンタープライズサーバーリージョンは、ロックおよび情報の同期を管理する共有リソースから情報にアクセスします。

共有 PAC リソースは次のとおりです。

Micro Focus データベースファイルハンドラー (MFDBFH) によってアクセスされる PAC リージョンデータベース。このデータベースは、ロックを保持し、PAC 内のエンタープライズサーバーリージョンによって使用される情報を共有します。
Micro Focus データベースファイルハンドラー (MFDBFH) によってアクセスされるリージョン間データベース。リージョン間データベースは、PAC 内のエンタープライズサーバーリージョン全体のリソースアクセスを制御するために使用できるリソースロックを保持します。
NoSQL データベース (通常は Redis) に格納された PAC スケールアウトリポジトリ (PSOR)。
オプションで、TSQ および TDQ を格納するための 1 つ以上の追加のスケールアウトリポジトリ (SOR)。
重要: パフォーマンス上の理由から、またアップグレードを容易にするために、TSQ および TDQ は PSOR に保存しないでください。
1 つ以上のデータストアデータベース。データストアは、アプリケーションの VSAM データファイルを格納することを目的とし、トランザクションのサポートを提供します。また、データストアは、スプールファイル、loadlib、構成ファイルなど、回復サービスを必要としないファイルを格納するためにも使用されます。

アップデートまたはパッチプロセスの実行時、これらの共有コンポーネントの 1 つ以上が変更されると、またはこれらのコンポーネントに格納されているレコード構造が変更されると、リスクが生じます。

アップグレードのタイプ

システムに適用したアップデートまたはパッチにより、システムの動作が変更される可能性があります。アップグレードまたはパッチに伴う変更を特定し、その変更の適用について、リスクを軽減して PAC の可用性を維持できる最良の方法を見極めることが重要です。Patch Update の ReadMe を確認してから、そのインストールを計画することを強くお勧めします。

アップグレードには次の 3 つのタイプがあり、どの方法が適切であるかは、変更対象となるコンポーネントの互換性によって決まります。

アップグレードまたはパッチによって共有 PAC リソースが変更されるが、互換性がある場合。この場合、同じ PAC 内で異なるバージョンが共存することが可能であり、「互換アップグレードプロセス」トピックで説明されている手順を使用できます。
アップグレードまたはパッチによって現在の共有 PAC リソースの 1 つ以上が影響を受けるか変更されるが、互換性がない場合。たとえば、PAC リージョンデータベースに対する変更、PSOR レイアウトに対する変更、既存の PAC と互換性のないその他の PAC メカニズムに対する変更などです。この場合、「互換性のないアップグレードプロセス」トピックで説明されている手順を使用できます。
アップグレードで、PAC の基本的なインフラストラクチャを変更する必要がある場合。たとえば、既存の RDBMS または SOR ベンダーを変更してから、新しい PAC を作成する必要がある場合があります。この場合、「PAC の構成」の章で説明されている手順を使用できます。その後、既存の PAC から新しい PAC にデータを移行できます。ただし、データの移行時に、ダウンタイムが必要になる場合があり、一部のデータが失われることもあります。

どの方法を採用すべきか確信が持てない場合は、「互換性のないアップグレードプロセス」の手順に従うことをお勧めします。

一括アップグレードが不可能な場合

PAC の一括アップグレードについて支援が必要な場合は、Micro Focus カスタマーサポートまでお問い合わせください。また、一括アップグレードが不可能な場合は、Patch Update の ReadMe で、最善の対応方法に関する情報が提供されます。新しいメジャー製品バージョンに移行する場合、一括アップグレードを実施できない可能性があります。

実稼働前のテスト

本番環境にディプロイする前に、ステージング環境でアップデートおよびアップデートプロセスをテストすることを強くお勧めします。ステージング環境は、分離した状態を維持しながら、本番環境を可能な限り忠実に反映する必要があります。実稼働前の環境では、アップデートプロセスの複製に加えて、アプリケーションコードを再コンパイルしてテストすることもできます。実稼働前のテストにより、プロダクションシステムに影響を与える前に、潜在的な問題を見つけて解決する機会を得られます。

グループでの PAC マシンのアップグレード

互換性のある PAC アップグレードプロセスでも、互換性のない PAC アップグレードプロセスでも、アップグレードの手順中に PAC の可用性を維持することが目標となります。ただし、各エンタープライズサーバーリージョンでは、アップグレードのために、ある時点で停止が必要になります。接続しているクライアントまたは接続しようとしているクライアントの一部が影響を受けることは避けられません。影響の程度は、クライアントセッションの性質、および各エンタープライズサーバーが停止するタイミングによって異なります。

クライアントが TN3270 リスナーに接続し、接続を長時間維持しながら長時間にわたってトランザクションを送信しようとしている場合について考えてみます。クライアントは、エンタープライズサーバーリージョンがアップグレードのために停止すると切断されます。クライアントは再接続する必要があり、多くの場合は、PAC 内の別のエンタープライズサーバーリージョンに接続することになります。その新たな接続先のエンタープライズサーバーリージョンが次に停止してアップグレードした場合、同じクライアントが複数回切断されることになります。このような状況は、接続しているクライアントにとって望ましくありません。

マシンを 1 台ずつではなく、グループでアップグレードすると、影響を最小限に抑えることができます。一時的に一部のエンタープライズサーバーリージョンだけでクライアントトラフィックを処理できる場合は、その他のインスタンスをグループでシャットダウンし、アップグレードして、再起動することをお勧めします。すべてのリージョンがアップグレードされるまで、この方法を繰り返すことができます。

PAC アップグレード時のクライアント接続の管理

実行中のエンタープライズサーバーリージョンをアップグレードのために停止する前に、まず新しいクライアント接続の受け入れを中止し、可能であれば、既存のクライアント接続を完了できるようにすることをお勧めします。また、Micro Focus Batch Scheduler Integration (MFBSI)、cassub、MQ によってトリガーされたトランザクションなど、スケジュールされた作業は、アップグレードプロセスの完了後に行われるように、一時停止または再スケジュールする必要があります。

エンタープライズサーバーリスナーの状態を「Disabled (無効)」(または「Stopped (停止)」) に変更すると、リスナーは指定されたポート番号でリッスンすることを停止します。ほとんどのロードバランサーは、これを認識し、ライブ接続エンドポイントのプールを自動的に更新して、既存の接続を維持しながら新しいクライアント接続を抑止するように構成できます。ロードバランサーはライブ接続エンドポイントのプールを手動で管理する機能も備えていることが理想的です。これには、ロードバランサーからのトラフィックを再度有効にする前に、テストのためにリスナーを手動で再度有効にすることができるという追加の利点があります。リスナーの状態を「Stopped」ではなく「Disabled」に設定すると、エンタープライズサーバーリージョンの再起動後にリスナーが自動的には起動しなくなります。状態を「Disabled」から「Started (開始)」に変更すると、新しいクライアント接続が再び有効になります。

注: これは、既存のクライアント接続がない場合にのみ機能します。

PAC アップグレードの準備では、PAC の前に配置されたロードバランサーでエンタープライズサーバーリスナーを無効にした場合の影響を確認することをお勧めします。既存の長時間にわたるクライアント接続 (TN3270 リスナーへの接続など) は、エンタープライズサーバーリージョンが停止すると必然的に終了され、通信ログにエラーが報告されます。アクティブなクライアント接続のリストは、Enterprise Server Common Web Administration (ESCWA) を使用して表示できます。それには、ナビゲーションタブで、目的のエンタープライズサーバーリージョンをクリックし、[MONITOR > Client] をクリックして、リージョンの CLIENT LIST テーブルを表示します。

Micro Focus Directory Server (MFDS) 構成のバックアップ

Enterprise Developer 6.0 より前のバージョンの場合、PAC を実行している各エンタープライズサーバーインスタンスをバックアップすることをお勧めします。

Enterprise Developer 6.0 以降では、エンタープライズサーバーインスタンスのバックアップは必須ではありません。これは、Patch Update インストーラーによって MFDS 構成が自動的に保持されるためです。

MFDS 構成をバックアップする方法の詳細については、「リポジトリをエクスポートするには」を参照してください。すべてのサーバー定義およびすべての関連するセキュリティ構成情報をエクスポートするオプションを選択してください。構成バックアップを復元する方法の詳細については、「リポジトリをインポートするには」を参照してください。

Enterprise Server Common Web Administration (ESCWA) 構成のバックアップ

ESCWA を使用して PAC を構成および管理することをお勧めします。通常は、PAC を管理し、PAC および SOR 構成を保存するために、単一のホストで実行される ESCWA のインスタンスを選択します。その後、PAC 内のすべてのエンタープライズサーバーインスタンスをこの単一の ESCWA インスタンスから管理します。これを行うためには、各エンタープライズサーバーリージョンが実行されているリモート Directory Server を ESCWA 構成に追加する必要があります。詳細については、「Enterprise Server Common Web Administration」を参照してください。

ESCWA インスタンスは、PAC に含まれないマシン上で実行することをお勧めします。この構成により、PAC の Patch Update プロセスが簡素化され、ESCWA を実行している製品のバージョンと PAC を構成するエンタープライズサーバーリージョンを実行しているマシンのバージョンが同じである必要がなくなります。

注: 製品のバージョンが Enterprise Developer 6.0 より前の場合、ESCWA 構成はアプリケーション構成ファイル commonwebadmin.json に保存されます。アプリケーション構成ファイルは、C:\ProgramData\Micro Focus\Enterprise Developer\ESCWA (Windows) または $COBDIR/etc (UNIX) にあります。このファイルは手動でバックアップおよび復元する必要があります。

互換性のある PAC アップグレードプロセスおよび互換性のない PAC アップグレードプロセス

互換性のある PAC アップデートプロセスおよび互換性のない PAC アップデートプロセスを示す例として、次の PAC 構成について考えます。MYPAC という名前の PAC に、MYPSOR という名前の PSOR があります。この PAC は、Region 1 および Region 2 という名前の 2 つのエンタープライズサーバーリージョンで構成されています。エンタープライズサーバーリージョンは、Host 1 および Host 2 という名前の別々のマシンで実行されています。

この例では、PAC は、2 台の別々のマシンで実行されている 2 つのエンタープライズサーバーインスタンスで構成されています。PAC が 2 つ以上のエンタープライズサーバーインスタンスで構成されている場合は、マシンを 1 台ずつではなくグループでアップグレードすることを検討するよう強くお勧めします。グループでのアップデートにより、クライアントの接続への影響が最小限に抑えられます。詳細については、「グループでの PAC マシンのアップグレード」を参照してください。

この場合、Enterprise Server Common Web Administration (ESCWA) サービスは個別のマシンで実行されており、この例の一部としてバックアップおよび復元する必要はないと仮定できます。

また、各エンタープライズサーバーマシンの Directory Server 構成はすでにバックアップされていると仮定しています。Enterprise Developer 6.0 以降では、Patch Update のインストーラーで MFDS の構成が自動的に保持されるため、この処理は必要ありません。