この章では、2 種類のファイルシステムロギング (トランザクションボリュームと UFS ロギング) の概念について説明します。 トランザクションボリュームに関連する作業の実行手順については、第19章「トランザクションボリューム (作業)」を参照してください。 UFS ロギングの詳細については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 17 章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。
この章では、次の内容について説明します。
将来の Solaris リリースでは、トランザクションボリュームは Solaris オペレーティング環境から削除される予定です。 Solaris 8 リリースからサポートされている UFS ロギングは、トランザクションボリュームと同じ機能を備えており、より高い性能を提供します。UFS ロギングでは、システム管理の要件やオーバーヘッドが軽減されます。 最適な性能と機能を得る上でこれらの利点は非常に重要です。
ファイルシステムロギングには、トランザクションボリュームを使用する方法と UFS ロギングを使用する方法の 2 種類があります。
ファイルシステムロギングとは、UFS ファイルシステムを更新する前にその変更をログに書き込む処理のことです。 ログに記録されたトランザクション情報は、後でファイルシステムに適用することができます。 たとえば、新しいディレクトリを作成する場合、mkdir コマンドは、ログに記録されてからファイルシステムに適用されます。
システムの再起動時に、不完全なトランザクションは廃棄され、操作が完結しているトランザクションは適用されます。 つまり、完結したトランザクションだけが適用されるために、ファイルシステムの整合性が常に保たれます。 したがって、fsck コマンドを使ってファイルシステムの整合性をチェックする必要はありません。
システムクラッシュが起こると、実行中のシステムコールが中断され、UFS の整合性が損なわれます。 fsck コマンドを実行せずに UFS をマウントすると、このような不整合によってシステム異常やデータの損傷が発生することがあります。
大規模なファイルシステムの整合性をチェックするには、ファイルシステムのデータを読み取り、検証する必要があるため、長い時間がかかります。 UFS ロギングを使用すれば、完結しなかったシステムコールの呼び出しによる変更は破棄されるため、起動時に UFS ファイルシステムをチェックする必要はありません。
UFS ロギングとトランザクションボリューム の機能は、ファイルシステム情報のログを維持するという点では同じです。 両者の主な違いは次のとおりです。
トランザクションボリュームではログ情報を物理的に異なるデバイスに書き込むことができるが、UFS ロギングでは、ログとファイルシステムが同じボリュームに作成されます。
UFS ロギングの性能は、どのような場合でもトランザクションボリュームよりも優れています。
UFS ロギングではルート (/) を含むあらゆる UFS ファイルシステムのログをとることができるが、トランザクションボリュームではルート (/) ファイルシステムのログをとることはできません。
将来の Solaris リリースでは、トランザクションボリュームは Solaris オペレーティング環境から削除される予定です。 Solaris 8 リリースからサポートされている UFS ロギングは、トランザクションボリュームと同じ機能を備えており、より高い性能を提供します。UFS ロギングでは、システム管理の要件やオーバーヘッドが軽減されます。 最適な性能と機能を得る上でこれらの利点は非常に重要です。
UFS ロギングを有効にするには、ファイルシステムに対して mount_ufs -logging オプションを使用するか、/etc/vfstab ファイルを編集してファイルシステムのマウントオプションに logging を追加する必要があります。 UFS ロギングを有効にしたままファイルシステムをマウントする方法の詳細については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 17 章「ファイルシステムのマウントとマウント解除 (手順)」と mount_ufs(1M) のマニュアルページを参照してください。
トランザクションボリュームの使用方法については、以降の節をお読みください。
UFS ファイルシステムのロギングを新たに使用する場合は、トランザクションボリュームではなく、UFS ロギングを使用してください。
トランザクションボリューム は、ファイルシステムのロギングを管理するためのボリュームで、本質的には UFS ロギングと同じです。 どちらの方法でも、UFS の更新をファイルシステムに適用する前にログに記録します。
トランザクションボリュームは、2 つのデバイスからなります。
ログデバイスやマスターデバイスは、物理的なスライスでも、ボリュームでもかまいません。 ただし、信頼性と可用性を高めるために、ログデバイスには RAID 1 ボリューム (ミラー) を使用するようにします。 これは、物理ログデバイスにデバイスエラーが発生すると、データが失われることがあるからです。 マスターデバイスにも、RAID 1 や RAID 5 ボリュームを使用することができます。
トランザクションボリュームにログデバイスがあれば、ロギングは、トランザクションボリュームがマウントされたときに自動的に開始されます。 マスターデバイスには、UFS ファイルシステムがあらかじめ格納されていてもかまいません (トランザクションボリュームを作成しても、マスターデバイスの内容が変更されることはありません)。 あるいは、後でトランザクションボリュームにファイルシステムを作成することもできます。 同じように、トランザクションボリュームを削除しても、マスターデバイスの UFS ファイルシステムが変更されることはありません。
トランザクションボリュームを構成したら、そのトランザクションボリュームを物理スライスや別の論理ボリュームと同じように使用できます。 トランザクションボリュームを作成する方法については、「トランザクションボリュームの作成 」を参照してください。
次の図に、マスターデバイス d3 とミラー化されたログデバイス d30 から構成されるトランザクションボリューム d1 を示します。
次の図に、ミラー化されたログデバイス d30 を共有している 2 つのトランザクションボリューム d1 と d2 を示します。 両方のマスターデバイスと共有ログデバイスはどれも RAID 1 ボリュームです。
トランザクションボリュームを使用する場合は、「トランザクションボリューム用の要件」と 「トランザクションボリュームの指針」を参照してください。
トランザクションボリュームを使用する場合は、次の要件を考慮してください。
トランザクションボリュームを作成する前に、マスターデバイスおよびログデバイスとして使用するスライスまたはボリュームを特定します。
ルート (/) 以外の任意のファイルシステムをロギングできます。
データの冗長性を確保するためにログデバイスをミラー化します。
負荷の高いディスクにログを置かないようにします。
ログには少なくとも 1M バイトの記憶領域を割り当てます。 (ログが大きければ、それだけ多くのファイルシステムのトランザクションを格納できます。) 100M バイトのファイルシステムデータごとに、1M バイトのログ領域を割り当てます (ログ領域は最大でも 64M バイトまでにします)。 ログの最大領域は 1G バイトですが、ほとんどの場合、64M バイトを超えるログ領域が必要になることはなく、領域がむだになります。
同じトランザクションボリュームのログデバイスとマスターデバイスは、入出力負荷を均一にするために異なるドライブ (できれば異なるコントローラ) 上に配置するようにします。
トランザクションボリュームは、ログデバイスを共有できます。 ただし、負荷の高いファイルシステムには独自のログを用意します。 ログデバイスを共有した場合、ある種のエラーが発生すると、ログデバイスを共有するすべてのファイルシステムを fsck コマンドでチェックしなければならないことがあります。
トランザクションボリュームを設定したら、ログデバイスをファイルシステム間で共有できます。
ログ (ログデバイス) は通常、頻繁にアクセスされます。 最適な性能を得るために、ログを使用頻度の高いディスクに置かないようにします。 また、ログをディスクの中央に配置すると、ログにアクセスするときの平均シーク時間を最小にできます。
ログサイズが大きいほど、性能が向上します。 ログサイズが大きいほど、並列性 (1 秒間に実行されるファイルシステム操作の数) が高くなります。
ログデバイスのミラー化を強くお勧めします。 デバイスエラーによってログデバイスのデータが失われると、ファイルシステムの整合性が損なわれ、ユーザの介入がなければ、fsck では修復できなくなってしまうことがあります。 マスターデバイスとして RAID 1 ボリュームを使用する方法は、データの冗長性を確保する上で有効です。
一般的にロギングが必要なのは、大規模な UFS ファイルシステムと、データの更新頻度が高い UFS ファイルシステムです。 通常は、ほとんど読み取り操作だけが行われる小規模なファイルシステムをロギングする必要はありません。
ログデバイス用のスライスがない場合でも、トランザクションボリュームを構成できます。 これは、ログデバイス用のスライスが余分にないときに、エクスポートされたファイルシステムをロギングしたい場合に有用です。 ログデバイス用にスライスが使用可能になったら、トランザクションボリュームにログデバイスを追加するだけですみます。
システムに十分な数の使用可能なスライスがない場合や、ログデバイスを共有するファイルシステム上の主な操作が書き込みではなく読み取りである場合は、ファイルシステムの間でログデバイスを共有することを検討してください。
ログデバイスを共有するマスターデバイスの 1 つがエラー状態になると、ログデバイスは変更を転送できなくなります。 この問題が起こると、ログデバイスを共有するすべてのマスターデバイスがハードエラー状態になります。
metastat コマンドを使用して、マスターデバイスやログデバイスなどのトランザクションボリュームを表示します。 デバイスごとに次の情報が表示されます。
「デバイス (Device)」はスライスまたはボリュームのデバイス名です。
「開始ブロック (Start Block)」はデバイスの開始ブロックです。
「Dbase」は、デバイスに状態データベースの複製が含まれているかどうかを示します。
次の表に、トランザクションボリュームの状態とその処置を示します。
表 181 トランザクションボリュームの状態
状態 |
説明 |
処置 |
---|---|---|
正常 (Okay) |
デバイスは正常に機能している。 マウントされているファイルシステムに対してはロギングが実行されているため、起動時にファイルシステムのチェックは行われません。 |
必要ない |
接続中 (Attaching) |
ログデバイスは、トランザクションボリュームが閉じられるかマウント解除されたときに、トランザクションボリュームに接続されます。 接続されると、デバイスは「正常 (Okay)」状態に移行します。 |
必要ない |
切断済み (Detached) |
トランザクションボリュームにはログデバイスがない。 UFS ロギングの利点は無効になっています。 |
起動時に fsck コマンドがデバイスを自動的にチェックする。 fsck(1M) のマニュアルページを参照。 |
切断中 (Detaching) |
ログデバイスは、トランザクションボリュームが閉じられるかマウント解除されたときに、トランザクションボリュームから切断されます。 切断されると、デバイスは「切断済み (Detached)」状態になります。 |
必要ない |
ハードウェアエラー (Hard Error) |
デバイスの使用中にデバイスエラーまたはパニックが発生した。 デバイスが閉じられるかマウント解除されるまで、すべての読み取りと書き込みに対して入出力エラーが返されます。 デバイスは、最初に開かれたときに「エラー (Error)」状態に移行します。 |
トランザクションボリュームを修復します。 「パニックした場合のトランザクションボリュームを回復するには」または 「ハードウェアエラー状態のトランザクションボリュームを回復するには」を参照。 |
エラー (Error) |
デバイスは読み書き可能。 ファイルシステムを読み取り専用でマウントできるが、実際には 読み取りや書き込みを行うたびに入出力エラーが返されます。読み取りや書き込みはデバイスエラーを受け取ります。 この後でデバイスエラーが起っても、デバイスは「ハードウェアエラー (Hard Error)」 状態には戻りません。 |
トランザクションボリュームを修復します。 「パニックした場合のトランザクションボリュームを回復するには」または 「ハードウェアエラー状態のトランザクションボリュームを回復するには」を参照。 fsck または newfs コマンドが正常に終了すると、デバイスは「正常 (Okay)」状態に戻る。 デバイスが「ハードウェアエラー (Hard Error)」か「エラー (Error)」状態にある場合は、システムの起動時に fsck コマンドがファイルシステムを自動的にチェックし、修復する。 newfs コマンドを実行すると、デバイスのデータは破棄される。 |
トランザクションボリュームは、UFS ファイルシステムに対して UFS ロギングと同様なロギング機能を提供します。 次の例では、第5章「Solaris ボリュームマネージャの構成と使用」のサンプルシステムを使用して、トランザクションボリュームのファイルシステムロギングによって再起動の時間を短縮する方法を示します。
トランザクションボリュームの特別な機能 (特に、ログデバイス以外のデバイスにログを記録する機能) を使用する必要がある場合を除き、UFS ロギングの使用を検討してください。 UFS ロギングの性能は、トランザクションボリュームよりも優れています。
サンプルシステムには、ルート (/) や /var のミラーを始め、ロギングによって最大限のアップタイムと可用性を確保する必要がある論理ボリュームがいくつかあります。 ログの記録先として第 3 の RAID 1 ボリュームを使用するようにトランザクションボリュームを構成すると、冗長性を確保し、再起動の時間を短縮できます。