フル装備の Drobo Pro を入手し、それを使用して 2 台の Hyper-V ホスト マシンで実行される VHD を保存することを検討しています。ホスト マシンは iScsi 経由で Drobo Pro に接続します。
Drobo Pro と Hyper-V を使用した経験のある方はいらっしゃいますか? 私の主な質問/懸念は速度についてです。Drobo は、たとえば 12 個の VHD を同時に実行できるほど高速ですか?
答え1
私は Data Robotics の製品マーケティング チームに所属しており、DroboPro、パフォーマンス、仮想化に関する質問にお答えできればと思っています。
DroboPro のパフォーマンスに関しては、パフォーマンス数値を掲載した独立したレビューがいくつかあります。1 つは GeekBrief.tv、もう 1 つは LA Final Cut Pro ユーザー グループです。
こちらがLAFCPUGのレビューです。GeekbriefのレビューはGeekbrief.tvで簡単に見つかります。
http://www.lafcpug.org/reviews/review_drobopro.html
ぜひ、完全なレビューをご覧ください。iSCSI パフォーマンスに関しては、LAFCPUG は Blackmagic というツールを使用し、読み取り速度が約 80MB/秒、書き込み速度が約 70MB/秒でした。GeekBrief.tv は AJA というツールを使用し、読み取り速度が約 74MB/秒、書き込み速度が約 79MB/秒でした。darthcoder が投稿で示唆しているように、バースト速度は確実に高くなりますが、単一の GbE での持続スループットに関しては、80MB/秒が限界に近いです。
Geekbrief.tv のレビューで注目すべき点の 1 つは、DroboPro をスイッチに直接接続することについては触れられていないことです。これは、スイッチを接続する前に USB 管理ポート経由で固定 IP を割り当てるだけで簡単に実行できます。弊社のダッシュボード管理ソフトウェアの最新バージョンは、マルチホストと最大 16 x 16TB の仮想ボリュームをサポートしています。
仮想化に関しては、Data Robotics は、市場シェアの観点から最優先事項である VMware ESX で DroboPro の認定を進めています。ただし、VMware の認定が完了したら、Microsoft Hyper-V および Citrix XenServer でも同様の認定を行う予定です。Hyper-V または Xenserver でのテストはまだ正式には実施していませんが、VMware、Hyper-V、Xen で Drobo および DroboPro を正常に使用しているお客様が複数いることを認識しています。
DroboPro が同時に実行される 12 個の VHD を処理するのに十分な速度であるかどうかという質問に関しては、問題なく動作するはずですが、実際にはワークロードによって異なります。
それが物事を明確にするのに役立つことを願っています。
答え2
ギガビット イーサネット接続では、最大 120 MB/秒しか得られません。これは最良のケースで、おそらく 100 MB/秒が上限になるでしょう。これは Drobo がそれに追いつくことができる場合です (追いつくことができると聞いていますが)。
私は同じトランスポート経由で EMC Celerra から iSCSI を使用しましたが、使用率の低いホスト 10 台程度では比較的良好な結果でした。SQL サーバー 1 台はおそらく 250 ～ 500tps、Clearcase サーバーはおそらくその 3 倍の速度でした。
答え3
個人的には、Drobo Pro に関する情報がもっと出てくるまでは、Drobo は避けたほうがいいでしょう。通常の Drobo はエンタープライズ グレードの機器ではなく、パフォーマンスもいまいちです。実稼働環境に導入する前に、Pro がエンタープライズ グレードにふさわしいものであると確信する必要があります。
以前、Xen メーリング リストに、Xen 仮想マシンのストレージとして Drobo Pro を使用しようとしているユーザーのスレッドが少なくとも 1 つありました。そのスレッドでは IO エラーが発生していました。したがって、Hyper-V でも同じまたは類似の問題が発生する場合と発生しない場合があります。そのため、テストを行う準備をしてください。
答え4
すでによく答えられている質問に私の意見を付け加えると、VM のストレージを検討している場合は、VM の塊の一部ではなく、各 VM を独自のストレージ ニーズを持つ個別のものとして考えることが非常に良い考えです。このため、VM システムのブート ファイルを 1 つの SATA ドライブ ボリュームに統合しても問題ないかもしれませんが、パフォーマンスを重視して SQL データベースを実行している場合は、データ、ログ、一時ファイルなどに別々のヘッドを用意するのが最善です。同様のシナリオは、メディア ストリーミング、バックアップ サーバーなど、大量の IO があるものに当てはまります。
私は Drobo を使ったことはありませんが、中小企業やハードウェア/システム管理者を嫌う開発者 (つまり私の経験ではほとんどの開発者) にシンプルなソリューションを提供している点には感謝しています。現在、優れた iSCSI ソリューションは数多く存在し、スタンドアロンの iSCSI ターゲット ソフトウェアも非常に優れたものになっています。私が今 iSCSI システムを構築するとしたら、おそらく eBay で 12 台程度の SAS ディスクを搭載したミッドレンジの DAS シェルフを探し、それを、優れた RAID カード (または 2 枚) を搭載し、iSCSI ターゲットを実行しているラック サーバー (この場合は Windows Storage Server 2008 r2 が最適です) と組み合わせるでしょう。Drobo ほど美しくはなく (またはほとんど静かではありません)、柔軟性と適応性に優れ、適切に構成すればパフォーマンスが向上します。