第15章 DCL CLI を使った CPU の再割り当て

15.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 ユーティリティを使用して，所有者インスタンスでコマンドを実行する必要があります。

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

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

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

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

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

別の方法として，SYSMAN ユーティリティと基礎になる SMI サーバ を使用して， 所有者インスタンスでコマンド環境を設定することもできます。 この方法を使用すると，特定のリソース管理操作を実行するためにかなり単純なコマンド・プロシージャを作成できます。 しかし，この方法には制限があります。 まず，関係する 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 のコピーにコマンド・パラメータを渡します。 最終的に，所有者インスタンスがローカルにコマンドを実行します。

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

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

$CPU_TRANSITION[W] は，CPU の管理に使用できる OpenVMS システム・サービスです。 $CPU_TRANSITION[W] は，現在のシステムの構成セットの中の CPU， または OpenVMS Galaxy 構成の中の未割り当ての CPU の現在の処理状態を変更します。

15.5 再割り当ての失敗

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

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