2    クラスタ単位のファイル・システム,ストレージ,デバイス名

構成および管理の観点では,TruCluster Server の最も重要な機能は,ファイルおよびディレクトリに対するネームスペースをクラスタ単位に 1 つだけ作成することです。このネームスペースにより,すべてのファイル・システムが,どのクラスタ・メンバからも同じように見えます。また,ほとんどの構成ファイルは 1 つだけ存在します。一部の例外を除き,クラスタのディレクトリ構造は,スタンドアロン・システムの場合と同じです。

クラスタ単位のネームスペースは,クラスタ・ファイル・システム (CFS) やデバイス要求ディスパッチャなどの,TruCluster Server テクノロジによって実現されています。CFS やデバイス要求ディスパッチャについては,この章で後述します。

この章では,次の事項について説明します。

クラスタ内でストレージ・ソフトウェアがどのように動作するかを理解するには,まず,図 2-1 を参照してください。この図は,クラスタ内で階層を形成しているストレージ・ソフトウェアをわかりやすく示しています。デバイス要求ディスパッチャは,物理デバイスへのすべての入出力を制御しています。すべてのクラスタ入出力は,このサブシステムを通ります。また,CFS は AdvFS (Advanced File System) などの既存のファイル・システムより上の層にあります。

図 2-1:  クラスタでのストレージ・ソフトウェア階層

2.1    サポートされているファイル・システム

表 2-1 に,サポートされているファイル・システムの要約を示します。

表 2-1:  クラスタでサポートされているファイル・システム

タイプ サポート方法 障害の特性
AdvFS (Advanced File System) 読み取り/書き込み ファイル・ドメインのサービスは,そのファイル・システムの置かれているストレージに接続しているかしていないかを基にして選ばれるメンバが行う。メンバに障害が発生すると,CFS はそのドメインに対して新しいサーバを選択する。パスに障害が発生すると,CFS はそのストレージへの代替デバイス要求ディスパッチャ・パスを使用する。
CD-ROM ファイル・システム (CDFS) 読み取り専用 デバイスに直接接続されたメンバが,CD-ROM デバイスに対する読み取り専用アクセスのサービスを行う。TruCluster Server は共用バス上の CD-ROM デバイスをサポートしていないため,デバイスが接続されているメンバに障害が発生すると,他のメンバがサービスを引き継いだ場合でも,CD-ROM デバイスはアクセス不能となる。障害が発生していたメンバがクラスタに復帰すると,そのデバイスが再度アクセス可能となる。
DVD-ROM ファイル・システム (DVDFS) 読み取り専用 デバイスに直接接続されたメンバが,DVD-ROM デバイスに対する読み取り専用アクセスのサービスを行う。TruCluster Server は共用バス上の DVD-ROM デバイスをサポートしていないため,デバイスが接続されているメンバに障害が発生すると,他のメンバがサービスを引き継いだ場合でも,DVD-ROM デバイスはアクセス不能となる。障害が発生していたメンバがクラスタに復帰すると,そのデバイスが再度アクセス可能となる。
FFM (File-on-File Mounting) ファイル・システム 読み取り/書き込み(ローカル) ローカル・メンバだけが,マウントおよびアクセス可能。
メモリ・ファイル・システム (MFS) 読み取り/書き込み(ローカル) クラスタ・メンバは,MFS ファイル・システムを読み取り専用または読み取り/書き込みでマウントできる。ファイル・システムにはそのメンバだけがアクセス可能。リモート・アクセスは不可。フェイルオーバはない。
名前付きパイプ 読み取り/書き込み(ローカル) 読み取り側と書き込みは側は,同じメンバ上に存在しなければならない。
ネットワーク・ファイル・システム (NFS) サーバ 読み取り/書き込み 外部のクライアントは,クラスタによって NFS エクスポートされたファイル・システムをマウントする際に,省略時のクラスタ別名または /etc/exports.aliases で指定されている別名をホスト名として使用する。ファイル・システムのフェイルオーバおよび回復は,外部の NFS クライアントには見えない。
NFS クライアント 読み取り/書き込み クラスタ・メンバは,クラスタ外の NFS ファイル・システムのマウントを行うことができる。クラスタ・メンバに障害が発生すると,そのファイル・システムは自動的にアンマウントされる。クラスタが automount または autofs を使用して動作している場合,ファイル・システムの再マウントは自動的に行われる。それ以外の場合は,ファイル・システムの再マウントは手動で行う必要がある。
PC-NFS サーバ 読み取り/書き込み PC クライアントは,クラスタによって NFS エクスポートされたファイル・システムをマウントする際に,ホスト名として省略時のクラスタ別名または /etc/exports.aliases で指定されている別名を使用する。ファイル・システムのフェイルオーバと回復は,外部の NFS クライアントには見えない。
/proc ファイル・システム 読み取り/書き込み(ローカル) 各クラスタ・メンバには,そのメンバだけがアクセスできる固有の /proc ファイル・システムがある。
UNIX ファイル・システム (UFS)

読み取り専用(クラスタ単位)

読み取り/書き込み(ローカル)

読み取り専用で明示的にマウントされた UFS ファイル・システムは,そのファイル・システムの置かれているストレージに接続しているメンバが選ばれてサービスし,クラスタ全体で読み取り専用のアクセスを行うことができる。メンバに障害が発生すると,CFS はそのファイル・システムに対して新しいサーバを選択する。パスに障害が発生すると,CFS はそのストレージへの代替デバイス要求ディスパッチャ・パスを使用する。

読み取り/書き込みのサポートは MFS の読み取り/書き込みサポートと同じである。クラスタ・メンバは,UFS ファイル・システムを読み取り/書き込みでマウントすることができる。そのファイル・システムへはそのメンバだけがアクセスできる (そのメンバだけが読み取りと書き込みができる)。リモート・アクセスは不可。フェイルオーバはない。

TruCluster Server では単一システムの管理機能をクラスタに拡張しているため,Tru64 UNIX システムの管理方法が理解できていれば,TruCluster Server クラスタの管理方法も理解できていることになります。TruCluster Server には,クラスタの全メンバが共用できる単一のルート (/) ファイル・システムなど,ファイルおよびディレクトリ用のクラスタ単位のネームスペースがあります。同様に,ストレージ・デバイス用のクラスタ単位のネームスペースもあります。各ストレージ・デバイスには,クラスタ内で一意のデバイス名が 1 つあります。

SysMan のグラフィカル管理ユーティリティ群によってクラスタ環境を統合して表示することができ,個々のメンバを管理することやクラスタ全体を管理することもできます。図 2-2 に,メンバが 2 つ (provolonepolishham) で名前が deli というクラスタの SysMan Station ハードウェア・ビューを示します。

図 2-2:  クラスタのハードウェア・ビュー

TruCluster Server は,Tru64 UNIX バージョン 4.0 シリーズのオペレーティング・システム向けの TruCluster 製品で提供されていた,次の可用性および性能に関する機能を備えています。

2.2    クラスタ・ファイル・システム

クラスタ・ファイル・システム (CFS) では,すべてのファイルがすべてのクラスタ・メンバから見えて,アクセスできます。どのクラスタ・メンバからも同じように見えます。ファイルがすべてのクラスタ・メンバに接続されたデバイスに格納されているか,1 つのメンバのプライベートなデバイスに格納されているかは,関係ありません。CFS は,クラスタ・メンバ間でキャッシュの整合性を保つことにより,クラスタ内にマウントされているファイル・システムの見え方が常にすべてのメンバで同じであることを保証します。

CFS から見ると,1 つのクラスタ・メンバがクラスタ全体に対して,各ファイル・システムや AdvFS ドメインについてのサービスを行っているように見えます。どのクラスタ・メンバも,クラスタ内のどのデバイス上にあるファイル・システムであっても,サービスを行うことができます。クラスタのブート時にマウントされたファイル・システムについては,そのファイル・システムに最初にアクセスしたクラスタ・メンバがサービスを行います。つまり,1 つのクラスタ・メンバのプライベートなバスに接続されているデバイスのファイル・システムについては,そのメンバがサービスを行うことになります。

このクライアント/サーバ・モデルでは,1 つのクラスタ・メンバが,あるドメインではクライアントになり,他のドメインではサーバになります。また,メンバの役割がクライアントかサーバかを切り替えることもできます。たとえば,/usr/sbin/cfsmgr コマンドをオプションなしで入力すると,ドメインおよびファイル・システムの名前,それぞれがマウントされている位置,それぞれのサーバの名前,サーバの状態が返されます。この情報を使用して,ファイル・システムを他の CFS サーバに再配置し,クラスタ内の負荷をバランスさせることができます。

CFS は,X/Open および POSIX のファイル・システム・アクセスに関するセマンティクスに従っているため,ファイル管理インタフェースおよびユーティリティは,スタンドアロン・システムと同じように動作します。

図 2-3 は,共用バス上のディスクにあるファイル・システムと,それらを結合したクラスタ・ディレクトリ構造の関係を示しています。各メンバは固有のブート・パーティションからブートしますが,その後,そのファイル・システムを,クラスタ単位のネームスペースにある boot_partition マウント・ポイントにマウントします。この図は,クラスタ内のファイル・システムの見え方が,どのクラスタ・メンバでも同じになることを示す一例です。物理的な構成は,他にも多数考えられます。また,実際のクラスタには,ルート (/),/usr/var などの重要なファイル・システムをミラーリングするためのストレージが追加されています。

図 2-3:  すべてのクラスタ・メンバからファイル・システムを使用できるようにする CFS

CFS では,次の性能強化が行われています。

詳細は,『クラスタ管理ガイド』を参照してください。

2.3    デバイス要求ディスパッチャ

TruCluster Server クラスタでは,デバイス要求ディスパッチャ・サブシステムが,物理デバイスへの入出力をすべて制御します。すべてのクラスタ入出力は,このサブシステムを経由します。このサブシステムでは,単一システムによるオープンだけが認められているので,デバイスをオープンできるのは一度に 1 つのプログラムだけとなります。デバイス要求ディスパッチャにより,物理ディスクおよびテープ・ストレージは,そのストレージがクラスタ内で物理的に存在する位置に関係なく,全クラスタ・メンバから使用できるようになります。デバイス要求ディスパッチャは,新しいデバイス命名モデルを使用して,クラスタ全体でデバイス名の一貫性を保ちます。これにより,非常に柔軟にハードウェアを構成できるようになります。メンバは,ディスクがつながっているバスに直接接続されていなくても,そのディスクのストレージにアクセスできます。

デバイス要求ディスパッチャは,必要に応じてクライアント/サーバ・モデルを使用します。CFS はファイル・システムや AdvFS サーバ・ドメインのサービスを行いますが,デバイス要求ディスパッチャは,ディスク,テープ,CD-ROM ドライブなどのデバイスに対するサービスを行います。CFS のクライアント/サーバ・モデルでは,1 つのクラスタ・メンバがクラスタ全体に対して各ファイル・システムまたは AdvFS ドメインのサービスを行いますが,デバイス要求ディスパッチャでは,同時に動作する多数のサーバを使用することができます。

デバイス要求ディスパッチャ・モデルでは,クラスタ内のデバイスはサーバの 1 つに接続されている入出力デバイスか,ダイレクト・アクセス入出力デバイスです。サーバの 1 つに接続されているデバイス (テープ・デバイスなど) は,1 つのメンバ,つまりそのデバイスのサーバからのアクセスだけをサポートします。ダイレクト・アクセス入出力デバイスは,複数のクラスタ・メンバからの同時アクセスをサポートします。共用バス上のダイレクト・アクセス入出力デバイスには,そのバス上にあるすべてのクラスタ・メンバがサービスを行うことができます。

drdmgr コマンドを使用すると,デバイスのデバイス要求ディスパッチャの状態を調べることができます。次の例では,dsk6 デバイスが共用バス上にあり,3 つのクラスタ・メンバがサービスを行っています。

# drdmgr dsk6
 
   View of Data from member polishham as of 2000-07-26:10:52:40
 
                   Device Name: dsk6
                   Device Type: Direct Access IO Disk
                 Device Status: OK
             Number of Servers: 3
                   Server Name: polishham
                  Server State: Server
                   Server Name: pepicelli
                  Server State: Server
                   Server Name: provolone
                  Server State: Server
            Access Member Name: polishham
           Open Partition Mask: 0x4 < c >
  Statistics for Client Member: polishham
     Number of Read Operations: 737
    Number of Write Operations: 643
          Number of Bytes Read: 21176320
       Number of Bytes Written: 6184960
 

デバイス要求ディスパッチャは,文字型ディスク・デバイスとブロック型ディスク・デバイスの両方へのクラスタ単位のアクセスをサポートしています。 TruCluster Server 構成内の raw ディスク・デバイス・パーティションへのアクセスは,Tru64 UNIX のスタンドアロン・システムと同じ方法で行います。 つまり,/dev/rdisk ディレクトリ内のデバイス・スペシャル・ファイルの名前を使用します。

注意

TruCluster Server バージョン 5.0 より前は,ストレージへのこのようなレベルの物理アクセスを可能にするためには,クラスタ管理者が特別な DRD (Distributed Raw Disk) サービスを定義しなければなりませんでした。 このアクセス方法は,TruCluster Server バージョン 5.0 からはクラスタ・アーキテクチャ内に組み込まれており,すべてのクラスタ・メンバが自動的に利用できます。

2.4    CFS とデバイス要求ディスパッチャに関する FAQ

ここでは,CFS とデバイス要求ディスパッチャに対する FAQ (Frequently Asked Questions: よく尋ねられる質問) のうち,次の内容に関する FAQ にお答えします。

2.4.1    CFS,入出力,およびクラスタ・インターコネクト

質問: ダイレクト・アクセスが可能な入出力ディスクの接続されている共用バスで入出力を行った場合,その入出力はクラスタ・インターコネクトを通らなければなりませんか。

答え: raw 入出力 の場合,そのデバイスに直接接続されているノードは,デバイス要求ディスパッチャを介してそのデバイスにある raw パーティションへ直接アクセスします (デバイスのサーバになっているノードは drdmgr コマンドで調べられます)。

ファイル・システムではなく,直接接続されているブロック・ストレージへブロック入出力を行うと,その入出力は,そのデバイス・スペシャル・ファイルの CFS サーバが処理します。

通常のファイル入出力では,読み取りを行うファイルのサイズが 64 K バイトより小さい場合,そのファイル・システムの CFS サーバが処理します。CFS クライアントがそのファイル・システムの CFS サーバでない場合,要求はクラスタ・インターコネクトを通して,そのファイル・システムの CFS サーバになっているノードへ送られ,その CFS サーバ・ノードのデバイス要求ディスパッチャに渡されます。ある CFS サーバ・ノードへ送られた要求が,そのノードとは別のノードに存在するデバイス要求ディスパッチャへ転送されることはありません (非同期書き込みの場合は,いったんメモリに書き込まれた後,後書きによって,サーバへ一括して送られます)。

読み取るファイルが 64 K バイト以上であれば,CFS クライアントはダイレクト・アクセス・キャッシュド・リードを使って,そのファイルをストレージから直接読み取ることができます。

また,プログラムで O_DIRECTIO を指定してファイルをオープンすると,その読み取り/書き込み要求に対するディスク・ストレージへの入出力は,AdvFS や CFS でキャッシングされることなく,直接メモリ・アクセスによって実行されます。ファイルに対する直接入出力は,どのメンバがその入出力要求を出したかに関係なく,クラスタ・インターコネクトを通りません。

ダイレクト・アクセス・キャッシュド・リードについての詳細は,2.2 節 で説明しています。 open(2) も参照してください。

まとめると,入出力は次の場合に,ストレージに対して直接行われます。

2.4.2    AdvFS 要求ブロック・キャッシング

質問: AdvFS ファイル・システムの要求ブロックは CFS クライアント・ノードでキャッシングされるのですか。

答え: はい。 CFS クライアントはデータをキャッシングし,後書きします。

2.4.3    デバイス要求ディスパッチャとファイルのオープン

質問: プログラムでファイルをオープンした場合,デバイス要求ディスパッチャはどの過程で処理に関わるのですか。

答え: open() では CFS しか関係しません。read()write() では CFS とデバイス要求ディスパッチャが関係してきます。その際,デバイス要求ディスパッチャが関係するのは,read() の場合は CFS の読み込むキャッシュに必要内容を置かなければならないときであり,また,write() の場合は CFS の書き込むキャッシュを空にしなければならないときです。

2.4.4    CFS サーバの再配置

質問: CFS サーバの再配置はいつ行うと効果的ですか。

答え: cfsmgr コマンドの出力を使って,どのメンバが最も多くの入出力を処理しているかを調べてください。通常,再配置の目的は 1 つのノードにすべてのファイル・システムの処理が集中するのを避けることです。CFS はメモリを大量に使用しますので,すべてのファイル・システムが同じメンバで処理される事態になると,処理が遅くなることがあります。再配置の方法としては,しばらくの間入出力を監視し,どのメンバをどのファイル・システムの CFS サーバとすればよいかを決定した後,システムを適正なホストへ自動的に再配置する簡単なブート・スクリプトを (たとえば,/sbin/init.d/ に) 作成して適用するのが最も簡単です。

たとえば,2 つのメンバ (M1 と M2) からなるクラスタと 6 個のファイル・システム (A,B,C,D,E,F) を考えてみてください。入出力を監視した結果,M1 に A,D,および E を,また,M2 に B,C,および F をそれぞれ担当させた方がよいと決定したとします。この場合,M1 が A,D,および E を自分のところに再配置し,M2 が B,C,および F を自分のところに再配置するブート・スクリプトを作成します。

入出力をクラスタ・メンバの間で分散させる場合は,デバイス要求ディスパッチャではなく,CFS のレベルで分散させてください。つまり,入出力をクラスタ・メンバの間で分散させる場合は,drdmgr コマンドではなく,cfsmgr コマンドを使用してください。

2.5    コンテキスト依存シンボリック・リンク

単一のネームスペースを使用することによりシステム管理が大幅に簡略化されますが,構成ファイルやディレクトリをすべてのクラスタ・メンバと共用したくはありません。たとえば,メンバのファイル /etc/sysconfigtab にはシステムのカーネル構成要素の構成に関する情報が含まれており,その構成を使用するのはそのシステムのみでなければなりません。このため,クラスタでは,各メンバが /etc/sysconfigtab という名前のファイルの読み取り/書き込みを行うと,実際にはメンバ固有の sysconfigtab ファイルの読み取り/書き込みを行うというメカニズムを使用する必要があります。

次のような特徴を持つネームスペースを作成するために,TruCluster Server は,Tru64 UNIX バージョン 5.0 で導入されたコンテキスト依存シンボリック・リンク (CDSL) という特殊な形式のシンボリック・リンクを使用します。CDSL を使用すると,名前がクラスタ単位のファイルまたはディレクトリを表しているか,メンバ固有のファイルまたはディレクトリを表しているかには関係なく,同じ名前でファイルまたはディレクトリにアクセスできます。CDSL では,従来の命名規則を守りながら,各メンバがメンバに固有のシステム構成ファイルを読み書きできるようにしています。

CDSL には,パス名の解決時にだけ決定される値を持つ変数が含まれています。 {memb} 変数は,クラスタ内にあるメンバ固有のファイルへのアクセスに使用されます。次の例は,/etc/rc.config への CDSL を示しています。

/etc/rc.config -> ../cluster/members/{memb}/etc/rc.config
 

CDSL のパス名を解決する際,カーネルは {memb} 変数を membern (n は現在のメンバのメンバ ID) という文字列に置き換えます。つまり,メンバ ID が 2 のクラスタ・メンバでは,パス名 /cluster/members/{memb}/etc/rc.config は,/cluster/members/member2/etc/rc.config として解決されます。図 2-4 は,{memb} と,CDSL のパス名解決の関係を示しています。

異なるクラスタ・メンバがそれぞれ異なるデータのセットで,アプリケーションのインスタンスを複数実行する場合には,CDSL が便利です。アプリケーションが CDSL を使用してメンバ固有のデータ・セットおよびログ・ファイルを保守する方法については,『クラスタ高可用性アプリケーション・ガイド』を参照してください。

図 2-4:  CDSL のパス名解決

ファイルまたはディレクトリを移動する前に,移動先の名前が CDSL と一致しないことを確認してください。移動先のファイル名が CDSL と一致する場合には,メンバ固有のファイルを保守するために特別な配慮が必要になります。たとえば,次の例に示す /etc/rc.config ファイルがあるとします。

/etc/rc.config -> ../cluster/members/{memb}/etc/rc.config
 

ファイルを /etc/rc.config に移動すると,シンボリック・リンクが実際のファイルに置き換わります。したがって,/etc/rc.config は,/cluster/members/{memb}/etc/rc.config へのシンボリック・リンクではなくなります。

mkcdsl コマンドを使用すると,システム管理者は CDSL の作成と CDSL のインベントリ・ファイルの更新ができます。cdslinvchk コマンドは,現在の CDSL インベントリを検証します。これらのコマンドについての詳細は, mkcdsl(8) および cdslinvchk(8) を参照してください。

CDSL についての詳細は,Tru64 UNIX の『システム管理ガイド 』, hier(5)ln(1)symlink(2) を参照してください。

2.6    デバイス名

ここでは,Tru64 UNIX バージョン 5.0 で導入されたデバイス命名モデルについて簡単に説明します。このデバイス命名モデルについての詳細は,Tru64 UNIX の 『ハードウェア管理ガイド』を参照してください。

デバイス名はクラスタ単位で一貫性があり,次のような特徴があります。

Tru64 UNIX バージョン 5.0 のリリースより前は,ディスク・デバイスにはディスクの入出力パスがコード化され,付与されていました。このパスには多くのデータが組み込まれており,少なくとも次のような情報が含まれていました。ディスクが接続されているコントローラへのアクセスに使用するデバイス・ドライバ,ドライバが管理するシステムのコントローラのインスタンス,コントローラごとのデバイス・ユニット ID などの情報です。

たとえば,rz デバイス・ドライバは SCSI と ATAPI/IDE の両方のデバイス・コントローラへのアクセスに使用されていました。これらのコントローラに接続されたディスクの名前は,rzn です。n は,接続されたディスクへのコントローラとユニット ID の両方を表していました。たとえば,2 番目の SCSI/ATAPI/IDE コントローラ上での SCSI ID=3 のディスクは,rz11 でした。そのディスクを 3 番目のコントローラへ移動すると,rz19 となっていました。

Tru64 UNIX バージョン 5.0 では新しいデバイス命名モデルを使用するようになりました。このモデルのデバイス名は簡単に,デバイスの種類を示す名前とインスタンス番号から構成されています。これらの 2 つの要素で,dsk0 などの,デバイスのベース名が形成されます。デバイスの新しい名前のインスタンス番号は古い名前のユニット番号に対応しません。オペレーティング・システムは,デバイスを検出すると,インスタンス番号を 0 (ゼロ) から順に割り当てます。また,最新のディスクには,ディスクを別々のものとして識別する ID があります。この機能をサポートするディスクの場合,Tru64 UNIX バージョン 5.0 はこの ID を追跡し,それを使ってディスクとデバイス名をマップするテーブルを保守します。そのため,これらのディスクの物理的接続を変更しても,そのディスクのデバイス名は変わりません。この機能により,システム管理者がシステム上でディスクを構成するときの柔軟性が大きくなります。

TruCluster 環境では,クラスタ内の各ディスクには単一の名前が与えられるので,新しいデバイス命名モデルの柔軟性は特に有益です。

注意

Tru64 UNIX は,古いスタイルのデバイス名を互換性のオプションとしてサポートしていますが,TruCluster Server は新しいスタイルのデバイス名のみをサポートしています。古いスタイルのデバイス名 (/dev の構造) に依存するアプリケーションは,新しいデバイス命名モデルを使用するように変更する必要があります。

表 2-2 に,新しいデバイス名の例を示します。

表 2-2:  新しいデバイス名の例

古い名前 新しい名前 説明
/dev/rz4c /dev/disk/dsk4c オペレーティング・システムが 5 番目に認識したディスクの c パーティション
/dev/rz19c /dev/disk/dsk5c オペレーティング・システムが 6 番目に認識したディスクの c パーティション

デバイス名スペシャル・ファイルに割り当てられるサフィックスは,デバイスのタイプによって次のように変わります。

Tru64 UNIX には,デバイス名を識別するためのユーティリティがあります。たとえば,次の hwmgr コマンドを使用すると,クラスタ内のデバイスおよびデバイスの階層に関する情報がそれぞれ表示されます。

hwmgr -view devices -clusterhwmgr -view hierarchy -cluster
 

hwmgr コマンドを使用して,メンバのハードウェア構成をリストし,バス・ターゲット LUN 名と /dev/disk/dskn 名の対応を表示することができます。hwmgr コマンドについての詳細は, hwmgr(8) を参照してください。

注意

LSM (Logical Storage Manager) の命名規則は変更されていません。

2.7    ワールドワイド ID

Tru64 UNIX は,新しいデバイス名をディスクのワールドワイド ID (WWID) に対応付けます。ディスクの WWID は一意であり,WWID をサポートするデバイスの製造元で設定されます。このため,2 台のディスクが同じ WWID を持つことはありません。WWID を使用してディスクを識別することには,2 つの意味があります。オペレーティング・システムがいったんディスクを認識すると,ディスクの /dev/disk/dsk 名は SCSI アドレスが変わっても変わりません。

ディスクを認識するこの機能により,Tru64 UNIX は,複数の SCSI アダプタを通してアクセスできるディスクの場合に,ディスクへのマルチパスをサポートできます。TruCluster Server 環境内でディスクを移動しても,ディスクのデバイス名と,ディスクへのアクセス方法は変わりません。

注意

RAID アレイ・コントローラ下のディスクの名前は,コントローラ・モジュールの WWID と,自身のバス,ターゲット,LUN の位置の両方に対応付けられます。この場合,ディスクを移動すると,そのデバイス名が変わります。ただし,hwmgr ユーティリティを使用して,このようなディスクを以前のデバイス名に対応付けることはできます。

次の hwmgr コマンドは,クラスタの WWID を表示します。

# hwmgr -get attr -a name -cluster 
 

2.8    クラスタと LSM

LSM (Logical Storage Manager) を使用すると,どのクラスタ・メンバからでもすべての LSM ボリュームへ共用でアクセスできます。LSM は,物理ディスク・デバイス,論理エンティティ,およびその両者を結び付けるマッピングで構成されます。LSM はボリュームと呼ばれる仮想ディスクを,UNIX の物理ディスク上に構築します。LSM は物理ディスクとアプリケーションの間にボリュームを透過的に配置し,アプリケーションが物理ディスクではなくボリュームを操作するようにします。たとえば,物理ディスク上ではなく,LSM ボリューム上にファイル・システムを作成します。

図 2-1 ですでに示したように,LSM はデバイス要求ディスパッチャの上に階層化されています。単一のシステムで LSM を使用するのと同じように,クラスタ内で LSM が使用できます。クラスタ構成と非クラスタ構成のどちらにも同じ LSM ソフトウェア・サブセットが使用され,どのクラスタ・メンバからでも構成を変更できます。LSM は,クラスタ単位で構成の一貫性を保ちます。

クラスタ単位の基本ファイル・システムに対する LSM のサポート状況は次のとおりです。

TruCluster Server 環境での LSM に特有の構成および使用方法については,Tru64 UNIX 『Logical Storage Manager』を参照してください。LSM の実装に関する Tru64 UNIX と TruCluster Server の違いについては,『クラスタ管理ガイド』を参照してください。