仮想マシン内でデータベースを実行することの欠点は何ですか？どうすれば克服できますか？[閉まっている]

仮想マシン内で何かを実行すると、パフォーマンスヒットのいくつかのレベルを持っていますが、どのくらいそれはない、実際にデータベース・システムのパフォーマンスに影響を与えますか？

いくつかの興味深いベンチマークでこの学術参考書を見つけましたが、XenとPostgreSQLのみを使用した限定的なテストでした。結論は、VMを使用しても「パフォーマンスに高いコストがかかることはない」ということでした（実際のデータではそうでないと思うかもしれませんが）。

仮想マシン内でのデータベースの実行に関連する技術的、管理的、およびその他の欠点は何ですか？

客観的な事実に裏打ちされた答えを投稿してください、私は投機や他の半宗教的な議論には興味がありません（オタクの情熱は多くの点で良いですが、ここでは役に立ちません）。

とはいえ、

• 仮想マシンでデータベースを実行すると、どのような問題が発生しますか？（参照を投稿してください）
• これらの問題は重要ですか？
  • 特定のシナリオでのみ重要ですか？
• 回避策は何ですか？

多くのDBベンダーはこれを行うのに非常に時間がかかりましたが、現在ではほとんどすべてのベンダーが仮想化環境で実行されるソフトウェアを公式にサポートしています。

ESXi上でLinuxで多くのOracle 11gインスタンスを実行しているため、非常に優れたパフォーマンスを得ることができます。すべてのハードウェアスケーリングと同様に、仮想化ホストに十分なリソース（RAM、CPU）があり、ディスクレイヤーが必要なIOパフォーマンスを提供するタスクに対応していることを確認する必要があります。

ErikAが言うように、これはますます一般的になっています。私はSQL Serverキャンプにいて、VMで運用システムを個人的に実行していませんが、ためらうことはありません（このトピックについてもう少し勉強した後）。ただし、そのパスをたどる前に考慮すべきことがいくつかあります（少なくともSQL Serverの場合）。ディスクIO（他の人が述べたように）とメモリ割り当てはほんの2つの例です。ハイパーバイザーによっても状況は異なります。

Brent Ozarは、SQL Serverの仮想化、特にVMWareの専門家として認められています。彼の資料を一読することを強くお勧めします。

http://www.brentozar.com/community/virtualization-best-practices/

ある缶は、そこですはず。コルベットは時速150マイルで走行できますが、公共の高速道路を利用する必要がありますか？不必要に自分を傷つける可能性があります。

データベースはゲストオペレーティングシステムです。設計時に、リソースのブロックを取得し、パフォーマンス上の理由から直接管理します。データベースサーバーのコアオペレーティングシステムを仮想ホスト環境のゲストにするとすぐに、ディスクとRAMのブロック割り当て要素とデータベースサーバーの間にハイパーバイザーを使用した調停レイヤーが配置されます。遅くなります。クエリの効率が悪いほど、処理が遅くなります。これらの非効率性は今日、専用のハードウェアでは隠されている場合がありますが、依存リソースに調停を導入するとすぐに、すぐに判明します。

仮想化を要求する多くのBeanカウンターが認識できないのは、ゲストオペレーティングシステムとしてのデータベースサーバーが独自の統合レイヤーを提供していることです。IPアドレスを移動したり、追加のホスト名を設定するなど、1つの物理サーバー上の複数の論理データベースインスタンスを統合して移動できない理由はありません。また、このモデルを使用すると、管理者が物理ホストの数を減らすために推進しているコスト削減を維持できるだけでなく、任意のハイパーバイザーの影響なしで物理リソースへのブロックアクセスを維持できるため、有益な意思決定を行うことができます。その他。

同じことが、Javaなどの他のゲストオペレーティングシステムにも当てはまります。仮想化ソリューションは一般的に忙しい環境であり、ハイパーバイザーはリソースの「トークンを取得する」ユーザーについて多くの決定を行う必要があります。その層を削除できるときはいつでも、あなたは良くなるでしょう。

最初に、自然なゲストオペレーティングシステムレイヤーを使用して複数のインスタンスを結合します。おそらく、プラットフォームの統合とパフォーマンスの目標を簡単に達成できるでしょう。

ここで実現する2つのことがあります。

• ハードウェアの単位あたりのDBのパフォーマンスの単位は、仮想化されたdbでは少し低くなります。つまり、同じレベルのパフォーマンスを得るには、もう少しハードウェアを購入する必要があります。
• これは、同じレベルであることや、望ましいレベルのパフォーマンスが得られないことを意味しません。多くの場合、改善された管理と（容易にHAのような）他の利点から、あなたが得る利益の方法わずかに増加したハードウェアコストを相殺して余り。

つまり、SQL Serverのインストール場所は、すぐに仮想化するつもりのない2台のサーバーのうちの1台です（もう1台はプライマリDCです）。

アプリケーションを実行するのに十分なリソースをVMに提供できるのであれば、SQL Serverの実行はVMで問題ありません。物理的な世界で24コアと256ギガバイトのRAMが必要な場合、仮想世界で24のvCPUと256ギガバイトのRAMを提供する必要があります。

私は記事を書いたすべてのVMwareのvSphereの下にSQL Serverを実行してについて先月、SQL Serverの雑誌では。

dom0の可用性が高い仮想環境（Xen）で、PostgreSQLとMySQLの2つのデータベースを実行しています。domUファイルシステムはすべて、iSCSI SAN LUN上にあり、LVM2論理ボリュームで分割されています。MySQLデータベースはCacti専用であるため、あまり使用されることはなく、iSCSI LUNにも配置されています。

PostgreSQLデータベースは、ステージング環境のデータベースであるため、MySQL dbよりも使用率が高くなっています。このため、データベースはローカルRAID10セットに配置され、DRBDは2番目のクラスターノードに複製されます。ただし、実際の負荷の観点では、このステージングデータベースにはあまり負荷がかかりません。私の意見では、これは仮想化するのに良い/素晴らしい候補になります。

組織にとっての利点のいくつかは、電力消費の削減、ラックスペースの節約、およびハードウェア管理オーバーヘッドの削減です。

一方、メインの本番データベースは、仮想化されることを想像できません。

私は多数のサーバーでMSSQLおよびMySQLサーバーを使用しています。数年前、VMでSQLサーバーを実行することのパフォーマンスの問題について聞いたことがあったため、VMでSQLサーバーのセットアップを開始することにheしていました。ただし、最初のカップルのSQLサーバーをセットアップした後は驚きましたが、パフォーマンスに変化は見られませんでした。私が取り組んでいるサーバーの多くはVM上にあり、私が働いている大規模なエンタープライズクライアントのほとんどすべてがSQLサーバーを有効化しています。

はい、VMはオーバーヘッドコストをいくらか追加します。1つのボックスで複数のVMをホストする場合は、強力なサーバーが必要になります。注意すべき一般的なリソースの問題は、VMを追加し、利用可能なリソースを間引くことです。ある程度の成長を計画することは一般的な方法ですが、2台または3台のVMをホストするためにサーバーを購入し、現在10台のVMを実行している場合、おそらくパフォーマンスが低下します。

VMでSQLサーバーを実行しているときのパフォーマンスの問題を見たことがないと言ったら嘘をつくでしょう。しかし、パフォーマンスの低下が見られる場合は、環境に何らかの問題がある可能性があることを学びました。