. RUVDS では、高速で強力にするためにラインに NVMe サーバーがありませんでした.. 昨年、このような Bitrix や 1C に流行が展開し始めたので...サービスに対する需要があり、他のホスティング サービスにもそれがあって注文されています - 一般的に、構成と特定のハードウェア オプションを選択し、世界中の 11 か所すべてで購入するだけでよいという事実にすべてが当てはまりました。そしてここで、現在サポートされている構成は高速と低速の 2 つだけであると言わなければなりません。スペアパーツ、サポート、ソフトウェアなどは、適切な価格のポリシーの 1 つであるためです。つまり、3分の1が追加され、4年でそこに何かを変更することが可能になります。
SSD RAID はどこにでもあります (HDD が料金表で示されている場合でも)。
最初に学んだことは、NVMe は通常の方法では RAID に結合されていないこと、つまり、信頼できるディスクは期待できないということです。次に、Hi-CPU を同じサーバーにプッシュしたかったのですが、4.5 GHz の周波数はサーバーのものではなく、そのような周波数のホーム デスクトップ ハードウェアおよびサーバー ソリューションは、単に物理的に自然界に存在しないことに驚きました。
さらに、その途中で、管理者はテスト ユーティリティに致命的なバグを発見しました。一般的に、VDS ホスティングで NVMe ソリューションがどのように見えるかをテストで説明します。
私たちは何か間違ったことをしたかもしれないとすぐに言わなければなりません。誰かがそれを理解してくれたら、とても感謝します。
当たりe<0x8D><0x8D> NVMeへの期待
HDDからSSDに乗り換えたら、まるで天と地の差でした。テストを実行すると、パフォーマンスが何倍にも向上します。これは NVMe には当てはまりませんでした。さらに、既存の NVMe 構成と正面衝突した場合、ドライブが常に回避できるとは限りませんでした。テストの条件に応じて、それらは速くなったり遅くなったりしました。
開始するために、いくつかのサーバー オプションを購入しました。私たちは通常、プラットフォームを購入してテストし、何が問題なのかを理解し、再度テストしてから 11 か所に展開するだけです。一度に多くのスペアパーツが使用され、新しいサポート プロセスにはコストがかかるためです。その後、プラットフォームを購入したところ、すぐに信じられないほど不毛な結果に出くわしました。
異なるゲスト オペレーティング システム上の同じハイパーバイザーでは、サーバー内の SSD と NVMe を区別できませんでした。生地でも。
RAID で NVMe を使用する場合、速度は SSD よりも遅くなります。大まかに言うと、RAID を使用する場合、1 つの PCIe バスに含め、この PCI Express に限定され、異なるバスで数台のディスクしか並列化できません。コントローラーが必要です。
どうしてだろう、誰も正常な答えを出すことはできなかった。彼らは、信頼できる古いベンダー、新しいベンダー、そして一般的に左翼のベンダーに尋ねました。誰もが肩をすくめて言いました。表記は表記とは異なりますが、意味は変わりません。そこで、おそらくレイドなしで NVMe を使用する必要があることに気付きました。ある会社 (友好的な競争相手) があります - そして、彼らだけが数年前に同じことをしたと説明しました。彼らはいくつかのプラットフォームを放棄し、最終的には RAID を使用しないことが決定されました。
つまり、最初の問題は、ディスクが解放されたときに、管理者によってもたらされる新しいディスクの自動再構築が行われないことです。 RAID がないと、クライアントは仮想マシンのステータスとデータを失います。同じではありませんが、私たちは前進しようとしています。
次に、U2 と M2 のいずれかを選択します。高価なU2リムを購入しました。それらは、Okulinka インターフェースを介してバスに閉じ込められています。M2 はデスクトップでより頻繁に使用され、マザーボードに固定されます。私たちもテストしましたが、それらの間に大きな違いはありません。ただし、中間インターフェイスなしでディスクがボードに直接差し込まれている場合は、修理が難しくなります。障害が発生した場合は、サーバーのカバーを取り外して突っ込む必要があります。
テストがNVMeの現実になった
結果は、ホスト OS、ハイパーバイザーのバージョン、仮想マシン上のホーム OS のバージョン、およびテスト方法の選択によって異なります。
これは、最新のハイパーバイザーがドライバーで NVMe をネイティブにサポートしている一方で、他のハイパーバイザーは SSD オーバーヘッドとして機能するという事実に依存しています。私たちは実績のあるソリューションを使用することに慣れているため、これもあまり良い結果ではありません。サーバー Windows 12-16-19 があります。私たちは最大のバージョン 16 を使用します。次のバージョンが出たら 19 を使用します。最新バージョンは常にベータ版なので。一般に、サーバー管理で最新バージョンのソフトウェアを使用するのは、オタクと自殺者だけです。そして、はい、あなたの手が今、けいれんしている場合、あなたはオタクです。またはベータテスター。しかし、あなたはまだそれについて知らないかもしれません。ソフトウェア ベンダーは定期的に新しいバージョンをリリースし、再起動、更新、パッチを提供します。安定して動作するには、世代を重ねる必要があります。いつものように、2 番目のサービス パックを待っています。新しい脆弱性や MS からの新しい更新パックについてクライアントに説明することはできません。より正確に、私たちは説明できますが、クライアントは常に信じているとは限りません。 19 日のウィンドゥにある私たちの車の艦隊では、走るのはあまり良くありません。すべてのサーバーが更新と再起動でカラー ミュージックを実行し始めたら、泥沼で自分の顔を打ち負かす必要はありません。
2 番目の重要な点は、45 GB のファイルの奇妙さに関するものです。これでわかるでしょう。
方法論: テスト中に、diskspdユーティリティを使用し ました。CrystalDiskMarkはねじ込みたその周りに 私たちが最初に使用していたが、私たちは1個の非常に面白いバグを見つけました。
両方のユーティリティが次のことを行うことが重要です。
- 複数のテスト ファイルを同時に指定できます。さらに、これらのファイルは異なるディスクに配置できます。これは、異なるディスクで個別に読み取るときに、コントローラー全体のスループットを確認するのに役立ちます。スレッド数。ファイルの読み書きを行う、互いに独立したスレッドがいくつ作成されるか。
- スレッドごとの未処理の IO 要求の diskspd 数 - 変換にいくつかの不一致がある場合があります。さらに、CrystalDiskMark では、このパラメータはキューと呼ばれることはほとんどありませんが、キューと呼ばれます。
直<0x96><0x8D><0x8D> 未処理のIOパラメータ数を把握する
ユーティリティの仕組みを理解するために、そのソース コードを調べることができます。次の行が最も興味深いです。
読むために:
if (useCompletionRoutines) { rslt = ReadFileEx(...); } else { rslt = ReadFile(...); }
そして、同様の行を書く:
if (useCompletionRoutines) { rslt = WriteFileEx(...); } else { rslt = WriteFile(...); }
明確にするために引数は省略されています。 :私たちはより多くの読み書きが標準WinAPIの機能によって実行されているという事実に興味を持っている
のReadFile
のWriteFile
、対応する非同期機能:
ReadFileEx
WriteFileExを
使用すると、コードを詳しく見てみた場合、あなたは次のことを理解することができます:
設定した場合 、優れた数をIO = 1、同期 ReadFile および WriteFile オプションが使用されます。 書き込み操作の疑似コードは 次のようになります。
void testThreadFunc() { while (!stopTesting) { WriteFile(...) // } }
未処理の IOの数 > 1を設定する と、非同期の ReadFileEx および WriteFileEx オプションが使用され、未処理の IOの 数によって、各スレッドのそのような呼び出しの深さが設定され ます。 未処理の IO 数 = 3 の書き込み操作の疑似コードは 次のようになります。
void callback1() { while (!stopTesting) { WriteFileEx(..., callback1) } } void callback2() { while (!stopTesting) { WriteFileEx(..., callback2) } } void callback3() { while (!stopTesting) { WriteFileEx(..., callback3) } } void testThreadFunc() { WriteFileEx(..., callback1) // WriteFileEx(..., callback2) // WriteFileEx(..., callback3) // // }
したがって、 未処理の IOの数は、各スレッドの非同期呼び出しの数です。
重点<0x96><0x8D><0x8D> CrystalDiskMark を使わなかった理由
CrystalDiskMarkユーティリティ は、diskspd のグラフィカルなフロントエンドに すぎません。ユーティリティをインストールしてCdmResource \ DiskSpd ディレクトリに移動すると、これを簡単に推測できます 。
しかし、このシェルの実装には多くの問題があります。
まず、何らかの方法でdiskspdコードを変更します 。CrystalDiskMarkコードを見れば、それは簡単に理解できます 。
command.Format(L"\"%s\" %s -d%d -A%d -L \"%s\"", ..., GetCurrentProcessId(), ...);
diskspd を呼び出すとき に、現在のプロセスの ID を指定した -A パラメータが渡されます。 Diskspd には、そのようなパラメータはありません。CrystalDiskMarkの作成者は 、diskspdコンソール出力を解析しない ことを決定し、よりトリッキーな方法でデータを取得することにしました。さらに、選択された方法は最も成功しません。
この関数では、diskspd が直接呼び出され ます。
int ExecAndWait(TCHAR *pszCmd, BOOL bNoWindow, double *latency) { DWORD Code = 0; … GetExitCodeProcess(pi.hProcess, &Code); *latency = (double)*pMemory * 1000; // milli sec to micro sec return Code; }
原則として、SharedMemory を介した レイテンシーの転送 について質問はありません。しかし、Code変数の値が使用されているコードをさらに検討 すると、これが測定されたディスク速度であることが明らかになります。プロセスの ErrorCode を介してそれを返すことはお勧めできません。たとえば、何らかの理由でプロセスがエラーで終了した場合、テストの結果としてエラー コードが表示されるだけです。 また、レイテンシーの戻り値の正確性にも疑問があります 。-L スイッチを指定すると 、diskspdは次のようなものを返します。
たとえば、 6 行目は、 95% の時間でレイテンシが54.306ms未満になることを 意味します。 CrystalDiskMarkは、テーブル内のすべての値の平均を単純に返します。これは誤解を招く可能性があります。
当たり<0x96><0x8D><0x8D> テストパラメータ
NVME の利点を確認するには、未処理の IOの数を十分に大きく設定する必要があります 。私たちは、番号を選んだ 32
❒:プラットフォーム
のSupermicroのSuperServer SYS-6029P-WTRT 2U
❒ドライブを:
インテルSSD DC P4610シリーズ1.6TB、2.5インチのPCIe 3.1 x4の、3D2、TLC
❒コマンドは10Gファイルのdiskspdを実行します:
DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c10G G:/testfile.dat DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c10G G:/testfile.dat DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c10G G:/testfile.dat
❒ 50Gファイルの実行diskspdへのコマンド:
DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c50G G:/testfile.dat DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c50G G:/testfile.dat DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c50G G:/testfile.dat
当たり<0x96><0x8D><0x8D> 結果
❒表1のWindowsサーバー2019ホストOS
|
|
SSD RAID 5 |
NVME U.2 |
|
Windows Server 2016 仮想サーバー 10GB ファイル (IOPS - 多いほど良い) |
11636 |
246813 |
|
Windows Server 2016 仮想サーバー 45GB ファイル (IOPS - 多いほど良い) |
9124 |
679 |
|
Debian Virtual Server 10 ファイル 10GB (IOPS - 多いほど良い) |
- |
162748 |
|
Debian 10 仮想サーバー ファイル 45GB (IOPS - 多いほど良い) |
- |
95330 |
❒表1のWindowsサーバー2016ホストOS
|
|
SSD RAID 5 |
NVME U.2 |
|
Windows Server 2016 仮想サーバー 10GB ファイル (IOPS - 多いほど良い) |
11728 |
101350 |
|
Windows Server 2016 仮想サーバー 45GB ファイル (IOPS - 多いほど良い) |
11200 |
645 |
|
Debian Virtual Server 10 ファイル 10GB (IOPS - 多いほど良い) |
10640 |
52145 |
|
Debian 10 仮想サーバー ファイル 45GB (IOPS - 多いほど良い) |
9818 |
39821 |
Hyper-V と Windows Server ゲストの下では、結果を説明するのは困難です。約10G の小さなファイルで は、RAID の SSD と比較してIOPS が大幅に向上し ます。しかし、逆に45Gファイル を使用すると、IOPS が大幅に低下し ます。
セット<0x96><0x8D><0x8D> 今はHi-CPUへ
2 番目の驚きは、4.5 GHz プロセッサで始まりました。
ここで言わなければならないのは、サーバー系のプロセッサはデスクトップから -1 世代でも使われているということです。ベータ テスターはゲーマーであり、ソフトウェア パッチを送信できるためです。しかし、サーバーでは、同じハートブレードでさえすぐには修正されず、すべてではありませんでした。すべてのサーバー ソリューションは信頼性が高く、高価ですが、速度は常に劣ります。
デスクトップ以外のタスクがあります。マシンは多くの顧客の間で分割されます。そして今、自然界にはない 4.5 GHz での構成が見られます。
次の 2 つの実装があることがわかりました。
- Hi-CPU ( , ). , , . .
- , turbo boost-, . ! - 3,6 4,5 . , -, : . ( ), . .
▍
その結果、実証済みの 3.6 GHz (ターボ ブースト 4.4 GHz) を維持し、プロセッサの研究を終了することにしました。
NVMe では、ご覧のとおり、超標準ユーティリティからランダムな結果を取得したため、ツールを変更しました。次にハイパーバイザーとOSの問題です。
商業的には、これらのディスクはますます多くの機能を提供します。作業を学ぶ必要があります。私たち自身のために、ハイパーバイザーのホスト バージョンの特定の組み合わせを残し、テストを続け、ディスクも提示します。ホスティング業者が NVMe を書いたとしても、それはまだ何の意味もありません。特定の新鮮な * nix アセンブリと骨の折れる構成を備えた KVM では、優れた利益を得ることができますが、各テストにはアスタリスクを付ける必要があります。 12 番目の Windows または Debian では、すべてが異なります。
一般に、NVMe は無条件の標準ですが、これまでのところ、NVMe を使用した方が確実に高速になるという意味ではありません。私たちはそれを使って慎重にサーバーを配置していますが、利益が価格の上昇にほぼ対応している限り、魔法はありません。