web-dev-qa-db-ja.com

SSDディスクと10 GbeネットワークでのiSCSIパフォーマンスの低下

iSCSIターゲット

buntu 14.04 （Trusty Tahr）、16 GB RAMおよび3つのSamsung SSDディスクを使用するLVMバックアップiSCSIターゲットとして16コアCPU、それぞれがLSIを使用して65k IOPSを実行可能オンボードキャッシュを備えた6 Gbit/sコントローラー。

ターゲットのSSDディスクのベンチマーク：

fio --filename=/dev/sdd --direct=1 --sync=1 --rw=write --bs=4k --numjobs=10 --iodepth=1 --runtime=60 --time_based --group_reporting --name=ssd-max

iops=65514

ここで、sddはハードウェアで構成されています RAID 3つのSamsung 850 EVO SSDを使用しています。

イニシエーター

32 GBのUbuntu 14.04クライアントに500G LUNをエクスポートしましたRAMおよび8コアCPU。

エクスポートされたLUNのベンチマーク

fio --filename=/dev/sdg --direct=1 --sync=1 --rw=write --bs=4k --numjobs=10 --iodepth=1 --runtime=60 --time_based --group_reporting --name=client-max

iops=2400

DASを実行するとネットワーク経由でパフォーマンスが大幅に低下し、少なくとも10k IOPSが期待されていました。

ターゲットとイニシエーター間の通信は1ミリ秒未満で、iperfは9.2ギガビット/秒のネットワークスループットを示しています。

各データはディスクに書き込まれる前にイニシエーターとターゲットの両方のネットワークスタックを経由する必要があるため、4k書き込みのパフォーマンスに影響があることを理解していますが、これは65kから2kへの許容できない低下です。

問題はどこにありますか？ 10 Gbit/sイーサネット NICターゲットとイニシエーターの間にあります。何かアイデアはありますか？

linuxiscsissdopen-iscsi
10
Kevin Parker

短い答え：これは、ネットワーク遅延とシリアルワークロードの結果です（direct=1、sync=1およびiodepth=1）。

長い答え：以前の書き込みがコミットされる前に新しい書き込みをキューに入れることができないため、シリアルワークロードを作成したdirect=1、sync=1およびiodepth=1を使用しますおよびが確認されました。つまり、書き込みの送信率はネットワークのレイテンシに厳密に依存します。 2つのマシン間の単純なpingは、0.2msを超える可能性があり、より高いレベルのプロトコルをTCP（およびその上にiSCSI）として使用する場合）。合計ネットワークレイテンシが約0.33ミリ秒と想定すると、最大IOPS値は約3000になります。これには、他のレイテンシソース（ディスク自体）を考慮しないため、記録した内容と一致します。

これを試してください：--direct=1 --sync=1なしで最初のベンチマークを実行し、これらのオプションを使用して別のベンチマークを実行しますが、iodepthを32リクエストに増やします。次に、ここで結果を報告します。

20
shodanshok