構成および管理の観点では,TruCluster Server の最も重要な機能は,ファイルおよびディレクトリに対するネームスペースをクラスタ単位に 1 つだけ作成することです。このネームスペースにより,すべてのファイル・システムが,どのクラスタ・メンバからも同じように見えます。また,ほとんどの構成ファイルは 1 つだけ存在します。一部の例外を除き,クラスタのディレクトリ構造は,スタンドアロン・システムの場合と同じです。
クラスタ単位のネームスペースは,クラスタ・ファイル・システム (CFS) やデバイス要求ディスパッチャなどの,TruCluster Server テクノロジによって実現されています。CFS やデバイス要求ディスパッチャについては,この章で後述します。
この章では,次の事項について説明します。
サポートされているファイル・システム (2.1 節)
クラスタ・ファイル・システム (CFS) (2.2 節)
デバイス要求ディスパッチャ (2.3 節)
CFS とデバイス要求ディスパッチャについての FAQ (2.4 節)
コンテキスト依存シンボリック・リンク (CDSL) (2.5 節)
デバイス名 (2.6 節)
ワールドワイド ID (2.7 節)
クラスタと LSM (Logical Storage Manager) (2.8 節)
クラスタ内でストレージ・ソフトウェアがどのように動作するかを理解するには,まず,図 2-1
を参照してください。この図は,クラスタ内で階層を形成しているストレージ・ソフトウェアをわかりやすく示しています。デバイス要求ディスパッチャは,物理デバイスへのすべての入出力を制御しています。すべてのクラスタ入出力は,このサブシステムを通ります。また,CFS は AdvFS (Advanced File System) などの既存のファイル・システムより上の層にあります。
図 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 つ (provolone
と
polishham
) で名前が
deli
というクラスタの SysMan Station ハードウェア・ビューを示します。
図 2-2: クラスタのハードウェア・ビュー
TruCluster Server は,Tru64 UNIX バージョン 4.0 シリーズのオペレーティング・システム向けの TruCluster 製品で提供されていた,次の可用性および性能に関する機能を備えています。
TruCluster Server を使用すると,TruCluster Available Server Software および TruCluster Production Server 製品と同様に,クラスタのどのメンバからでもディスク・データにアクセスできる,可用性の高いサービスを実現できます。
Tru64 UNIX 上で実行されるアプリケーションはすべて,可用性の高いシングル・インスタンス・アプリケーションとしてクラスタ内で実行できます。必要なリソースや現在のメンバ自体が利用できなくなると,アプリケーションは自動的に他のクラスタ・メンバに再配置 (フェイルオーバ) されます。
TruCluster Server を使用すると,TruCluster Production Server Software 製品と同様に,分散型アプリケーションの構成要素を並列に実行できます。これにより,クラスタ特有の同期メカニズムと性能の最適化という利点を生かしつつ,可用性を高めることもできます。
クラスタ・ファイル・システム (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 では,次の性能強化が行われています。
直接入出力: ファイル (フラグ
O_DIRECTIO
を使ってオープンする) への直接入出力が使用可能な場合は,ディスク・ストレージに対する読み取り/書き込み要求が,AdvFS および CFS のキャッシングをバイパスし,直接メモリ・アクセスを使用して実行されます。これにより,キャッシングとファイル領域の同期化を行うデータベース・アプリケーションの入出力の性能が向上します。CFS サーバのローカルなアプリケーションと同様にリモート CFS クライアントも,直接入出力用にオープンされたファイル・システムに対する読み取り/書き込みを直接的に行うことができます。どのメンバの入出力要求でも,ファイルに対する直接入出力はクラスタ・インターコネクトを経由して CFS サーバへは転送されません。
ダイレクト・アクセス・キャッシュド・リード: AdvFS ファイル・システムでは,サイズが 64 K バイト以上の場合の読み取り性能が向上しました。CFS では,ダイレクト・アクセス・キャッシュド・リード機能により,同時に複数のクラスタ・メンバがストレージから直接読み取りを行うことができるようになりました。ダイレクト・アクセス・キャッシュド・リードでは,読み取り要求を出したクラスタ・メンバがそのファイル・システムのあるストレージに直接接続されている場合には,クラスタ・インターコネクトを経由して CFS サーバへアクセスしに行くのではなく,そのストレージに直接アクセスします。この機能拡張により,サーバがメタデータとログを更新するという今までのファイル・システムのモデルをそのまま活かしながら,CFS クライアントからストレージに対して直接入出力できるようにすることで,クラスタ・インターコネクトの負荷を削減しました。
64 K バイト以上のファイルを読み書きするアプリケーションでは,そのファイルからデータを読み込む際にダイレクト・アクセス・キャッシュド・リードを使用します。たとえば,次のようなアプリケーションは,ダイレクト・アクセス・キャッシュド・リードの効果が期待できます。
Web サーバやプロキシ・サーバのように,ほとんどが読み取りだけを行うマルチ・インスタンス・アプリケーション。これらのアプリケーションでは,複数のクラスタ・ノードから同時に直接アクセスすることができます。
バックアップ・アプリケーション。アプリケーションがどのノードで動作しても,ファイル・システムの内容はクラスタ・インターコネクトを経由しません。
ファイル・システムのマウント。mount コマンドがあるメンバ上で発行されたときにそのメンバが対象となるストレージに接続されていなければ,そのストレージに接続されているメンバがファイル・システムの 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 にお答えします。
CFS,入出力,およびクラスタ・インターコネクト (2.4.1 項)
AdvFS 要求ブロックのキャッシング (2.4.2 項)
デバイス要求ディスパッチャとファイルのオープン (2.4.3 項)
CFS サーバの再配置 (2.4.4 項)
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)
まとめると,入出力は次の場合に,ストレージに対して直接行われます。
直接接続されているストレージに対する raw 入出力
CFS クライアントが CFS サーバと同じノードにある
O_DIRECTIO
でオープンしたファイルへのファイル入出力
64 K バイト以上のファイルの読み込み
質問: AdvFS ファイル・システムの要求ブロックは CFS クライアント・ノードでキャッシングされるのですか。
答え:
はい。
CFS クライアントはデータをキャッシングし,後書きします。
2.4.3 デバイス要求ディスパッチャとファイルのオープン
質問: プログラムでファイルをオープンした場合,デバイス要求ディスパッチャはどの過程で処理に関わるのですか。
答え:
open()
では CFS しか関係しません。read()
と
write()
では CFS とデバイス要求ディスパッチャが関係してきます。その際,デバイス要求ディスパッチャが関係するのは,read()
の場合は CFS の読み込むキャッシュに必要内容を置かなければならないときであり,また,write()
の場合は CFS の書き込むキャッシュを空にしなければならないときです。
2.4.4 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
パーティション |
デバイス名スペシャル・ファイルに割り当てられるサフィックスは,デバイスのタイプによって次のように変わります。
ディスク --
一般に,ディスク・デバイス・ファイル名は,ベース名と 1 文字のサフィックス (a
〜
z
) で構成されます (たとえば,/dev/disk/dsk0a
)。ディスクでは,a
〜
h
を使用してパーティションを識別します。省略時には,フロッピィ・ディスクおよび CD-ROM デバイスでは文字
a
および
c
のみを使用します (たとえば,floppy0a
,cdrom1c
)。
raw デバイス名用として,同じデバイス名がディレクトリ
/dev/rdisk
にもあります。
テープ --
テープ・デバイス・ファイル名は,ベース名とサフィックスで構成されます。このサフィックスは,文字
_d
の後に 1 桁の数字を付加したものです (たとえば,tape0_d0
)。このサフィックスは,/etc/ddr.dbase
ファイルのデバイスのエントリに応じた,テープ・デバイスの密度を表します。
例を次に示します。
デバイス | 密度 |
tape0 |
省略時の密度 |
tape0c |
省略時の密度 (圧縮あり) |
tape0_d0 |
/etc/ddr.dbase
内のエントリ 0 に対応する密度 |
tape0_d1 |
/etc/ddr.dbase
内のエントリ 1 に対応する密度 |
テープ用デバイス・スペシャル・ファイルの新しい命名規則では,古い名前のサフィックスに対して,次に示すような新しい名前のサフィックスが対応します。
古いサフィックス | 新しいサフィックス |
l
(低) |
_d0 |
m
(中) |
_d2 |
h
(高) |
_d1 |
a
(代替) |
_d3 |
テープのデバイス名は 2 セットあり,どちらも新しい命名規則に準拠しています。
--巻き戻しのあるデバイスは
/dev/tape
ディレクトリにあり,巻き戻しのないデバイスは
/dev/ntape
ディレクトリにあります。/etc/ddr.dbase
ファイルの内容を見ると,どちらのデバイス・スペシャル・ファイルを使用するかを判断できます。
Tru64 UNIX には,デバイス名を識別するためのユーティリティがあります。たとえば,次の
hwmgr
コマンドを使用すると,クラスタ内のデバイスおよびデバイスの階層に関する情報がそれぞれ表示されます。
# hwmgr -view devices -cluster # hwmgr -view hierarchy -cluster
hwmgr
コマンドを使用して,メンバのハードウェア構成をリストし,バス・ターゲット LUN 名と
/dev/disk/dskn
名の対応を表示することができます。hwmgr
コマンドについての詳細は,
hwmgr
(8)
注意
LSM (Logical Storage Manager) の命名規則は変更されていません。
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
LSM (Logical Storage Manager) を使用すると,どのクラスタ・メンバからでもすべての LSM ボリュームへ共用でアクセスできます。LSM は,物理ディスク・デバイス,論理エンティティ,およびその両者を結び付けるマッピングで構成されます。LSM はボリュームと呼ばれる仮想ディスクを,UNIX の物理ディスク上に構築します。LSM は物理ディスクとアプリケーションの間にボリュームを透過的に配置し,アプリケーションが物理ディスクではなくボリュームを操作するようにします。たとえば,物理ディスク上ではなく,LSM ボリューム上にファイル・システムを作成します。
図 2-1 ですでに示したように,LSM はデバイス要求ディスパッチャの上に階層化されています。単一のシステムで LSM を使用するのと同じように,クラスタ内で LSM が使用できます。クラスタ構成と非クラスタ構成のどちらにも同じ LSM ソフトウェア・サブセットが使用され,どのクラスタ・メンバからでも構成を変更できます。LSM は,クラスタ単位で構成の一貫性を保ちます。
クラスタ単位の基本ファイル・システムに対する LSM のサポート状況は次のとおりです。
サポート: ルート (/
),/usr
,/var
の各ファイル・システム,および,メンバのスワップ・パーティション
未サポート: クォーラム・ディスクとメンバのブート・ディスク
TruCluster Server 環境での LSM に特有の構成および使用方法については,Tru64 UNIX 『Logical Storage Manager』を参照してください。LSM の実装に関する Tru64 UNIX と TruCluster Server の違いについては,『クラスタ管理ガイド』を参照してください。