![]() |
![]() |
日本−日本語 | ![]() |
|
|
![]() |
![]() |
HP OpenVMS Alpha: パーティショニングおよび Galaxy ガイド![]() 第2章 OpenVMS Galaxy の概念 |
|
![]() |
目次
OpenVMS Alpha で HP Galaxy ソフトウェア・アーキテクチャを使用すると, 1 台のコンピュータで OpenVMS の複数のインスタンスを実行できます。 システム・リソースは動的に再割り当てすることができ,コンピュータをリブートしなくても,必要に応じてコンピュータ・パワーをアプリケーションに割り当てることができます。 この章では,OpenVMS Galaxy の概念について, OpenVMS Alpha バージョン 7.3 で提供される機能を中心に説明します。 ソフトウェアは CPU,メモリ,I/O ポートを OpenVMS オペレーティング・システムの個々のインスタンスに割り当てることで,これらのリソースを論理的に パーティション分割 します。 このパーティション化はシステム管理者が行うものであり,ソフトウェアの機能です。 ハードウェアを物理的に分割する必要はありません。各インスタンスには, 動作に必要なリソースが割り当てられます。OpenVMS Galaxy 環境は, CPU などのリソースを OpenVMS の異なるインスタンスに動的に再割り当てすることができるという点で,適応型 です。 OpenVMS Galaxy ソフトウェア・アーキテクチャには, 次のハードウェアおよびソフトウェア・コンポーネントが含まれています。 コンソール OpenVMS システムの コンソール は,接続されている端末と, ファームウェア・プログラムで構成されます。 ファームウェア・プログラムは電源投入時の自己診断テスト, ハードウェアの初期化,システム・ブートの開始, システム・ブートとシャットダウン時の I/O サービスを実行します。 また,コンソール・プログラムはコンソール端末の入出力,環境変数の検索, NVRAM (不揮発性ランダム・アクセス・メモリ) の保存をはじめ, その他のさまざまなサービスのために, オペレーティング・システムに実行時サービスも提供します。 OpenVMS Galaxy コンピューティング環境では, コンソールはハードウェア・リソースのパーティション分割で重要な役割を演じます。 NVRAM に永久的なシステム構成を保存し,稼働中の構成をメモリに記憶します。 コンソールは,OpenVMS オペレーティング・システムの各インスタンスに対して, 実行中の構成データを指すポインタを与えます。 共用メモリ メモリは論理的に,プライベート・セクションと共用セクションに分割されます。 オペレーティング・システムの各インスタンスには, それぞれ独自のプライベート・メモリがあります。つまり, 他のインスタンスはプライベート・メモリの物理ページをマッピングしません。 共用メモリの一部は, OpenVMS のインスタンスが他のインスタンスと通信するために使用され, 残りの共用メモリはアプリケーション用に使用されます。 Galaxy ソフトウェア・アーキテクチャは, ノンユニフォーム・メモリ・アクセス (NUMA) 環境用に準備されており, このようなシステムが最大限のアプリケーション性能を実現できるように, 必要に応じて特殊なサービスを提供します。 CPU OpenVMS Galaxy コンピューティング環境では, インスタンス間で CPU を再割り当てすることができます。 I/O OpenVMS Galaxy には,スケーラビリティの高い I/O サブシステムがあります。 これは,各インスタンスに対して 1 つずつ, 複数のプライマリ CPU がシステム内にあるからです。 また,OpenVMS は現在, SMP システムのセカンダリ CPU に一部の I/O を分散するための機能も備えています。 独立インスタンス OpenVMS Galaxy では,リソースをまったく共用せずに, 1 つ以上の OpenVMS インスタンスを実行できます。 リソースを共用しない OpenVMS インスタンスを 独立インスタンス と呼びます。 OpenVMS の独立インスタンスは共用メモリの使用に参加しません。 基本オペレーティング・システムもアプリケーションも, 共用メモリにアクセスしません。 OpenVMS Galaxy は独立インスタンスだけで構成することができます。 このようなシステムは従来のメインフレーム・スタイルのパーティション化によく似ています。アーキテクチャの面から考えると, OpenVMS Galaxy は 対称型マルチプロセッサ (SMP) ハードウェア・アーキテクチャを基礎にしています。 CPU,メモリ,I/O はマシン内で完全に接続されているものと想定されており, メモリはキャッシュと密接に結合されているものと想定されています。 各サブシステムは他のすべてのサブシステムに完全にアクセスできます。 図 2-1 「OpenVMS Galaxy アーキテクチャの概念図」 に示すように, Galaxy ソフトウェアはリソースをパイであると考えます。 さまざまなリソース (CPU,プライベート・メモリ,共用メモリ,I/O) は, 特定の階層構造でパイの内部に同心円として並べられます。 その場合,共用メモリが中心になります。 Galaxy では, それぞれ異なるサイズの複数のスライスにパイを分割する機能がサポートされます。 各スライスは,サイズとは無関係に,すべての共用メモリにアクセスできます。 さらに,パイを分割するのはソフトウェアであるため, スライスの数やサイズは動的に変化させることができます。 つまり,パイの各スライスはオペレーティング・システムの完全なインスタンスです。 各インスタンスには専用のプライベート・メモリ,多くの CPU, 必要な I/O が割り当てられます。各インスタンスは, アプリケーション・データが格納されているすべての共用メモリを確認できます。 システム・リソースは,リブートせずにオペレーティング・システムのインスタンス間で再割り当てすることができます。 たとえば,図 2-2 「別の Galaxy アーキテクチャ・ダイアグラム」 は,Galaxy の比率がインスタンスによってどのように違うかを示しています。 OpenVMS 機能の進歩にともない,OpenVMS Galaxy では,実績のある OpenVMS Cluster,対称型マルチプロセシング,性能を向上するためのさまざまな機能を活用して,これまでより高いレベルの性能,スケーラビリティ,可用性を提供しており,非常に柔軟な操作機能も提供します。 クラスタ OpenVMS Cluster テクノロジには 15 年にわたる実績があり, OpenVMS Galaxy 内でクラスタ接続されたインスタンス間で通信を容易にします。 OpenVMS Cluster はソフトウェアの概念です。これは, 各コンピュータで 1 つずつ動作している OpenVMS オペレーティング・システムを結合したものであり,さまざまな媒体を介して通信することで, 複数のコンピュータの処理パワーと記憶容量を 1 つの共用環境として構築します。 OpenVMS Galaxy もソフトウェア概念です。 しかし,これは 1 台のコンピュータ で協調動作する OpenVMS オペレーティング・システムの集合であり, 共用メモリを通じて通信します。OpenVMS Galaxy では, オペレーティング・システムのインスタンスを Galaxy 内の他のインスタンスや他のシステムのインスタンスとクラスタ接続することができます。 OpenVMS Galaxy はそれ自体で完全なシステムです。 現在,クラスタにノードを追加できるのと同様に, OpenVMS Galaxy も既存の OpenVMS クラスタに追加することができますが, OpenVMS Galaxy アーキテクチャではシングル・システムという点に焦点を絞っています。 OpenVMS Galaxy 内で完全に稼働するアプリケーションは, マルチシステム・クラスタでは実現できない高い性能を活用することができます。 SMP OpenVMS Galaxy のインスタンスは SMP 構成にすることができます。 CPU の数はインスタンスの定義の一部です。OpenVMS Galaxy のインスタンスは, 完全な OpenVMS オペレーティング・システムであるため, すべてのアプリケーションが従来のシングル・インスタンス・コンピュータの場合と同様に動作します。 CPU の再割り当て CPU はあるインスタンスから別のインスタンスに動的に再割り当てすることができ, その間も 2 つのインスタンス上ですべてのアプリケーションの実行を継続できます。 再割り当ては 3 つの独立した機能によって実現されます。 それは,再割り当てする CPU の停止,再割り当て,起動です。 アプリケーションで必要なリソースが変化すると, CPU を適切なインスタンスに再割り当てすることができます。 しかし,いくつかの制限があります。 たとえば,インスタンスのプライマリ CPU を再割り当てすることができず, 特定の割り込みを処理するために,特定の CPU を指定することはできません。 動的な再構成 OpenVMS オペレーティング・システムの複数のインスタンスを実行することで, システム管理者は,処理パワーを最も必要としているアプリケーションを稼働しているインスタンスにその処理パワーを再割り当てすることができます。 要件の変化にともなって,構成も変更することができます。OpenVMS では, すべてのインスタンスおよびそのアプリケーションの実行を続行しながら, 動的な再構成が可能です。 OpenVMS Galaxy テクノロジの多くの利点は,OpenVMS オペレーティング・システムの複数のインスタンスを 1 台のコンピュータで実行することで実現されています。 OpenVMS の複数のインスタンスを同時にメモリに格納することで,OpenVMS Galaxy コンピューティング環境は次の機能を向上させます。
ここでは,これらの利点についてさらに詳しく説明します。 互換性 既存のシングル・システム・アプリケーションは, まったく変更せずに,OpenVMS Galaxy のインスタンスで実行できます。 既存のOpenVMS Cluster アプリケーションも, OpenVMS Galaxy のクラスタ接続されたインスタンスで,変更せずに実行できます。 可用性 OpenVMS Galaxy システムは, 従来のシングル・システム SMP システムより高い可用性を提供できます。 これは,オペレーティング・システムの複数のインスタンスがハードウェア・リソースを制御するからです。 OpenVMS Galaxy では, OpenVMS の複数のバージョン (バージョン 7.2 以上) を同時に実行できます。 たとえば,現在のバージョンを 1 つのインスタンスで実行しながら, オペレーティング・システムやアプリケーションの新しいバージョンを別のインスタンスでテストすることができます。 その後,一度に 1 つずつ, 各インスタンスでシステム全体をアップグレードすることができます。 スケーラビリティ システム管理者は,ビジネス・ニーズの拡大や変化にともなって, アプリケーションの要件に対応するようにリソースを割り当てることができます。 CPU が Galaxy 構成に追加された場合は, OpenVMS のどのインスタンスにでも割り当てることができます。 つまり,アプリケーションは CPU のパワーを 100 パーセント利用できるのです。 SMP でスケーラビリティに関して一般的に発生する問題点のために, OpenVMS Galaxy が制限を受けることはありません。 システム管理者は OpenVMS インスタンスの数を定義し, 各インスタンスで CPU の数を割り当て,その使用方法を制御することができます。 さらに,試行錯誤を繰り返しながらリソースを評価することができます。 システム管理者は最も効果的なリソースの組み合わせが見つかるまで, OpenVMS のインスタンス間で CPU を再割り当てすることができます。 OpenVMS のすべてのインスタンスとそのアプリケーションは, CPU を再割り当てしている間も実行を継続できます。 適応性 OpenVMS Galaxy では,すべてのアプリケーションの実行を継続しながら, コンピューティング・リソースをオペレーティング・システムの他のインスタンスに動的に再割り当てすることができるので, 非常に高い適応性を実現できます。 CPU の再割り当て機能は,OpenVMS Galaxy コンピューティング環境の適応機能をもっとも顕著に表すものです。 たとえば,特定の時刻に必要とされるリソースが変化することがシステム管理者にわかっている場合は,システム管理者は CPU を OpenVMS の他のインスタンスに再割り当てするコマンド・プロシージャを作成し, そのプロシージャをバッチ・キューに登録することができます。 同様の方法で,システム負荷も管理することができます。 OpenVMS Galaxy 環境では,ハードウェア・リソースの割り当てや動的な再割り当ては, ソフトウェアによって完全に制御されます。 ハードウェアが OpenVMS Galaxy システムに追加されると,リソースを既存のインスタンスに追加することも,新しいインスタンスを定義することもできます。 その場合,実行中のアプリケーションに影響ありません。 所有コスト OpenVMS Galaxy では,コンピュータがクラスタ・メンバの場合も, 独立システムの場合も,オペレーティング・システムの複数のインスタンスが 1 台のコンピュータで動作するので, 既存のコンピュータをアップグレードし,処理能力を拡大することができ, また,一部のコンピュータを交換することもできます。 必要なコンピュータの台数が削減されるため, 必要なシステム管理作業や設置空間も大幅に削減されます。 性能 OpenVMS Galaxy では,SMP やクラスタ・テクノロジで発生する多くのスケール・ボトルネックが排除されることで, 事務処理アプリケーションの性能を向上できます。 また,インスタンス間で割り込みを分散することができるため, 多くの I/O 構成が可能になります。 たとえば,特定の I/O トラフィックが特定のインスタンスで実行されるように, システムの I/O 作業負荷を分割することができます。 OpenVMS Alpha バージョン 7.3 では,OpenVMS Galaxy 環境を構築して, 次の機能を実現できます。
IT 作業負荷が予測不可能な場合や大きく変動する場合, あるいは急激な増加を示している場合には, 作業負荷の管理能力を強化する必要があります。 このような場合,OpenVMS Galaxy テクノロジを導入することで, 非常に柔軟な方法でシステム・リソースの動的な再構成と管理が可能になります。 OpenVMS Galaxy はハードウェアとソフトウェアを統合したソリューションであり, システム管理者は簡単なドラッグ・アンド・ドロップ操作で, 各 CPU の再割り当てなどの作業を実行できます。 OpenVMS Galaxy コンピューティング環境は, 次のような高可用性アプリケーションにとって理想的です。
OpenVMS Galaxy コンピューティング環境は, クラスタや複数の独立したシステムをご利用の, 現在の OpenVMS ユーザのための自然な発展の道筋です。 OpenVMS Galaxy は,作業負荷が予測可能な場合も予測不可能な場合も, 成長の著しい組織にとって魅力的です。 OpenVMS Galaxy テクノロジは非常に柔軟な方法でシステム・リソースの動的な再構成と管理を可能にしますが, Galaxy システムが組織にとって最良の技術的選択ではない場合もあります。 組織のコンピューティング・ニーズの焦点が次のようなものに向けられている場合には,OpenVMS Galaxy は最良の選択ではありません。
OpenVMS Galaxy コンピューティング環境では, 1 台のコンピュータ・システムのインスタンス間でどの程度の協調動作を行うかを, お客様が判断できます。 shared-nothing コンピューティング・モデルでは, インスタンスはリソースを共用せず,操作は相互に分離されます (2.7.1 項 「shared-nothing コンピューティング・モデル」を参照)。 shared-partial コンピューティング・モデルでは, インスタンスは一部のリソースを共用し,制限された方法で協調動作します (2.7.2 項 「shared-partial コンピューティング・モデル」を参照)。 shared-everything モデルでは, インスタンスは完全に協調動作し,使用可能なすべてのリソースを共用します。 この結果,オペレーティング・システムはネットワークにとって 1 つの結合されたものとして認識されます (2.7.3 項 「shared-everything コンピューティング・モデル」を参照)。 shared-nothing 構成 (図 2-3 「shared-nothing コンピューティング・モデル」 を参照) では, OpenVMS のインスタンスは相互に完全に独立しており, 独立したコンピュータであるかのように, 外部インターコネクトを通じて接続されます。 Galaxy では,使用可能なすべてのメモリが OpenVMS の各インスタンスのプライベート・メモリに割り当てられます。 各インスタンスにはそれぞれ独自の CPU セットと適切な量の I/O リソースが割り当てられます。 shared-partial 構成 (図 2-4 「shared-partial コンピューティング・モデル」 を参照) では,システム・メモリの一部が共用メモリとして指定され,各インスタンスがアクセスできます。 各インスタンスのコードとデータはプライベート・メモリに格納されます。 複数のインスタンスのアプリケーション間で共用されるデータは, 共用メモリに格納されます。 インスタンスはクラスタ接続されません。 shared-everything 構成 (図 2-5 「shared-everything コンピューティング・モデル」 を参照) では, インスタンスはメモリを共用し,相互にクラスタ接続されます。 シングル・インスタンス Galaxy は,Galaxy コンソールのないシステムです。 通常コンソール・ファームウェアから提供されるGalaxy 構成データは, ファイルに作成されます。システム・パラメータ GALAXY を 1 に設定することで, SYSBOOT はファイルをメモリに読み込み, システムはシングル・インスタンス Galaxy としてブートされます。 共用メモリ,Galaxy システム・サービス, さらに CPU のセルフ・マイグレーションも備えています。 この構成は,ES45 以外のどの Alpha プラットフォームでも可能です。 シングル・インスタンス Galaxy 構成は, ラップトップからメイン・フレームまでどのプラットフォームでも動作します。 この機能を利用すれば,早期に OpenVMS Galaxy 機能を評価することができ, さらにもっとも重要なこととして, 完全なスケールの Galaxy プラットフォームを準備しなくても, Galaxy 対応アプリケーションを開発し, テストすることができるという利点があります。 シングル・インスタンス Galaxy はエミュレータではなく,実際の Galaxy コードであるため,アプリケーションはマルチインスタンス構成で動作します。 シングル・インスタンス Galaxy の実行の詳細については, 第11章 「Alpha システムでのシングル・インスタンス Galaxy の使用」 を参照してください。 OpenVMS Galaxy コンピューティング環境を構築する場合は, 構成にとって適切なハードウェアを用意する必要があります。 OpenVMS Galaxy の構成では,一般に次の規則が適用されます。
各ハードウェア固有の構成の要件の詳細については, 使用しているハードウェアに関する本書の章を参照してください。 XMI バスは AlphaServer 8400 システムで Galaxy 構成の最初のインスタンス (インスタンス 0) でのみサポートされます。 AlphaServer 8400 システムでは,すべての XMI 装置に対して DWLM-AA XMI プラグイン・ユニット・サブシステム・ケージは 1 つだけサポートされます。 すべての XMI 装置をシステムに接続するために, システムの背面に I/O バルクヘッドが必要なため,DWLM-AA はシステムである程度の空間を使用します。 このため, システム内に DWLPB PCI プラグイン・ユニットは 2 つだけしか追加できません。
メモリを誤った方法で構成すると,一般にメモリが無駄になります。 EISA バスは Galaxy 構成の最初のインスタンス (インスタンス 0) でのみサポートされます。すべての EISA オプションの設計により,これらはシステムのインスタンス 0 に必ず存在しなければなりません。 Galaxy システムのどの EISA 装置の場合も,KFE70 は最初のインスタンスで使用しなければなりません。 すべての EISA 装置はインスタンス 0 に存在しなければなりません。 Galaxy システムの他のインスタンスでは,EISA 装置はサポートされません。 他のインスタンスにインストールされた KFE72-DA は,コンソール接続だけを提供し, 他の EISA 装置に対して使用することはできません。 OpenVMS Galaxy コンピューティング環境の各インスタンスに対して, CD ドライブを使用できるように設定してください。 OpenVMS Galaxy で複数のシステム・ディスクを使用する予定がある場合は, アップグレードやソフトウェアのインストール時に, 各インスタンスに 1 台ずつ CD ドライブがあると便利です。 OpenVMS Galaxy インスタンスが相互にクラスタ接続されており,1 つの共通のシステム・ディスクを使用する場合は,1 台の CD ドライブだけで十分です。 これは,他のクラスタ接続されたインスタンスに CD ドライブを提供できるからです。 オペレーティング・システムをアップグレードする場合は, CD ドライブが接続されているインスタンスを使用してアップグレードできます。 ここでは,OpenVMS Galaxy コンピューティング環境内の他のインスタンスや,Galaxy 以外の OpenVMS クラスタと,インスタンスをクラスタ接続するための情報をまとめます。 クラスタ・インスタンスに適用される,必要な OpenVMS Galaxy ライセンスの詳細については,『OpenVMS License Management Utility Manual』を参照してください。 OpenVMS Alpha バージョン 7.3 をインストールするときに, OpenVMS インストール・ダイアログで OpenVMS Cluster および OpenVMS Galaxy インスタンスに関する質問が表示されます。 次の質問に対して “Yes” と応答し,
次の質問に対して “Yes” と応答すると,
次の情報が表示されます。
詳細については,『OpenVMS インストレーション・ガイド[翻訳版]』を参照してください。 ここでは,OpenVMS Galaxy コンピューティング環境での SCSI 装置名に関する情報をまとめます。 OpenVMS Cluster 装置名の詳細については,『OpenVMS Cluster システム』を参照してください。 共用 SCSI バスを装備した OpenVMS Galaxy を構築する場合,次のことに注意する必要があります。 OpenVMS では,各インスタンスで SCSI 装置に同じ名前を正しく付けるには,OpenVMS の装置命名機能を使用する必要があります。 たとえば,SHOW CONFIG コマンドを入力したときに,システムに次のアダプタがあるとしましょう。
このシステムを 2 インスタンス Galaxy に設定すると, ハードウェアは次のようになります。
共用 SCSI は,インスタンス 0 の PKA0 からインスタンス 1 の PKB0 に接続されます。 LP_COUNT 環境変数を 0 に設定してシステムを初期化すると, SYSGEN パラメータ STARTUP_P1 が MINIMUM に設定されていない限り, システムで OpenVMS をブートすることができません。 これは,LP_COUNT 変数が 0 に設定されている場合,PKB が PKC に接続されるため, 複数のパーティションで初期化するために設定した SCSI 装置名が, LP_COUNT 変数を 0 に設定して初期化するときに正しくなくなるからです。 ブート時に発生する装置構成で,OpenVMS は PKA0 と PKB0 が接続されていることに気付きます。 OpenVMS は各装置に同じ割り当てクラスおよび名前が与えられているものと解釈しますが,この場合は同じではありません。 2 インスタンス Galaxy 用に設定された装置名は, コントローラのコンソール名が変更されたために正しく機能しません。 shared-everything クラスタ環境では, すべてのセキュリティ・データベース・ファイルがすべてのインスタンス間で共用されます。 このようなクラスタ環境で動作する OpenVMS Galaxy インスタンスは, Galaxy 関連のすべてのセキュリティ・プロファイルに関して, 自動的に一貫性のあるビューを提供します。 すべての Galaxy インスタンスですべてのセキュリティ・データベース・ファイルを共用しないことを選択した場合は,一貫性のあるセキュリティ・プロファイルを実現するには,手動の操作が必要になります。 オブジェクトのセキュリティ・プロファイルを変更すると,このオブジェクトにアクセスできるすべてのインスタンスで同様の変更を行わなければなりません。 手動で次々に変更が必要になるため,このような構成は US C2 評価や他の機関による同様の評価の対象になっていません。 オペレーティング・システムに対するセキュリティ評価が必要な組織では,1 つの OpenVMS Galaxy 内のすべてのインスタンスが同じクラスタに所属するように設定する必要があります。 OpenVMS Galaxy インスタンスは,同一のクラスタ内に存在するとき以外は, 同一のタイム・ゾーン内に置く必要はありません。たとえば, 3 インスタンスの Galaxy 構成における各インスタンスは, 異なるタイム・ゾーンに置くことができます。 この後の項では,OpenVMS Galaxy で開発するのに役立つ OpenVMS プログラミング・インタフェースについて説明します。 概念の多くは,従来のシングル・インスタンス OpenVMS システムを拡張したものです。 各章で説明するサービスの C 関数プロトタイプを表示するには, 次のコマンドを入力してください。
その後,表示するサービスの出力ファイルを検索します。 Galaxy プラットフォームの主な機能の 1 つに,オペレーティング・システムの 複数のインスタンス間でリソースを共用できる機能があります。 この章で説明するサービスは,Galaxy 内の共用リソースへのアクセスの同期をとるために,協調動作スキームを作成する基礎となるものを提供します。 galaxy ロック は,スピンロックとミューテクスの組み合わせです。 所有されている galaxy ロックを取得しようとする間,スレッドは短期間スピンします。 スピン中にロックが使用可能にならないと,スレッドは待ち状態になります。 これは SMP スピンロックと異なります。 SMP スピンロックでは,スピンが時間切れになると,システムがクラッシュしますが, このような動作は Galaxy では認められません。 galaxy ロックの性質上,これらのロックは共用メモリに存在します。 その共用メモリはユーザまたは galaxy ロック・サービスによって割り当てることができます。 ユーザがメモリを割り当てる場合は,ロック・サービスはロックの場所だけを追跡します。 ロック・サービスがメモリを割り当てる場合は, ユーザの代わりにメモリを管理します。 execlets の MON バージョンの一部でしかない他のモニタリング・コードと異なり, galaxy ロックのモニタリング・コードは常にロードされます。 galaxy ロックを取り扱うために複数のルーチンが提供されています。 これらのルーチンは,ロックに関係する基礎的な機能だけを提供します。 SMP をサポートするために使用されるスピン・ロックより少し豊富な機能を備えていますが,ロック・マネージャが提供する機能より,はるかに劣ります。 表 2-1 「ロック・プログラミングのための Galaxy システム・サービス」 はロック・プログラミングのための OpenVMS Galaxy システム・サービスについてまとめています。 表 2-1 「ロック・プログラミングのための Galaxy システム・サービス」 と表 2-2 「イベント・プログラミングのための Galaxy システム・サービス」 のサービスに対する構文は『OpenVMS System Services Reference Manual』で説明しています。 表 2-1 ロック・プログラミングのための Galaxy システム・サービス
特定のシステム・イベントが発生したときに,アプリケーションにそのことを通知するように登録することができます。 たとえば,インスタンスが galaxy に参加したり,CPU が構成セットに参加したときに,そのことを通知できます (構成セットとは,現在のインスタンスに所有され制御されるプロセッサの集まりです)。 イベントが登録されると,アプリケーションは登録されたイベントの発生時にどのように応答するかを判断できます。 表 2-2 「イベント・プログラミングのための Galaxy システム・サービス」 はイベント・プログラミングのための OpenVMS システム・サービスについてまとめています。 表 2-2 イベント・プログラミングのための Galaxy システム・サービス
この節では, OpenVMS Galaxy 環境に特定した System Dump Analyzer (SDA) について説明します。 SDA の使い方の詳細については,『OpenVMS Alpha System Analysis Tools Manual』を参照してください。 Galaxy インスタンスでシステム・クラッシュが発生した場合, OpenVMS はデフォルトの動作として,障害が発生したインスタンスのプライベート・メモリの内容と,共用メモリの内容をダンプします。 完全なダンプの場合, 共用メモリとプライベート・メモリのすべてのページがダンプされます。 選択型ダンプの場合は, システム・クラッシュが発生した時点で使用されていたページだけがダンプされます。 共用メモリのダンプは,動的 SYSGEN パラメータ DUMPSTYLE のビット 4 をセットすることで無効に設定できます。 このビットは,弊社のサポート要員から助言があった場合にだけセットするようにしてください。 このビットをセットすると, システム・クラッシュの原因を判断するのに必要なデータがシステム・ダンプに含まれなくなる可能性があります。 表 2-3 「DUMPSTYLE のビットの定義」 は,DUMPSTYLE のすべてのビットの定義と, OpenVMS Alpha での各ビットの意味を示しています。 ビットはどの組み合わせでも指定できます。 表 2-3 DUMPSTYLE のビットの定義
DUMPSTYLE のデフォルト設定は 0 です (つまり,共用メモリも含めて,完全なダンプを圧縮せずにシステム・ディスクに書き込みます)。 DUMPSTYLE の値が MODPARAMS.DAT に指定されていない場合は,AUTOGEN.COM はシステムのメモリが 128 MB 未満の場合は 1 に (共用メモリも含めて,選択型ダンプを圧縮せずにシステム・ディスクに書き込みます),128 MB 以上の場合は 9 に (共用メモリも含めて,選択型ダンプを圧縮してシステム・ディスクに書き込みます) 設定します。 表 2-4 「SDA コマンドの拡張」 は,共用メモリおよび OpenVMS Galaxy データ構造を表示するために使う System Dump Analyzer の拡張についてまとめています。 詳細については適切なコマンドを参照してください。
表 2-4 SDA コマンドの拡張
|
![]() |
|||||||||||||||
|