| 前へ | 次へ | 目次 | 索引 |
GCU では，チャートと呼ぶ 6 種類のモデルのサブセットが提供されます。
6 種類のチャートは次のとおりです。
| チャート名 | 表示の内容 |
|---|---|
| Logical Structure | 動的リソース割り当て |
| Physical Structure | 変化しないハードウェアの関係 |
| CPU Assignment | CPU 割り当ての単純な表示 |
| Memory Assignment | メモリ・サブシステム・コンポーネント |
| IOP Assignment | I/O モジュールの関係 |
| Failover Targets | プロセッサ・フェールオーバー割り当て |
これらのチャートは，さまざまな種類のコンポーネントの表示を有効または無効に設定して，関係するコンポーネントのサブセットの表示を提供することで作成されます。
各チャートには，そのチャート固有の機能があります。たとえば， CPU の再割り当てでは，インスタンス・コンポーネントが表示されていなければなりません。インスタンスは Physical Structure チャートや Memory Assignment チャートに表示されないので，CPU の再割り当ては Logical Structure チャートおよび CPU Assignment チャートでのみ実行できます。
チャートの詳細については， 第 12.4 節 を参照してください。
12.1.3 会話
アクティブ Galaxy 構成モデルを表示している間，システム・コンポーネントと直接会話することができます。たとえば， CPU をあるインスタンスから別のインスタンスに再割り当てするには， CPU を適切なインスタンスにドラッグ・アンド・ドロップします。GCU はその操作が有効であるかどうか確認し，外部コマンド・アクションを実行して構成を変更します。設定されていないモデルとの会話は，単にオフライン・モデルに対する描画操作であり，稼動中のシステムには影響しません。
Galaxy コンポーネントと会話している間，GCU は誤った構成や不適切な管理アクションが実行されないように，組み込みルールとユーザ定義ルールを適用します。たとえば，プライマリ CPU を再割り当てすることはできず， CPU を Galaxy インスタンス以外のコンポーネントに再割り当てすることもできません。このような操作を実行すると，ステータス・バーにエラー・メッセージが表示され，モデルは適切な構成に戻ります。実行しようとした操作が構成ルールのいずれかに違反する場合は，ステータス・バーに赤で表示されるエラー・メッセージに，違反するルールが示されます。
マウスの右ボタンをクリックし，ポップアップ・メニューから [Parameters] を選択するか，メイン・ツールバーの [Components] メニューから [Parameters] を選択すると，選択したコンポーネントの詳細情報を表示できます。
[Galaxy] メニューの [Shutdown] または [Reboot] を使用すると，GCU は 1 つ以上の Galaxy インスタンスをシャットダウンまたは再ブートすることができます。さまざまなシャットダウン・パラメータや再ブート・パラメータは，[Shutdown] ダイアログ・ボックスに入力できます。クラスタ接続された Galaxy インスタンスを完全にシャットダウンするには，CLUSTER_SHUTDOWN オプションを指定する必要があります。[Shutdown] ダイアログ・ボックスでは，インスタンスの組み合わせまたはすべてのインスタンスを選択できます。GCU は "非常に賢明"なので，所有者のインスタンスを最後にシャットダウンします。
12.2 GCU による OpenVMS Galaxy の管理
Galaxy Configuration ユーティリティ (GCU) を使用して Galaxy システムを管理する機能は，管理操作に関係する各インスタンスの機能に応じて異なります。
GCU は Galaxy のどのインスタンスからも実行できます。しかし， Galaxy ソフトウェア・アーキテクチャでは，リソースの再割り当てのためにプッシュ・モデルを実装しています。つまり，プロセッサを再割り当てするには，プロセッサを現在所有しているインスタンスで再割り当てコマンド機能を実行しなければなりません。GCU はこの必要条件を認識しており，1 つ以上の通信パスを使用して，再割り当て要求を所有者インスタンスに送信しようとします。DCL はこの必要条件を認識していないため，DCL を使用してリソースを再割り当てする場合は，SYSMAN を使用するか，または個別にログインした端末を使用して，所有者インスタンスでコマンドを実行しなければなりません。
GCU では，SYSMAN とその基礎になっている SMI_Server プロセスの使用が歓迎され，Galaxy の他のインスタンスにコマンド・パスが提供されます。しかし，SMI_Server では，コマンド環境が共通のセキュリティ・ドメイン内に存在するように，インスタンスはクラスタ内に存在していなければなりません。しかし，Galaxy インスタンスはクラスタ接続されていない可能性があります。
SMI_Server に適したコマンド・パスをシステムが提供できない場合は，GCU は DECnet タスク間通信を使用しようとします。このためには，参加するインスタンスが DECnet を実行していなければならず，参加する各 Galaxy インスタンスは SYSTEM アカウントに対してプロキシを設定しておく必要があります。
12.2.1 独立インスタンス
1 つ以上のインスタンスが Galaxy 共用コミュニティのメンバにならないように，Galaxy システムを定義することができます。これを 独立インスタンスと呼びます。独立インスタンスは GCU に認識されます。
これらの独立インスタンスも CPU の再割り当てに参加することができます。独立インスタンスは共用メモリや関連サービスを利用できません。
12.2.2 分離されたインスタンス
インスタンスをクラスタ接続せず，プロキシ・アカウントを設定せず， DECnet 機能も割り当てないことが可能です。このようなインスタンスを
分離されたインスタンスと呼びます。このようなインスタンスは GCU に認識され，CPU を再割り当てすることができます。分離されたインスタンスからリソースを再割り当てする場合は，分離されたインスタンスのコンソールから行わなければなりません。
12.2.3 必要な PROXY アクセス
GCU が管理アクションを実行しなければならない場合は，最初に SYSMAN ユーティリティを使用しようとします。SYSMAN では，関係するインスタンスが同じクラスタ内に存在しなければなりません。この条件が満たされない場合は，GCU は DECnet タスク間通信を使用しようとします。この機能を利用するには，関係する各インスタンスにイーサネット装置，DECnet 機能，ターゲット・インスタンスでの適切なプロキシ・アクセスが必要です。
たとえば，クラスタ接続されていない 2 インスタンス構成について考えてみましょう。インスタンス 0 で GCU が実行されており，ユーザが CPU をインスタンス 1 からインスタンス 0 に再割り当てしようとすると，実際の再割り当てコマンドはインスタンス 1 で実行しなければなりません。このために，ファイル SYS$MANAGER:GCU$ACTIONS.COM 内の GCU のアクション・プロシージャは，インスタンス 1 の SYSTEM アカウントに対して DECnet タスク間接続を確立しようとします。このためには，インスタンス 1 に対して，インスタンス 0 の SYSTEM アカウントへのプロキシ・アクセスが許可されている必要があります。確立された接続を使用して，インスタンス 0 のアクション・プロシージャは，パラメータをインスタンス 1 の対応するアクション・プロシージャに渡し，そのアクション・プロシージャは操作をローカル操作として取り扱います。
GCU アクション・プロシージャは，それがシステム管理者によって使用されるものと想定します。したがって，アクション・プロシージャ・ファイル SYS$MANAGER:GCU$ACTIONS.COM で， SYSTEM アカウントが使用されます。相手のインスタンスの SYSTEM アカウントへのアクセスを許可するには，インスタンス 1 でプロキシを設定しなければなりません。
プロキシ・アクセスを設定するには
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE |
UAF> CREATE/PROXY UAF> ADD/PROXY instance::SYSTEM SYSTEM UAF> EXIT |
instanceを，アクセスを許可しているインスタンスの名前に置き換えます。GCU を実行しているインスタンスから管理する各インスタンスに対して，これらの操作を実行します。たとえば，典型的な 2 インスタンス Galaxy で，インスタンス 0 でのみ GCU を実行している場合は，インスタンス 0 に対して，インスタンス 1 でのみプロキシ・アクセスを追加する必要があります。GCU をインスタンス 1 でも実行する予定がある場合は，インスタンス 1 に対してインスタンス 0 でプロキシ・アクセスを追加する必要があります。 3 インスタンス Galaxy システムでは，制御する各インスタンスの各組み合わせに対して，プロキシ・アクセスを追加しなければなりません。この理由から，GCU は常にインスタンス 0 から実行するようにしてください。
SYSTEM アカウントを使用する必要はありません。アカウントを変更するには，関係する各インスタンスで SYS$MANAGER:GCU$ACTIONS.COM を変更する必要があります。タスク間接続を設定する行を探し， SYSTEM アカウント名を適切な名前に変更します。
選択したアカウントには OPER，SYSPRV，CMKRNL 特権が必要です。また，このアカウントに対して自分のインスタンスへの必要なプロキシ・アクセスを追加する必要もあります。
12.3 Galaxy 構成モデル
GCU は完全にプログラミング可能な表示エンジンです。GCU は，ルールセットを使用して，システム・コンポーネントの動作や適切な属性に関する知識を取得します。この特別な構成に関する知識を利用して， GCU はシステム・コンポーネント間の関係を表すモデルを組み立てます。 GCU は，コンソール・ファームウェアが構築した構成モデルを解析することで，現在のシステム構造を解析します。この構造は Galaxy 構成ファイルと呼ばれ，メモリに格納され，必要に応じてファームウェアおよび OpenVMS エグゼクティブ・ルーチンで更新され，現在のシステム構成および状態が正確に反映されます。
GCU は構成ファイルのバイナリ表現を単純な ASCII 表現に変換し，拡張します。この表現はオフライン・モデルとしてファイルに格納できます。GCU は後でオフライン・モデルを再ロードし，モデルに対応するようにシステム構成を変更できます。アクティブ・モデルを表示している場合も，オフライン・モデルを表示している場合も，現在の構成はいつでもオフライン Galaxy 構成モデル (.GCM) ファイルとして保存できます。
オフライン・モデルを現在のシステム構成として使用するには，モデルをロードし，そのモデルに設定しなければなりません。モデルに設定するには， [Engage] ボタンをクリックします。GCU は現在の構成ファイルをスキャンし，それをモデルと比較し，モデルに設定するのに必要な管理アクションの一覧を作成します。GCU はこの一覧を最終確認のために表示します。ユーザが承認すると，GCU はアクションを実行し，現在のシステム構成および状態を反映するように，モデルは設定された状態になります。
モデルの設定を解除すると，GCU はただちに CPU とインスタンスをオフラインとしてマークします。その後，モデルを自由に変更することができ，モデルを保存したり，モデルに再び設定することができます。通常，ビジネスにとって役立つことが証明されたモデルだけを若干数保存します。これらのモデルは，システム管理者または適切な特権が与えられたユーザ，または DCL コマンド・プロシージャを使用して設定することができます。
12.3.1 アクティブ・モデル
GCU は 1 つのアクティブ・モデルを管理します。このモデルは常にメモリ内の構成ファイルから作成されます。構成ファイルは Galaxy コンソールまたは Alpha システムのファイル・ベースのシングル・インスタンス Galaxy から取得できます。どこから取得した場合でも，コンソール・コールバックがファイルの保全性を管理します。 GCU は Galaxy イベント・サービスを使用して，構成がいつ変更されたかを判断します。構成が変更されると，GCU は構成ファイルを解析し，現在のシステムを反映するようにアクティブ・モデルを更新します。アクティブ・モデルは，オフライン・モデルとして保存することを選択しない限り，ファイルに保存されません。通常，アクティブ・モデルは追加モデルを作成するための基礎になります。モデルを作成する場合，必要に応じてオフライン・モデルに設定できるように，オンラインで作成するのが最適です。
12.3.2 オフライン・モデル
GCU はオフライン Galaxy 構成モデルをいくつでもロードすることができ，それが特定のシステム・ハードウェア用に作成されたものである場合，自由に切り換えることができます。モデルの表現は単純な ASCII データ定義フォーマットです。
モデル・ファイルを ASCII 形式で編集する必要はありません。 GCU モデルとルールセットは Galaxy 構成言語 (GCL) と呼ぶ単純な言語に準拠しています。この言語は新しい Galaxy の発展に伴って，必要に応じて進歩していくでしょう。モデルとルールセット・ファイルを直接作成する場合は，このことに注意する必要があります。モデルを誤って壊した場合は，いつでも別のモデルを作成できます。ルールセットを壊した場合は，OpenVMS Galaxy Web サイトから別のルールセットをダウンロードする必要があります。
12.3.2.1 例: オフライン・モデルの作成
オフライン Galaxy 構成モデルを作成するには
必要に応じて，モデルはいくつでも作成でき，保存できます。
オフライン・モデルに設定するには
Galaxy 構成ファイルには，かなり大量の構成データが格納されます。複雑な Galaxy 構成の場合は，ファイルが非常に大きくなる可能性があります。 GCU がシステムに関するすべての情報を表示した後，表示の内容は非常に複雑になります。この問題を回避するために，GCU では Galaxy チャートを使用します。チャートは単にさまざまなコンポーネント，装置，相互接続の表示を制御するためのマスクの集合です。コンポーネント階層構造の中で，各チャートには，そのチャートで指定されたコンポーネントだけが表示されます。別のチャートを選択すると，別のコンポーネント・サブセットが表示されます。
デフォルト設定では，GCU は 5 つのあらかじめ構成されたチャートを使用します。各チャートは，固有のコンポーネント関係を表示するように設計されています。一部の GCU コマンド操作は，特定のチャートの内部でのみ実行できます。たとえば，Physical Structure チャートの内部から CPU を再割り当てすることはできません。 Physical Structure チャートには，Galaxy インスタンス・コンポーネントは表示されないので，CPU のドラッグ・アンド・ドロップの宛先がありません。チャートはユーザが変更できるので，GCU ではそのメニューおよびコマンド操作を特定のチャートに制限していません。場合によっては，適切なチャートを選択するのに役立つように，GCU は情報メッセージを表示します。
12.4.1 コンポーネントの識別と表示プロパティ
各コンポーネントには固有の識別子があります。この識別子は， CPU ID などの場合は単純な連続番号であり，I/O アダプタの場合は物理バックプレーン・スロット番号であり，メモリ装置の場合は物理アドレスです。GCU は各種類のコンポーネントに形状と色も割り当てます。可能な場合は，GCU はさらに動作中のシステムから収集した補足情報を利用して，各コンポーネントを区別します。
各コンポーネントの表示プロパティは， Galaxy 構成ルールセット (SYS$MANAGER:GALAXY.GCR) の内部で割り当てられます。ウィンドウの色や表示テキストのスタイルなどの特定の表示プロパティをカスタマイズする場合を除き，このファイルは編集すべきではありません。
各コンポーネントに関して表示されるテキストもカスタマイズできます。各種類のコンポーネントには，その外観，内容，相互関係を示す文がルールセットで割り当てられます。
1 つの役立つ機能として，どのテキストを画面上で各コンポーネント・タイプに表示するかを選択する機能があります。ルールセット内で装置宣言を使用すると，表示テキスト文を構成するテキストとパラメータを指定できます。現在のズーム係数で完全なテキストを表示できない場合は，この表示テキストのサブセットが表示されます。このサブセットをニーモニックと呼びます。ニーモニックは任意のテキストやパラメータを含むように変更できます。
| 前へ | 次へ | 目次 | 索引 |