一部のサーバーをLinuxに移行する必要があり、評価する必要がある重要な側面は、新しいホストシステムに回復力のあるストレージ容量が必要であることです。自然に基本的な調査をしているうちにLVMを知りました。
lvmを使用するとパフォーマンスの損失はありますか？それでは、どのように測定しますか？
今私が考えているのは、LinuxをホストOSとして置き、その上でLVMを実行し、Linuxボックスを仮想化することです（ゲストOSにもLVMを追加する必要がありますか？）。
答え1
LVMは実際に大きな混乱を引き起こさないように設計されています。ユーザースペースの観点からは、これはディスクの上部にある別の「仮想アイテム」レイヤーのように見え、すべてのI / Oが実際のI / Oハードウェアに到達するか、実際のI / Oハードウェアから出るためにそれを通過する必要があることを想像するのは当然です。
しかしそれは真実ではない。コアすでに上位レベルの操作（「ファイルへの書き込み」など）をデバイスドライバに接続し、ディスクの実際のブロックに再接続するマッピング（または実際には複数層のマッピング）が必要です。
このルックアップはLVMを使用すると変更されますが、それはすべてです。 （とにかく起こらなければならないことなので、少しだけ変更しても性能にはわずかな影響を与えます。）ファイルが実際に書き込まれると、これらのビットは他の場合と同様に物理メディアへのパスを直接使用します。
場合によっては、LVMがパフォーマンスの問題を引き起こす可能性があります。 LVMブロックがプライマリシステムと正しく整列していることを確認する必要があります。これは最新のディストリビューションで自動的に発生します。次のバグがある古いカーネルを使用していないことを確認してください。これ。ああ、LVMスナップショットを使用するとパフォーマンスが低下します（アクティブなスナップショットごとにパフォーマンスが悪化します）。ただし、ほとんどの場合、影響は最小限に抑える必要があります。
最後の質問はどのようにテストしますか？標準ディスクベンチマークツールは次のとおりです。ボニー++。 LVM を使用してパーティションを作成、テスト、削除し、(他の要素を同じに保ちながら同じ場所で)、汎用ファイルシステムを作成して再ベンチマークします.それらはほぼ同じでなければなりません。
答え2
LVMは他のように良い面と悪い面があります。
LVMはビットヒット（またはディスクから読み取ることができる）の前に解決する必要がある別の抽象化層であるため、パフォーマンスの面でやや邪魔になります。ほとんどの場合、これらのパフォーマンスの影響は事実上測定できません。
LVMの利点は、データを移動せずに既存のファイルシステムにさらにストレージを追加できることです。ほとんどの人はこれらの利点のためにそれが好きです。
このようにLVMを使用することの1つの欠点は、追加のストレージがディスクにまたがる（つまり複数のディスクがある場合）、ディスク障害によってデータが失われる可能性が高いことです。ファイルシステムが2つのディスクにまたがっていて、どちらかが失敗すると失われる可能性があります。ほとんどの人にとって、これはスペース対コストの理由で許容可能なリスクです（つまり、本当に重要な場合はそれを正しく実行する予算があります）。そして彼らが言ったように、はいさて、そうですか？
私がビューにLVMを使用していない唯一の理由は、災害復旧が明確に定義されていないか、少なくとも定義されていないためです。 LVMボリュームがあり、複雑なオペレーティングシステムを持つディスクは、他のコンピュータに簡単に接続して復元することはできません。 LVMボリュームを回復するための多くのガイドラインには、次の手順があります。過去に戻ってvgcfgbackupを実行し、結果の/ etc / lvmconfファイルをホースボリュームをホストしているシステムにコピーします。。この質問を最後に検討してから3〜4年間状況が変わったことを願っていますが、個人的にはこの理由でLVMを使用したことはありません。
それが言うことです。
あなたの場合、仮想マシンはホストシステムと比較して比較的小さいようです。私にとって、これは後でVMからストレージを拡張したいと思うかもしれません。最善の方法は、VMに別の仮想ディスクを追加してから、影響を受けるVMファイルシステムを拡張することです。仮想ディスクはホストシステムの同じ物理デバイスに存在する可能性が高いため、複数のディスクにまたがる脆弱性はありません。
仮想マシンが重要な場合は、いずれの方法でもホストシステムをRAIDに設定するため、後でストレージを追加できる柔軟性が低下します。したがって、LVMの柔軟性が不要な場合があります。
したがって、ホストシステムでLVMを使用せずにLVMを使用するためにVMをインストールするとします。
答え3
通常、新しい複雑さの階層を追加すると（別名「やるべきことが増えます」）、速度は速くなりません。注：ジョブを追加することのみ可能で、ジョブの実行方法を「変更」することはできません。
どのように測定しますか？ LVMのあるパーティションとLVMのないパーティションを作成し、通常のベンチマークを使用して実行します。人々がそうであるように
http://www.umiacs.umd.edu/~toaster/lvm-testing/
速度にはわずかな影響しかないようです。これは、ベンチマークを実行している他の人の結果と一致しているようです。
「Ext4は、LVMが存在しない場合よりもLVMがある場合より速く、他のファイルシステムのベンチマークでも高速です。」 Linuxカーネルメーリングリストスレッド
ただし、使用するハードウェアとオペレーティングシステムが同じように機能していることを確認し、柔軟なストレージを提供する追加の複雑さ層の影響を（おそらくわずかに）無視できることを確認するには、直接ベンチマークする必要があります。
ゲストOSにLVMを追加する必要がありますか？これは、ゲストOSにも柔軟なストレージが必要かどうかによって異なります。そうではありませんか？要件によって、配布すべき項目が決まります。
答え4
lvm2が読み書き速度を2倍にすることができると述べた人はいません（raid0に似ています）。私は個人的にストリップモードでlvm2を使って3つの同じディスクを使います。読み書きには1/3の時間がかかるため、影響が大きく、ファイルシステムが3倍高速です。私は知っています。ディスクに障害が発生すると、その中のすべてのデータにアクセスできなくなります。しかし、それでも何も失われません。なぜなら、バックアップが必須であり、Raid、LVM2、ZFSなどのものはバックアップを避けないからです。ミラーリング、raid5などを使用する場合は、常にストリッピング（最高のパフォーマンスを得るため）と同期バックアップを使用してください。 ZFSは即時圧縮に適しており、ミラーリングと同様に、1より大きいコピーパラメータを使用しますが、ZFSにはあるが他のZFSにはない機能の1つは、ビット破損（変更されたビット）の即時自動回復です。ディスクがダウンしている間に自発的に発生し、ZFS iは非常に大きな影響（チェックサムの計算、検証）と主な問題（より多くの物理ディスクの追加）を持っていました。
リカバリ：私は外部ディスクバックアップ、複数（2〜3）SSD、およびOS用のlvm2ストライピングにのみZFSを使用します。 （アップグレード後にOSレプリケーションを再実行します。）不変OSを使用する傾向があります。仮想マシンなど、lvm2からデータが削除された複数のローテーションディスクがあり、変更後にバックアップを再実行するため、ディスクエラーが発生した後に交換するだけです。最後のバックアップを復元します。これで書き込み速度が近づいています。最大1.8GiB / sでバックアップからVMを復元するのに30秒未満かかります（VMディスクあたり32GiB）。
したがって、私の答えは次のようになります。 1つだけ使用しないで、賢明にすべての部分を最大限に活用してください。 lvm2ストリップはmdraidレベル0よりも速く、6つの回転ディスクを使用すると高速です。 SSDをストリッピングするときの1つの注意点は2つと3つです。さて、4つのSSDはパフォーマンスを低下させます（私のテストでは、lvm、mdraid0などの同じ4つのSSDをストリップモードで使用すると書き込みが遅くなりました）。 SSD TRIMのような書き込み増幅がおそらくパフォーマンスの低下の主な理由のようです。削除されたボリュームにさらにSSDを追加すると、書き込み速度が遅くなります。
SSDとraid0（削除されたボリューム）の警告、完全な並べ替え、クラスタサイズ、stipサイズなどをファイルシステムに正しく割り当てて、たとえばパフォーマンスが低下しないようにします。ディスクセクタは2048なので、読み書きが可能です。最小値は2Kで、512バイトを使用するファイルシステムを使用しないでください。 2Kまたは4Kクラスターサイズを使用する方が良いです。これで、3xHDD、2Kセクタをそれぞれ使用すると仮定するため、読み取り/書き込み最適化されたファイルシステムでは、クラスタは次のようになります。 3x2K = 6Kですが、これは多くのファイルシステムでは不可能です。次に、64Kクラスターサイズ、64K / 6K = 32/3を使用すると、何が起こるかを考えてみましょう。これにより不均衡が生じ、最適ではない。最適なクラスタサイズを得るには、数学を実行します。
最良の結果は次のとおりです。クラスタサイズ = ストライプサイズ * ストライプ内のディスクの数 これにより、各読み取り/書き込みのサイズがすべてのディスクが動作できるように十分であるため、速度が大幅に向上します。 3つのディスクの192Kクラスターサイズと64Kストライプサイズの例。 6つのディスクの192Kクラスターサイズと32Kストライプサイズの別の例です。
そして常に4K、8K、16K、32K、64Kブロックで個々のディスクをテストする必要があることを覚えておいてください。多くのディスクは4Kのような低い数字では非常に劣りますが、64K、128K以上では10倍以上高速です。
はい、大きなクラスタサイズを使用すると、各ファイルのlasクラスタスペースが無駄になる可能性があります（数百万のファイルを使用している場合はファイルごとに1バイトのみ）。ファイルシステム動的システムでコンパクト/パッケージを使用することをお勧めします。たとえば、4Kクラスタサイズの4TiBディスクには、それぞれ1Byteの4TiB / 4K = 1073741824未満のファイルのみを含めることができます。これは、すべてのファイルサイズが1Byte（クラスタサイズ4K）の場合は1GiBに過ぎず、大きい場合はクラスタサイズに対する最悪の割合です。ファイルが仮想マシン（32GiBに近い場合や数メガバイト）のように大きい場合、これらの大きなファイルの場合は最後のクラスタでのみ損失が発生するため、大きなクラスタサイズはパフォーマンスの面ではるかに優れています。ただし、VMがそれをどのように使用しているかを知っておく必要があります。
誰もこの秘密を伝えません。ゲスト内で4Kクラスターサイズを使用しないでください。仮想ディスクが存在するクラスターサイズと同じまたはその倍数のクラスターサイズを使用してください。
はい、私はゲストディスクから最高速度を得たいと思います。 6台の回転ディスクを使用すると、1.7GiB/sに近づいていると述べたように、SATA IIIバス速度はディスク自体ではなくボトルネックです。私は安価でない高度なディスク、128MiBキャッシュを使用しており、各書き込み速度は283MiB / sです。
あなたと皆のために：速度テストを実行する前に、クラスタサイズ、ストライプサイズ、ブロックサイズの関係を理解することをお勧めします。そうしないと、LVM2または他のRAID（またはZFS）テストが間違った結論を出す可能性があります。
たとえば、次のようになります。 Sata II ポート マザーボードで 2x60MiB/s 2.5 インチ 5400rpm Sata ディスクを使用し、2xSSD Sata III (Sata III に接続されている場合はそれぞれ 250MiB/s 以上書き込み可能) ポートを使用して Linux ブート時間をテストしました。起動時間はわずか2秒短縮され、5分起動時間はわずか2秒しかかかりません。ほとんどのブート中はディスクが使用されていないため、I / OではなくRAMとCPUを操作します。
おおよその速度（つまり最大速度）だけでなく、常に実行したい実際の作業をテストしてください。
最高速度は良いです。代表的なものではないことを知っておいてください。ディスクを常に最高速度で使用することはできず、OSとアプリケーションはI / OなしでRAMとCPUで作業を行う必要があるため、ディスク速度がそうでない場合はまったく問題ありません。
誰もがSSDがWindowsの起動速度を大幅に向上させると言いますが、私がテストした結果、これも間違っていることがわかりました。起動時間はほぼ8分に過ぎず、28秒に過ぎませんでした。
したがって、あなたが本当に私のような場合：Linuxは起動時にRAMにコピーし、SSDは回転するHDDよりも優れていません。また、USB 3.1 Gen2スティック（139MiB / s読み取り）をテストしましたが、起動時間は数秒で影響を受けました。起動には5分かかります。なぜですか？簡単です。 RAMへのコピー中は読み出しが行われます。その後、ボルトの残りの部分はディスク/ SSD / USBスティックを使用しなくなり、データはRAMドライブのようにRAMにあります。
今私は私が所有しているすべてのSSDを販売していますが、起動時にLinuxのRAMコピーを改善するわけではありませんが、ベンチマークで5倍速いことがわかりました...参照、ベンチマークは間違った結論を提供します。実際にテストします。日雇い労働者。
これにより、状況が明確になることを願っています。クラスタとストライプサイズが間違っているLVMの影響は、階層のオーバーヘッドよりはるかに大きいです。