良い一日、
私の英語は申し訳ありませんが、それは私の母国語ではありません、そして最近、私は分析的執筆で練習するべきよりも少ないです。
ベアメタルHPProliantサーバーにESXi6.0.0 Update2をインストールしています。 2台のP411RAIDコントローラーを介して接続された2台の外付けHDDエンクロージャーで十分に動作します。その上、サーバーの内部2.5インチスロットの一部は、HPオンボード統合P410 RAIDコントローラーによって提供されるSSD(ほんの一握り)で占有されています(はい、それは悪いことです)。すべてのHDDとSSDはサイズとRPMに応じていくつかのデータストアがあり、すべてのデータストアはRAID10として構成されています。
当然、いくつかのVMがあり、大量の本番データが毎日受信され、突然、適切なソフトウェアがインストールされた専用のVM、および安価な8 SATA 5400で実行される専用のデータストアを利用するバックアップソリューションがあります。 RPMはそれぞれ3TBを駆動するため、合計で12TBの第1層オンサイトバックアップを使用できます。
オンサイトバックアップの第2層がありました。つまり、外部電源のエンクロージャにある4TB ST4000NM0055に対して実行された最も重要なVMのバックアップコピーがあり、バックアップに接続されていますVM PCIパススルーPCIを介して- USB3.1カード。
最近、PCI-USB3.1カードに障害が発生し(VMWareで承認されていませんでしたが、約1年間機能しました)、バックアップコピーを移動して、より安定したフェイルセーフパスで接続することにしました。これは、このHPProliantサーバーのメインボードに直接配置されている既存の空いているSATAポートを利用して行われました。 SATAポートには電力が供給されており、SSD SATAとして文書化されており、上記のP410およびP411とは関係なく、別のコントローラーを介して動作しているようです。
そこで、適切なケーブルを調達し、SeagateST8000NM0055をSATAポートに接続しました。 7TBのシンプロビジョニングされたデータストアを介して新しいドライブをバックアップVMに接続した直後、ファイル移動のパフォーマンスにはまだ多くの要望が残されていることに気付きました。古いUSB3.0ドライブからのバックアップ移動は70で開始されました。 -80MBps(メガバイト/秒)ですが、10〜15分以内に10MBpsに低下し、そのレベルで数時間停止しました。3TBのファイル移動操作の終了は、開始から80〜90時間であると予想されました。
シンプロビジョニングされたVMDKの大規模なファイル移動と基礎となるディスクスペースの割り当ては、基本的に同じデータボリュームに対して2つの重い操作であると想定したため、データ転送速度が予想外に低いことが原因である可能性があります。プロセスをスピードアップするために、私はシンプロビジョニングされたVMDKを膨らませるその時点で300GBからターゲットの7TBに決定しました。そこで、バックアップVMをシャットダウンし、VMWare vCenter操作Webインターフェイスで右クリック膨張しました。
これは6日前に発生しましたが、ドライブはまだ膨張しています...サーバーにCPUやディスクの負荷がかかっていないため、使用率はすべての種類の容量の15〜25%です。ですから、今回は通常を超えていると思いますが、キャンセルするかのように、転送済みの300GBの重要ではないが感傷的なデータが失われるのを待つしかありません。
毎日の状況を確認していると、書き込みIOPSが非常に低いだけでなく、3〜4日実行した後、突然ほぼ2倍に増加していることに気付きました。そのメディアで実行される唯一の操作は、ディスクの膨張です。
ESXiホスト設定でのデータストアハードウェアアクセラレーションのオンとオフの切り替えなど、いくつかの調整が見つかり、試行されました。つまり、次のパラメータがあります。 SATAにもSASデータストアにも影響はありません。
このドライブのパフォーマンスを向上させるために欠けているものは何ですか?自宅のPCの経験から、少なくとも100MBpsの操作が簡単にできると思います。したがって、完全に膨らませるには、現在目標としている最大180時間ではなく、20時間かかるはずです。
TL; DR:ESXI 6.0、直接接続されたSATAHDDの書き込みパフォーマンスが10MBpsで止まっているようです。時々それは百日咳の20MBpsにジャンプします。説明するために助けを送ってください
このようなひどいパフォーマンスの理由は、HPBIOSドライブ書き込みキャッシュがデフォルトで無効に設定されていたためです。
有効(ここでは明らかにパワーサイクルが必要)に変更した後、このエンタープライズHDDモデルから期待されるパフォーマンスは通常に戻りました。