仮想化により、組織はインフラストラクチャをはるかに効率的に使用および管理できますが、データストレージシステムへのシーケンシャルアクセスとランダムアクセスの両方について、ストレージシステムに非常に高い要求を課します。 しかし、あらゆる種類のストレージシステムを使用する際の最大の問題は、ランダムデータ操作です。 そして、データストレージシステムに投資された資金の大部分が費やされるのは、まさにこの欠点を解消するためです。 その結果、仮想作業環境の運用中に節約されたお金のほとんどは、より高価で生産性の高いストレージシステムの購入に費やされます。
ioTurbineは、ioDriveカードを強力で管理しやすいツールに変え、仮想環境のストレージシステムのパフォーマンスを向上させることにより、VMwareのパワーを解き放ちます。 インストール後、ioTurbineは、ハイパーバイザーおよびゲストオペレーティングシステムのコンポーネントとしてバックグラウンドで実行されます。 最適なリソース利用のために、ioTurbineは仮想マシン間でI / Oを動的にバランスし、ホスト間でvMotionとマシンの移動もサポートします。
ioTurbineは仮想マシンに対して透過的に機能するため、マシンのダウンタイムなしで構成変更をその場で行うことができます。 管理者は、仮想マシンとアプリケーション間の優先順位を構成して、現時点で必要な場所で最高のパフォーマンスを確保できます。 メインデータウェアハウスをアンロードすることにより、アプリケーションとシステム全体の生産性が向上します。
私たちは少しテストをして、「オウム」の増加率、つまり 仮想マシンで。
IBM System x3650 M3サーバーは、次の構成のテストベンチとして選択されました。
- XeonプロセッサーE5506
- 48GBのメモリ
- 8xSAS 146GB 10kハードドライブ
- ioDrive2 365Gb MLC
テスト方法は簡単です。キャッシュを無効にしてN番目の仮想マシンを取得し、テストを実行してから、すべてのマシンのキャッシュをオンにして、テストを再度実行しました。
テストに関しては、2つありました。
- Iometer（70R / 30W）
- SQLIOランダム読み取り
- SQLIO順次読み取り
実際、最初は、キャッシュのない仮想マシンのパフォーマンスを0に維持し、その後キャッシュを接続することで追加できる仮想マシンの数を確認する必要がありました。 しかし、このシステムのテストと研究には非常に長い時間がかかったため、最終的には最大10台の仮想マシンを使用してパフォーマンス測定を行うことにしました。
イオメーター
SQLIOランダム読み取り
IOPS
MB / s
SQLIO順次読み取り
IOPS
MB / s
ご覧のように、より総合的なIometerテストでは、2番目の仮想マシンを起動した後の差はそれほど大きくありませんが、SQLサーバーの動作をエミュレートするよりリアルなSQLIOテストでは、インジケーターは10番目の仮想マシンでより楽しくなり、最後になります他のすべての場合では、キャッシュを使用した場合、キャッシュを使用しない場合よりも1.5〜2倍高速になりますが、インジケータは互いに近くなります。
残念なことに、仮想マシンのライブマイグレーション中にテストを実施することはできませんでしたが、今後の記事の1つでこの問題に戻ることになるでしょう。
ioTurbineの結果として私が言いたいことは、サーバーを拡張する可能性が限られている場合、ioTurbine + ioDriveはディスクサブシステムのパフォーマンスを向上させるための非常に良いソリューションです。
Fusion-ioを購入したり、デモカードでリクエストしたりするには、 アレクセイコトフ方向のヘッドにお問い合わせください。
KorPによる投稿