日本-日本語
≫日本HPホーム ≫製品 & サービス ≫OpenVMS製品情報
≫  お問い合わせ


OpenVMS マニュアル
≫ 

OpenVMS ドキュメント
ライブラリ

≫ タイトルページ
≫ 目次
≫ まえがき
≫ 第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 ホーム

HP OpenVMS
OpenVMS Cluster システム
目次 索引


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

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

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



以下の目的で，クラスタワイド論理名テーブルを追加作成しなければならないことがあります。

  • マルチプロセス・クラスタワイド・アプリケーションを使用するため。

  • UIC グループのメンバを共用するため。

クラスタワイド論理名テーブルを作成するには，親テーブルに対する作成 (C) アクセス権と LNM$SYSTEM_DIRECTORY に対する書き込み (W) アクセス権を保有するか，または SYSPRV (システム) 特権が必要です。

共有論理名テーブルは，UIC ベースで保護されています。ユーザの各クラス (システム (S)，オーナ (O)，グループ (G)，およびワールド (W)) には，4 つのアクセス・タイプ， (読み込み (R)，書き込み (W)，作成 (C)，削除 (D)) が認められています。

クラスタワイド論理名テーブルは，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブルの場合と同じ方法で追加作成できます。つまり， CREATE/NAME_TABLE コマンドを使用するか， $CRELNT システム・サービスを使用します。クラスタワイド論理名テーブルを作成する場合は， /PARENT_TABLE 修飾子を使用し，修飾子の値としてクラスタワイド・テーブル名を指定します。既存のクラスタワイド・テーブルを親テーブルとして使用すると，新規テーブルもクラスタ単位になります。

以下の例では，クラスタワイド論理名テーブルの作成方法を示しています。 

$ CREATE/NAME_TABLE/PARENT_TABLE=LNM$CLUSTER_TABLE - 
_$ new-clusterwide-logical-name-table



5.4.4 クラスタワイド論理名テーブルに関係するエイリアスの競合

クラスタワイド論理名テーブルに関係するエイリアスの競合は，他の種類の論理名テーブルのエイリアスの競合とは異なる方法で処理されます。 表 5-2 では，競合の種類とその結果を示しています。

表 5-2 エイリアスの競合と結果
競合の種類 結果
既存のクラスタワイド・テーブルと同じ名前および同じアクセス・モードで論理テーブルを作成した。 新しいローカル・テーブルは作成されない。条件値 SS$_NORMAL が返される。これは，サービスは正常終了したが，論理名テーブルがすでに存在することを示す。すべてのノードで既存のクラスタワイド・テーブルとその名前が有効になる。
既存のローカル・テーブルと同じ名前および同じアクセス・モードでクラスタワイド・テーブルを作成した。 新しいクラスタワイド・テーブルが作成される。条件値 SS$_LNMCREATED が返される。これは，論理名テーブルが作成されたことを示す。ローカル・テーブルとその名前は削除される。クラスタワイド・テーブルが DCL コマンド DEFINE を使用して作成されている場合は，以下のメッセージが表示される。

DCL-I-TABSUPER, previous table table_name has been superseded

クラスタワイド・テーブルが $CRELNT システム・サービスを使用して作成された場合は， $CRELNT は条件値 SS$_SUPERSEDE を返す。

既存のクラスタワイド・テーブルと同じ名前および同じアクセス・モードでクラスタワイド・テーブルを作成した。 新しいクラスタワイド・テーブルは作成されない。条件値 SS$_NORMAL が返される。これは，サービスは正常終了したが，論理名テーブルがすでに存在することを示す。$CRELNT システム・サービスの CREATE-IF 属性の設定とは無関係に，既存のテーブルとそのすべての名前が有効なままになる。このため，既存のテーブル名が他のノードから誤って削除されるのを防止できる。



5.4.5 クラスタワイド論理名の作成

クラスタワイド論理名を作成するには，論理名を登録するテーブルに対して，書き込み (W) アクセス権が必要です。あるいは， LNM$SYSCLUSTER にだけクラスタワイド論理名を作成する場合は， SYSNAM 特権が必要です。アクセス・モード (ユーザ，スーパーバイザなど) を指定した場合を除き，作成する論理名のデフォルト・アクセス・モードは，名前を作成したときのアクセス・モードになります。DCL コマンドを使用して名前を作成した場合は，デフォルト・アクセス・モードはスーパーバイザ・モードになります。プログラムで名前を作成した場合は，通常，アクセス・モードはユーザ・モードになります。

クラスタワイド論理名を作成する場合，論理名の定義にクラスタワイド論理名テーブルの名前を指定しなければなりません。クラスタワイド論理名は，DCL コマンドまたは $CRELNM システム・サービスを使用して作成できます。

以下の例では，DEFINE コマンドを使用して，デフォルトのクラスタワイド論理名テーブル LNM$CLUSTER_TABLE にクラスタワイド論理名を作成する方法を示しています。 

$ DEFINE/TABLE=LNM$CLUSTER_TABLE logical-name equivalence-string

作成したクラスタワイド論理名テーブルに登録されるクラスタワイド論理名を作成するには，DEFINE コマンドを使用して新しいクラスタワイド論理名を定義し，/TABLE 修飾子に新しいクラスタワイド・テーブルの名前を指定します。以下の例を参照してください。 

$ DEFINE/TABLE=new-clusterwide-logical-name-table logical-name - 
_$ equivalence-string

  注意
既存のクラスタワイド論理名と同じアクセス・モードおよび同じ等価名と属性を使用して，新しいクラスタワイド論理名を作成しようとすると，既存の名前は削除されず，メッセージもリモート・ノードに送信されません。この動作は，他の種類の論理名テーブルに対して同様の操作を実行したときと異なります。他の種類の論理名の場合は，既存の名前が削除され，新しい名前が作成されます。クラスタワイド論理名の場合は，このように異なる動作を行うことで，パフォーマンスを向上しています。

条件値 SS$_NORMALが返されます。サービスは正常終了しますが，新しい論理名は作成されません。



クラスタワイド論理名を使用する場合は，以下のガイドラインに従ってください。

  1. 特定の論理名はクラスタ単位で使用しないでください。
    以下の論理名はクラスタ単位で使用できません。

    • メールボックス名。メールボックス・デバイスはノードにローカルであるため，クラスタ単位では使用できません。

    • SYS$NODE と SYS$NODE_FULLNAME は LNM$SYSTEM_TABLE に登録しなければならず，ノード固有です。

    • LMF$LICENSE_TABLE。

  2. LNM$SYSTEM の定義は変更しないでください。
    LNM$SYSTEM は現在，LNM$SYSTEM_TABLE， LNM$SYSCLUSTER_TABLE として定義されています。この 2 つのテーブルの順序を逆にしないでください。順序を入れ替えると， /SYSTEM 修飾子を使用して作成された名前または LNM$SYSTEM に登録されている名前が LNM$SYSCLUSTER_TABLE に登録され，クラスタ単位で使用されるようになります。この結果，さまざまなシステム障害が発生します。たとえば，MOUNT/SYSTEM コマンドはマウントされているボリュームに対してクラスタワイド論理名を作成しようとしますが，その結果，エラーが発生します。

  3. LNM$SYSTEM の内容は LNM$SYSTEM に保存しておいてください。
    LNM$SYSTEM に登録されている論理名を LNM$SYSCLUSTER にマージしないでください。LNM$SYSTEM に登録されている多くのシステム論理名にはシステム・ルートが含まれており，ノード固有のデバイスまたはノード固有のディレクトリのどちらか一方，またはその両方が含まれています。

  4. サイトで使用されている論理名の命名規則に従ってください。
    混乱を招く名前や競合する名前を避けるために，システム固有の論理名に対して 1 つの命名規則を設定し，クラスタワイド論理名に対して別の命名規則を設定します。

  5. 自分のサイトの論理名にドル記号 ($) を使用しないようにします。これは，OpenVMS ソフトウェアで名前にドル記号が使用されるからです。

  6. クラスタワイド論理名データベースに一貫性がない場合，クラスタワイド論理名操作がストールされることを認識してください。
    システムのクラスタワイド論理名データベースが完全に初期化されていない場合，システムの初期化時にこのような現象が発生することがあります。また，クラスタ・サーバ・プロセスがクラスタワイド論理名データベースの更新を完了していない場合や，ノードがクラスタに追加されたり，クラスタから削除された後の再同期化でこのような状況が発生することもあります。再びデータベースの整合性が確立されたら，クラスタワイド論理名操作の処理はただちに再開されます。



5.4.7 アプリケーションでのクラスタワイド論理名の使用

$TRNLNM システム・サービスと $GETSYI システム・サービスは，クラスタワイド論理名固有の属性を提供します。ここでは，これらの属性について説明します。また，クラスタワイド・テーブルの作成に関連する部分では，$CRELNT の使い方についても説明します。アプリケーションでの論理名の使用の詳細については，『HP OpenVMS Programming Concepts Manual』を参照してください。

$TRNLNM システム・サービスでは，以下の 2 つのクラスタワイド属性が提供されます。

  • LNM$V_CLUSTERWIDE

  • LNM$M_INTERLOCKED

クラスタワイド論理名に対して LNM$_ATTRIBUTES アイテムを求めると， LNM$V_CLUSTERWIDE が出力属性としてアイテム・リストに返されます。

LNM$M_INTERLOCKED は，attr 引数ビットであり，このビットをセットしておくと，現在処理中のクラスタワイド論理名の変更が完了してから，名前が変換されるようになります。デフォルト設定では， LNM$M_INTERLOCKED はセットされません。アプリケーションでクラスタワイド論理名の最新の定義を使用する必要がある場合は，変換を要求する際にこの属性を指定することで，処理中のすべての変更が完了するまで，変換をストールさせることができます。

シングル・システムで，あるプロセスが論理名データベースの共用可能部分を変更すると，その変更はそのノードの他のプロセスからただちに確認できます。さらに，変更がまだ完了していない場合は，他のプロセスは共用可能論理名を変換したり，変更することができません。

一方，あるプロセスがクラスタワイド論理名データベースを変更すると，その変更はそのノードではただちに確認できますが，変更が他のノードに伝達されるまでには少し時間がかかります。デフォルト設定では，クラスタワイド論理名の変換はストールされません。したがって，異なるノードのプロセスが 1 つの論理名を変換し，変更がまだ完了していないときに，異なる等価名を取得する可能性があります。

LNM$M_INTERLOCKED を使用すると，アプリケーションでクラスタワイド論理名の最新の定義を必ず受け取ることができるようになります。

$GETSYI システム・サービスに，クラスタワイド属性 SYI$_CWLOGICALS が追加されました。 SYI$_CWLOGICALS を指定すると，$GETSYI は，クラスタワイド論理名データベースが CPU 上で初期化されているときは 1，初期化されていないときは 0 を返します。この値は論理値 (1 または 0) であるため，アイテム記述子のバッファ長フィールドは 1 (バイト) でなければなりません。非クラスタ・システムでは，SYI$_CWLOGICALS の値は常に 0 です。

$CRELNT を使用してクラスタワイド・テーブルを作成する場合は，テーブル名を指定しなければなりません。OpenVMS では，クラスタワイド・テーブルに対してデフォルト名が与えられません。これは，デフォルト名を使用すると，SYSPRV 特権を持たないプロセスが共用可能テーブルを作成することができるからです。

5.4.8 クラスタワイド論理名の定義およびアクセス

ブート・ノードでクラスタワイド論理名データベースを初期化するには，他のノードにメッセージを送信し，データベースの内容を含む CLUSTER_SERVER プロセスの応答メッセージが必要です。ブート・ノードにある CLUSTER_SERVER プロセスは，等価な名前とテーブルを作成するために，システム・サービスを呼び出します。この初期化にかかる時間は，クラスタワイド論理名データベースのサイズや，クラスタ・インターコネクトのスピード，そして応答ノードの CLUSTER_SERVER プロセスの応答性などの状況によって変わります。

ブート・ノードにあるクラスタワイド論理名データベースのコピーが，その他のクラスタにある論理名データベースと同じになるまでに，ブート・ノードでクラスタ単位名またはテーブルを作成または削除しようとすると，気づかないうちにストールされます。デフォルトでは変換はストールされないため，データベースが一致する前にクラスタ単位名を変換しようとすると，タイミングによって失敗したり，成功したりします。データベースが一致するまで変換をストールするようにするには， F$TRNLNM CASE 引数を INTERLOCKED に指定します。

一般に，システム管理者は SYLOGICALS.COM コマンド・プロシージャを編集して，システム・スタートアップ時に有効になるサイト固有の論理名を定義します。しかし，クラスタワイド論理名を定義する場合， 第 5.4.8.2 項 にある論理名以外は，できるだけ SYSTARTUP_VMS.COM コマンド・プロシージャ内で定義することをお勧めします。クラスタワイド論理名を SYSTARTUP_VMS.COM 内で定義することをお勧めするのは， SYSTARTUP_VMS.COM がブート・プロセスで SYLOGICALS.COM よりずっと後の段階で実行されるからです。

OpenVMS スタートアップは，CLUSTER_SERVER プロセスなどの作成したプロセスによるアクションを除けば，単一の流れで同期がとれています。 CLUSTER_SERVER はスタートアップ時の初期の段階に作成されますが， SYLOGICALS.COM 実行時では，ブート・ノードのクラスタワイド論理名データベースのコピーの初期化が完了していないことがあります。このような場合，SYLOGICALS.COM にあるクラスタ単位の定義によりスタートアップがストールされ，システムが運用開始するまでの時間が余計にかかります。

OpenVMS では，SYSTARTUP_VMS.COM が実行される前にクラスタワイド・データベースを初期化してしまうようにしています。

LMF$LICENSE，NET$PROXY，VMS$OBJECTS など，特定の論理名を有効にするには， SYSTARTUP_VMS.COM を起動するよりも前に，スタートアップの初期の段階でこれらの論理名を定義する必要があります。このような論理名のほとんどは，SYLOGICALS.COM に定義しますが， VMS$OBJECTS は例外で SYSECURITY.COM で定義し，それ以外の名前は SYCONFIG.COM で定義します。

名前をクラスタワイド論理名として定義するには， SYSTARTUP_VMS.COM でこれらの名前を定義することをお勧めしていますが， SYLOGICALS.COM と SYSECURITY.COM にも同様な作業を行う必要があります。この作業を行うと，スタートアップの時間がかかる可能性がありますので注意してください。

代わりに，従来の方法で，すべてのノードで名前をシステム・ワイド論理名として同一の定義を用いて定義することもできます。

すべてのクラスタ・ノードに共通なスタートアップ・コマンド・プロシージャ部分でクラスタワイド論理名を定義する場合は，条件付き定義を使用するようにしてください。たとえば次のようになります。 

$ IF F$TRNLNM("CLUSTER_APPS") .EQS. "" THEN - 
_$ DEFINE/TABLE=LNM$SYSCLUSTER/EXEC CLUSTER_APPS - 
_$ $1$DKA500:[COMMON_APPS]

条件付き定義を使用すると，意図に反した定義が行われるのを防止できます。たとえば，システム管理者が SYSTARTUP_VMS.COM にも定義されている名前を再定義し，新しい定義が一時的なものであるために， SYSTARTUP_VMS.COM を変更しなかったとします。新しいノードがクラスタに参加すると，そのノードは最初にその新しい定義を受け取ります。しかし，新しいノードが SYSTARTUP_VMS.COM を実行すると，そのノード自体も含めて，クラスタ内のすべてのノードは元の値に戻されてしまいます。

条件付き定義を SYLOGICALS.COM または SYSECURITY.COM に含める場合， F$TRNLNM CASE 引数を INTERLOCKED に指定し，変換が完了する前にクラスタワイド論理名の初期化が完了しているようにします。この引数指定と条件付き定義の例を以下に示します。 

 $ IF F$TRNLNM("CLUSTER_APPS",,,,"INTERLOCKED") .EQS. "" THEN - 
 _$ DEFINE/TABLE=LNM$SYSCLUSTER/EXEC CLUSTER_APPS - 
 _$ $1$DKA500:[COMMON_APPS]

  注意
F$GETSYI ("CWLOGICALS") は，クラスタに接続されていないシステムでは常に FALSE を返します。クラスタ環境と非クラスタ環境の両方で動作するように設計されているプロシージャでは，最初に現在の環境がクラスタ環境であるかどうか判断し，クラスタ環境の場合は，クラスタワイド論理名が初期化されるかどうかを判断しなければなりません。

目次 索引

© 2012 Hewlett-Packard Development Company, L.P.