11 CPUの再割り当て

OpenVMSでは，CPUリソースの管理方法が複数サポートされます。コンソールはコンソール環境変数を使用して， 各CPUのデフォルトの所有者インスタンスを設定します。 このため，CPUリソースは静的に割り当てることができ， 正確な初期構成が可能です。コールド・ブート(つまりパワー・サイクルまたは初期化) では，コンソールの不揮発性RAMからこのデフォルト構成が復元されます。

構成がブートされた後，CMKRNL (Change Mode to Kernel)特権を持つユーザに対して，OpenVMS ではもっと洗練された手段でリソースを割り当てることができます。 ここではこれらの方法について説明します。

11.1 DCLによる再割り当て

CMKRNL特権を持つユーザは，次のDCLコマンドを使用してCPUの再割り当て操作を実行できます。

     $ STOP/CPU/MIGRATE=instance-or-id   cpu-id

ユーザはターゲット・インスタンス名(SCSNAME)または数値ID (0，1など) と，再割り当てするCPUの数値IDを指定しなければなりません。次の例では， このコマンドの形式をいくつか示しています。

     $ STOP/CPU/MIGRATE=0  4      !Reassign CPU 4 to instance 0
     $ STOP/CPU/MIGRATE=1  3,4,5  !Reassign CPUs 3,4,5 to instance 1
     $ STOP/CPU 7/MIGRATE=BIGBNG  !ReassignCPU 7 to instance BIGBNG
     $ STOP/CPU/ALL/MIGRATE=0     !Reassign all secondary CPUs to instance 0

これらのコマンドはコマンド・プロシージャに挿入できます。たとえば， 必要とされる処理能力がわかっているアプリケーションのスタートアップ・ プロシージャで，余分なCPUリソースをインスタンスに移動することができます。 同様に，時間のかかるI/O集約型操作(たとえばバックアップなど) をこれから実行するインスタンスから，CPUの割り当てを解除して， CPUを他のインスタンスが使用できるように設定することもできます。ジョブが完了したら， 割り当てを元に戻すことができます。また，シャットダウンされるインスタンスからCPU を再割り当てすることもできます。

この方法では，あるインスタンスからリソースを再割り当てすることだけが可能です。 これは，Galaxyソフトウェア・アーキテクチャで定義されているプッシュ・ モデルです。このモデルでは，現在の使い方を認識しない他のインスタンスによって， リソースが"盗まれる"ことを防止します。 DCLを使用してGalaxyシステム全体を効果的に管理するには，関係する各インスタンスにログインするか，SYSMAN ユーティリティを使用して，所有者インスタンスでコマンドを実行する必要があります。

11.2 GCUのドラッグ・アンド・ドロップによる再割り当て

GCUでは，Galaxyリソースを管理するために会話型のビジュアル・インタフェースが提供されます。GCU を使用すると，インスタンス間で単にドラッグ・ アンド・ドロップするだけで，CPUを再割り当てすることができます。 さらに，GCUを使用すると，さまざまな構成のチャート(構成モデルと呼びます) を作成し，それをファイルに保存できます。構成モデルはいつでもロードして， 設定することができ，システムは要求されたモデルに設定するために， 必要に応じてリソースを再割り当てします。

11.3 インターモダル再割り当て

Galaxyソフトウェア・アーキテクチャではリソース・プッシュ・モデルが定義されているため， リソースは，現在それを所有しているGalaxyインスタンスから割り当てなければなりません。 ユーティリティやユーザがマルチインスタンスGalaxy 構成でリソースの割り当てを効果的に管理するには， 各インスタンスでコマンドを実行するための何らかの手段を設定しなければなりません。

このような手段の1つとして，各Galaxyインスタンスでウィンドウまたはターミナル・ セッションを開き，これらの各ウィンドウでリソース管理操作を実行する方法があります。

別の方法として，SYSMANユーティリティと基礎になるSMI-Serverを使用して， 所有者インスタンスでコマンド環境を設定することもできます。この方法を使用すると， 特定のリソース管理操作を実行するためにかなり単純なコマンド・ プロシージャを作成できます。しかし，この方法には制限があります。 まず，関係するGalaxyインスタンスはクラスタ内に存在しなければなりません。 また，コマンド・プロシージャは可変パラメータをSYSMAN 環境スクリプトに効果的に渡すことができず，SYSMANスクリプトの内部にリモート・ システム・パスワードを指定することもできません。したがって，SYSMAN を使用する汎用のコマンド・プロシージャ・インスタンスを作成するのは面倒です。

GCUは実際に，管理アクションを実行するために，可能であれば必ずSYSMAN を使用します。システムがSYSMANをサポートするように構成されていない場合は，GCU は管理トランスポートとしてプロキシ・アカウント間でDECnet タスク間通信を使用しようとします。その方法も失敗した場合は( つまり，システムでDECnetが実行されていなかったり，必要なプロキシ・ アカウントが設定されていない場合など)，GCUは，GCUが現在実行されているインスタンス以外のGalaxy インスタンスを管理することができません。 選択した場合は，各Galaxyインスタンスに対して1つずつ，GCUの複数のコピーを実行できます。 しかしほとんどの場合，OpenVMS Galaxyシステムはクラスタ接続されているか，DECnet を使用していると考えてもかまいません。

GCUの管理アクションは，SYS$MANAGER:GCU$ACTIONS.COMコマンド・プロシージャをもとにして実行されます。 このファイルを変更して，それぞれの環境に適するようにアクションをカスタマイズすることができます。 たとえば，TCP/IP 環境では，管理トランスポートのためにREXECや同様のユーティリティを選択することができ， 管理アクションが実行されるときに， 何らかの形式の通知やログを含むこともできます。

GCU$ACTIONS.COMファイルは，動作方法が通常のファイルと少し異なります。SYSMAN を使用する場合，このプロシージャはテンポラリ・ファイルに小さなSYSMAN コマンド・スクリプトを作成して，SYSMANが取り扱うことができない可変パラメータを取り扱います。SYSMAN を使用できない場合は， このプロシージャは所有者インスタンスのプロキシ・アカウントに対して，DECnet タスク間接続を開始しようとします。接続が成功すると，この接続を使用して， 所有者インスタンスにあるGCU$ACTIONS.COMのコピーにコマンド・ パラメータを渡します。最終的に，所有者インスタンスがローカルにコマンドを実行します。

11.4 Galaxyサービスを使用したソフトウェアによる再割り当て

おそらくリソース割り当てを管理するための最適な方法は，Galaxy API を使用して独自のリソース管理ルーチンを作成する方法でしょう。独自のルーチンを作成すれば， 独自の基準およびアプリケーション環境をもとに， リソース管理に関する判断を下すことができます。しかし，第11.3節で説明したものと同じプッシュ・ モデルの制限事項があるため， ルーチンはGalaxy対応でなければならず，おそらく相互の操作を調整するために共用メモリを使用する必要があります。

CPU再割り当てAPIの詳細については，第17 章を参照してください。

11.5 再割り当ての失敗

CPUの再割り当てはさまざまな理由で失敗したり，ブロックされることがあります。GCU は管理アクションをSYSMANまたはDCLスクリプトに埋め込むので， 再割り当てが失敗した理由を常に識別して報告できるわけではありません。 たとえばGCUは，プライマリCPUの再割り当てを禁止するために， 再割り当てアクションを許可する前に，特定のチェックを実行します。また， オペレーティング・システムやコンソール・ファームウェアだけが検出できるその他の理由によって， 再割り当てが失敗することもあります。 たとえば，現在，プロセス・アフィニティやFast Pathデューティが割り当てられているCPU の再割り当ての失敗をオペレーティング・システムが検出した場合，DCL メッセージがコンソールとユーザ端末の両方に表示されます。

再割り当てのためのGalaxy APIは，ほとんどの失敗を呼び出し側に報告することができます。 しかし，再割り当てサービスを使用した場合でも，ハードウェア・ プラットフォームの依存関係をオペレーティング・システムから確認できないために， コンソールが再割り当てを拒否することがあります。