日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:OpenVMS Cluster システムの管理の概要
第 2 章:OpenVMS Cluster の概念
第 3 章:OpenVMS Cluster インターコネクト構成
第 4 章:OpenVMS Cluster オペレーティング環境
第 5 章:共用環境の準備
第 6 章:クラスタ・ストレージ・デバイス
第 7 章:クラスタ・キューの設定と管理
第 8 章:OpenVMS Cluster システムの構成
第 9 章:大規模な OpenVMS Cluster システムの構築
第 10 章:OpenVMS Cluster システムの保守
付録 A :クラスタ・システム・パラメータ
付録 B :共通ファイルの作成
付録 C :クラスタのトラブルシューティング
付録 D :LAN 制御のためのサンプル・プログラム
付録 E :LAN 制御のためのサブルーチン
付録 F :NISCA プロトコルのトラブルシューティング
付録 G :NISCA トランスポート・プロトコル・チャネル選択および輻輳制御
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本

OpenVMS
OpenVMS Cluster システム


目次 索引

第 5 章
共用環境の準備

どの OpenVMS Cluster 環境でも,リソースはできるだけ共用することが最適です。リソースを共用すると,作業をクラスタ全体で分散できるため,簡単に作業負荷のバランスをとることができます。

5.1 共用可能なリソース

全部ではありませんが,大部分のリソースは OpenVMS Cluster のノード間で共用できます。以下の表は共用できるリソースを示しています。

共用可能なリソース 説明
システム・ディスク 同じアーキクテクチャ 1 のすべてのメンバは,1 つのシステム・ディスクを共用でき,各メンバが独自のシステム・ディスクを保有することもでき,メンバがこの 2 つの方法の組み合わせを利用することもできる。
データ・ディスク すべてのメンバはどのデータ・ディスクも共用できる。ローカル・ディスクの場合,MSCP サーバを使用してディスクをクラスタ全体でアクセス可能として設定しない限り,アクセスはローカル・ノードだけに制限される。
テープ・ドライブ すべてのメンバはテープ・ドライブを共用できる (ただし,すべてのメンバが同時にアクセスできるというわけではない)。ローカル・テープ・ドライブの場合,TMSCP サーバを使用して,テープをクラスタ全体からアクセス可能として設定しない限り,アクセスはローカル・ノードに制限される。DSA テープだけは,すべての OpenVMS Cluster メンバにサービスを提供できる。
バッチ・キューとプリント・キュー ジョブが実際に実行されているプロセッサとは無関係に,ユーザは, OpenVMS Cluster 内のどのキューにもバッチ・ジョブを登録できる。汎用キューは,使用可能なプロセッサ間で負荷のバランスをとることができる。
アプリケーション ほとんどのアプリケーションは,シングル・システムの場合と同様に,OpenVMS Cluster で動作できる。アプリケーション設計者は,OpenVMS Cluster の複数のノードで同時に動作し,ファイル内のデータを共用するアプリケーションを構築することもできる。
利用者登録ファイル すべてのノードは,すべてのシステムで,同じアクセスに対して共通の利用者登録ファイル (UAF) を使用することができ,複数の UAF を使用してノード固有のクォータを有効にすることもできる。共通の UAF を使用する場合,ユーザ・パスワード,ディレクトリ,上限,クォータ,特権はすべてのシステムで同一になる。

1システム・ディスクのデータは,Alpha プロセッサと VAX プロセッサの間で共用できる。しかし,VAX ノードを Alpha システム・ディスクからブートすることはできず, Alpha ノードを VAX システム・ディスクからブートすることもできない。



5.1.1 ローカル・リソース

以下の表は,ローカル・ノードだけからアクセスできるリソースを示しています。

共用できないリソース 説明
メモリ OpenVMS Cluster の各メンバは独自のメモリを管理しなければならない。
ユーザ・プロセス OpenVMS Cluster のメンバでユーザ・プロセスが生成される場合,プロセスはローカル・メモリを使用して,そのコンピュータで完了しなければならない。
プリンタ キューを通じて入力を受け付けないプリンタは,そのプリンタが直接接続されている OpenVMS Cluster メンバからだけ使用される。キューを通じて入力を受け付けるプリンタは,OpenVMS Cluster のどのメンバからもアクセス可能である。



5.1.2 構成例

図 5-1 は,Alpha システム・ディスクと VAX システム・ディスクの両方を保有し,Alpha システムと VAX システムの間で環境ファイルを共用できるように設定されているデュアル・ポート・ディスクを保有する OpenVMS Cluster システムの例を示しています。

図 5-1 リソース共用の構成例




処理のニーズに応じて,すべての環境ファイルがクラスタ単位で共用される環境,または一部のファイルはクラスタ単位で共用され,他のファイルは特定のコンピュータからだけアクセス可能な環境のいずれかを準備できます。

以下の表は,共通環境クラスタと多重環境クラスタの特徴を示しています。

クラスタの種類 特徴 利点
共通環境
オペレーティング環境は OpenVMS Cluster 内のすべてのノードで同一である。 環境は以下のように設定される。

  • すべてのノードが同じプログラム,アプリケーション,ユーティリティを実行する。

  • すべてのユーザが同じ種類のユーザ・アカウントを持ち,同じ論理名が定義される。

  • すべてのユーザがストレージ・デバイスおよびキューに対して共通のアクセス権を持つことができる (アクセス権は,アクセス制御リスト [ACL] 保護が各ユーザに対してどのように設定されているかに応じて異なる)。

  • すべてのユーザが構成内のどのノードにもログインでき,他のすべてのユーザと同じ環境で作業する。

共通バージョンのシステム・ファイルを使用するため,管理が簡単である。
多重環境
オペレーティング環境はノードごとに変更できる。 個々のプロセッサまたは一部のプロセッサが以下のように設定される。

  • ユーザが実行するタスクの種類と使用するリソースに応じて,複数のアクセス権が提供される。

  • 他のノードでは使用できないリソースを共用できる。

  • 他のプロセッサが一般的なタイムシェアリング作業を実行している間,制限されたリソースを使用して専門化された機能を実行する。

  • ユーザはログインしているノード固有の環境で作業することができる。

一部のデータだけをコンピュータ間で共用し,しかも特定のコンピュータが特別なニーズに対応できるように設定したい場合に効果的である。



5.3 共通システム・ディスクのディレクトリ構造

オペレーティング・システムのインストールまたはアップグレード・プロシージャで, 共通システム・ディスク が作成されます。ほとんどのオペレーティング・システム・ファイルとオプションの製品ファイルは,このシステム・ディスクの共通のルート・ディレクトリに格納されます。

システム・ディスクのディレクトリ構造は,Alpha システムと VAX システムで同一です。システム・ディスクが Alpha 用の場合も VAX 用の場合も,ディレクトリ構造全体,つまり, 共通ルートと各コンピュータの ローカル・ルートは同じディスクに格納されます。インストールまたはアップグレードが完了した後, 第 8 章 で説明する CLUSTER_CONFIG.COM コマンド・プロシージャを使用して,クラスタにブートするときに使用されるローカル・ルートを新しい各コンピュータに対して作成します。

通常のシステム・ディレクトリの他に,各ローカル・ルートには [VMS$COMMON] のディレクトリ・エイリアスである [SYSn.SYSCOMMON] ディレクトリが格納されます。これは,クラスタ共通ファイルが実際に格納されるクラスタ共通ルート・ディレクトリです。コンピュータをクラスタに追加すると,CLUSTER_CONFIG.COM は共通ルート・ディレクトリ・エイリアスを定義します。

5.3.2 ディレクトリ構造の例

図 5-2 は,JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には,ローカル・ルート (JUPITR の場合は SYS0,SATURN の場合は SYS1) と,クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。

図 5-2 共通システム・ディスクのディレクトリ構造




論理名 SYS$SYSROOT は,最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し,次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって,システム・ディレクトリの論理名 (SYS$SYSTEM, SYS$LIBRARY,SYS$MANAGER など) は,2 つのディレクトリを指します。

図 5-3 は,論理名 SYS$SYSTEM がファイル指定で使用されているときに,共通システム・ディスクのディレクトリがどのように検索されるかを示しています。

図 5-3 共通システム・ディスクでのファイルの検索順序


重要: 共通システム・ディスクのシステム・ファイルを操作する場合は,この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは,常に該当するコンピュータのシステム・サブディレクトリに格納し,更新しなければなりません。

  1. MODPARAMS.DAT は SYS$SPECIFIC:[SYSEXE] に格納しておかなければなりません。これは, JUPITR では [SYS0.SYSEXE] であり,SATURN では [SYS1.SYSEXE] です。したがって,JUPITR にログインするときに,JUPITR の新しい MODPARAMS.DAT ファイルを作成するには,以下のコマンドを入力します。


    $ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT 
    


    ファイルが作成された後,JUPITR にログオンするときに,以下のコマンドを使用してファイルを変更することができます。


    $ EDIT SYS$SYSTEM:MODPARAMS.DAT 
    


    このコマンドを入力したときに,MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず, SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合,このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は,このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。

  2. 同じ共通システム・ディスクからブートされる他のコンピュータにログインするときに,JUPITR の MODPARAMS.DAT を変更するには,以下のコマンドを入力します。


    $ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT 
    

  3. 1 つのクラスタ共通システム・ディスクを使用するクラスタ内で,クラスタ共通システム登録ファイルのレコードを変更するには,任意のコンピュータから以下のコマンドを入力します。


    $ SET DEFAULT SYS$COMMON:[SYSEXE] 
    $ RUN SYS$SYSTEM:AUTHORIZE 
    

  4. 同じクラスタ共通システム・ディスクからブートされる別のコンピュータにログインするときに,コンピュータ固有のシステム登録ファイルのレコードを変更するには,デフォルト・ディレクトリを特定のコンピュータに設定しなければなりません。たとえば,JUPITR コンピュータのコンピュータ固有のシステム登録ファイル (SYSUAF.DAT) を設定している場合,以下に示すように,AUTHORIZE を起動する前に,デフォルト・ディレクトリを JUPITR コンピュータの固有の [SYSEXE] ディレクトリに設定する必要があります。


    $ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] 
    $ RUN SYS$SYSTEM:AUTHORIZE 
    



5.4 クラスタ単位論理名

OpenVMS バージョン 7.2 では,OpenVMS Alpha と OpenVMS VAX の両方でクラスタ単位論理名が提供されるようになりました。クラスタ単位論理名は,共用可能な論理名の便利さと使いやすさを OpenVMS Cluster システムにまで拡張します。

既存のアプリケーションは,アプリケーション・コードを変更せずに,クラスタ単位論理名を利用できます。ただし,アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。

デフォルト設定では,新しい論理名はローカルでのみ有効です。クラスタ単位論理名は,ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには,クラスタ単位論理名テーブルにその論理名を作成しなければなりません。

クラスタ単位論理名の最も重要な機能は以下のとおりです。

  • 新しいノードがクラスタに参加する場合,現在設定されているクラスタ単位論理名全部を自動的に受け取ります。

  • クラスタ単位論理名または論理名テーブルが作成,変更,削除されると,その変更は OpenVMS バージョン 7.2 以降が稼動するクラスタ内の他のすべてのノードに自動的に伝達されます。クラスタ単位のテーブルに対するセキュリティ・プロファイルの変更も,この方法で自動的に伝達されます。

  • クラスタ単位の名前の変換によってパフォーマンスができるだけ低下しないように,変換はローカルに行われます。

  • LNM$CLUSTER_TABLE と LNM$SYSCLUSTER_TABLE は, OpenVMS バージョン 7.2 以降が稼動するすべてのシステムに存在するため,クラスタ単位論理名を使用するプログラムとコマンド・プロシージャは,クラスタに接続されていないシステムでも開発,テスト,実行することができます。



5.4.1 デフォルトのクラスタ単位論理名テーブル

クラスタ単位論理名をサポートするために,オペレーティング・システムは, 表 5-1 に示すように,システム・スタートアップ時に 2 つのクラスタ単位論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は,プロセス論理名テーブル,ジョブ論理名テーブル,グループ論理名テーブル,システム論理名テーブルに加えて提供されるものです。クラスタ単位論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。

表 5-1 デフォルトのクラスタ単位論理名テーブルと論理名
名前 目的
LNM$SYSCLUSTER_TABLE クラスタ単位システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは,クラスタ単位論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は,誰でも使用することができ,SHOW LOGICAL/SYSTEM に, LNM$SYSTEM のテーブル名,LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト),LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して,論理名を変換することができる。
LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は,LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。
LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて,すべてのクラスタ単位論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると,そのテーブルはクラスタ単位で使用可能になる。
LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。



5.4.2 変換順序

LNM$SYSTEM の定義は,LNM$SYSCLUSTER を含むように拡張されています。システム論理名を変換する場合,検索順序は LNM$SYSTEM_TABLE,LNM$SYSCLUSTER_TABLE です。システムのデフォルト・テーブル名である LNM$FILE_DEV と LNM$DCL_LOGICALS の定義には,LNM$SYSTEM が含まれているため,これらのデフォルト・テーブルを使用する変換には,LNM$SYSCLUSTER に指定されている定義が含まれます。

論理名の解釈に関する現在の優先順位はそのまま保存されます。 LNM$FILE_DEV に対して変換されるクラスタ単位論理名は,システム論理名の後に,最後に解釈されます。論理名が解釈される順序は, 図 5-4 に示すように,プロセス --> ジョブ --> グループ --> システム --> クラスタの順です。

図 5-4 LNM$FILE_DEV によって指定される変換順序



目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項