LVMの危険性と警告
最近、一部のサーバーで1 TBを超えるハードドライブ用のLVMを使い始めました。それらは便利で、拡張可能で、インストールも非常に簡単です。しかし、LVMの危険性と警告に関するデータは見つかりませんでした。
LVMを使用することの欠点は何ですか？
私はその投稿を[+1]しました。少なくとも私にとっては、ほとんどの問題が存在していると思います。数100台のサーバーと数百TBのデータを実行しているときにそれらを確認します。私にとって、LinuxのLVM2は誰かが持っている「賢いアイデア」のように感じます。これらのいくつかのように、それらは時々「賢くない」ことが判明します。つまりカーネルとユーザースペース（lvmtab）の状態が厳密に分離されていない場合、破損の問題が発生する可能性があるため（コードが正しくない場合）、本当に賢明に対処できたかもしれません。
さて、この分離が理由であった理由-違いはPV損失の処理と、PVが欠落しているVGのオンライン再アクティブ化、つまりPVが欠落していることを示しています。 -「元のLVM」（AIX、HP-UX）の微風は、状態の処理が十分でないため、LVM2でがらくたになります。また、クォーラム損失の検出（ハハ）や状態の処理（ディスクを削除した場合、使用不可のフラグが付けられません）については話さないでください。それもしませんいまいましいステータス列）
Re：安定性pvmove ...理由は
pvmoveデータ損失
ブログのトップランキングの記事ですね。ちょうど今、物理的なlvmデータがmid-pvmoveからの状態でまだハングしているディスクを調べます。私はいくつかのメモリリークがあったと思います、そしてユーザースペースからライブブロックデータをコピーすることは良いことだという一般的な考えはただ悲しいです。 lvmリストからの素晴らしい引用 "vgreduce --missingはpvmoveを処理しないようです"実際にpvmove中にディスクが切り離されると、lvm管理ツールがlvmからviに変更されます。ああ、また、ブロックの読み取り/書き込みエラーの後でpvmoveが続行し、実際にはターゲットデバイスにデータを書き込まないというバグもありました。 WTF？
Re：スナップショット新しいデータをスナップショットlv領域に更新し、スナップを削除するとマージし直すことにより、CoWは安全に行われません。これは、元のLVへの新しいデータの最後のマージバック中に、IOスパイクが発生することを意味します。さらに重要なことに、データ破損のリスクがはるかに高くなります。壁にぶつかるとスナップショットは壊れますが、オリジナルは壊れます。
アドバンテージはパフォーマンスにあり、3回ではなく1回の書き込みを行います。高速で安全ではないアルゴリズムを選択することは、「Unix」でVMwareやMSなどの人々に明らかに期待されることです。むしろ、「正しく行われる」と思います。スナップショットバッキングストアがプライマリデータとは異なるディスクドライブにある限り、パフォーマンスの問題はあまり見られませんでした（もちろん、別のディスクにバックアップしています）
Re：バリア LVMのせいにできるかどうかはわかりません。私の知る限り、これは開発者の問題でした。しかし、この問題を少なくともカーネル2.6から2.6.33まで実際に気にかけないことにはいくつかの責任があるかもしれません。AFAIKXenは、仮想マシンにO_DIRECTを使用する唯一のハイパーバイザーです。まだそれを使用してキャッシュします。 Virtualboxには少なくともこのようなものを無効にする設定があり、Qemu/KVMは一般にキャッシュを許可しているようです。すべてのヒューズFSにも問題があります（O_DIRECTなし）
Re：サイズ LVMは表示されたサイズを「丸める」と思います。またはGiBを使用します。とにかく、VG Peサイズを使用して、LVのLE数を掛ける必要があります。これで正しいネットサイズが得られ、その問題は常に使用上の問題です。 fsck/mount（hello、ext3）中にそのようなことに気付かなかったり、オンラインの "fsck -n"（hello、ext3）が機能していないファイルシステムによって悪化します。
もちろん、それはあなたがそのような情報のための良い情報源を見つけることができないことを示しています。 「VRAのLEはいくつ？」 「PVRA、VGDAなどの物理オフセットは何か」
オリジナルのLVM2と比較すると、LVM2は「UNIXを理解していない人は、UNIXを再発明することを非難され、不十分です」の典型的な例です。
数か月後に更新します。私は今、テスト用の「完全なスナップショット」シナリオに達しています。それらがいっぱいになると、スナップショットは元のLVではなくブロックします。私がこれを最初に投稿したとき、私はそこで間違っていました。一部のドキュメントから間違った情報を取得したか、理解した可能性があります。私のセットアップでは、私は常にそれらがいっぱいにならないように非常に偏執的だったので、修正することはありませんでした。スナップショットを拡張/縮小することも可能です。
それでも解決できないのは、スナップショットの古さを特定する方法です。彼らのパフォーマンスについては、「薄い」Fedoraプロジェクトページに、スナップショットのテクニックが改訂されており、スナップショットごとに遅くならないようになっていると書かれています。彼らがそれをどのように実装しているかはわかりません。
バックアップにスナップショットを使用する予定の場合-スナップショットが存在する場合の主要なパフォーマンスヒットに備えてください。続きを読む ここ 。そうでなければそれはすべて良いです。私は数十台のサーバーで数年にわたって本番環境でlvmを使用していますが、それを使用する主な理由は、ボリュームを簡単に拡張できないアトミックスナップショットではないためです。
ところで、1 TBのドライブを使用する場合は、パーティションの調整について覚えておいてください。このドライブには、おそらく4kBの物理セクターがあります。
アダム、
別の利点：新しい物理ボリューム（PV）を追加し、すべてのデータをそのPVに移動してから、サービスを中断することなく古いPVを削除できます。この機能を過去5年間に少なくとも4回使用しました。
まだはっきりと指摘していなかった欠点は、LVM2にはやや急な学習曲線があることです。ほとんどの場合、抽象化では、ファイルと基盤となるメディアの間に作成されます。一連のサーバーで家事を共有する数人だけで作業している場合、チーム全体がさらに複雑になることに気付くでしょう。 IT作業に専念する大規模なチームは通常、このような問題は発生しません。
たとえば、私はここでそれを広く使用しており、正しく起動しないシステムを回復するための基本、言語、および基本的なことをチーム全体に教えるために時間をかけています。
特に注意する必要があるのは、LVM2論理ボリュームからブートすると、サーバーがクラッシュしたときにリカバリー操作が困難になるということです。 Knoppixとその友達は、常にそれに適したものを持っているとは限りません。そのため、/ bootディレクトリは独自のパーティションにあり、常に小さくネイティブであると判断しました。
全体として、私はLVM2のファンです。
いくつかのこと：
複数のPVにわたるLVのスパン
[〜＃〜] vm [〜＃〜]スペースを横方向に拡張する：（= = --- ==）[〜＃〜]追加[〜＃〜]PVからVGへの増加と[〜＃〜]単一[〜＃〜]PV。これは醜く、ファイルシステムを複数のPVに分散し、PVのチェーンがより長く、より長くなることに依存します。 VMのストレージを横方向に拡張すると、ファイルシステムは次のようになります。
PVがスパンされたLVのホスティング部分を失った場合のデータ損失
私はこれについて多くの混乱を見てきました。線形LV-とその中に存在するファイルシステム-が複数のPVにまたがっている場合、完全または部分的なデータ損失が発生しますか？解答は次のとおりです。
論理的には、これは私たちが期待すべきことです。 LVデータを保持するエクステントが複数のPVに分散していて、それらのPVの1つが消えると、そのLV内のファイルシステムが壊滅的に損傷します。
これらの小さな落書きが複雑な主題をLVMで作業するときのリスクを理解するのを少し容易にしたことを願っています