1    ファイル・システムの計画

Advanced File System (AdvFS) は HP Tru64 UNIX オペレーティング・システムの標準ファイル・システムです。 この章では,次のトピックについて説明します。

1.1    AdvFS の概要

AdvFS ファイル・システムは,従来の UNIX ファイル・システム (UFS) とは異なります。 AdvFS では,システムをシャットダウンすることなく,いつでもシステム構成を変更できます。 AdvFS は,AdvFS Utilities とともに使用して,マルチボリューム・ファイル・システムをサポートするので,システム条件の変化に応じて,ストレージを柔軟に追加/削除することが可能です。 これに加えて,LSM (Logical Storage Manager) のボリュームとストレージ・エリア・ネットワーク (SAN) を AdvFS のストレージとして使用することができます。

これに比べるとUFS モデルは柔軟性を欠きます。 各ディスク,あるいはディスク・パーティションに 1 つのファイル・システムがあります。 UFS のディレクトリ階層構造は,物理ストレージ層に密接に結び付いています。 このため,ファイル・システムの空き容量が足りなくなっても,ファイルの絶対パス名を変更しない限り他のディスクへファイルを移動することはできません。 論理ディレクトリをディレクトリ・サブツリーに分けてサブツリーを別のディスクにマッピングする作業は,慎重に考えなければなりません。 周到に計画しても,UFS モデルではディレクトリ構造の調整には限界があります。

ユーザ側の視点では,AdvFS は従来の UNIX のファイル・システムとほとんど変わりありません。 すなわち,各ユーザは mkdir コマンドでディレクトリを作成し,cd コマンドでディレクトリ間を移動し,ls コマンドでディレクトリの内容のリストを表示することができます。 また,AdvFS の論理構造とクォータ管理,およびバックアップ機能は,従来のファイル・システムの設計に基づいています。 ただし,AdvFS では newfsdumprestorefsck など,いくつかの標準的なコマンドがサポートされていないか,あるいは他のコマンドで置き換えられています。 AdvFS のコマンドとユーティリティ,および UFS のコマンドとの比較についての詳細は,付録 B を参照してください。

システム管理者は,AdvFS システムをオンライン状態に維持したまま,ファイル・システムのバックアップや再構成,およびチューニングを行うことができます。 各ユーザは,必要なファイルを誤って削除してしまった場合でも,定義済みのゴミ箱ディレクトリや AdvFS ファイルセット・クローンから,システム管理者の手を借りることなくファイルを復元できます。

1.2    ライセンス登録

AdvFS は Tru64 UNIX オペレーティング・システムの標準ファイル・システムですが,その機能を拡張する AdvFS Utilities は別ライセンスで提供されています。 したがって,AdvFS Utilities を使用するには,事前にライセンス PAK (Product Authorization Key) を登録する必要があります。 詳細については,最寄りの弊社代理店または各支店/営業所にお問い合わせください。

1.3    ファイル・システムの構造

AdvFS ファイル・システムは,ディレクトリ階層レイヤと物理ストレージ・レイヤの 2 種類の階層で構成されます。 ディレクトリ階層レイヤは,ファイル・ネーミング・スキームや,ファイルの作成およびオープン,ファイルの読み書きなどの POSIX に準拠した機能を実現します。 物理ストレージ・レイヤは,先書きログ,キャッシュ機能,ファイル割り当て,物理ディスク入出力機能を実現します。

このように独立したファイル・システム構造により,ディレクトリ階層レイヤと物理ストレージ・レイヤを別々に管理することができます。 ファイルのパス名を変えずに,定義された複数のディスク・ボリューム間でファイルを移動できます。 パス名は変わらないため,物理レベルでのこの操作はエンド・ユーザには全く影響を与えません。

AdvFS は,クラスタ構成のファイル・システムです。 クラスタの動作もまた,エンド・ユーザには全く影響を与えません。 1 つのクラスタ上で動作する AdvFS は,エンド・ユーザにとってはほとんど例外なく,1 つのノード上で動作するのと全く変わらないように見えます。

AdvFS では,ファイルセットとドメインという独自の概念を実装しており,この 2 つの概念によって二重構造のファイル・システムが実現されています。 図 1-1 は,AdvFS ファイル・システムの構造を示しています。

図 1-1:  AdvFS ファイル・システムの構造

AdvFS が使用できる各種ストレージについては,1.5 節 を参照してください。

1.3.1    ファイルセット,ドメイン,およびボリューム

ファイルセットとは,従来の UNIX ファイル・システムの論理構造に従ったディレクトリ名とファイル名の階層構造であり,これがシステムにマウントする対象になります。 AdvFS は従来のファイル・システムより優れており,ドメインと呼ばれる共通のストレージ・プールを共用する複数のファイルセットを作成することができます。 AdvFS ファイル・システムの構成についての詳細は,1.4.1 項 を参照してください。 ファイルセットの操作についての詳細は,2.4 節 を参照してください。

ドメインは物理ストレージ層を表し,ディレクトリ構造とは別に管理されます。 ドメインでは,ディレクトリ構造に影響を与えないでボリュームの追加/削除を行うことができます。 ドメイン管理についての詳細は,2.3 節を参照してください。

ボリュームは,UNIX ブロック・デバイスと同様に動作するメカニズムです (1.4.2 項を参照)。 最初に作成された時点では,どのドメインも単一ボリュームで構成されています。 オプションの AdvFS Utilities を使うと,1 つ以上のボリュームを追加して,単一ボリューム・ドメインをマルチボリューム・ドメインに変換することができます。

1.3.2    トランザクション・ログ・ファイル

AdvFS ファイル・システムは,先書きログを採用してファイル・システムの完全性を確保する,ログ・ベースのファイル・システムです。 先書きログでは,実際の変更をディスクに書き込む前に,メタデータ (ファイル・システム構造) の変更がトランザクション・ログ・ファイルにすべて書き込まれます。 トランザクション・ログ・ファイルの内容は,一定間隔でディスクに書き込まれます。

ドメインを作成すると,AdvFS によって対応するトランザクション・ログ・ファイルが 1 つ作成されます。 クラッシュから回復する際,AdvFS はトランザクション・ログ・ファイルを読み取り,ファイル・システム・トランザクションの状態を確認します。 完了しているトランザクションはすべてディスクに書き込まれ,完了していないトランザクションは実行が取り消されます。 回復速度を左右するのは,ファイル・システム内のデータ量ではなく,ディスクに書き込まれていないトランザクション・ログのレコードの数です。 回復は通常,数秒で終わります。 従来の UNIX ファイル・システムでは,fsck ユーティリティを使用してシステム障害から回復します。 fsck ユーティリティでは,大容量のファイル・システムの検査と修復には数時間を要する場合があります。

省略時の設定では,ファイル・システム構造のみがロギングされます。 ただし,ファイル・データをロギングするように選択し,システムがストレージに書き込みを行う方法を変更することもできます (5.5 節を参照)。 データ・ロギングを有効にしておくと,システム・クラッシュが発生しても内部的にファイルの整合性が維持されますが,システムの性能が低下する可能性があります。

1.3.3    ファイル・ストレージの割り当て

ファイルは静的なものではなく,時間の経過とともに必要な容量が変化します。 スペースを過度に割り当てず,ディスク上で連続的にファイルを配置できるように,AdvFS は独自のファイル・ストレージ割り当てスキームを使用します。

ファイル・ストレージ割り当てに際しては,以下のような機能が使用されます。

1.4    AdvFS ファイル・システムの構成

構成の計画段階で,/ (ルート),/usr,および /var ファイル・システムを AdvFS に設定することを検討してください。 ルートと /usr に AdvFS を使用すれば,構成の柔軟性が高まるとともに,システム障害時のダウン時間を大幅に短縮させることができます。

従来の UFS 構成と同じように,ドメインごとにパーティション (ボリューム) が 1 つで,各ドメインにはファイルセットが 1 つあるという形式で AdvFS を設定できます。 オプションの AdvFS Utilities を利用できる場合は,スペースが必要になった時点でボリュームを追加して (ボリュームが 1 つに制限されているローカルのルート・ファイル・システムを除く),既存のドメインのサイズを大きくすることができます。 その際,既存の構成を変更する必要はありません。

1.4.1    ドメインとファイルセットの構成

複数のファイルセットからなる 1 つのドメインを作成することもできますし,それぞれのファイルセットについてドメインを作成することもできます。 また,これら 2 つ方法を取り混ぜてシステムを構築することもできます。 AdvFS Utilities を利用できる場合,ドメインを複数のボリュームに分散させることもできます。

十分な数のドライブを利用できる場合,1 つのドメインに1 つのディスクを使用してください。 ドメインには,同じディスク上のいくつかのパーティション (たとえば,abgh など) を追加するよりも,1 つのパーティション (通常パーティション c) を追加することをお勧めします。

パーティションを異なるドメインに分割しないでください。 たとえば,パーティション a をあるドメインに追加し,パーティション b を別のドメインに追加しないでください。

同じタイプおよび同じ速度のディスクを複数使用する場合には,一般的にこれらの各ディスクにドメインを分散させた方が,効率化を図ることができます。 たとえば,独立した 3 つのディスク・ボリュームを持つドメインは,1 つのディスク上に 3 つのパーティションを持つドメインよりも効率的です。 これは,後者の構成では,I/O パスが 1 つしかないためです。

複数のドメインを作成すると,物理リソースをより自由に制御できるようになります。 ドメインを,組織内で意味のあるまとまり,たとえば,特定のプロジェクト,ユーザのグループ,部門,または事業所ごとに使用するように作成することができます。 たとえばドメインを,組織内のエンジニアリング,財務,人事などの部門ごとに作成することができます。

データ管理アプリケーション・プログラミング・インタフェース (DMAPI) を使用可能にしたドメイン (付録 D) では,1 つのファイルセットしか使用できません。

表 1-1 に,各種構成の長所と短所を示します。

表 1-1:  ドメインとファイルセットの各種構成の比較

構成 長所 短所
ディスク全体を 1 つのドメインに使用。 小さなパーティションが複数の物理デバイスに分散していない。 効率がよい。 デバイスの I/O ストリームは共有されない。 大きなボリューム上に小さなドメインがある場合,スペースを無駄に使う。
ドメインが,1 つのボリュームにではなく複数のボリュームにわたって構成されている (Advanced Utilities が必要)。 I/O 負荷を分散。 スループットが向上。 ボリュームの 1 つに障害が発生すると,ドメイン全体にアクセスできなくなる。
同じ数のボリューム上に,1 つの大きなドメインではなく,小さなドメインが複数存在。 復旧が速い。 スループットが向上。 いくつかの管理作業を省略可能。 管理上のオーバヘッドが増える可能性がある。
ドメイン上に 1 つの大きなファイルセットではなく,多数のファイルセットが存在。 個々のファイルセットに対して限界値を設けることができ,資源をより細かに制御できる。 管理上のオーバヘッドが増える。 あるユーティリティを実行するのにすべてのファイルセットをマウントしなければならない場合がある。
高速ボリュームまたは輻輳のないボリューム上にトランザクション・ログがある。 ログにより I/O のボトルネックが発生しない。 ハードウェアのコストがかかる。
ルート・ファイルセットを AdvFS として構成。 システム・クラッシュの後の復旧が速い。 なし

どのファイル・システムを使用しているかは,次の方法で調べることができます。

第 5 章 に,ファイル・システムを最適化する方法について詳しく説明しています。 『システムの構成とチューニング』 に,ファイル・システムの計画と構成についての詳細なガイドラインがあります。 グラフィカル・ユーザ・インタフェースを使って,ドメインを構成する方法は,付録 E を参照してください。

1.4.2    ボリュームの構成

ボリュームは,ブロック特殊デバイスとなるエンティティです。 1 つのディスク・パーティション,ディスク全体,LSM により作成されたボリュームの集合体,ハードウェア RAID,または SAN などがこのエンティティに相当します。 ボリュームはそれぞれ,1 つのドメインにしか割り当てできません。 そのドメインには,ドメイン ID によって関連付けられます。 この ID は,そのボリュームの AdvFS メタデータに自動的に保存されます。 オプションの AdvFS Utilities を使用する場合,1 つのドメインに複数のボリュームを追加することができます。

AdvFS のドメインのそれぞれのボリュームには,ビットファイル・メタデータ・テーブル (BMT) とストレージ・ビットマップが存在します。 BMT にはファイルの構造に関する情報 (メタデータ) が格納されます。 ストレージ・ビットマップには,ディスクの空き状況と割り当て状況の追跡結果が記録されています。 これに加えて,各ドメインの個々のボリュームには,トランザクション・ログ・ファイルが格納されます。 これには,ディスクに書き込まれるまでのすべてのメタデータの変更が格納されます。

次の表には,AdvFS ボリューム上にドメインを構成するさまざまな方法の長所と短所を示します。

表 1-2:  AdvFS ボリュームの各種構成の比較

構成 長所 短所
ボリュームがディスク・パーティションに相当する。 ディスクの小さい領域も使用できる。 サイズの制約。 他のパーティションとの I/O の競合が発生。
ボリュームが 1 つのディスクに相当する。 1 つのパーティションを使用するよりも効率的。 サイズの制約
ボリュームが 1 つの RAID ボリューム (LSM かハードウェア) または SAN に相当する。 性能と信頼性が向上する。 利用可能な容量が増える。 コストがかかる。 LSM ライセンスか,追加のハードウェアが必要。

1.5    AdvFS のストレージの選択

ドメインを作成すると,AdvFS はそのドメインに関連付けられたブロック特殊デバイス名を用いて,ストレージを識別できるようになります。 ストレージには,直接接続されたディスク,ソフトウェア RAID ボリューム,ハードウェア RAID,および ストレージ・エリア・ネットワークなどを使用できます。

LSM,ハードウェア RAID,および SAN のボリュームを使用すると,高度なバックアップや動的ボリューム拡張などの機能を利用することができます。 LSM の詳細は,『Logical Storage Manager』 を参照してください。 ハードウェア RAID と SAN の各種製品については,http://h30097.www3.hp.com/storage/index.html を参照してください。