web-dev-qa-db-ja.com

ソフトウェアRAID、LUKS暗号化、LVMパーティション化による高いI / OレイテンシKVMセットアップ

前の質問 で説明したMumbleサーバーのパフォーマンスの問題は、原因不明のI/O遅延の問題が原因であることがわかりました。何が原因で、さらにデバッグするのかわからないので、このトピックについてのアイデアをお願いします。

Hetzner EX4Sルートサーバー as KVMハイパーバイザー。サーバーはDebianWheezy Beta 4を実行しており、KVM仮想化はLibVirtを介して利用されます。

S.M.A.R.T.エラーが報告された後にハードドライブの1つが交換されたため、サーバーには2つの異なる3TBハードドライブがあります。最初のハードディスクはSeagate Barracuda XT ST33000651AS （512バイトの論理、4096バイトの物理セクターサイズ）、もう1つはSeagate Barracuda 7200.14（AF）ST3000DM001-9YN166（512バイトの論理および物理セクターサイズ）。2つのLinuxソフトウェアRAID1デバイスがあります。1つは暗号化されていないブートパーティション用で、 1つは暗号化された残りのコンテナとして、両方のハードドライブを使用します。

後者のRAIDデバイスの内部には、AES暗号化LUKSコンテナがあります。 LUKSコンテナ内には、LVM物理ボリュームがあります。ハイパーバイザーのVFSは、説明されているLVM物理ボリューム上の3つの論理ボリュームに分割されます。1つは/用、1つは/ home用、もう1つはスワップ用です。

ブロックデバイス構成スタックの図を次に示します。

sda (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

sdb (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

md0 (Boot RAID)
- ext4 (/boot)

md1 (Data RAID)
- LUKS container
  - LVM Physical volume
    - LVM volume hypervisor-root
    - LVM volume hypervisor-home
    - LVM volume hypervisor-swap
    - … (Virtual machine volumes)

ゲストシステム（仮想マシン）は、ほとんどがDebian Wheezy Beta4も実行しています。追加のUbuntuPreciseインスタンスが1つあります。また、LVM物理ボリュームからブロックデバイスを取得します。ボリュームには、ネイティブライトスルーモードのVirtioドライバーを介してアクセスします。ハイパーバイザーとゲストシステムの両方のIOスケジューラー（エレベーター）は、デフォルトのdeadlineではなくcfsに設定されています。これは、たまたま最もパフォーマンスが高かったためです。 bonnie ++テストシリーズに従ってセットアップします。

I/O遅延の問題は、ゲストシステム内だけでなく、ハイパーバイザーシステム自体で実行されているサービスにも影響を及ぼしています。セットアップは複雑に見えますが、以前のサーバーはパフォーマンスの問題がなく、ほぼ同じ基本セットアップで4年間実行されていたため、基本構造が遅延の問題を引き起こすことはないと確信しています。

古い設定では、次の点が異なっていました。

  • Debian Lennyは、ハイパーバイザーとほぼすべてのゲストの両方のOSでした
  • Xenソフトウェアの仮想化（したがって、Virtioもありません）
  • libVirt管理なし
  • さまざまなハードドライブ、それぞれのサイズは1.5TB（1つはSeagate Barracuda 7200.11 ST31500341ASで、もう1つはもうわかりません）
  • IPv6接続がありませんでした
  • ハイパーバイザーでもゲストでも、顕著なI/O遅延の問題はありませんでした

データシートによると、現在のハードドライブと古いマシンのハードドライブの平均遅延は4.12msです。

kvm-virtualizationsoftware-raidioluksdebian-wheezy
6
aef

7200RPM SATAドライブは4.12msの遅延を実行できないため、1秒あたり1/4.12ms（約240）のIOを実行できますが、これは現実的ではありません。

単一ディスクのIOPSを計算するための適切な式は、1 /（avg_seek_time + avg_rotational_latency）であり、7200RPMドライブの場合は約75IOPSになります。ディスクのスペックシートがある場合、ドライブは異なるレイテンシで書き込みと読み取りを吸収できるため、2つのレイテンシがありますが、それらは+ -10％以内です。

キューの深さが高すぎない場合、SATAディスクからIOあたり13〜15ミリ秒の遅延が予想されます。10〜15ミリ秒はすべて問題ないと見なされます。20ミリ秒は、遅延の問題を深く示唆します。キュー（または非常に大きいIOリクエストサイズ）および30ms以上は、病的なものを指します。理論的には、95パーセンタイルは15ms未満であり、システムは「正常に」動作します。

本番ワークロードの実行中に、ホストとゲストからの平均サービス時間の測定値を提供できますか？この値は、「await」列のiostatの出力を確認することで取得できます。

それとは別に、仮想ファイルシステムからデバイスの物理ブロックに至るまで非常に多くのものを階層化するため、セットアップには可能な限り最大の抽象化レイテンシがあると思います。

さらに、HBAにBBWCがあり（または代わりにディスク書き込みキャッシュが有効になっている）、ハイパーバイザーとゲスト内のファイルシステムがバリアを使用していないことを確認できますか？

7
pfo