test

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

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

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

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

注 –

将来の 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 のシステム管理 (基本編)』の「ファイルシステムのマウントとマウント解除 (手順)」と mount_ufs(1M) のマニュアルページを参照してください。

トランザクションボリュームの使用方法については、以降の節をお読みください。

注 –

UFS ファイルシステムのロギングを新たに使用する場合は、トランザクションボリュームではなく、UFS ロギングを使用してください。

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

トランザクションボリューム は、ファイルシステムのロギングを管理するためのボリュームで、本質的には UFS ロギングと同じです。 どちらの方法でも、UFS の更新をファイルシステムに適用する前にログに記録します。

トランザクションボリュームは、2 つのデバイスからなります。

注意 – 注意 –

ログデバイスやマスターデバイスは、物理的なスライスでも、ボリュームでもかまいません。 ただし、信頼性と可用性を高めるために、ログデバイスには RAID 1 ボリューム (ミラー) を使用するようにします。 これは、物理ログデバイスにデバイスエラーが発生すると、データが失われることがあるからです。 マスターデバイスにも、RAID 1 や RAID 5 ボリュームを使用することができます。

トランザクションボリュームにログデバイスがあれば、ロギングは、トランザクションボリュームがマウントされたときに自動的に開始されます。 マスターデバイスには、UFS ファイルシステムがあらかじめ格納されていてもかまいません (トランザクションボリュームを作成しても、マスターデバイスの内容が変更されることはありません)。 あるいは、後でトランザクションボリュームにファイルシステムを作成することもできます。 同じように、トランザクションボリュームを削除しても、マスターデバイスの UFS ファイルシステムが変更されることはありません。

トランザクションボリュームを構成したら、そのトランザクションボリュームを物理スライスや別の論理ボリュームと同じように使用できます。 トランザクションボリュームの作成手順については、トランザクションボリュームの作成を参照してください。

例 — トランザクションボリューム

次の図に、マスターデバイス d3 とミラー化されたログデバイス d30 から構成されているトランザクションボリューム d1 を示します。

図 17–1 トランザクションボリュームの例

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

例 — ログデバイスの共有

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

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

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

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

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

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

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

注 –

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

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

注意 – 注意 –

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

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

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

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

表 17–1 トランザクションボリュームの状態

状態 

説明 

処置 

正常 (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 ロギングと同様なロギング機能を提供します。 第 4 章「Solaris ボリュームマネージャの構成と使用」のサンプルシステムに基づく構成例は、トランザクションボリュームのファイルシステムロギングによって再起動の時間をいかに短縮できるかを示しています。

注 –

トランザクションボリュームの特別な機能 (特に、ログデバイス以外のデバイスにログを記録する機能) を使用する必要がある場合を除き、UFS ロギングの使用を検討してください。 UFS ロギングの性能は、トランザクションボリュームよりも優れています。

サンプルシステムには、ルート (/) や /var のミラーを始め、ロギングによって最大限のアップタイムと可用性を確保する必要がある論理ボリュームがいくつかあります。 ログの記録先として第 3 の RAID 1 ボリュームを使用するようにトランザクションボリュームを構成すると、冗長性を確保し、再起動の時間を短縮できます。