日本-日本語

製品  >  ソフトウェア  >  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 システム


目次 索引

第 6 章
クラスタ・ストレージ・デバイス

OpenVMS Cluster システムの最も重要な機能の 1 つは,複数のシステム間でデバイスとファイルをアクセスできるようにする機能です。

従来のコンピューティング環境では,1 台のシステムがストレージ・サブシステムに直接接続されていました。システムはネットワークを介して他のシステムと接続することができますが,そのシステムがシャットダウンされると,ネットワーク上の他のシステムは,ダウンされたシステムに接続されているディスクや他のデバイスにアクセスできなくなります。

OpenVMS Cluster システムでは,ディスクとテープは 1 つまたは複数のメンバからアクセス可能になるように設定できます。したがって,1 台のコンピュータがシャットダウンされても,他のコンピュータはそのデバイスにアクセスできます。

6.1 データ・ファイルの共用

クラスタ・アクセス可能デバイスは,OpenVMS Cluster で重要な役割を果たします。データ・ファイルまたはアプリケーションをクラスタ・アクセス可能デバイスに格納しておくと,コンピュータは各共通ファイルのシングル・コピーを共用できるようになるからです。データの共用は,VAX コンピュータ間,Alpha コンピュータ間, VAX コンピュータと Alpha コンピュータの間で可能です。

さらに,複数のシステム (VAX と Alpha) が同時に共用ディスク・ファイルに書き込みを行うことができます。この機能によって,OpenVMS Cluster 内の複数のシステムが 1 つのシステム・ディスクを共用でき,複数のシステムが同じディスクからブートでき,オペレーティング・システム・ファイルやユーティリティを共用して,ディスク領域を節約し,システム管理を単純化することができるのです。

注意: テープの場合,複数のシステムが同時に 1 つのテープ・ファイルにアクセスすることはできません。

6.1.1 アクセス方式

ビジネス・ニーズに応じて,特定のデバイスへのアクセスを,そのデバイスに直接接続されている (ローカルな) コンピュータのユーザに制限しなければならないことがあります。また,ディスクやテープをサービス対象のデバイスとして設定して, OpenVMS Cluster 内のすべてのコンピュータのどのユーザでも,そのデバイスを割り振り,利用できるようにすることもできます。

表 6-1 は,さまざまなアクセス方式を示しています。

表 6-1 デバイスへのアクセス方式
方式 デバイスへのアクセス 説明
ローカル デバイスに直接接続されているコンピュータに制限される。 他のシステムにサービスを提供するように設定できる。 図 6-3
デュアル・ポート 2 つの物理ポートのいずれかを使用する。各ポートは別々のコントローラに接続することができる。1 台のコントローラで障害が発生しても,他のコントローラにフェールオーバすることで,デュアル・ポート・ディスクは動作を続行できる。 いずれかのコントローラが使用可能な限り,デバイスはクラスタ内のすべてのシステムからアクセスできる。 図 6-1
共用 複数のシステムへの共用インターコネクトを介してアクセスできる。 共用インターコネクトに接続されていないシステムにサービスするように設定できる。 図 6-2
サービス MSCP または TMSCP サーバ・ソフトウェアがロードされているコンピュータを通じてアクセスできる。 MSCP および TMSCP サービスについては, 第 6.3 節 を参照。 図 6-2図 6-3
デュアル・パス 複数のパスを通じてアクセスできる。 1 つのパスで障害が発生した場合,デバイスは他のパスを介してアクセスされる。割り当てクラスを使用することが必要である (パスに依存しない固有の名前を提供する方法については, 第 6.2.1 項 を参照)。 図 6-2
注意: 個々のディスクへのパスは,一部のノードからはローカルであり,他のノードからはサービスされるように見えることがある。



6.1.2 例

ストレージ・サブシステムが特定のシステムに直接接続されている場合は,ホスト・システムに依存するため,サブシステムの可用性は低下します。このような構成の可用性を向上するために, OpenVMS Cluster システムではデュアル・ポート,デュアル・パス, MSCP サービス,TMSCP サービスがサポートされています。

図 6-1 では,デュアル・ポート構成を示しています。この構成には,2 台のコンピュータにディスクが別々に接続されています。どちらか一方のコンピュータが使用可能である限り,クラスタ内の他のシステムからディスクにアクセスできます。

図 6-1 デュアル・ポート・ディスク


注意: Volume Shadowing for OpenVMS を使用して,ディスクをシャドウイングすることもできます。デュアル・ポートとシャドウイングによって提供されるシステム障害からの自動的な回復機能は,ユーザにとって透過的であり,オペレータの介入は必要ありません。

図 6-2 は,このデュアル・パス SCSI および LAN 構成を示しています。ディスク・デバイスには,共用 SCSI インターコネクトを通じてアクセス可能です。また,LAN 上のクライアント・ノードは, MSCP サービスを介してディスク・デバイスにアクセスできます。

規則: デュアルパスの DSA ディスクは CPU に直接接続されているため,システム・ディスクとして使用できません。デバイスは一度に 1 つのコントローラにしか接続されないので,1 台のサーバ・ノードだけが,デバイスのローカル接続を使用できます。 2 番目のサーバ・ノードは MSCP (または TMSCP サーバ) 経由でデバイスにアクセスします。デバイスを現在提供しているコンピュータに障害がある場合,他のコンピュータが障害を検出し,そのデバイスをローカル接続から使用できなくします。それによって,そのデバイスはクラスタでそのまま使用できます。

図 6-2 デュアル・パス・ディスク


デュアル・パス・ディスクまたはデュアル・パス・テープは,以下の条件が満たされる場合,クラスタに対してデバイスをサービスする 2 台のコンピュータ間でフェールオーバすることができます。

  • 各コンピュータで同じデバイス・コントローラ名が生成され,同じ割り当てクラスが指定されていること。この結果,デバイスは両方のシステムで同じ名前を持つようになります (割り当てクラスについては, 第 6.2.1 項 参照)。

  • 2 台のコンピュータで,ディスクに対して MSCP サーバを実行しているか,テープに対して TMSCP サーバを実行しているか,またはその両方のサーバを実行していること。

警告: これらの要件を満たさないと,データの整合性が損なわれる可能性があります。

図 6-3 に示すように, HSC ストレージ・デバイスまたは HSJ ストレージ・デバイスは, 2 つのストレージ・サブシステム間でデュアル・ポート接続に設定することができます。

図 6-3 クラスタ・アクセス可能デバイスを含む構成


設計により,HSC および HSJ ディスクとテープは,同じスター・カプラに接続されている OpenVMS Cluster のすべてのノードから直接アクセスできます。したがって,デバイスがデュアル・ポート接続になっている場合,自動的にデュアル・パスにもなります。CI によって接続されているコンピュータは,デバイスに接続されているいずれかのサブシステムを通るパスによって,デュアル・ポート HSC デバイスまたは HSJ デバイスにアクセスできます。どららかのサブシステムで障害が発生しても,アクセスはもう一方のサブシステムにフェールオーバされます。

注意: フェールオーバで使用されるパスを制御するには,特定のパスを介してディスクへのアクセスが強制的に行われれように,優先パスを指定することができます。優先パス機能については, 第 6.1.3 項 を参照してください。

6.1.3 優先パスの指定

RA シリーズ・ディスクや MSCP サーバを介してアクセスされるディスクも含めて,DSA ディスクに対して優先パスの指定がサポートされます (テープの場合,この機能は使用できません)。優先パスがディスクに対して指定されると, MSCP ディスク・クラス・ドライバは以下の目的でそのパスを使用します。

  • DCL コマンド MOUNT を使用して最初にディスクを検索し,そのディスクをオンラインにする処理

  • すでにマウントされているディスクをフェールオーバする処理

さらに,マウントされているディスクのフェールオーバを開始して,ディスクを強制的に優先パスに設定したり,MSCP サーバによってアクセスされるディスクに対して負荷バランス情報を使用することができます。

優先パスを指定するには,SET PREFERRED_PATH DCL コマンドを使用するか, $QIO 関数 (IO$_SETPRFPATH) を使用し,P1 パラメータにカウント付き ASCII 文字列のアドレス (.ASCIC) を指定します。この文字列は,HSC または HSJ のノード名であるか,優先パスとして設定される OpenVMS システムのノード名です。

規則: ノード名は,ローカル・ノードから認識される MSCP サーバを稼動している既存のノードと一致しなければなりません。

関連項目: DCL コマンド SET PREFERRED_PATH の使用方法については,『OpenVMS DCL ディクショナリ: N--Z』を参照してください。

IO$_SETPRFPATH 関数の使用方法については,『OpenVMS I/O User's Reference Manual』を参照してください。

6.2 OpenVMS Cluster ストレージ・デバイスの命名

OpenVMS オペレーティング・システムでは,デバイス名は ddcu という形式です。ただし,

  • dd は,デバイスの種類を表す定義済みコードです。

  • c は,定義済みコントローラ指定です。

  • u は,ユニット番号です。

CI デバイスまたは DSSI デバイスの場合,コントローラ指定は常に英字の A です。ユニット番号はシステム管理者が選択します。

SCSI デバイスの場合,コントローラ名は,システム構成をもとに OpenVMS で割り当てられます。ユニット番号は,SCSI バス ID とデバイスの論理ユニット番号 (LUN) によって決定されます。

デバイス名は OpenVMS Cluster 内で固有の名前でなければならず,クラスタのすべてのメンバが同じデバイスに対して同じ名前を使用しなければならないため,OpenVMS では以下に示すように,デバイス名に接頭辞が追加されます。

  • デバイスが 1 台のコンピュータに接続されている場合は,デバイス名の先頭にそのコンピュータの名前が付加されます。


    node$ddcu
    


    ただし,node はデバイスが接続されてるシステムの SCS ノード名です。

  • デバイスが複数のコンピュータに接続されている場合は,デバイス名のノード名の部分は,以下に示すように,ドル記号と数字 (使い方に応じて,ノード割り当てクラスまたはポート割り当てクラス) に変更されます。


    $allocation-class$ddcu 
    



6.2.1 割り当てクラス

割り当てクラスの目的は,一意で変化しないデバイス名を提供することです。デバイス名は共用デバイス,ファイル,データを一意に識別するために, OpenVMS Cluster 分散ロック・マネージャが OpenVMS 機能 (RMS や XQP など) と組み合わせて使用します。

複数のパスを介してストレージ・デバイスにアクセスできるような OpenVMS Cluster 構成では,割り当てクラスが必要です。割り当てクラスを使用しないと,デバイスへのアクセス・パスが変化したときに,ノード名に依存するデバイス名も変化します。

OpenVMS バージョン 7.1 より前のバージョンでは,ノード・ベースの割り当てクラスのみがありました。これを割り当てクラスと呼んでいました。 OpenVMS バージョン 7.1 で,2 番目の種類である ポート割り当てクラスが導入されました。これは単一のインターコネクトに固有のものであり,そのインターコネクトに接続されているすべてのデバイスに割り当てられます。ポート割り当てクラスは, SCSI デバイスの名前付け用に元々設計されました。これらの使用は,デバイス・タイプ (フロッピィ・ディスク, PCI RAID コントローラ・ディスク,および IDE ディスク) を追加するために拡張されて使われています。

ポート割り当てクラスを使用するかどうかは任意です。これは, 第 6.2.3 項 に示すように特定の構成で発生する可能性のある,デバイス名および構成の競合を解決できるようになっています。

以前のノード・ベースの割り当てクラスとそれよりも新しいポート割り当てクラスを区別するために,以前の割り当てクラスにノード割り当てクラスという名前がつけられました。

OpenVMS バージョン 7.2 よりも前では,同じマルチパス・デバイスに直接アクセスするノードはすべて,ノード割り当てクラスに対して 0 以外の同じ値を使用する必要がありました。 OpenVMS バージョン 7.2 で MSCP_SERVE_ALL システム・パラメータが導入されました。このシステム・パラメータで,すべてのディスクにサービスするか,またはノード割り当てクラスの異なるものを除外するように設定できます。

注意

SCSI デバイスが複数のホストに接続されていて,ポート割り当てクラスが使用されていない場合は,同じマルチパス・デバイスに直接アクセスするノードはすべて, 0 以外の同じノード割り当てクラスを使用する必要があります。

マルチパス MSCP コントローラにも割り当てクラス・パラメータがあり,接続されているノードの割り当てクラスに対応するように設定されます (割り当てクラスが一致しない場合,ノードに接続されているデバイスをサービスすることができません)。

6.2.2 ノード割り当てクラスの指定

ノード割り当てクラスは,コンピュータ,HSC または HSJ コントローラ,DSSI ISE に割り当てることができます。ノード割り当てクラスは 1〜255 の数値であり,システム管理者が割り当てます。

ノード割り当てクラスのデフォルト値は 0 です。ノード割り当てクラスの値として 0 が適切なのは,ローカルのシングル・パス・ディスクをサービスする場合だけです。ノード割り当てクラス 0 が割り当てられた場合,サービスされるデバイスの名前は, node-name$device-name という構文を使用して付けられます。つまり,デバイス名の接頭辞はノード名になります。

ノード割り当てクラスの値を指定する場合,以下の規則が適用されます。

  1. サテライトをサービスする場合,サービスする側のコンピュータとコントローラに 0 以外の同じノード割り当てクラス値を割り当てなければなりません。

  2. ノード割り当てクラス値が 0 以外のコンピュータ上のすべてのクラスタ・アクセス可能デバイスには,クラスタ全体で固有の名前を与えなければなりません。たとえば,2 台のコンピュータのノード割り当てクラスの値が同一である場合,その 2 台のコンピュータの両方に DJA0 という名前のローカル・ディスクまたは MUA0 という名前のテープを接続することはできません。この規則は HSC および HSJ サブシステムにも適用されます。

システム管理者は,ディスクとテープのそれぞれにノード割り当てクラスを割り当てます。ディスクのノード割り当てクラスとテープのノード割り当てクラスは,同一でなくてもかまいません。

ノード割り当てクラス名は以下のように作成されます。


$disk-allocation-class$device-name
$tape-allocation-class$device-name

警告: ノード割り当てクラス値およびデバイス・ユニット番号を正しく設定しないと,データの整合性が侵される可能性があり,ロックの競合が発生して,正常なクラスタ動作ができなくなることがあります。 図 6-4 では, CI 構成でクラスタ・デバイス名を指定する方法を示しています。

図 6-4 HSC コントローラ間でデュアル・パス接続されているディスクとテープ


この構成で,以下のことに注意してください。

  • ディスク・デバイス名 ($1$DJA17) とテープ・デバイス名 ($1$MUB6) は,2 つのコントローラのノード割り当てクラスを使用して作成されています。

  • 2 台のコンピュータのノード割り当てクラスは必要ありません。

  • JUPITR と SATURN は,VOYGR1 または VOYGR2 を通じてディスクやテープにアクセスできます。

  • ディスクとテープの割り当てクラスが同一である必要はありません。

ノード割り当てクラス 1 のコントローラが 1 台使用できなくなっても,ユーザは他のコントローラを通じてそのノード割り当てクラスによって指定されるデバイスにアクセスできます。

図 6-6 では, 図 6-4 をもとに,JUPITR コンピュータと NEPTUN コンピュータを通じてデバイス $1$DUA17 と $1$MUA12 にアクセスするサテライト・ノードを追加しています。この構成では,デバイスへのアクセス・パスとは無関係に,サテライト・ノードが統一されたデバイス名を使用することができるように, JUPITR コンピュータと NEPTUN コンピュータにノード割り当てクラスが必要です。

注意: すべてのサーバ,HSC,HSJ サブシステム,DSSI ISE に対して同じノード割り当てクラス値を使用すれば,通常,システム管理は簡単になります。1〜255 の数値を任意に選択できます。しかし,ノード割り当てクラス値を変更するには,クラスタ全体をシャットダウンして,リブートしなければなりません ( 第 8.6 節 を参照)。コンピュータとコントローラに対して共通のノード割り当てクラスを使用する場合は,すべてのデバイスに固有のユニット番号が割り当てられていることを確認してください。


目次 索引

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