web-dev-qa-db-ja.com

VT-dとベアメタルのパフォーマンスペナルティをどのように判断できますか?

プライベートクラウドのセットアップを作成するために、少し奇妙な方法でサーバーを構成しようとしています。

ストレージディスクが接続されているHBAを取得し、それをVM(おそらくxen)に渡して、vSANタイプのセットアップを作成できるようにする必要があります。これを実行したいので、次のことができます。単一のサーバー内にSANタイプのセットアップを実装します。

私が周りに尋ねていたとき、人々は私にIOPSはベアメタルほど良くないと言っていました。私はそれをセットアップに少し考慮しましたが、それがシステムにどれほどの損害を与えるのだろうかと思いました。

また、VMはベアメタルで実行されていますが、ストレージコントローラーが渡されると、VMはホストに依存しているため、奇妙な依存関係ループが作成されます。トラブルシューティングが面倒なこと以外に、パフォーマンスの大幅な低下を実際に引き起こしますか?

ちなみに、ここで主に問題となっているファイルシステムはZFSです。おそらくFreeBSD(FreeNASやNexantaStorなどを含む)またはOpenIndianaで実行されています。

ありがとう!

1
ianc1215

しかし、本当の答えです。

はい、VT-dパススルーでストレージを実行すると、遅延やパフォーマンスの低下が発生する可能性があります。

しかし、実際的な側面について考えてください。そもそも、システムがIOPSにバインドされることはありません。このストレージにはいくつかのレベルの抽象化があり、VMを使用しているという事実は、ベアメタルと比較してトレードオフに問題がないことを示しています。

あなたが持つべき本当の懸念は、ソリューションがまったく機能するかどうかです! VT-dは気質があり、すべてのアダプターで機能するとは限りません。

だからあなたのワークロードであなた自身をテストしてください!

1
ewwhite

私はお勧めしません このタイプのパススルー もうセットアップします。特に信頼性とパフォーマンスに関しては、ほとんどの点で負けです。

それは確かに実行できますが、最も安全な解決策(特に、ESXiのようなハイパーバイザーを使用する場合)は、サポートされているRAIDコントローラーとローカルストレージを使用することです。 ZFSストレージが必要な場合は、スタンドアロンのZFSストレージシステムを構築します。

1
ewwhite

免責事項:私はXenの経験がないので、ESXiに関して書きますが、概念は似ています。


最初の質問について"ベアメタルとパススルーを使用したVMのパフォーマンスの違いをテストする方法は?"

設定は次のようになります。

  • VT-dをサポートするIntelXeon CPUを搭載したサーバーグレードのメインボード(代替手段はありますが、シンプルに保ちます)
  • OSに応じて約20〜30GBの単一のSATASSD(HDDの場合もありますが、少し遅くなります)
  • ディスクをサポートするLSIチップを搭載したHBA
  • 2つのIntelNICは、オンボードまたはPCIe、あるいはその両方である可能性がありますが、同じモデルである必要があります。ほとんどのボードにはすでにそれらがありますが、10ギガビットのものがあるのは一部だけです。 1Gbitを使用する場合、通常、約4つのディスクまたは単一のSSDでシーケンシャルな読み取りと書き込みのパフォーマンスが最大になるため、10Gbitをお勧めします(内部ネットワークもほとんどの場合10GBitなので、これはより興味深いでしょう)。
  • ハイパーバイザー用のUSBスティック

まず、ハイパーバイザーをUSBスティックにインストールして構成します。 SSDを2つのスライスに分割します。最初のスライスで通常行うように、ベアメタルOSを再起動してインストールします。 HBAを他のディスクと一緒に使用し、パフォーマンステスト用に1つ以上のプールを構成します。それらのテストを行い、結果を書き留めます。少なくとも、コマンドラインからのローカルパフォーマンスと、必要なプロトコル(iSCSI、NFS、SMB)を使用したネットワークパフォーマンスをテストする必要があります。可能であれば、SSDもテストします(厳密には必要ありません)。終了したら、プールをエクスポートします。

次に、再起動し(リモートコンソールがあると想定しているので、これをリモートで実行できます)、ローカルSSDではなくUSBスティックから起動します。次に、SSDの2番目のスライスを使用して、スライス2全体にまたがる仮想ファイルシステムを作成します。このVFSに、以前と同じISOから、ただし仮想マシンとしてシステムをインストールします。ハイパーバイザーでパススルーをセットアップし、1つの物理NICとHBAをこの新しいVMに割り当てます。また、少なくとも1つの仮想NICをこのVMに割り当てます(異なるタイプをテストする場合は、それ以上)。できるだけ多くのRAMをVMに割り当てて、条件を類似させます。

次に、VMを起動し、構成して、VMから(VNCまたはSSH経由で)プールを再度インポートします。これで、物理アダプターと仮想アダプターの両方に対して以前と同じテスト(ローカルおよびリモート)を実行し、違いを確認できます。さらに、2つ目のVMを作成できますが、プールから提供される共有NFSまたはiSCSIボリュームに配置されます。このVMでのテストは、VMホストとしてのその後のユースケースについて多くのことを教えてくれます。


パフォーマンスメトリックを超えたいくつかの考え。私はいくつかの理由でこのセットアップが好きです:

  1. これはネイティブセットアップと非常によく似ています。サーバーが停止した場合は、すべてのディスクを取り外して他のホストに接続できます。ホストにハイパーバイザーがある場合は、小さなストレージVMを起動した後も引き続き使用できます。そうでない場合でも、すべてがプール自体にあるため、すべてのデータとネットワーク共有の準備ができています。従来のセットアップでは、同じタイプのRAIDコントローラー、ファイルシステムのサポートについて心配する必要があり、ハイパーバイザーが必要になります(または仮想ディスクからデータをコピーします)。
  2. コンポーネントがうまく連携していれば、驚くほど安定しています。優れたハードウェアを購入すれば、問題ははるかに少なくなります。また、問題が発生した場合でも、データは保存されます(少なくとも、VMでは絶対に行わない同期書き込みを無効にしない場合)。また、何らかの理由でデータが失われたとしても、他のファイルシステムよりも早くデータを知ることができます。
  3. より安価で効率的です。基本的に完全なSANを仮想化していますが、2つのケース、2つのラックスペース、2つの冗長電源、2つのCPUなどは必要ありません。一方、同じ予算でさらに多くのことができます-2つの通常のサーバーの代わりに、すべての優れた機能(冗長電源、HBAマルチパスなど)を備えた強力なサーバーを入手でき、リソース(メモリ、電源など)を必要に応じて使用します。
  4. 柔軟性があります。各タスクに最適なオペレーティングシステムを使用できます。たとえば、ストレージにOracle Solaris、OmniOS、Nexentaなどのillumosディストリビューションを使用してVM、すべての最新機能とそれらが長年提供してきた安定性を取得します。次に、ActiveDirectory用のWindowsServer、内部または外部のルーティングおよびネットワークタスク用のFreeBSDまたはOpenBSD、アプリケーションソフトウェアまたはデータベース用のさまざまなLinuxディストリビューションなどを追加します(オーバーヘッドは必要ないが柔軟性が必要な場合は、SmartOSを試してみてください)ベアメタル。ただし、ハイパーバイザーの選択はKVMに限定されます)。

もちろん、欠点もあります。 ewwhiteは1つ言及しました、ハードウェアは一致する必要があります。さらに:

  1. パフォーマンスは、従来のセットアップほど良くなることはほとんどありません。問題にかなりの金額を投じることができます(RAMの増加、SSDまたはNVMe上のZIL、ディスクの増加、SSDディスクのみ)が、パフォーマンスが最初の懸念事項である場合、VMは最良の選択ではなく、ZFSは最良の選択ではありません、および両方を一緒にすることも最良の選択ではありません。これは、回避できないトレードオフです。安全性と柔軟性はありますが、最大のパフォーマンスは得られません。
  2. 起動、シャットダウン、および電源喪失のために、いくつかのマイナーな準備を行う必要があります。経験則:ストレージVMは、最初に完全に起動し、最後に完全に起動する必要があります。ブーツをテストして時間を計り、他のマシンを起動する前にどれだけ待つ必要があるかを確認します。シャットダウンはそれほど重要ではありません。時期尚早のシャットダウンは、個々のVMの電力損失とほぼ同じです(アプリケーションソフトウェアとオペレーティングシステム、ハイパーバイザーとストレージレイヤーが、重要なものにのみ同期書き込みを使用することに同意している限り、これは安全です)。
  3. 更新にはもう少し時間がかかる場合があります。ストレージVMを変更する場合は、他のすべてのVMをシャットダウンする必要があることを忘れないでください(または強制的にシャットダウンされます)。したがって、もう少しダウンタイムを計画します(これはもちろん、更新のためにSANがダウンする物理的なセットアップの場合と同じです)。また、コア機能(ハイパーバイザー、ネットワークドライバー、仮想ネットワークドライバー、ストレージドライバー、ストレージVM)の更新を徹底的にテストする必要があります。これは、NFSの動作がランダムに不安定になるバグが発生しないためです。
  4. あなたはまだバックアップをしていますよね? ;)
1
user121391