中断のない継続的な運用を実現するためには、通常、PAC 環境が必要になります。Patch Update (パッチ アップデート)、メンテナンス、またはその他のシステム アップグレードを実行する場合、PAC の管理に関する課題が生じることがあります。
本ドキュメントでは、PAC 環境に対して Patch Update を実行する際に採用すべきベスト プラクティスについて説明します。
パフォーマンス/可用性クラスター (PAC) 環境については、その使用目的が CICS サービスをサポートすることか JES サービスをサポートすることかを問わず、PAC へのアップグレードを行う前に理解しておく必要のある特性がいくつかあります。
PAC 環境とは、スケールアウト アーキテクチャで構成され、単一の論理エンティティとして連携する複数のマシンに分散されることがある、2 つ以上のエンタープライズ サーバー リージョンと言うことができます。
各エンタープライズ サーバー リージョンは、ロックおよび情報の同期を管理する共有リソースから情報にアクセスします。
共有 PAC リソースは次のとおりです。
アップデートまたはパッチ プロセスの実行時、これらの共有コンポーネントの 1 つ以上が変更されると、またはこれらのコンポーネントに格納されているレコード構造が変更されると、リスクが生じます。
システムに適用したアップデートまたはパッチにより、システムの動作が変更される可能性があります。アップグレードまたはパッチに伴う変更を特定し、その変更の適用について、リスクを軽減して PAC の可用性を維持できる最良の方法を見極めることが重要です。Patch Update の ReadMe を確認してから、そのインストールを計画することを強くお勧めします。
アップグレードには次の 3 つのタイプがあり、どの方法が適切であるかは、変更対象となるコンポーネントの互換性によって決まります。
どの方法を採用すべきか確信が持てない場合は、「互換性のないアップグレード プロセス」の手順に従うことをお勧めします。
クライアントが TN3270 リスナーに接続し、接続を長時間維持しながら長時間にわたってトランザクションを送信しようとしている場合について考えてみます。クライアントは、エンタープライズ サーバー リージョンがアップグレードのために停止すると切断されます。クライアントは再接続する必要があり、多くの場合は、PAC 内の別のエンタープライズ サーバー リージョンに接続することになります。その新たな接続先のエンタープライズ サーバー リージョンが次に停止してアップグレードした場合、同じクライアントが複数回切断されることになります。このような状況は、接続しているクライアントにとって望ましくありません。
マシンを 1 台ずつではなく、グループでアップグレードすると、影響を最小限に抑えることができます。一時的に一部のエンタープライズ サーバー リージョンだけでクライアント トラフィックを処理できる場合は、その他のインスタンスをグループでシャットダウンし、アップグレードして、再起動することをお勧めします。すべてのリージョンがアップグレードされるまで、この方法を繰り返すことができます。
実行中のエンタープライズ サーバー リージョンをアップグレードのために停止する前に、まず新しいクライアント接続の受け入れを中止し、可能であれば、既存のクライアント接続を完了できるようにすることをお勧めします。また、Micro Focus Batch Scheduler Integration (MFBSI)、cassub、MQ によってトリガーされたトランザクションなど、スケジュールされた作業は、アップグレード プロセスの完了後に行われるように、一時停止または再スケジュールする必要があります。
PAC アップグレードの準備では、PAC の前に配置されたロード バランサーでエンタープライズ サーバー リスナーを無効にした場合の影響を確認することをお勧めします。既存の長時間にわたるクライアント接続 (TN3270 リスナーへの接続など) は、エンタープライズ サーバー リージョンが停止すると必然的に終了され、通信ログにエラーが報告されます。アクティブなクライアント接続のリストは、Enterprise Server Common Web Administration (ESCWA) を使用して表示できます。それには、ナビゲーション タブで、目的の エンタープライズ サーバー リージョン をクリックし、[ ] をクリックして、リージョンの CLIENT LIST テーブルを表示します。
Enterprise Developer 6.0 より前のバージョンの場合、PAC を実行している各エンタープライズ サーバー インスタンスをバックアップすることをお勧めします。
Enterprise Developer 6.0 以降では、エンタープライズ サーバー インスタンスのバックアップは必須ではありません。これは、Patch Update インストーラーによって MFDS 構成が自動的に保持されるためです。
MFDS 構成をバックアップする方法の詳細については、「リポジトリをエクスポートするには」を参照してください。すべてのサーバー定義およびすべての関連するセキュリティ構成情報をエクスポートするオプションを選択してください。構成バックアップを復元する方法の詳細については、「リポジトリをインポートするには」を参照してください。
ESCWA を使用して PAC を構成および管理することをお勧めします。通常は、PAC を管理し、PAC および SOR 構成を保存するために、単一のホストで実行される ESCWA のインスタンスを選択します。その後、PAC 内のすべてのエンタープライズ サーバー インスタンスをこの単一の ESCWA インスタンスから管理します。これを行うためには、各エンタープライズ サーバー リージョンが実行されているリモート Directory Server を ESCWA 構成に追加する必要があります。詳細については、「Enterprise Server Common Web Administration」を参照してください。
ESCWA インスタンスは、PAC に含まれないマシン上で実行することをお勧めします。この構成により、PAC の Patch Update プロセスが簡素化され、ESCWA を実行している製品のバージョンと 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 の構成が自動的に保持されるため、この処理は必要ありません。