LVMとmdadm / dmraidはどちらもLinuxでソフトウェアRAID機能を提供します。ほぼフォローアップです。この質問は2014年に出てきた質問です。。その時、@ダクロバート成熟したLVM raidの代わりにmdadmを選択することをお勧めしますが、これは4年前のことです。それ以来、状況が変わったと想像できます。しかし、私は以前LVM raidを使ったことがなく、最近使った経験もありません。
それでは、LVMレイドの現状はどうですか？もう成熟したのかな？言及された欠陥はありますか？@德ロバートこれで投稿は解決されましたか、それともまだ残っていますか？何について
- 安定化、
- 特性（成長、収縮、変形）、
- 修理と復元、
- コミュニティサポート、
- パフォーマンス
mdadmと比較してLVM raid？
人々が実際にそれを使用しているのか、それとも誰もがまだmdadmに固執しているのだろうか？論理ボリュームを管理するためにmdadmの上にLVMを使用することをお勧めしますか、またはLVMにRAIDを管理することをお勧めしますか？論理ボリューム管理の利点を必要としなくても、mdadmの代わりにLVM raidの使用を検討する価値はありますか？
元の回答の下にコメントを追加することを検討しました。@ダクロバート彼の投稿を更新しましたが、新しい質問をすることにしました。単に古い文章を現在の形にまとめるのではなく、他のメンバーに近づいて新しい経験をしたいと思います。
答え1
私はチームの先輩であり、いろいろな環境を持っています（私の記憶が正しいなら今は約5つですが、年末までにもっと多くの環境を確保する予定です）。
これらの環境の規模は物理ホスト8〜25台（通常はCPUとメモリに完全にロードされます）で、各ホストで実行される仮想サーバーは50〜400台です。
ストレージは常にファイバチャネルにありますが、ファブリックスイッチとディスクアレイは、顧客（顧客が受け取る取引、所有するストレージ会社との関係など）によって大きく異なります。
各環境は、DWDMを介して相互接続された2つのデータセンターにまたがっています（2つのDCネットワーク（ipとfc）が1つとして表示されます）。もちろん、ネットワークは VLAN と FC ゾーニングに応じて小さな部分に分けられます。
私たちはvmware（クールに実行されます）、virshの元のqemu + kvm、Pacemakerクラスタで実行されているvirshのqemu + kvm、ovirtが調整するvirshのqemu + kvmを含むさまざまなハイパーバイザーを持っています。
我々は、ハイパーバイザークラスタリングとVM内クラスタリングを使用します。
最も古い環境は10年を超えていましたが、定期的に改造されています（想像できれば素晴らしいことです）。
これらすべてを説明するのはなぜですか？ご覧のとおり、この動物園は非常にダイナミックです。ほぼ4年間、毎日このすべての技術が実際に働いている様子を見ることができてありがとう。このような環境には通常、数千のLVMボリュームがあり、最終的に作業中にすべてのボリュームに触れることになるという点は追加する必要はありません。
最も古い環境は完全にLVMに基づいていました。
LVMの最大の問題は、それが愚かなことをしたら自分で責任を負う必要があるということです。これは、予期しない場合（または必要に応じて）および本番環境（開発ではないテストまたはプレプロダクションではない）でしばしば発生します。
さらに、コマンドは非常にバロックであり、やや元に戻すことができますが、ボリュームからデータのポンピングを開始したときにのみ可能です。これが発生し、後でエラーが見つかった場合は、ボリュームを焼いて新しいボリュームを起動します。より速く、強力で、間違いも減るでしょう。
デフォルトでは、LVM設定全体が失われたことを意味するいくつかの奇妙なLVMエラーが表示されました。
最も衝撃的なのは、初心者の管理者がLVMスタックを数百ギガのストレージに拡張し、拡張LVのサイズが突然-4兆として報告されたことです。ボリュームの奇妙な負のサイズのため、umount、fsck、またはその他の回復ツールを実行できず、他の問題が発生します。幸いなことに、ディレクトリに入ることはまだ機能していたので、VM全体を再構築し、rsyncを使用して（ほとんど読み取り専用）データを転送しました。その後、データチームは分析を実行し、欠落しているデータが見つかりませんでした。したがって、おそらく空き容量が何らかの方法で混乱している可能性があります。ただし、最終的な結果は、LVMがこれらの複雑な状況を作成し、基本的なデータ回復ツールも実行できないボリュームをロックすることです。
元のシステムも失われ、交換後に解体する必要がありました。私と私たちの建築家は下の命令を分析しました。
また、拡張LVMミラーリングを少量使用しますcling（LVサブデバイスを物理層の正しいデータセンターに接続するため）。これにより、クロスDCリンクが破損した場合にミラーが少なくとも片面に組み立てられます。私が言いたいのは、夜中にこれらの設定を扱いたくないということです。
LVMスナップショットが修正されたと推定されているにもかかわらず、使用する勇気はありませんでした。オンラインでは、これらの問題に関する恐怖の話が多すぎるため、試してみるのは面倒です。特に、これらの問題を完全に回避するためのツールがあるので、さらにそうです。
一般的な使用に関して、LVMとLinuxファイルシステムの全体的な状態の主な問題は、自己チェックが不可能であることです。
まだLVMイメージを掘り下げる時間がありませんでしたが、LVMイメージが実際にブロックのチェックサムを計算しているという人や明示的な書面による確認をまだ見つけられませんでした（crc32でも、すべてのチェックサムはこれを行います）。それでは、LVMイメージ再計算を実行しても、実際には何をしているのでしょうか？進行状況カウンタが100％に達し、不整合カウンタが0の場合、ミラー間のデータが一致することを意味しますか、それともチェックサム全体がエラーなしで完了したことを意味しますか（これはまったく異なるものです）。
LVMに直面する2番目の問題はもう少し間接的です。最も一般的なファイルシステムは次のとおりです。 、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、ユーザーデータのチェックサムはext4ありません。 90年代には大丈夫だったかもしれませんが、今は大きな問題です。今より明確になりました。実際のユーザーデータコンテンツに興味があるため、ユーザーデータメタデータには実際に興味がありません。とにかく保存のポイントは何ですか？写真が最後に変更された時期を知りたいか、写真の内容を実際に見たいですか？xfsjfs
少なくとも基本的なユーザーデータチェックサムを追加する予定がありますが、xfsまだありません。
これはなぜ重要ですか？クラスタ設定ではフェンシングが頻繁に発生し、時にはフェンシングが最終的にストーンサークルを引き起こすことがあります。もしそうなら、イベントが発生した後にクラスタがついに安定したら、データは大丈夫だとどう言うことができますか？
LVM + FSを使用すると、方法がないので簡単にすることはできません。うん、バックアップに比べれば…ただ置いておこう、そうですか？
最後に、LVMは脆弱です。特に、パッシブ/アクティブクラスタボリュームまたはクラスタlvm設定の場合、どのlvm部分がルートをlvm.confに構築するかを表示する必要があります。それ以外の場合、LVMはどの部分がクラスタ化されているのか、どのルートが起動するのかを知らないため、すべての部分を組み立てます。これはクラスターにとって大きな問題です。この問題を解決するには、lvm.confのコピーもinitrdにコピーされていることを確認する必要があります（dracutを参照）。これらすべてを保証しない場合、次に 2 つ以上のノードが同時に起動した場合、両方とも同じ lvm ボリュームをアクティブにしようとします。これで楽しさを想像できます。
初心者の管理者がクラスタを構成して組み立てた後（特に私が指示した場合）、この問題を解決しなければならなかったことが何回かわかりません。自分が書いたメモをよく忘れてしまっても、これはこのステップが難しいことを意味します。
これは通常、最初のフェンシングの後にのみ現れるので、同僚に解決するように任せることができる本当に素晴らしい時限爆弾です:)。
それで長年にわたって私はLVMが消えなければならないと信じてきました。 LVMはその目的を達成しましたが、ZFSとBTRFSはできること、より良いこと、そしてより多くのことができます。
ZFSとBTRFSの両方は、すべてのプールメタデータをプールに直接保存します。 dracutバインディングbtrfs/zfs.confsがない場合、プールは最初からそうする必要があるため、init ramdiskから完全に切断されます。カーネルコマンドラインで使用するプールのルートを指定できます。
まず第一に、エラーが発生した後にBTRFSとZFSでクリーンアップを実行し、実際にストレージを再スキャンして実際の情報を取得できます。ユーザーデータ（！）間違い。スクラブはキラー機能であり、次世代FSを実行する理由です。クリーンアップすると、自動的にデータが破損しないことを実際に確認できます。
二番目に重要なのは、スナップショットは効果があります。いつも。スナップショットはCOWシステムの基本的な作業単位であり、すべての鍵であるため、機能しないと大きな問題が発生します。
最後に、「悪い」方は、大量のデータを処理する能力のためにBTRFSを使用することをお勧めします。それらを分割、縮小、バランスの再調整など、多くの奇妙なことができます。最適なポイントが見つかるまで、BTRFS システムのディスクを使用してダンスできます。これは、ストレージを購入する余裕のない安価なLinux管理者（Linux管理者の90％を意味）の究極の夢です。または、最高のソリューションが見つかるまで同じデータにアクセスし続けながらストレージを3回再構築するのが好きな人。
ZFSはこの領域で機能をゆっくり増やしていますが、それでもBTRFSのスケーラビリティから遠いです。しかし、ZFSの1つは、BTRFS（Linuxバギーと少し似ています）とは異なり、ZFSは強力なデータトラック（タンカー）でもあるということです。
ZFSは多くのテストを受け、ツールは信じられないほど洗練されています。 BTRFSと比較すると、どのくらいの費用がどこにあるかをすぐに確認できます。ヒント：rootアクセスなしでBTRFSプールに対してクエリコマンドを実行することはできませんが、ZFSを使用すると、すべてのZFS操作に完全なアクセス制御リストがあり、特定のユーザーに委任できます。
全体的に私の直感は、数年以内にZFSが機能パリティの観点からゆっくりとBTRFSと競争することです。一方、私が推定したBTRFSは20％だけ完成したもので、永遠に未完成のままになります。これはすべてLinuxの世界で一般的です。
しかし、どちらにしても多くのLVMの問題を減らすことができます。