明らかに、生のSAN LUNを提供するためのVMブートおよびデータvDisk)を分割する方法は無限にありますが、どの方法を使用し、それらは何ですか?長所/短所、そしてあなたが出くわした良い「ベストプラクティス」ドキュメントはありますか(私が意味する非常に一般的なVMWareのもの以外)。よろしくお願いします。
私が働いている場所では、サイズが500GBのESXサーバーのファイバー接続LUNを紹介しています。 SCSI予約の問題により、FC接続ストレージをESXに提供するには500GBが最適なサイズのようです。
今後の大きなトレンドは、ESXデータストアにNFSマウントされたストレージを使用することです。特に、10ギガビットイーサネットが主流になりつつある今です。 NFSは、ESX環境でも、従来のファイバー接続ストレージに多くの利点をもたらします。
さまざまなストレージにはさまざまな機能とオプションがあり、VMware環境に活用できるため、使用しているストレージのタイプを知ることは役に立ちます。
すでにお察しのとおり、これはVMwareの質問ではなく、SANの質問です。TR-3428であり、VDIのいとこであるTR-3705は、VMwareの実装の概要を説明する素晴らしい仕事をしています。 NetApp SAN。これらのドキュメントは、netapp以外のSANで議論の余地のある用途です。SANの長所/短所を説明できないためです。
データストアを分割する理由はたくさんあります。 ESX3.5で最も一般的な理由は、間違いなくロックです。 OS /ブートデータストアとアプリケーションデータストアを選択する人もいますが、これによってパフォーマンスが向上することはごくわずかであることがわかりました。一時データをOSから別のデータストアに分離することで実際のパフォーマンスが向上することを確認しましたが、この手法を実行可能にするには、高性能データストアにリダイレクトする必要があります。
結局、私はvmごとに1つのvmdkに戻り、例外を処理しました。私がこれを行った理由は2つあります。1つはベストプラクティスの実装が非常に複雑であることがわかりました。セットアップが面倒だっただけでなく、システムSAが台無しになり、ゲインの可能性が失われることがよくありました。多くの場合、VMのパフォーマンスが低下します。2つ目は、今日のsVMotionで、これは本当に以前ほど重要ではありませんでした。以前は、すべての答えを知る必要がありました。現在、結果がその方向に進み続けるのが好きな場合は、スイングしてください。VMは厄介な動物であり、2つの仮想インフラストラクチャは同じようには見えません。 ベストプラクティス使用は制限されています。試行錯誤を繰り返すと、最終的には環境に最適なソリューションが得られます。
そうは言っても、私はNetApp over NFS(dedupe(IN PRODUCTION)を使用)を使用し、平均60vmの600GBデータストアを実行しています。私にとって、NFSが提供する統合率はパフォーマンスの低下を上回りました。 NFSが提供できる以上の需要を管理している少数(10未満)のVMは、ISCSIデータストア(250GB)にあります。
NetAppストレージを使用している場合に備えて、私が過去にかなり使用した非常に有益なガイドは、 TR-3428 です。また、別のストレージベンダーを使用する場合に役立つ可能性のある一般的なESX/SAN情報も含まれています。