library home hp.com home products and services support and drivers solutions
cd-rom home
End of Jump to page title
HP OpenVMS Systems
Documentation

Jump to content


OpenVMS

OpenVMS
OpenVMS Cluster システム


前へ 次へ 目次 索引


5.4.6 管理のガイドライン

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

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

  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 の使い方についても説明します。アプリケーションでの論理名の使用の詳細については,『OpenVMS Programming Concepts Manual』を参照してください。

5.4.7.1 $TRNLNM システム・サービスのクラスタ単位属性

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

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

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

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

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

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

5.4.7.2 $GETSYI システム・サービスのクラスタ単位属性

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

5.4.7.3 $CRELNT システム・サービスによるクラスタ単位・テーブルの作成

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

5.5 クラスタ単位論理名の定義およびアクセス

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

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

5.5.1 SYSTARTUP_VMS.COM 内でのクラスタ単位論理名の定義

一般に,システム管理者は SYLOGICALS.COM コマンド・プロシージャを編集して,システム・スタートアップ時に有効になるサイト固有の論理名を定義します。しかし,クラスタ単位論理名を定義する場合, 第 5.5.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 が実行される前にクラスタ単位・データベースを初期化してしまうようにしています。

5.5.2 SYLOGICALS.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 にも同様な作業を行う必要があります。この作業を行うと,スタートアップの時間がかかる可能性がありますので注意してください。

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

5.5.3 スタートアップ・コマンド・プロシージャで条件付き定義を使用

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


$ 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 を返します。クラスタ環境と非クラスタ環境の両方で動作するように設計されているプロシージャでは,最初に現在の環境がクラスタ環境であるかどうか判断し,クラスタ環境の場合は,クラスタ単位論理名が初期化されるかどうかを判断しなければなりません。

5.6 スタートアップ・コマンド・プロシージャの調整

コンピュータがブートされた直後に,サイトに依存しないコマンド・プロシージャ SYS$SYSTEM:STARTUP.COM が実行されてシステムが起動され,一連のスタートアップ・イベントが制御されます。STARTUP.COM プロシージャは,クラスタ固有およびノード固有のタスクを実行するその他の多くのスタートアップ・コマンド・プロシージャを呼び出します。

ここでは,適切なクラスタ固有スタートアップ・コマンド・プロシージャや他のシステム・ファイルを設定することによって,他のコンピュータをクラスタに追加する前に,最初にインストールしたコンピュータで OpenVMS Cluster オペレーティング環境を準備する方法について説明します。

関連項目: スタートアップ・コマンド・プロシージャの詳細については,『OpenVMS システム管理者マニュアル』も参照してください。

5.6.1 OpenVMS スタートアップ・プロシージャ

OpenVMS オペレーティング・システムには,複数のスタートアップ・コマンド・プロシージャが添付されています。 SYS$SYSTEM:STARTUP.COM コマンド・プロシージャは, OpenVMS がブートされた直後に実行され,以下の表に説明するサイト固有のスタートアップ・コマンド・プロシージャを起動します。

プロシージャ名 起動元 機能
SYS$MANAGER:
SYPAGSWPFILES.COM
SYS$SYSTEM:
STARTUP.COM
ページ・ファイルとスワップ・ファイル (自動的にインストールされるプライマリ・ページ・ファイルとプライマリ・スワップ・ファイル以外のファイル) をインストールするためにコマンドを追加するファイル。
SYS$MANAGER:
SYCONFIG.COM
SYS$SYSTEM:
STARTUP.COM
特殊デバイスを接続し,デバイス I/O ドライバをロードする。
SYS$MANAGER:
SYSECURITY.COM
SYS$SYSTEM:
STARTUP.COM
セキュリティ監査サーバを起動する前に,セキュリティ監査ファイルとセキュリティ・アーカイブ・ファイルの場所を定義する。
SYS$MANAGER:
SYLOGICALS.COM
SYS$SYSTEM:
STARTUP.COM
システム単位論理名を作成し,システム・コンポーネントをエグゼクティブ・モードの論理名として定義する (クラスタ単位論理名は SYSTARTUP_VMS.COM に定義しなければならない)。クラスタ共通ディスクはこのプロシージャの最後でマウントできる。
SYS$MANAGER:
SYSTARTUP_VMS.COM
SYS$SYSTEM:
STARTUP.COM
以下の多くのスタートアップ機能とログイン機能を実行する。

  • システム・ディスクを除き,他のすべてのボリュームをマウントする。

  • デバイスの属性を設定する。

  • クラスタ単位論理名を定義する。

  • バッチ・キューとプリント・キューを初期化し,起動する。

  • イメージをインストールする。

  • レイヤード製品を起動する。

  • DECnet ソフトウェアを起動する。

  • 最新のシステム障害を分析する。

  • 古いオペレータ・ログ・ファイルを消去する。

  • LAT ネットワークを起動する (使用する場合)。

  • 会話型ユーザの最大数を定義する。

  • システムが起動され,稼動していることを通知する。

  • ユーザがログインすることを許可する。

ディレクトリ SYS$COMMON:[SYSMGR] には,編集可能な各コマンド・プロシージャのテンプレート・ファイルが格納されています。システムのスタートアップおよびログイン属性のカスタマイズの例として,コマンド・プロシージャ・テンプレート (SYS$COMMON:[SYSMGR]*.TEMPLATE) を利用すると便利です。

5.6.2 スタートアップ・プロシージャの作成

OpenVMS Cluster 共用環境を準備する場合,最初に SYSTARTUP_VMS コマンド・プロシージャを作成します。各コンピュータは,スタートアップ時にこのプロシージャを実行して,オペレーティング環境を定義します。

SYSTARTUP_VMS.COM プロシージャは以下の方法で準備します。

ステップ 操作
1 各コンピュータの SYS$SPECIFIC:[SYSMGR] ディレクトリで, SYSTARTUP_VMS.TEMPLATE ファイルを編集して,以下のように SYSTARTUP_VMS.COM プロシージャを設定する。

  • 以下のようなコンピュータ固有のスタートアップ機能を実行する。

    • デュアル・ポート・ディスクとローカル・ディスクの設定

    • デバイス・ドライバのロード

    • ローカル・ターミナルとターミナル・サーバ・アクセスの設定

  • 共通スタートアップ・プロシージャの起動 (この後の説明を参照)

2 すべてのコンピュータに共通のスタートアップ・コマンドを格納した共通コマンド・プロシージャを作成する。共通プロシージャには以下のコマンドを格納できる。

  • イメージのインストール

  • 論理名の定義

  • キューの設定

  • 物理的にアクセス可能なマス・ストレージ・デバイスの設定とマウント

  • 他の共通のスタートアップ機能の実行

注意: これらのコマンドは,共通プロシージャから起動される個々のコマンド・プロシージャに格納することもできる。たとえば, SYS$EXAMPLES ディレクトリの MSCPMOUNT.COM ファイルは,クラスタ・ディスクをマウントするために通常使用されるコマンドを格納した共通コマンド・プロシージャの例である。この例には,プロシージャの各フェーズを説明するコメントが含まれている。

3 共通プロシージャを共通システム・ディスクまたは他のクラスタ・アクセス可能ディスクの SYS$COMMON:[SYSMGR] ディレクトリに格納する。

重要: 共通プロシージャは通常,共通システム・ディスクの SYS$COMMON:[SYSMGR] ディレクトリに格納されるが,クラスタ全体でアクセス可能で,プロシージャの起動時にマウントされているディスクであれば,どのディスクにでも格納できる。各コンピュータに対して共通プロシージャのコピーを作成する場合,変更時に必ず各コピーを更新することを忘れないようにしなければならない。


前へ 次へ 目次 索引