DLPAR セーフ・プログラムと DLPAR 認識プログラム

DLPAR セーフ・プログラムは、 DLPAR 操作の結果によって障害が発生することはありません。

リソースが除去され、 新しいリソースの追加によってスケール変更が行われない可能性がある場合、 そのパフォーマンスは悪影響を受けますが、 プログラムは予期したとおりに機能します。 実際、 DLPAR セーフ・プログラムでは、オペレーティング・システムが尊重しなければならない依存関係が存在するため、 DLPAR 操作が正常に行われないことがあります。

DLPAR 認識 プログラムには、 時間の経過とともにシステムの実際のシステムのキャパシティーが変化するにつれて、 システム・リソースの使用を調整するために設計されている、 DLPAR コードが備えられています。 これは、以下の方法で行われます。
  • システムのポーリングを定期的に行い、システム・トポロジーへの変更を発見しようとする
  • システム・トポグラフィーへの変更が行われているときに通知される、 アプリケーション固有のコードを登録する

DLPAR 認識 プログラムは、 少なくとも、 DLPAR 操作を失敗させる可能性のある状態になるのを避けるように、 設計しなければなりません。 最も良いのは、 DLPAR 認識プログラムでパフォーマンスおよびスケーラビリティーも考慮に入れることです。 メモリーの追加または除去の際に必要なレベルのパフォーマンスを維持するために、 バッファーをドレーンしてサイズ変更する必要があるので、 このような設計は非常に複雑な作業になります。 さらに、 スレッドの数を動的に調整して、 オンライン・プロセッサー数の変更に対応しなければなりません。 これらのスレッド・ベースの調整は 必ずしもプロセッサー・ベースの決定に制限されません。 例えば、Java プログラムでメモリー使用量を減らす最善の方法は、スレッドの数を減らすことです。なぜなら、このようにすることにより Java™ 仮想マシンのガーベッジ・コレクターが処理しなければならないアクティブ・オブジェクトの数が減るからです。

ほとんどのアプリケーションは、デフォルトでは DLPAR セーフです。

プログラムを DLPAR セーフにする

DLPAR では、 バイナリーの互換性に関する障害を示す、 以下のエラーが生じる場合があります。
注: これらのエラーは、プロセッサーの追加の結果です。
  • ユニプロセッサー・システム用に最適化されたコードがプログラム内にある場合に、 区画内のプロセッサーの数が 1 から 2 に増加すると、 ランタイム検査を行うプログラムは、検査のいずれかの間にプロセッサーが追加された場合に、 想定外のパスを使用する可能性があります。 ユニプロセッサーのシリアライズ技法を用いて独自のロック・プリミティブをインプリメントしている (つまり、sync および isync 命令が組み込まれていない) プログラムでも、 潜在的な問題が生じる可能性があります。 それらの命令は、自己変更コードや生成されたコードでも使用しなければならないため、 DLPAR 使用可能システムで必要です。 ユニプロセッサー・ベースの論理がないかどうかを調べてください。 ユニプロセッサーであることを示すプログラムには、 オンライン・プロセッサーの数を識別する論理を組み込まなければなりません。
    プログラムは、以下の方法でオンライン・プロセッサーの数を判別できます。
    • _system_configuration.ncpus フィールドのロード
    • var.v_ncpus
    • _SC_NPROCESSORS_ONLN フラグを設定して、 sysconf システム・コールを使用する。
  • プロセッサー番号によってデータを番号付けするプログラムは、 それらのデータ構造に索引付けするために、 通常は mycpu システム・コールを使用して、 現在実行中のプロセッサーの ID を判別します。 新しいプロセッサーが追加されるとき、 データへのパスが正しく初期化または割り振られないことがあるため、 問題が生じる可能性があります。 オンライン CPU の数を使用してプロセッサー・ベースのリストを事前割り当てするプログラムは、DLPAR でこの値が変更されるので、中断されます。
    この問題を避けるために、 同時にオンラインにできるプロセッサーの最大数を使用して、 プロセッサー・ベースのデータを事前割り当てしてください。 これは、その時点で N 個のプロセッサーがアクティブになっているということではなく、 最大数として N 個のプロセッサーをサポートするようにオペレーティング・システムが構成されているということです。 プロセッサーの最大数が一定であるのに対し、 オンラインのプロセッサー数は、 プロセッサーがオンラインになれば増加し、オフラインになれば減少します。 区画の作成時には、 プロセッサーの最少数、必要数、および最大数が指定されます。 最大値は以下の変数で反映されます。
    • _system_configuration.max_ncpus
    • _system_configuration.original_ncpus
    • var.v_ncpus_cfg
    • sysconf (_SC_NPROCESSORS_CONF)

    _system_configuration.original_ncpus および var.v_ncpus_cfg 変数は既存の変数です。 DLPAR が使用可能になっているシステムでは、 これらの変数は可能な最大値を表しています。 DLPAR が使用可能になっていないシステムでは、 ブート時に構成されたプロセッサーの数によって、 値が検出されます。 プロセッサーが 動的プロセッサー割り当て解除 によってオフラインにされていた場合でも、これらの変数は、どちらもサポートできる概念上の最大値を表します。AIX® 4.3 以降で同じバイナリーの使用が容易になるため、 AIX 4.3 で作成されたアプリケーションでは、 これらの既存のフィールドを使用するようにお勧めします。 アプリケーションでプロセッサー・ベースのデータのランタイム初期化が必要な場合、 プロセッサーが追加される前に呼び出された DLPAR ハンドラーを登録することができます。

プログラムを DLPAR 認識にする

DLPAR 認識 プログラムは、 システム構成の変更を認識し、動的に適応するように設計されています。 このコードは DLPAR の認識モデルをサブスクライブする必要がなく、 システム構成の変化を発見するために、 システムのポーリングを定期的に行うシステム・リソース・モニターの形で、 より汎用的に構造化することができます。 この方法はいくつかの限られたパフォーマンス関連の目標を達成するために使用できますが、 DLPAR と緊密に統合されている訳ではないため、 システム構成への大規模な変更を管理するには効果的ではありません。 例えば、 ホット・プラグ可能ユニットが複数のプロセッサーおよびメモリー・ボードから成り立っている場合があるため、 ポーリング・モデルは、 プロセッサーのホット・プラグをサポートしているシステムには適していない場合があります。 また、 DLPAR プロセッサーの除去イベントが開始される前に解決しなければならない、 アプリケーション固有の依存関係 (プロセッサーのバインディングなど) を管理するのにも使用できません。

DLPAR テクノロジーを活用できるアプリケーションのタイプを以下に示します。
  • 以下のような、システム構成に応じてスケール変更するように設計されているアプリケーション。
    • アプリケーションの起動時に、 オンライン・プロセッサーの数または物理メモリーのサイズを検出するアプリケーション。
    • プロセッサーおよびメモリーについて想定されている構成に基づいてスケール変更する (これは通常、 スレッドの最大数、最大バッファー・サイズ、 または固定メモリーの最大量の使用法に適用される) ように外部から指示されているアプリケーション。
  • オンライン・プロセッサーの数とシステム・メモリーの合計量を認識するアプリケーション。以下のタイプのアプリケーションがあります。
    • パフォーマンス・モニター
    • デバッグ・ツール
    • システム破損ツール
    • ワークロード・マネージャー
    • ライセンス・マネージャー
      注: ライセンス・マネージャー (特にユーザー・ベースのライセンス・マネージャー) の中には、DLPAR で使用できないものがあります。
  • plock システム・コールを使用して、 アプリケーション・データ、テキスト、またはスタックを固定するアプリケーション。
  • PinvOption (SHM_PIN) によって System V 共有メモリー・セグメントを使用するアプリケーション。
  • bindprocessor システム・コールを使用して、 プロセッサーへバインドするアプリケーション。

ラージ・メモリー・ページの動的論理区画化はサポートされていません。 ラージ・ページ・プールに事前割り振りされるメモリーの量は、 メモリーに関係する区画の DLPAR 機能に重大な影響を与えます。 ラージ・ページの入ったメモリー領域は除去できません。 そのため、 アプリケーション開発者はラージ・ページを使用しないオプションを用意することもできます。

DLPAR API を使用してプログラムを DLPAR 認識にする

プログラムを DLPAR 認識にするために、 アプリケーション・インターフェースが提供されています。 動的論理区画化のさまざまなフェーズで、 SIGRECONFIG シグナルがアプリケーションに送信されます。 DLPAR サブシステムは、 典型的な操作での check、pre、および post フェーズを定義しています。 アプリケーションはこのシグナルを待ち、DLPAR でサポートされているシステム・コールを使用することにより、 進行中の捜査に関するより詳細な情報を入手し、 何らかの必要なアクションを行うことができます。

注: シグナルを使用する場合、 アプリケーションによって不用意にシグナルがブロックされたり、 システムでのロードによって、 タイムリーなスレッドの実行が妨げられることもあります。 シグナルの場合、 システムは短い期間待機して (ユーザー指定タイムアウトの機能)、 次のフェーズに進みます。 不適切な非特権のスレッドによってすべての DLPAR 操作の実行が妨げられることがあるため、 永久に待機するのは賢明な方法ではありません。

適時のシグナルの送達に関する事柄は、 シグナル・マスクとスケジューリング優先順位を制御することにより、 アプリケーションによって管理することができます。 DLPAR 認識コードは、 アルゴリズムに直接組み込むことができます。 また、 シグナル・ハンドラーを複数の共有ライブラリーにまたがってカスケードすることにより、 よりモジュラー化された方法で通知を組み込むこともできます。

API を使用して DLPAR イベントを統合するには、 以下のことを行います。
  1. sigaction システム・コールを使用して、 SIGRECONFIG シグナルを受け取ります。 デフォルトのアクションでは、 シグナルが無視されます。
  2. シグナルをリアルタイムで送達できるように、 少なくとも 1 つのスレッドでシグナル・マスクを制御します。
  3. シグナルを受け取るスレッドのスケジューリング優先順位が効率的かどうか確認し、 シグナルが送信された後で即座に実行されるようにします。
  4. dr_reconfig システム・コールを実行し、 リソースのタイプ、アクションのタイプ、イベントのフェーズ、 および現在の要求に関連する他の情報を取得します。
    注: dr_reconfig システム・コールをシグナル・ハンドラーの中で使用することにより、 DLPAR 要求の性質を判別することができます。