日本-日本語

製品  >  ソフトウェア  >  OpenVMS

OpenVMS FAQ


≫ 

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

タイトルページ
目次
第 1 章:概要
第 2 章:ドキュメント
第 3 章:時間の管理
第 4 章:ネットワークとクラスタ
索引
OpenVMS ホーム

HP OpenVMS
FAQ


目次 索引



メッセージをポケットベル・デバイス (ページャ) に送信して, TAP (Telocator Alphanumeric Protocol) ページング・パッケージなどのさまざまなプロトコルを介して通信するためのサードパーティ製品が提供されています。

RamPage (Ergonomic Solutions) は提供されているパッケージの 1 つで,メッセージを作成して,ポケットベルに送信することができます。その他に,Target Alert (Target Systems; 以前は DECalert 製品) も提供されています。 Networking Dynamics Corp は Pager Plus という製品を提供しています。 System Watchdog パッケージもポケットベルに送信することができます。 Process Software のパッケージ PMDF は,特定の電子メール・アドレスをポケットベル・サービスにルーティングすることもできます。

多くの市販のポケットベル・サービスでは,ポケットベル・ユーザ向けに電子メール・アドレスが提供されています。ポケットベルに割り当てられている電子メール・アドレスに直接,電子メールを送信したり,転送したりすることができます。

電話に接続して,ページング・シーケンスを送信し,少し時間をおいて,人間がダイヤルするときと同じ番号を送信する一連のコマンドをモデムに送信することで,ポケットベルへの送信をインプリメントしているユーザもいます。しかし,この方法は完全に信頼できる方法ではありません。モデムには「電話の接続状況の検出機能」がないため,ポケットベル接続会社の電話ベースのダイヤルアップ・レシーバに実際に接続されていないのに,プログラムがダイヤル・シーケンスを送信してしまうようなケースが発生することもあります。

提供されている製品についての情報は,英語版FAQの「Finding and using Software」を参照してください。

4.6 OpenVMS とクラスタ,ボリューム・シャドウイングについて教えてください

ここでは,OpenVMS とクラスタ,ボリューム・シャドウイング,およびクラスタに関連するシステム・パラメータについて説明します。

4.6.1 OpenVMS Cluster の通信プロトコルの詳細について教えてください

ここでは, OpenVMS SCS (System Communications Services) プロトコルについて説明します。 クラスタ関連の用語については, 第 4.6.1.2.1 項 を参照してください。

OpenVMS Cluster 環境はさまざまなネットワーク・プロトコルで動作しますが,クラスタのコアでは SCS (System Communications Services) プロトコルおよび SCS 固有のネットワーク・データグラムが使用されます。直接 (完全) 接続であることが前提です。

OpenVMS Cluster は DECnet や IP 上では動作しません

SCS プロトコル・ルータは提供されていません。

SCS を DECnet または IP 上で稼動することについては,多くの人が数年にわたって提案していますが, SCS はレイヤがはるかに深く,このようなプロジェクトを実現するには,SCS だけでなく,DECnet および IP ドライバの大幅なまたは完全な書き直しが必要になります。さらに,現在インプリメントされている DECnet および IP には,アプリケーション・レベルで動作する膨大なコードが含まれていますが,SCS はシステムのプリミティブ・コンテキスト,特にブートストラップで動作する必要があります。したがって,SCS がDECnet または IP 接続で動作するには,DECnet または IP スタックの主要な部分をカーネルに移動する必要があります。さらに,このように変更しても,その結果が期待される帯域幅や遅延時間の要件を満たすかどうか明確ではありません。

マルチサイト OpenVMS Cluster 構成の一般的なアプローチとしては,FDDI,Memory Channel (MC2),ポイント・ツー・ポイント・リモート・ブリッジ,ルータ,スイッチなどが使用されます。接続は透過的でなければならず, 10 メガビット/秒以上 (イーサネットの速度) で動作し,遅延時間はイーサネットの特性と同じか,それより優れていなければなりません。さまざまなサイトで FDDI,MC2,ATM,ポイント・ツー・ポイント T3 リンクが使用されています。

ここでは,OpenVMS Cluster 通信,クラスタで使用される用語,関連ユーティリティ,コマンドおよび制御インタフェースについて説明します。

4.6.1.2.1 クラスタで使用される用語について教えてください


SCS:
Systems Communication Services の頭文字。 VMSCluster システム間,および OpenVMS システムと SCS ベースのストレージ・コントローラの間で使用される通信プロトコルです。 SCSI ベースのストレージ・コントローラは SCS を使用しません。

ポート:
DSSI,CI,イーサネット,FDDI などの通信デバイス。各 CI バスや DSSI バスは異なるローカル・ポートであり, PAA0,PAB0,PAC0 などの名前が付けられています。すべてのイーサネットおよび FDDI バスによって,1 つの PEA0 ポートが構成されます。

仮想サーキット:
2 つのポートの間に確立される,信頼できる通信パス。 VMScluster 内の各ポートは,そのクラスタ内の他の各ポートとの間に仮想サーキットを確立します。

すべてのシステムとストレージ・コントローラが「仮想サーキット」を確立して,可能なすべてのポートの間で通信できるようにします。

SYSAP:
SCS を使用して通信する「システム・アプリケーション」。各 SYSAP は特定のリモート SYSAP と通信します。 SYSAP の例を以下に示します。

VMS$DISK_CL_DRIVER は MSCP$DISK に接続します。
ディスク・クラス・ドライバはすべての VMSCluster システムにあります。 MSCP$DISK は,SYSGEN パラメータ MSCP_LOAD が 1 に設定されているすべての VMSCluster システムおよびすべてのディスク・コントローラにあります。

VMS$TAPE_CL_DRIVER は MSCP$TAPE に接続します。
テープ・クラス・ドライバはすべての VMSCluster システムにあります。 MSCP$TAPE は,SYSGEN パラメータ TMSCP_LOAD が 1 に設定されているすべての VMSCluster システムおよびすべてのテープ・コントローラにあります。

VMS$VAXCLUSTER は VMS$VAXCLUSTER に接続します。
この SYSAP には接続マネージャが含まれており,クラスタの接続を管理し,クラスタ状態遷移アルゴリズムを実行し,クラスタ・クォーラム・アルゴリズムをインプリメントします。この SYSAP はロック・トラフィックやその他のさまざまなクラスタ通信機能も取り扱います。

SCS$DIR_LOOKUP は SCS$DIRECTORY に接続します。
この SYSAP は,リモート・システムで SYSAP を検索するのに使用されます。

MSCP と TMSCP。
MSCP (Mass Storage Control Protocol) および TMSCP (Tape MSCP) サーバは,ディスクおよびテープ・ストレージへのアクセスを可能にする SYSAP であり,通常,SCS プロトコルで動作します。 MSCP および TMSCP SYSAP は, OpenVMS (ディスクとテープをサービスする OpenVMS ホスト), CI および DSSI ベースのストレージ・コントローラ,ホスト・ベースの MSCP または TMSCP ストレージ・コントローラの内部にあります。 MSCP と TMSCP は MSCP および TMSCP ストレージ・デバイスをサービスするために使用でき,SCSI ストレージ・デバイスをはじめ, MSCP/TMSCP 以外のストレージ・デバイスをサービスすることもできます。

SCS 接続:
あるノードの SYSAP は,別のノードの対応する SYSAP との間で SCS 接続を確立します。この接続は使用可能な唯一の仮想サーキット上に確立されます。

4.6.1.2.2 クラスタ通信の制御について教えてください

2 つの OpenVMS システムの間に複数の仮想サーキットがある場合は, VMS$VAXCLUSTER から VMS$VAXCLUSTER への接続でこれらのサーキットのいずれかを使用できます。 2 つのシステムの間のロック・トラフィックはすべて,選択した仮想サーキット上を移動します。

各ポートには,「ロード・クラス」が割り当てられます。このロード・クラスは,接続でどの仮想サーキットを使用するかを判断するのに役立ちます。あるポートのロード・クラスが他のどのポートより高い場合は,そのポートが使用されます。 2 つ以上のポートのロード・クラスが同じである場合は,接続で最初に見つかったポートが使用されます。通常,すべての CI ポートと DSSI ポートのロード・クラスは 14 (16 進数) であり,イーサネット・ポートと FDDI ポートのロード・クラスは A (16 進数) です。 V7.3-1 以降は,ロード・クラスは動的な値です。

たとえば,複数の DSSI バスと 1 つの FDDI がある場合は,VMS$VAXCLUSTER 接続は DSSI バスを選択します。これは,このパスにシステム・ディスクがあるからです。したがって,OpenVMS システムのブート時に最初に検出された DSSI バスが常に使用されます。

すべてのロック・トラフィックを DSSI ではなく, FDDI で転送するには,たとえば,ロード・クラス値を調整するか,または DSSI SCS ポートを無効にする必要があります。

ロード・クラスに加え,MSCP および TMSCP サービスの優先パスを使用してクラスタ通信を制御することもできます。この機能を利用すると,リモートのディスクとテープ・ストレージのサービスに使用される SCS 接続を制御することができます。優先パスは,ディスクあるいはテープ・ストレージをサービスする各ホストあるいは各ストレージ・コントローラを越えてクラスタ I/O を明示的に広げるのに最も一般的に使用される機能です。この機能は,現在の I/O で必要とする各ホストあるいは各ストレージ・コントローラのそれぞれの I/O 帯域幅が不足しており,クラスタ I/O 負荷に対応するために帯域幅を統合しなければならない場合に特に便利です。

関連ツールについては,LAVC$STOP_BUS および LAVC$START_BUS などのさまざまなユーティリティ,および SET PREFERRED_PATH などの DCL コマンドを参照してください。

4.6.1.2.3 クラスタ通信を制御するツールとユーティリティについて教えてください

ほとんどのバージョンの OpenVMS で,以下のツールを使用できます。

  • SYS$EXAMPLES:LAVC$STOP_BUS

  • SYS$EXAMPLES:LAVC$START_BUS

これらのツールを使用すると,指定されたパス上のすべての SCS トラフィックを無効または有効にすることができます。

また,優先パス・メカニズムを使用して,ディスクへのどのパスを使用するかをローカル MSCP ディスク・クラス・ドライバ (DUDRIVER) に指示することもできます。一般に,この手法はデュアル・パス・ディスクで使用され,I/O トラフィックが特定のコントローラを通過するようにしています。このメカニズムを使用して,ディスク I/O レベルで I/O 負荷分散の大まかな形を実装することができます。

V7.2 より前のバージョンでは,優先パス機能は以下のツールを使用します。

  • SYS$EXAMPLES:PREFER.MAR

OpenVMS V7.2 以降では,以下の DCL コマンドを使用できます。


$ SET PREFERRED_PATH 

優先パス・メカニズムによって,優先パス以外のパス上の SCS 操作が禁止されたり,影響を受けることはありません。

OpenVMS V7.3 以降でのクラスタ通信の制御, SCS 仮想サーキットの制御,ポートの選択,および関連操作については,SCACP ユーティリティを参照してください。

4.6.2 クラスタ関連のシステム・パラメータの設定について教えてください

ここでは,クラスタ関連のシステム・パラメータの設定について詳しく説明します。

VMScluster 接続マネージャは,ディスクやメモリのデータが破損するのを防止するために,ボート (投票数) とクォーラム (定足数) という概念を使用します。クォーラムに対して十分なボートがある場合は,リソースへのアクセスは許可されます。十分なボートがない場合は,ユーザのアクティビテイはブロックされます。ユーザのアクティビテイをブロックする動作は「クォーラム・ハング」と呼ばれ,「ユーザ・データの整合性のインターロック」として考えるとわかりやすいでしょう。このメカニズムはパーティションに分割された VMScluster を防止することにより,膨大なディスク・データが破損するのを防止できるように設計されています。 クォーラム・メカニズムは特に,データの深刻な破損を防止することを目的にしています。

VMScluster 内の各 OpenVMS ノードで, VOTES と EXPECTED_VOTES という 2 つのパラメータの値を SYSGEN で設定します。 VOTES は,ノードが VMScluster に貢献するボートの数 (投票数) です。 EXPECTED_VOTES は,完全な VMScluster のブートが行われるときに期待されるボートの合計です。

一部のサイトでは,EXPECTED_VOTES を誤って非常に低い値に設定しようとすることがあります。これは,ボーティング・ノードの一部だけが VMScluster 内に存在する場合,このような低い値を使用できると確信しているためです。しかし,それは誤りです。さらに,EXPECTED_VOTES の値を適切に設定しないと,他のノードとの間で VMScluster 接続が確立された後,値は自動的に修正されます。そのため,接続が確立される前の,システム・ブートの最も初期の脆弱な部分で,ユーザ・データが大きく破壊される危険性があります。

VMScluster には,1 つ, 2 つ,あるいはもっと多くのボーティング・ノードを含むことができます。 2 ノード構成以外の構成では,一部のノードで障害が発生したときに,ノードのサブセットをアクティブな状態にしておくように構成することが簡単にできます。 2 ノード構成の場合は,プライマリ/セカンダリ構成 (プライマリがすべてのボートを保有する構成),ピア構成 (一方のノードがダウンすると,もう一方もハングする構成),共有クォーラム・ディスクのいずれかを使用する必要があります。共有クォーラム・ディスクが最も望ましい構成です。

クォーラム・ディスクを使用すると, VMScluster の状態遷移の速度がいくらか低下します。クォーラム・ディスクに割り当てられるボートを提供する第 3 のボーティング・ノードを追加すると,遷移は速くなります。クォーラム・ディスクを使用するということは,2 ノードから成る VMScluster 構成のいずれか一方のノードがダウンしたときに,もう一方のノードが動作できることを意味します。

注意

クォーラム・ディスクはコントローラ・ベースの RAID で保護できますが, ホストベースのシャドウ化ディスク上に置くべきではありません。ホストベースのボリューム・シャドウイングはロック・マネージャに依存し,ロック・マネージャは接続マネージャに依存し,接続マネージャはクォーラムに依存するため,クォーラム・ディスクの保護にホストベースのボリューム・シャドウイングを認めるのは技術的には適切ではありません(信頼性の点でも問題があります)。

クォーラム・ディスクを使用することを選択した場合, OpenVMS を最初にブートする際およびクォーラム・ディスクを指定する際に, QUORUM.DAT ファイルが自動的に作成されます。また,クォーラム・ディスクからのボートを必要とせずに OpenVMS がブートされる場合も, QUORUM.DAT ファイルが作成されます。

共有ストレージ・インターコネクトを備えた 2 ノード VMScluster では,通常,各ノードに 1 つのボートが与えられ,クォーラム・ディスクにも 1 つのボートが与えられます。 EXPECTED_VOTES は 3 に設定されます。

非共有インターコネクトでクォーラム・ディスクを使用する必要はありません。クォーラム・ディスクを使用しても全くメリットがなく,クォーラム・ディスクに割り当てられるボートはディスクへのアクセスをサービスする OpenVMS ホストに割り当てるべきです。

クォーラム・ハングの詳細については,OpenVMS のドキュメントを参照してください。動作中のシステムで EXPECTED_VOTES の値を変更する方法については, SET CLUSTER/EXPECTED_VOTES コマンドの説明を参照し, AMDS および Availability Manager ツールのドキュメントも参照してください。また,IPC (Interrrupt Priority Level %x0C; IPL C) ハンドラを起動するために使用されるプロセッサ固有のコンソール・コマンドについては, OpenVMS システム・コンソールに関するドキュメントを参照してください(IPC は OpenVMS I64 V8.2 ではサポートされていません)。 AMDS,Availability Manager,および IPC ハンドラはそれぞれ,クォーラム・ハングをクリアするために使用されます。一般に,IPC より,AMDS および Availability Manager ツールを使用することをお勧めします。これは特に,クラスタのサニティ・タイマの制限を超えてシステムを停止したままにしておく必要がある場合は IPC によって CLUEXIT バグチェックが発生する可能性があり,また,いくつかの Alpha コンソールおよびほとんどの Integrity コンソールが halt の後の再起動を認めていないためです。

クォーラム・スキームは,OpenVMS Engineering がデータの整合性を提供するために実装している「ブレード・ガード」です。これらのブレード・ガードを外す場合は,各自の責任で外してください。 OpenVMS Engineering がクォーラム・メカニズムを実装したのは,決してシステム管理者の作業を困難にするためではなくデータが混乱するのを防止するためです。


目次 索引

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