| 前へ | 次へ | 目次 | 索引 |
OpenVMS Alpha バージョン 7.3 では，OpenVMS Galaxy 環境を構築して，次の機能を実現できます。
IT 作業負荷が予測不可能な場合や大きく変動する場合，あるいは急激な増加を示している場合には，作業負荷の管理能力を強化する必要があります。このような場合，OpenVMS Galaxy テクノロジを導入することで，非常に柔軟な方法でシステム・リソースの動的な再構成と管理が可能になります。OpenVMS Galaxy はハードウェアとソフトウェアを統合したソリューションであり，システム管理者は簡単なドラッグ・アンド・ドロップ操作で，各 CPU の再割り当てなどの作業を実行できます。
OpenVMS Galaxy コンピューティング環境は，次のような高可用性アプリケーションにとって理想的です。
OpenVMS Galaxy コンピューティング環境は，クラスタや複数の独立したシステムをご利用の，現在の OpenVMS ユーザのための自然な発展の道筋です。
OpenVMS Galaxy は，作業負荷が予測可能な場合も予測不可能な場合も，成長の著しい組織にとって魅力的です。
2.6 OpenVMS Galaxy が最良の選択ではない場合
OpenVMS Galaxy テクノロジは非常に柔軟な方法でシステム・リソースの動的な再構成と管理を可能にしますが，Galaxy システムが組織にとって最良の技術的選択ではない場合もあります。組織のコンピューティング・ニーズの焦点が次のようなものに向けられている場合には，OpenVMS Galaxy は最良の選択ではありません。
OpenVMS Galaxy コンピューティング環境では，1 台のコンピュータ・システムのインスタンス間でどの程度の協調動作を行うかを，お客様が判断できます。
shared-nothing コンピューティング・モデルでは，インスタンスはリソースを共用せず，操作は相互に分離されます (第 2.7.1 節を参照 )。
shared-partial コンピューティング・モデルでは，インスタンスは一部のリソースを共用し，制限された方法で協調動作します (第 2.7.2 節を参照 )。
shared-everything モデルでは，インスタンスは完全に協調動作し，使用可能なすべてのリソースを共用します。この結果，オペレーティング・システムはネットワークにとって 1 つの結合されたものとして認識されます (第 2.7.3 節を参照 )。
2.7.1 shared-nothing コンピューティング・モデル
shared-nothing 構成 ( 図 2-3 を参照 ) では，OpenVMS のインスタンスは相互に完全に独立しており，独立したコンピュータであるかのように，外部インターコネクトを通じて接続されます。
Galaxy では，使用可能なすべてのメモリが OpenVMS の各インスタンスのプライベート・メモリに割り当てられます。各インスタンスにはそれぞれ独自の CPU セットと適切な量の I/O リソースが割り当てられます。
図 2-3 shared-nothing コンピューティング・モデル
shared-partial 構成 ( 図 2-4 を参照) では，システム・メモリの一部が共用メモリとして指定され，各インスタンスがアクセスできます。各インスタンスのコードとデータはプライベート・メモリに格納されます。複数のインスタンスのアプリケーション間で共用されるデータは，共用メモリに格納されます。
図 2-4 shared-partial コンピューティング・モデル
shared-everything 構成 ( 図 2-5 を参照 ) では，インスタンスはメモリを共用し，相互にクラスタ接続されます。
図 2-5 shared-everything コンピューティング・モデル
シングル・インスタンス Galaxy は，Galaxy 以外のプラットフォーム，つまり，Galaxy コンソールのないプラットフォーム用のインスタンスです。通常コンソール・ファームウェアから提供されるGalaxy 構成データは，ファイルに作成されます。システム・パラメータ GALAXY を 1 に設定することで，SYSBOOT はファイルをメモリに読み込み，システムはシングル・インスタンス Galaxy としてブートされます。共用メモリ，Galaxy システム・サービス，さらに CPU のセルフ・マイグレーションも備えています。この構成はどの Alpha プラットフォームでも可能です。
シングル・インスタンス Galaxy 構成は，ラップトップからメイン・フレームまでどのプラットフォームでも動作します。この機能を利用すれば，早期に OpenVMS Galaxy 機能を評価することができ，さらにもっとも重要なこととして，完全なスケールの Galaxy プラットフォームを準備しなくても，Galaxy 対応アプリケーションを開発し，テストすることができるという利点があります。
シングル・インスタンス Galaxy はエミュレータではなく，実際の Galaxy コードであるため，アプリケーションはマルチインスタンス構成で動作します。
シングル・インスタンス Galaxy の実行の詳細については，第 10 章 を参照してください。
2.9 OpenVMS Galaxy の構成上の考慮点
OpenVMS Galaxy コンピューティング環境を構築する場合は，構成にとって適切なハードウェアを用意する必要があります。OpenVMS Galaxy の構成では，一般に次の規則が適用されます。
各ハードウェア固有の構成の要件の詳細については，使用しているハードウェアに関する本書の章を参照してください。
2.9.1 XMI バスのサポート
XMI バスは AlphaServer 8400 システムで Galaxy 構成の最初のインスタンス ( インスタンス 0) でのみサポートされます。
AlphaServer 8400 システムでは，すべての XMI 装置に対して DWLM-AA XMI プラグ・イン・ユニット・サブシステム・ケージは 1 つだけサポートされます。すべての XMI 装置をシステムに接続するために，システムの背面に I/O バルクヘッドが必要なため，DWLM-AA はシステムである程度の空間を使用します。このため，システム内に DWLPB PCI プラグ・イン・ユニットは 2 つだけしか追加できません。
2.9.2 メモリ分割に関する制限事項
メモリを誤った方法で構成すると，メモリが無駄に使用されます。
2.9.3 EISA バスのサポート
EISA バスは Galaxy 構成の最初のインスタンス ( インスタンス 0 ) でのみサポートされます。すべての EISA オプションの設計により，これらはシステムのインスタンス 0 に必ず存在しなければなりません。Galaxy システムのどの EISA 装置の場合も，KFE70 は最初のインスタンスで使用しなければなりません。
すべての EISA 装置はインスタンス 0 に存在しなければなりません。Galaxy システムの他のインスタンスでは，EISA 装置はサポートされません。
他のインスタンスにインストールされた KFE72-DA は，コンソール接続だけを提供し，他の EISA 装置に対して使用することはできません。
2.10 推奨される CD ドライブ
OpenVMS Galaxy コンピューティング環境の各インスタンスに対して，CD ドライブを使用できるように設定してください。OpenVMS Galaxy で複数のシステム・ディスクを使用する予定がある場合は，アップグレードやソフトウェアのインストール時に，各インスタンスに 1 台ずつ CD ドライブがあると便利です。
OpenVMS Galaxy インスタンスが相互にクラスタ接続されており，1 つの共通のシステム・ディスクを使用する場合は，1 台の CD ドライブだけで十分です。これは，他のクラスタ接続されたインスタンスに CD ドライブを提供できるからです。オペレーティング・システムをアップグレードする場合は，CD ドライブが接続されているインスタンスを使用してアップグレードできます。
2.11 重要なクラスタ情報
ここでは，OpenVMS Galaxy コンピューティング環境内の他のインスタンスや，Galaxy 以外の OpenVMS クラスタと，インスタンスをクラスタ接続するときに重要な情報をまとめます。
クラスタ・インスタンスに適用される，必要な OpenVMS Galaxy ライセンスの詳細については，『OpenVMS License Management Utility Manual』を参照してください。
2.11.1 OpenVMS Galaxy インスタンスになる
OpenVMS Alpha バージョン 7.3 をインストールするときに，OpenVMS インストール・ダイアログで OpenVMS Cluster および OpenVMS Galaxy インスタンスに関する質問が表示されます。
次の質問に対して "Yes" と応答し，
Will this system be a member of an OpenVMS cluster? (Yes/No)
|
次の質問に対して "Yes" と応答すると，
Will this sytem be an instance in an OpenVMS Galaxy? (Yes/No)
|
次の情報が表示されます。
For compatibility with an OpenVMS Galaxy, any systems in the OpenVMS cluster
which are running versions of OpenVMS prior to V7.1-2 must have a
remedial kit installed. The appropriate kit from the following list
must be installed on all system disks used by these systems.
(Later versions of these remedial kits may be used if available.)
Alpha V7.1 and V7.1-1xx ALPSYSB02_071
Alpha V6.2 and V6.2-1xx ALPSYSB02_062
VAX V7.1 VAXSYSB01_071
VAX V6.2 VAXSYSB01_062
|
詳細については，『OpenVMS Alpha Installation and Upgrade Manual』を参照してください。
2.11.2 SCSI Cluster に関する留意事項
ここでは，OpenVMS Galaxy コンピューティング環境での SCSI 装置名に関する情報をまとめます。OpenVMS Cluster 装置名の詳細については，『OpenVMS Cluster System manual』を参照してください。
共用 SCSI バスを装備した OpenVMS Galaxy を構築する場合，次のことに注意する必要があります。
OpenVMS では，各インスタンスで SCSI 装置に同じ名前を正しく付けるには，OpenVMS の装置命名機能を使用する必要があります。
たとえば，SHOW CONFIG コマンドを入力したときに，システムに次のアダプタがあるとしましょう。
PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller KZPxxx) PKC0 (UltraSCSI controller) |
このシステムを 2 インスタンス Galaxy に設定すると，ハードウェアは次のようになります。
Instance 0 PKA0 (UltraSCSI controller) Instance 1 PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller) |
共用 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 用に設定された装置名は，コントローラのコンソール名が変更されたために正しく機能しません。
2.12 OpenVMS Galaxy コンピューティング環境でのセキュリティに関する留意事項
shared-everything クラスタ環境では，すべてのセキュリティ・データベース・ファイルがすべてのインスタンス間で共用されます。このようなクラスタ環境で動作する OpenVMS Galaxy インスタンスは，Galaxy 関連のすべてのセキュリティ・プロファイルに関して，自動的に一貫性のあるビューを提供します。
すべての Galaxy インスタンスですべてのセキュリティ・データベース・ファイルを共用しないことを選択した場合は，一貫性のあるセキュリティ・プロファイルを実現するには，手動の操作が必要になります。オブジェクトのセキュリティ・プロファイルを変更すると，このオブジェクトにアクセスできるすべてのインスタンスで同様の変更を行わなければなりません。
手動で次々に変更が必要になるため，このような構成は US C2 評価や他の機関による同様の評価の対象になっていません。オペレーティング・システムに対するセキュリティ評価が必要な組織では，1 つの OpenVMS Galaxy 内のすべてのインスタンスが同じクラスタに所属するように設定する必要があります。
2.13 OpenVMS Galaxy インスタンスのタイム・ゾーンでの構成
OpenVMS Galaxy インスタンスは，同一のクラスタ内に存在するとき以外は，同一のタイム・ゾーン内に置く必要はありません。たとえば，3 インスタンスの Galaxy 構成における各インスタンスは，異なるタイム・ゾーンに置くことができます。
2.14 OpenVMS Galaxy プログラムの開発
この後の項では，OpenVMS Galaxy で開発するのに役立つ OpenVMS プログラミング・インタフェースについて説明します。概念の多くは，従来のシングル・インスタンス OpenVMS システムを拡張したものです。
各章で説明するサービスの C 関数プロトタイプを表示するには，次のコマンドを入力してください。
$ LIBRARY/EXTRACT=STARLET SYS$LIBRARY:SYS$STARLET_C.TLB/OUTPUT=FILENAME |
その後，表示するサービスの出力ファイルを検索します。
2.14.1 ロック・プログラミング・インタフェース
Galaxy プラットフォームの主な機能の 1 つに，オペレーティング・システムの複数のインスタンス間でリソースを共用できる機能があります。リソースを共用する場合，そのリソースへのアクセスの同期をとる必要があります。この章で説明するサービスは，Galaxy 内の共用リソースへのアクセスの同期をとるために，協調動作スキームを作成する基礎となるものを提供します。
galaxy ロック は，スピンロックとミューテックスの組み合わせです。所有されている galaxy ロックを取得しようとする間，スレッドは短期間スピンします。スピン中にロックが使用可能にならないと，スレッドは待ち状態になります。これは SMP スピンロックと異なります。SMP スピンロックでは，スピンが時間切れになると，システムがクラッシュしますが，このような動作は Galaxy では認められません。
galaxy ロックの性質上，これらのロックは共用メモリのどこかに存在します。その共用メモリはユーザまたは galaxy ロック・サービスによって割り当てることができます。ユーザがメモリを割り当てる場合は，ロック・サービスはロックの場所だけを追跡します。ロック・サービスがメモリを割り当てる場合は，ユーザの代わりにメモリを管理します。
execlets の MON バージョンの一部でしかない他のモニタリング・コードと異なり，galaxy ロックのモニタリング・コードは常にロードされます。
galaxy ロックを取り扱うために複数のルーチンが提供されています。これらのルーチンは，ロックに関係する基礎的な機能だけを提供します。SMP をサポートするために使用されるスピン・ロックより少し豊富な機能を備えていますが，ロック・マネージャが提供する機能より，はるかに劣ります。表 2-1 はロック・プログラミングのための OpenVMS Galaxy システム・サービスについてまとめています。
| システム・サービス | 説明 |
|---|---|
| $ACQUIRE_GALAXY_LOCK | OpenVMS Galaxy のロックの所有権を取得します。 |
| $CREATE_GALAXY_LOCK | OpenVMS Galaxy ロック・ブロックを $CREATE_GALAXY_LOCK_TABLE サービスで作成されたロック・テーブルから割り当てます。 |
| $CREATE_GALAXY_LOCK_TABLE | OpenVMS Galaxy ロック・テーブルを割り当てます。 |
| $DELETE_GALAXY_LOCK | OpenVMS Galaxy ロックを無効にし，削除します。 |
| $DELETE_GALAXY_LOCK_TABLE | OpenVMS Galaxy ロック・テーブルを削除します。 |
| $GET_GALAXY_LOCK_INFO | 指定されたロックから "interesting" フィールドを返します。 |
| $GET_GALAXY_LOCK_SIZE | OpenVMS Galaxy ロックの最小サイズと最大サイズを返します。 |
| $RELEASE_GALAXY_LOCK | OpenVMS Galaxy ロックの所有権を解除します。 |
| 前へ | 次へ | 目次 | 索引 |