仮想マシン内でデータベースを実行することの欠点は何ですか？どうすればそれらを克服できますか？
仮想マシン内で何かを実行すると、ある程度のパフォーマンスヒットが発生しますが、それは本当にデータベースシステムのパフォーマンスにどの程度影響しますか？
私は この学術参照論文 を興味深いベンチマークで見つけましたが、それはXenとPostgreSQLのみを使用した限定的なテストでした。結論は、VMを使用しても「パフォーマンスに高いコストがかからない」ことです（ただし、実際のデータはそうではないと思われるかもしれません）。
仮想マシン内でデータベースを実行することに関連する技術的、管理的、およびその他の欠点は何ですか？
客観的な事実に裏付けられる回答を投稿してください。推測やその他の半宗教的な議論には興味がありません（オタクの情熱は多くの点で優れていますが、ここでは役に立たないでしょう）。
とはいえ、
- 仮想マシンでデータベースを実行すると、どのような問題が発生しますか？ （参照を投稿してください）
- これらの問題は重要ですか？
- 特定のシナリオでのみ重要ですか？
- 回避策は何ですか？
多くのDBベンダーはこれを行うのが非常に遅かったのですが、ほとんどすべてのベンダーが仮想化環境で実行されているソフトウェアを公式にサポートしています。
多くのOracle 11gインスタンスをESXi上のLinuxで実行しており、非常に優れたパフォーマンスを実現することは確かに可能です。すべてのハードウェアスケーリングと同様に、仮想化Hostに十分なリソース（RAM、CPU）があり、ディスクレイヤーが何でもIO必要なパフォーマンス。
ErikAが言うように、これはますます一般的になっています。私はSQL Serverのキャンプにいて、個人的にVMで実行されている運用システムはありませんが、（このトピックについてもう少し調べた後）ためらうことはありません。ただし、そのパスに進む前に考慮すべき点がいくつかあります（少なくともSQL Serverの場合）。ディスクIO（他の人が述べたように）とメモリ割り当ては2つの例にすぎません。ハイパーバイザーが異なると、状況も異なります。
Brent Ozarは、SQL Serverの仮想化、特にVMWareの仮想化のエキスパートとして認められています。彼の資料を一読することを強くお勧めします。
http://www.brentozar.com/community/virtualization-best-practices/
canがあり、次にshould。コルベットは時速150マイルで走行できますが、公道を走行する必要がありますか？不必要に自分を傷つける可能性があります。
データベースはゲストオペレーティングシステムです。設計上、開始時にリソースのブロックを取得し、パフォーマンス上の理由から直接管理します。データベースサーバーのコアオペレーティングシステムを仮想化ホスティング環境のゲストにすると、ディスクのブロック割り当て要素とRAMとデータベースの間にハイパーバイザーが配置されたアービトレーションレイヤーが配置されます。サーバー。速度が低下します。クエリの効率が悪いほど、速度は遅くなります。これらの非効率性は、専用ハードウェアで今日マスクされている可能性がありますが、依存するリソースにアービトレーションを導入するとすぐに、すぐにわかります。
仮想化を要求している多くのBeanカウンターが認識できないのは、データベースサーバーがゲストオペレーティングシステムとして独自の統合レイヤーを提供していることです。 IPアドレスの移動、追加のホスト名の設定など、1つの物理サーバー上の統合された複数の論理データベースインスタンスを移動できない理由はありません。これにより、サービスのこの自然な結合が可能になります。また、このモデルを使用すると、管理者が物理ホストの数を減らすために求めているコスト削減を維持できるだけでなく、任意のハイパーバイザーの影響を受けずに物理リソースへのブロックアクセスを維持できます。その他。
Javaのような他のゲストOSについても同様です。仮想化ソリューションは通常ビジーな環境であり、ハイパーバイザーはリソースで誰が「トークンを取得する」かについて多くの決定を行わなければなりません。いつでもあなたはその層を排除することができ、あなたはより良くなるでしょう。
最初に、自然なゲストオペレーティングシステムレイヤーを使用して複数のインスタンスを結合します。おそらく、プラットフォームの統合とパフォーマンスの目標を簡単に達成できるでしょう。
ここで実現することが2つあります。
- ハードウェアの単位あたりのDBパフォーマンスの単位は、仮想化されたdbの場合は少し低くなります。つまり、同じレベルのパフォーマンスを得るには、もう少しハードウェアを購入する必要があります。
- これは、同じレベルまたは望ましいレベルのパフォーマンスが得られないという意味ではありません。多くの場合、管理の向上とその他の利点（HAの容易さなど）から得られる利点方法わずかに増加したハードウェアコストを相殺する以上のものです。
そうは言っても、私がSQL Serverをインストールする場所は、すぐに仮想化するつもりがない2つのサーバーのうちの1つです（もう1つはプライマリDCです）。
SQL Serverの実行は、VMで十分です。ただし、VMにアプリケーションを実行するために十分なリソースを提供できる場合に限ります。物理的な世界では、 RAMの24コアと256ギグの場合、仮想世界に24のvCPUとRAMの256ギグを提供する必要があります。
私はただ 記事を書いた 先月のSQL Serverマガジンで、VMwareのvSphereで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サーバーの設定を始めるのをためらっていました。しかし、最初のいくつかのSQLサーバーをセットアップし、パフォーマンスに変化が見られないことに驚いた。 VM=を使用しているサーバーはますます増えており、私が働いているほとんどすべての大企業のクライアントは仮想化されたSQLサーバーを持っています。
はい、VMはいくつかのオーバーヘッドコストを追加します。単一のボックスで複数のVMをホストする場合は、Nice beefyサーバーが必要になります。よく見られるリソースの問題は追加のVMを追加し、利用可能なリソースを間引きます。ある程度の成長を計画することは一般的な慣行ですが、サーバーをホスト2または3のVMに購入し、現在その10のVMを実行している場合、おそらくパフォーマンスヒットが見られます。
VMでSQLサーバーを実行しているときにパフォーマンスの問題を見たことがないと言ったら、私はうそをつくでしょう。ただし、パフォーマンスが低下している場合は、環境に問題がある可能性があります。