概要
LVMを使用するリスク：
- SSDまたはVMハイパーバイザーでキャッシュの問題を書き込む脆弱性
- ディスク上の構造がより複雑なため、データの回復が困難
- ファイルシステムを正しくサイズ変更するのが難しい
- スナップショットは使いにくく、遅くてバグが多い
- これらの問題を考慮して、正しく設定するにはスキルが必要です
最初の2つのLVMの問題を組み合わせます。書き込みキャッシュが正常に機能せず、電源が失われた場合（PSUまたはUPSに障害が発生した場合など）、バックアップからの回復が必要になる場合があります。LVMを使用する主な理由は、稼働時間の増加（ディスクの追加、ファイルシステムのサイズ変更など）ですが、LVMが実際に稼働時間を短縮しないように、書き込みキャッシュのセットアップを正しく行うことが重要です。
-2018年12月に更新：LVMスナップショットの代替としてのZFSとbtrfsの安定性を含むスナップショット資料を更新
リスクを軽減する
次の場合、LVMは引き続き正常に機能します。
- ハイパーバイザー、カーネル、SSDで書き込みキャッシュのセットアップを取得します
- LVMスナップショットを避ける
- 最新のLVMバージョンを使用してファイルシステムのサイズを変更する
- 適切なバックアップをとる
詳細
LVMに関連するデータ損失が発生したことを過去にかなり調査しました。私が知っている主なLVMのリスクと問題は次のとおりです。
VMハイパーバイザー、ディスクキャッシング、または古いLinuxカーネルによるハードディスク書き込みキャッシュに対して脆弱であり、ディスク上の構造がより複雑なためデータの回復が困難になります-詳細については以下を参照してください。いくつかのディスクで完全なLVMセットアップがリカバリの機会なしに破損するのを見てきました。LVMとハードディスク書き込みキャッシュは危険な組み合わせです。
- ハードドライブによる書き込みキャッシュと書き込みの並べ替えは、パフォーマンスを向上させるために重要ですが、VMハイパーバイザー、ハードドライブの書き込みキャッシュ、古いLinuxカーネルなどにより、ブロックをディスクに正しくフラッシュできないことがあります。
- 書き込みバリアとは、カーネルが「バリア」ディスク書き込みの前に特定のディスク書き込みを完了することを保証することを意味し、突然の電力損失またはクラッシュの場合にファイルシステムとRAIDが回復できることを保証します。このようなバリアは、FUA（Force Unit Access）操作を使用して特定のブロックを即座にディスクに書き込むことができます。これは、完全なキャッシュフラッシュよりも効率的です。バリアを効率的なタグ付き / ネイティブコマンドキューイング（複数のディスクI / O要求を一度に発行）と組み合わせて、データ損失のリスクを増加させることなく、ハードドライブがインテリジェントな書き込み順序変更を実行できるようにします。
- VMハイパーバイザーにも同様の問題が発生する可能性があります：VMware、Xen、KVM、Hyper-V、VirtualBox などのVMハイパーバイザー上でLinuxゲストでLVMを実行すると、書き込みキャッシュと書き込み再書き込みにより、書き込み障壁のないカーネルに同様の問題が発生する可能性があります-注文。「ディスクへのフラッシュ」またはライトスルーキャッシュオプション（KVM、VMware、Xen、VirtualBoxなどに存在）についてハイパーバイザーのドキュメントを注意深く確認し、セットアップでテストします。VirtualBoxなどの一部のハイパーバイザーには、ゲストからのディスクフラッシュを無視するデフォルト設定があります。
- LVMを備えたエンタープライズサーバーは、常にバッテリーバックアップRAIDコントローラーを使用し、ハードディスク書き込みキャッシュを無効にする必要があります（コントローラーには、高速で安全なバッテリーバックアップ書き込みキャッシュがあります）。このXFS FAQエントリの著者によるコメントを参照してください。カーネルの書き込みバリアをオフにしても安全かもしれませんが、テストをお勧めします。
- バッテリーバックアップRAIDコントローラーがない場合、ハードドライブの書き込みキャッシュを無効にすると書き込みが大幅に遅くなりますが、LVMは安全になります。また、ext3の
data=orderedオプションと同等の（またはdata=journal追加の安全性のため）barrier=1を使用する必要があります。さらに、カーネルキャッシュが整合性に影響を与えないようにする必要があります。（または、デフォルトでバリアを有効にするext4を使用します。）これは最も単純なオプションであり、パフォーマンスを犠牲にして優れたデータ整合性を提供します。（Linux はしばらく前にデフォルトのext3オプションをより危険なものにdata=writeback変更したため、FSのデフォルト設定に依存しないでください。）
- ハードドライブの書き込みキャッシュを無効にするには：（SATAの場合）の
hdparm -q -W0 /dev/sdXすべてのドライブに追加/etc/rc.localするか、SCSI / SASの場合はsdparmを使用します。ただし、XFS FAQのこのエントリ（このトピックで非常に良い）によると、SATAドライブはドライブエラー回復後にこの設定を忘れる場合があります。したがって、SCSI / SASを使用するか、SATAを使用する必要がある場合は1分ごとに実行されるcronジョブのhdparmコマンド。
- パフォーマンスを向上させるために、SSD /ハードドライブの書き込みキャッシュを有効にしておくには：これは複雑な領域です-以下のセクションを参照してください。
- Advanced Formatドライブ、つまり4 KBの物理セクターを使用している場合は、以下を参照してください-書き込みキャッシュを無効にすると、他の問題が発生する場合があります。
- UPSは、エンタープライズとSOHOの両方にとって重要ですが、LVMを安全にするのに十分ではありません。ハードクラッシュや電力損失（UPS障害、PSU障害、ラップトップバッテリーの消耗など）を引き起こすものは、ハードドライブキャッシュのデータを失う可能性があります。
- 非常に古いLinuxカーネル（2009年の2.6.x）：非常に古いカーネルバージョン2.6.32以前では不完全な書き込みバリアサポートがあります（2.6.31にはいくつかのサポートがありますが、2.6.33はすべてのタイプのデバイスターゲットに対応します）- RHEL 6は、多くのパッチとともに2.6.32を使用します。これらの古い2.6カーネルにこれらの問題のパッチが適用されていない場合、ハードクラッシュによって大量のFSメタデータ（ジャーナルを含む）が失われ、ハードドライブの書き込みバッファーにデータが残ります（一般的なSATAドライブではドライブあたり32 MBなど）。カーネルがすでにディスク上にあると考えている32MBの最新のFSメタデータとジャーナルデータの損失は、通常、多くのFSの破損、したがってデータの損失を意味します。
- 要約： LVMで使用されるファイルシステム、RAID、VMハイパーバイザー、およびハードドライブ/ SSDセットアップに注意する必要があります。LVMを使用している場合は、非常に適切なバックアップが必要です。LVMメタデータ、物理パーティションのセットアップ、MBR、およびボリュームブートセクターを明確にバックアップしてください。また、SCSI / SASドライブを使用することをお勧めします。これらのドライブは書き込みキャッシュの方法について嘘をつく可能性が低いため、SATAドライブの使用にはさらに注意が必要です。
パフォーマンスのために書き込みキャッシュを有効にしておく（および横になっているドライブに対処する）
より複雑ではあるがパフォーマンスの高いオプションは、SSD /ハードドライブの書き込みキャッシュを有効に保ち、カーネル2.6.33+でLVMで動作するカーネル書き込みバリアに依存することです（ログで「バリア」メッセージを探すことによるダブルチェック）。
また、RAIDセットアップ、VMハイパーバイザーセットアップ、およびファイルシステムが書き込みバリアを使用することを確認する必要があります（つまり、キーメタデータ/ジャーナル書き込みの前後に保留中の書き込みをドライブがフラッシュする必要があります）。 XFSはデフォルトでバリアを使用しますが、ext3は使用しないため、ext3 barrier=1ではマウントオプションで使用するdata=ordered必要data=journalがあります。
書き込みキャッシュの使用はSSDの寿命にとって重要であるため、SSDには問題があります。スーパーキャパシタを備えたSSDを使用するのが最適です（電源障害時のキャッシュフラッシュを有効にして、キャッシュをライトスルーではなくライトバックできるようにします）。
Advanced Formatドライブのセットアップ-書き込みキャッシュ、アライメント、RAID、GPT
- 4 KiBの物理セクターを使用する新しいAdvanced Formatドライブでは、ドライブの書き込みキャッシュを有効にしておくことが重要です。これは、ほとんどのドライブが現在512バイトの論理セクターをエミュレートし（"512エミュレーション"）実際に4 KiBを使用しているセクター。
- Advanced Formatドライブの書き込みキャッシュをオフにすると、アプリケーション/カーネルが512バイトの書き込みを行っている場合、単一の4 KiB物理を行う前に8 x 512バイトの書き込みをキャッシュに依存するため、パフォーマンスに非常に大きな影響を与える可能性があります書く。キャッシュを無効にした場合の影響を確認するためのテストをお勧めします。
- 4 KiB境界でのLVのアライメントはパフォーマンスにとって重要ですが、LVM物理エクステント（PE）はデフォルトで4 MiBであるため、PVの基礎となるパーティションがアライメントされている限り、自動的に行われます。ここでRAIDを考慮する必要があります-このLVMおよびソフトウェアRAIDセットアップページでは、ボリュームの最後にRAIDスーパーブロックを配置し、（必要に応じて）
pvcreatePVを調整するオプションを使用することを推奨します。このLVM電子メールリストスレッドは、2011年にカーネルで行われた作業と、単一のLVで512バイトと4 KiBセクターのディスクを混在させる場合の部分ブロック書き込みの問題を示しています。
- Advanced Formatを使用したGPTパーティショニングでは、特にブート+ルートディスクの場合、最初のLVMパーティション（PV）が4 KiB境界で開始されるように注意する必要があります。
ディスク上の構造がより複雑なため、データを回復するのが難しくなります。
- ハードクラッシュまたは電源喪失（不適切な書き込みキャッシュによる）後に必要なLVMデータの回復は、適切なツールが明らかにないため、せいぜい手動のプロセスです。LVMは、メタデータのバックアップに適して
/etc/lvmいます。これは、LV、VG、PVの基本構造の復元には役立ちますが、ファイルシステムメタデータの損失には役立ちません。
- したがって、バックアップからの完全な復元が必要になる可能性があります。これには、LVMを使用しない場合の迅速なジャーナルベースのfsckよりも多くのダウンタイムが含まれ、最後のバックアップ以降に書き込まれたデータは失われます。
- TestDiskは、 ext3grep、ext3undelおよびその他のツールは、 非LVMディスクからパーティションおよびファイルを回復することができますが、彼らは直接LVMのデータ復旧をサポートしていません。TestDiskは、失われた物理パーティションにLVM PVが含まれていることを発見できますが、これらのツールはいずれもLVM論理ボリュームを理解しません。PhotoRecなどのファイルカービングツール は、ファイルシステムをバイパスしてデータブロックからファイルを再構築するため機能しますが、これは貴重なデータに対する最後の手段であり、低レベルのアプローチであり、断片化されたファイルではあまりうまく機能しません。
- 手動のLVMリカバリは場合によっては可能ですが、複雑で時間がかかります。リカバリ方法については、この例とthis、this、およびthisを参照してください。
ファイルシステムを正しくサイズ変更するのが難しい-LVMの利点としてファイルシステムの簡単なサイズ変更がしばしば与えられますが、LVMベースのFSのサイズを変更するには、6個以上のシェルコマンドを実行する必要がありますFSがマウントされていますが、最新のバックアップと同等のサーバーで事前にテストされたコマンド（実稼働サーバーの災害復旧クローンなど）を使用しない限り、FSを危険にさらすことはありません。
- 更新：最新バージョンは（）オプションを
lvextendサポートします-これが利用可能であれば、特にFSを縮小している場合、LVとファイルシステムのサイズを変更するより安全で迅速な方法であり、このセクションはほとんどスキップできます。-r--resizefs
- LVMベースのFSのサイズ変更に関するほとんどのガイドは、FSがLVのサイズよりもいくらか小さくなければならないという事実を考慮していません：詳細な説明はこちら。ファイルシステムを縮小する場合、FSのサイズ変更ツールに新しいサイズを指定する必要があります（例：
resize2fsext3、to lvextendまたは）lvreduce。細心の注意を払わずに、1 GB（10 ^ 9）と1 GiB（2 ^ 30）の違い、またはさまざまなツールがサイズを切り上げるまたは切り上げる方法により、サイズがわずかに異なる場合があります。
- 正確に計算を行わない場合（または最も明白な手順を超えるいくつかの追加手順を使用する場合）、LVに対して大きすぎるFSになる可能性があります。FSが完全にいっぱいになるまで、数か月または数年はすべてが正常に見えるようになり、その時点で深刻な破損が発生します。その状況を曇らせます。（この問題はファイルシステムのサイズの縮小にのみ影響する可能性があります-ただし、いずれかの方向でファイルシステムのサイズを変更すると、おそらくユーザーエラーによるデータ損失のリスクが増加することは明らかです。）
LVサイズは、FSサイズよりも2 x LVM物理エクステント（PE）サイズより大きくする必要がありますが、ソースが信頼できないため、詳細については上記のリンクを確認してください。多くの場合、8 MiBを許可するだけで十分ですが、100 MiBや1 GiBなど、もっと安全にするために許可する方がよい場合があります。4 KiB = 4096バイトブロックを使用して、PEサイズと論理ボリューム+ FSサイズを確認するには：
KiBでPEサイズを表示：
vgdisplay --units k myVGname | grep "PE Size"
すべてのLVのサイズ：
lvs --units 4096b
（ext3）FSのサイズ、4 KiB FSのブロックサイズを想定：
tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
対照的に、非LVMセットアップでは、FSのサイズ変更が非常に信頼性が高く簡単になります。Gpartedを実行し、必要なFSのサイズを変更すると、すべての処理が実行されます。サーバーでpartedは、シェルから使用できます。
- Gparted Live CDまたはParted Magicを使用することをお勧めします。これらには、ディストリビューションバージョンよりもバグのない最新のGparted＆カーネルが含まれているためです。カーネル。ディストリビューションのGpartedを使用している場合は、カーネルのビューが正しいように、パーティションを変更した直後に必ず再起動してください。
スナップショットは使いにくく、遅く、バグが多い -スナップショットが事前に割り当てられたスペースを使い果たすと、自動的に削除されます。特定のLVの各スナップショットは、そのLVに対するデルタであり（以前のスナップショットに対してではなく）、書き込みアクティビティが大きいファイルシステムのスナップショットを作成するときに多くのスペースを必要とします（スナップショットは以前のものよりも大きい）。元のLVと同じサイズのスナップショットLVを作成しても安全です。スナップショットの空き領域がなくなることはありません。
スナップショットは非常に遅くなる可能性があります（これらのMySQLテストでは LVMを使用しない場合よりも3〜6倍遅いことを意味します）- さまざまなスナップショットの問題に関するこの回答を参照してください。スナップショットには多くの同期書き込みが必要なため、速度が低下するのも一因です。
スナップショットにはいくつかの重大なバグがありました。たとえば、場合によっては、ブートが非常に遅くなったり、ブートが完全に失敗したりすることがあります（カーネルが LVMスナップショットである場合、ルートFSの待機中にタイムアウトする可能性があるため[Debian initramfs-toolsアップデート2015年3月で修正] ）。
- ただし、多くのスナップショットの競合状態のバグは2015年までに修正されたようです。
- スナップショットがコア機能ほど使用されていないためと思われるため、スナップショットのないLVMは一般に非常によくデバッグされているようです。
スナップショットの代替 -ファイルシステムとVMハイパーバイザー
VM /クラウドスナップショット：
- VMハイパーバイザーまたはIaaSクラウドプロバイダー（VMware、VirtualBox、Amazon EC2 / EBSなど）を使用している場合、多くの場合、それらのスナップショットはLVMスナップショットよりもはるかに優れた代替手段です。バックアップの目的でスナップショットを簡単に作成できます（ただし、FSを凍結することを検討してください）。
ファイルシステムのスナップショット：
オンラインバックアップとfsckのスナップショット
スナップショットは、割り当てられたスペースに注意する限り、バックアップの一貫したソースを提供するために使用できます（理想的には、スナップショットはバックアップされるLVと同じサイズです）。優れたrsnapshot（1.3.1以降）は、LVMスナップショットの作成/削除も管理します-LVMを使用したrsnapshotのこのHOWTOを参照してください。ただし、スナップショットに関する一般的な問題と、スナップショット自体をバックアップと見なすべきではないことに注意してください。
また、オンラインでfsckを実行するためにLVMのスナップショットを使用することができます。まだメインの非スナップショットFS使用しながら、LVのスナップショットを作成し、スナップショットをfsckが- ここで説明を -しかし、それはだ、完全に簡単ではない、それは使用するのが最善ですのでe2croncheckとしてテッドTsだけ説明します'o、ext3のメンテナー。
スナップショットの取得中にファイルシステムを一時的に「フリーズ」する必要があります。ext3やXFSなどの一部のファイルシステムは、LVMがスナップショットを作成するときにこれを自動的に行います。
結論
これらすべてにもかかわらず、私はまだいくつかのシステムでLVMを使用していますが、デスクトップのセットアップにはrawパーティションを好みます。LVMから得られる主な利点は、サーバーの稼働時間を長くする必要がある場合にFSを柔軟に移動およびサイズ変更できることです。必要ない場合は、gpartedが簡単で、データ損失のリスクが少なくなります。
LVMは、VMハイパーバイザー、ハードドライブ/ SSD書き込みキャッシュなどのために、書き込みキャッシュの設定に細心の注意を払う必要がありますが、LinuxをDBサーバーとして使用する場合も同様です。ほとんどのツール（gpartedクリティカルサイズの計算などを含む）のサポートが不足しているため、testdisk本来よりも使いにくくなっています。
LVMを使用している場合、スナップショットには細心の注意を払ってください：可能な場合はVM /クラウドスナップショットを使用するか、ZFS / btrfsを調べてLVMを完全に回避します-スナップショットを含むLVMと比較して、ZFSまたはbtrsが十分に成熟していることがあります。
結論：上記の問題とその対処方法がわからない場合は、LVMを使用しないことをお勧めします。