更新: 8 つの追加 SATA ポートを備えたボードでこのシナリオを試したところ、うまくいきました。思っていたよりも遅いですが、許容範囲です。David Schwartz との話し合いによると、何か異常な問題があるという彼の意見が正しいか、RHEL が同時に多くのホスト コントローラーをフル稼働させることができないという Ali Chen の意見が正しいかのどちらかだと思います。ここまで来たので、もう少し実験してみるつもりです。この時点では、基本的に好奇心を持つことで報酬を得ているようなものです。:)
オリジナル投稿を開始
そのため、セットアップは少し長くなります。システムには RocketU 1144D 4 ポート USB 3.0 カードが 2 枚あり、帯域幅の問題を回避するために 1 枚は PCIe 2.0 ソケットに、もう 1 枚は PCIe 3.0 ソケットに接続されています。これらの USB カードにはそれぞれ、外部電源の Silver Stone Raven エンクロージャに 4 枚の Crucial MX300 1TB SSD が接続されています。顧客によると、必要なのは、8 枚のディスクのうち 4 枚に同じファイル セットを同時に書き込み、同時に他の 4 枚のディスクからファイルを読み取って MD5 チェックサムを計算することです。各ディスクは、読み取り時またはすべてのファイルの書き込み後に、ファイル サイズが約 1GB になるように、可能な限り容量に近くなります。
さて、カードの 1 枚のみのディスクにアクセスしたり、ディスクにファイルを書き込んだりする場合、速度はそれほど悪くありません。フル TB では、ファイルあたり平均 3 ～ 4 秒です (読み取り/計算または書き込み)。問題は、両方を同時に実行しようとすると、読み取りと書き込みの速度が、ファイルあたり約 1.5 秒から 60 秒以上に急速に低下することです。
システム内の他のカードは、PCIe 3 16x スロットのビデオ カードと、別の PCIe 3 8x スロットの Intel X540-T2 アダプター (現在は使用されていません) のみです。
当社には、6 コア Zenon プロセッサ 2 基と 64 GB の RAM を搭載したデュアル CPU X10DRL-i サーバー MOBO があり、SATA ポートに接続された別の Crucial MX300 から RHEL 7.2 を実行しています。
そこで質問ですが、上記の操作を、次のように定義される適切な時間内に実行できるかどうかです: カード 1 に接続された 4 つの SSD から 1 つの SSD につき 1,000 個の 1 ギガバイトのファイルを読み取り、カード 2 に接続された 4 つの SSD に書き込む操作はすべて並行して実行する必要があります (顧客のため)。ただし、1 時間未満です。
私が学んでいることから、私は「いいえ」に傾き始めていますが、私よりも詳しい知識のある人がいて、より明確な答えを持っているかどうか聞いてみようと思いました。どんな助け、アドバイス、特に回答でも大歓迎です。
David Schwartz の提案による編集:
カードあたりの必要な帯域幅 USB 3.0 ポートあたり 5Gbps x4 ポート = 20 Gbps
利用可能な帯域幅 PCIe 2.0 x4、レーンあたり 500 MBps = 16 Gbps
1 枚のカードが PCIe 3 レーンを使用し、もう 1 枚のカードが PCIe 2 レーンを使用しているため、私の理解では、これらのリソースに競合は発生しないはずです。
注記：
カードの帯域幅が過剰に設定されていることは承知していますが、読み取りと書き込みに 1 GB のファイルあたり数分かかることはありません。
編集2:
David Schwartz の提案を受けて、システム モニターと htop を使用してコア使用率を監視しました。システムは、最初の 12 個のファイル IO で 100% または 100% に近い使用率、または 4 つのコアを示しています。その後、システムは数秒間フリーズし、ファイル IO の低下が発生します。さらに、この後、コア使用率が 100% になることはめったになく、100% になったとしても非常に短い時間です。
編集 3: おそらく最終編集です。
少し調査と実験をした結果、これは手元のカードでは機能しないと言えると思いますし、コメントで言及されている StarTech カードも機能しないと思います。いくつかのことに基づいてその結論に達することができると思います。要するに、カード上で SSD が 1 個であれば問題なく動作します。2 個であれば、多少の速度低下 (オーバーヘッドだと思います) はあるものの問題なく動作します。ただし、3 個以上になると問題が発生し始めます。これは、16 Gbps 相当の PCIe レーンで 20 Gbps をプッシュしようとしているため、理論上の最大値である 16 Gbps を得る代わりに、送信の両側のコントローラーが互いにトリップし、一般的にデータ転送が極端に遅くなるまで物事がバックアップされる可能性があるためだと想像しています。これは単なる理論ですが、顧客が USB 要件を放棄し、SATA やその他の方法を試すことができるようにするには十分でした。SATA の方がはるかにうまく機能しているので、勝者がいると思います。David Schwartz と Ali Chen の支援と提案に感謝します。
編集4: 実際の最終編集
そこで、昨日 SATA ソリューションを調べていたところ、偶然、自分の質問に対する答えを複数の部分から見つけました。実際の問題は 2 つあり、最初の問題が発見された後に初めて明らかになりました。
つまり、最初の問題はメモリ管理でした。書き込み用に大きなファイルを読み取るソフトウェアをテストしたところ、ファイルは 1 回読み取られ、その後複数回書き込まれているように見えました。しかし、実際はそうではありませんでした。つまり、複数の 1 GB ファイルに対する複数の読み取り要求が常に発生していました。なぜこれがテストでは機能したのに実際には機能しなかったのかはわかりませんが、事後検証を行う時間がなかったので、これは歴史に残ることになりました。
2 つ目の問題は、私たちがハードウェアの専門家ではないため、Linux システムで作業しているときに非常に重要な詳細を 1 つ知らなかったことです。NTFS は Linux ネイティブではないため (これはわかっていました)、どうやら実行速度が 1 桁近く遅くなるようです (これは知りませんでした)。これが Windows ボックスであれば、問題はなかったでしょう。
これら 2 つの要因を組み合わせると、私たちが経験した不安定な動作が生まれます。すべてのディスクを EXT4 に完全に再フォーマットすると、予測できない読み取り/書き込み時間は見られなくなり、すべてが期待どおりに機能しました。許容されるパラメータ内で同時書き込みと読み取り/md5 計算を実行できました。