iSCSIとAoEの両方のパフォーマンスが低い
手ごろな速度のストレージを探しています。低予算のため、ソフトウェアiSCSIまたはAoEターゲットを使用することにしました。生産インフラストラクチャを変更する前に、いくつかのテストを行って最適なテクノロジーを選択しています。
テストに使用するもの：
- ターゲットとしての富士通シーメンスRX200 S4
- イニシエーターとしてのFujitsu Siemens RX200 S4
- NetGearマネージド1GBitスイッチ
- オンボードNIC（Broadcom w/TOE）、EdiMax NIC、Broadcom NIC w/TOE-すべて1GBit
- ターゲットサーバーは、6 TBの2 TB WD Blue SATAドライブを備えたQLogicコントローラーを使用しています。
- ターゲットとイニシエーターの両方のオペレーティングシステムがUbuntu 16.04 LTSであり、すべてが更新されています。スイッチは保管専用です。結合とマルチパスをテストします。
私たちの問題は、読み取り速度が遅いことです。テストでは、ddと40〜100GBのファイルを使用します。
- ターゲットサーバーでのローカルの読み取りと書き込みは300 MB /秒以上です。
- iSCSIまたはAoEによるサーバーへの書き込みは、200MB /秒以上であり、満足しています。
- サーバーからの読み取りは常に95-99MB/sです。
私たちはietd、aoetools、LIOを試しました。 2つのNICのボンドを使用しました：バランスrrとLACP、r-rによるマルチパス。通常およびジャンボフレームを使用。最後に、ターゲットとホスト間で直接イーサネット接続を行いました（スイッチなし）。
すべてのテストで、同じ結果が少なくなります（もちろん、TOEとiSCSIなしで一般的なNICを使用すると、20〜30％悪い結果が得られました）。
Iperfを使用したテストネットワークでは、約200MB /秒（2GBit）の転送が見られました。 bmonを使用してターゲットでNICの使用状況を監視すると、両方のデバイスの使用率が等しいことがわかりました（読み取りの場合はそれぞれ約50MB/s、書き込みの場合は約100MB/s）。
運が悪かったので、3番目のNIC（もちろん両側）を使用することにしました。結果は奇妙でした：
- NIC 2枚-各50MB /秒
- NIC x 3-それぞれ33MB /秒
1GBit/sを超える出力を無効にするターゲットソフトウェアに制限はありますか？
私たちは何を間違っていますか？
ISCSI接続ストレージから最大限のパフォーマンスを引き出すには、ジャンボフレームとMPIO（LACPではない）を使用する必要があります。可能な場合は、RDMA/iSERをお勧めします。
AOE（ATA over Ethernet）は古く、たわごとです。すでに何年も前に、Coraidを廃止しました。 StarWind https://www.starwindsoftware.com/ をすでにiSCSIターゲットとして使用しており、StarWindはCoraidから可能なストレージに移行するように依頼されました。
したがって、現時点では、StarWindが提供するiSCSIとWindows、ESX、およびSCST http://scst.sourceforge.net/ をLinuxでイニシエータとして使用することは非常に優れています。 RDMA/iSERを使用すると、最大10ギガビットで、これまでのところ非常に満足しています。
イーサネットリンク集約がどのように機能するかについての予想は正しくありません。
Balance-rr以外のすべての集約メソッド（つまり、モード> 0のすべてのメソッド）はnotを実行し、単一接続のスループットを向上させます。むしろ、影響を受けるホストとの間で複数の接続が確立されると、利用可能な帯域幅の合計が増加します。言い換えると、LAG/LACPは、この1つの接続のシナリオには何のメリットもありません。
単一のインターフェースで通常可能なスループットよりも高い単一セッションのスループットを提供できる唯一の集約方法は、ラウンドロビン方式でパケットを分散するbalance-rrです。 両方イニシエーターとターゲットにbalance-rrを設定する必要がありました。ただし、bigキャッチは、これは主にスイッチに依存するということです。
とにかく、ターゲットとイニシエーターの両方をbalance-rrに設定した場合、2つのマシンを直接接続するとパフォーマンスが向上します。そうでない場合、iperfを投稿して、balance-rrと両方のマシンを直接接続します（スイッチなし）。また、ベンチマークに使用した正確なddコマンドを投稿してください。
注：ここではiSCSIについてのみ話しています。AoEについて読んだことがないので、新しいインフラストラクチャに実装することはありません（ほとんど機能していません）。
一部の非常に特定のポイントツーポイントプロトコル以外には、balance-rrを使用しないでください。ほとんどすべての種類の実世界の負荷がかかると、パフォーマンスはひどくなり、多数のネットワーク問題（大量のジッターなど）が発生します。絶対にスイッチと一緒に使用しないでください。
イニシエーター側でボンディングを使用せずにMPIOを使用して、負荷分散とフォールトトレランスを実現します。すべてのトラフィックを単一のパスに送信することによってパスが「混同」されないようにするには、個別のパス（ターゲットとイニシエーターの間のギガビットNIC）を別々のサブネットに配置します。
パスごとにLACPでターゲット側を自由に結合してください（ターゲットポート構成の例として、2つのパスの2つの結合で合計4つのNICを使用する場合のように）。これはうまく機能し、同じパスを使用する複数のイニシエーター接続のバランスをとることができます。また、可能であればジャンボフレームとiSERを使用します。ターゲットでLACPを使用すると、複数のNIC間の各パスへの接続のバランスが取られます。
イニシエーターでLACPを使用することは、同時に使用する多数のターゲットポータル接続を作成する場合にのみ効果的です（ほとんどすべてのワークロードでは一般的ではありません）。イニシエーターのパスごとにLACPを効果的に実装したとしても、各ボックスに（たとえば）4つの追加のファブリックを使用することは、ケーブル配線の悪夢になります。単一のイニシエーターに2Gib/s以上のスループットが必要な場合は、10GiB/sイーサネットを検討してください。
LACPが複数の接続用であることは知っています。テストは必死の行為でした:)
すべてのテストは、balance-rrと2つのNICを使用して行われました。
ISCSIターゲットへの書き込み：
dd if =/dev/zero of =/mnt/zero.bin bs = 1M count = 20
2000 + 0 przeczytanychrecordów
2000 + 0ザピサニッチレコード
2097152000バイト（2,1 GB、2,0 GiB）コピー、10,1093秒、207 MB /秒
iSCSIターゲットからの読み取り：
dd if =/mnt/zero.bin of =/dev/null bs = 1M
2000 + 0 przeczytanychrecordów
2000 + 0ザピサニッチレコード
2097152000バイト（2,1 GB、2,0 GiB）コピー、16,1684秒、130 MB /秒
ネットワーク速度：
iperf -c 172.16.10.8
--------------------------------------------- ---------------
172.16.10.80に接続するクライアント、TCPポート5001
TCPウィンドウサイズ：325 KByte（デフォルト）
--------------------------------------------- ---------------
[3] 172.16.10.80ポート5001に接続されたローカル172.16.10.70ポート37024
[ID]間隔転送帯域幅
[3] 0.0〜10.0秒2.30 Gバイト1.98 Gビット/秒
iperfおよびジャンボフレームを使用したテストでは、同じ結果が得られました。
イニシエーターで実行することで、読み取り速度が多少向上しました。
hdparm -a 2048/dev/dm-1
以前は256で、読み取り速度は96MB /秒でした
私の目標は、約200MB /秒の読み取り速度を達成することです。
編集：
1。 LACPは使用しません。1回限りのテストでした。
2。 balance-rrとMPIOを使用したテストでは、まったく同じ結果が得られます。マルチパスは、異なるサブネットのNICでテストされました。
3。 NICを追加しても読み取り速度は向上しませんが、各NICの使用率が低下するだけです。
4。問題は、より速く読み取ることができないいくつかの制限（ドライバー、モジュール？）であると考えています。しかし、それがターゲット側かイニシエーター側かはわかりません。
編集2：追加のテストをいくつか行いました。同じホストをターゲットおよびイニシエーターとして構成し、ネットワークハードウェアの問題を取り除きました。私はショックを受けました：まったく同じ読書速度！ 130 MB /秒！書き込みは227 MB/sです。
AoEの応答のほとんどは完全に不正確であり、事実に反しており、AoEの知識と経験の欠如を示しています。まず、消滅しているわけではありません。 CORAIDはAoEの背後にあるベンダーであり、CORAIDの商標を保持しながら「SouthSuite」として再起動しました。彼らも同じ開発者です。彼らは新製品を作り、古い製品のほとんどをサポートしています。オープンなテクニカルメーリングリストが明確に示しているように、彼らはAoE開発も推進しています。ウェブサイトをチェックしてください、それはすべて最新であり、彼らの歴史ページで物語全体を伝えます。
誰かが、AoEはジャンボフレームの恩恵を受けないだろうし、またまちがっていたと言いました。 「vbladed」のバージョン13のリリース後にサポートされました。新しいフレームサイズをサポートするためにMTUを調整する必要がありますが、それ以外の場合はうまく機能します。
iSCSIはOSIモデルのレイヤー5で実行されます。通常のトランスポートはTCPです。これにより、（TCPのチェックサムによる）エラー修正が行われ、レイヤー3でトラフィックをIP経由でルーティングできるようになります。それがiSCSIの利点が停止するところです。 FCP、AoE、FCoEなどと実際に比較すると、実世界のパフォーマンスはまったくひどいものです。ホラーショーのグーグルの「iSCSIパフォーマンス比較」にご招待します。
読み取り速度の問題は、ネットワークの設定ミスが原因である可能性があります。フロー制御をオフにし、十分な大きさのソケットバッファーを使用していることを確認してください。また、基盤となるファイルシステムが読み取りプリフェッチ用に調整されているかどうかについても触れていません。あなたのシナリオに基づいて、それはあなたに多くの助けになるかもしれませんが、キャッシュを無効にする必要がある特定のデータベースでそれを使用しないように注意してください。
802.3ad集約では、ラウンドロビンシナリオでも、単一ストリームのスループットはそれほど増加しません。また、ネットワーク構成が複雑になり、PDUの間隔を一致させなかったり、アクティブ/アクティブ状態をサポートするようにCisco VPCリンクを誤って構成したりすることで、自分の足で自分を撃つ新しい機会がいくつか得られます。 LACPをAoEで使用しないでください。LACPが独自のマルチパスと多重化を処理できるようにします。 AoEの以降のバージョンはこれを美しく処理し、ほとんどの場合、すべて自動であるためFCPよりも優雅に処理します。イーサネットポートを追加すると、帯域幅と回復力が向上します。ホストとイニシエーターのイーサネットポートを複数のスイッチに分散すると、さらに冗長性を提供できます。結合モードを構成する必要はありません。また、AoEに使用するのと同じインターフェイスでIPを実行しないでください。また、パフォーマンスに問題が生じることも知られています。
要するに、AoEの反論者に耳を傾けないでください。彼らは経験があまりなく、流行の脳波に乗っているだけのようです。群れを避けなさい。手作業でプリフェッチしてバッキングストアを構成すると、読み取りスループットが大幅に向上することがわかります。集約プロトコルの使用をやめ、iSCSIから叫び声を上げます。最後に、「dd」の使用を停止することは、優れたテストではなく、キャッシングの影響を受ける可能性があります。 「fio」、「iozone」、「dbench」などの実際のベンチマークツールを使用します。それらはより信頼できる結果を与えます。