Solaris ボリュームマネージャの管理

第18章 トランザクションボリューム (概要)

この章では、2 種類のファイルシステムロギング (トランザクションボリュームと UFS ロギング) の概念について説明します。 トランザクションボリュームに関連する作業の実行手順については、第19章「トランザクションボリューム (作業)」を参照してください。 UFS ロギングの詳細については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 17 章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。

この章では、次の内容について説明します。


将来の Solaris リリースでは、トランザクションボリュームは Solaris オペレーティング環境から削除される予定です。 Solaris 8 リリースからサポートされている UFS ロギングは、トランザクションボリュームと同じ機能を備えており、より高い性能を提供します。UFS ロギングでは、システム管理の要件やオーバーヘッドが軽減されます。 最適な性能と機能を得る上でこれらの利点は非常に重要です。


ファイルシステムロギングについて

ファイルシステムロギングには、トランザクションボリュームを使用する方法と UFS ロギングを使用する方法の 2 種類があります。

ファイルシステムロギングとは、UFS ファイルシステムを更新する前にその変更をログに書き込む処理のことです。 ログに記録されたトランザクション情報は、後でファイルシステムに適用することができます。 たとえば、新しいディレクトリを作成する場合、mkdir コマンドは、ログに記録されてからファイルシステムに適用されます。

システムの再起動時に、不完全なトランザクションは廃棄され、操作が完結しているトランザクションは適用されます。 つまり、完結したトランザクションだけが適用されるために、ファイルシステムの整合性が常に保たれます。 したがって、fsck コマンドを使ってファイルシステムの整合性をチェックする必要はありません。

システムクラッシュが起こると、実行中のシステムコールが中断され、UFS の整合性が損なわれます。 fsck コマンドを実行せずに 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 を示します。

図 181 トランザクションボリュームの例

マスターデバイスとログデバイスを結合し、トランザクションボリュームとして使用する例です。

例 ログデバイスの共有

次の図に、ミラー化されたログデバイス d30 を共有している 2 つのトランザクションボリューム d1d2 を示します。 両方のマスターデバイスと共有ログデバイスはどれも RAID 1 ボリュームです。

図 182 共有ログトランザクションボリュームの例

2 つのトランザクションボリュームで 1 つのログデバイスを共有しています。

トランザクションボリュームの背景情報

トランザクションボリュームを使用する場合は、「トランザクションボリューム用の要件」「トランザクションボリュームの指針」を参照してください。

トランザクションボリューム用の要件

トランザクションボリュームを使用する場合は、次の要件を考慮してください。


ログデバイスのミラー化を強くお勧めします。 デバイスエラーによってログデバイスのデータが失われると、ファイルシステムの整合性が損なわれ、ユーザの介入がなければ、fsck では修復できなくなってしまうことがあります。 マスターデバイスとして RAID 1 ボリュームを使用する方法は、データの冗長性を確保する上で有効です。


トランザクションボリュームの指針


注意  注意

ログデバイスを共有するマスターデバイスの 1 つがエラー状態になると、ログデバイスは変更を転送できなくなります。 この問題が起こると、ログデバイスを共有するすべてのマスターデバイスがハードエラー状態になります。


トランザクションボリュームの状態のチェック

metastat コマンドを使用して、マスターデバイスやログデバイスなどのトランザクションボリュームを表示します。 デバイスごとに次の情報が表示されます。

次の表に、トランザクションボリュームの状態とその処置を示します。

表 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 ボリュームを使用するようにトランザクションボリュームを構成すると、冗長性を確保し、再起動の時間を短縮できます。