私が勤務する IT 部門は、すべてのデータを SAN に保存して、100% 仮想化されたサーバーに移行しようとしています。まだ実行していませんが、最終的には既存の物理 SQL Server マシンも仮想サーバーに移動する必要があります。
数か月前、私は Heroes Happen Here のローンチ イベントに参加しました。SQL Server セッションの 1 つで、講演者は、これは運用システムには適していないと言いました。
だから私はいくつかのものを探しています：
これは個人的な経験から言えます。私が話している間、まさにこの問題を扱っているからです。私が現在請負業者として働いている場所には、SQL Server 開発システム用のこのタイプの環境があります。この環境でかなり控えめな BI システムを開発しようとしていますが、パフォーマンスの問題に本当に苦労しています。
単純な仮想マシンでは、TLB ミスとエミュレートされた I/O が非常に遅くなります。O/S が準仮想化をサポートしている場合 (Windows ではまだ成熟したテクノロジではありません)、準仮想化された I/O (基本的に VM の API にフックするデバイス ドライバー) を使用します。Opteron の最近のバージョンでは、ネストされたページ テーブルがサポートされているため、ソフトウェアで MMU をエミュレートする必要がなくなります (非常に遅い)。
したがって、大規模なデータ セットで実行され、(たとえば) ETL プロセスのように大量の I/O を実行するアプリケーションは、仮想化のアキレス腱につまずきます。メモリやディスク I/O に負担がかかる可能性のあるデータ ウェアハウス システムのようなものがある場合は、別のことを検討する必要があります。単純なトランザクション アプリケーションの場合は、おそらく問題ありません
私が使用しているシステムは、4x 2 ギガビット F/C リンクを備えた SAN 上のブレード (IBM サーバー) で実行されています。これはミッドレンジ SAN です。VM には 4 GB の RAM IIRC があり、現在は 2 つの仮想 CPU があります。最高の状態 (SAN が静かなとき) でも、これはXW9300の速度の半分にすぎません。XW9300には、1 つの U320 バスと 4GB の RAM に 5 つの SCSI ディスク (システム、tempdb、ログ、データ、データ) があります。
あなたのマイレージは異なるかもしれませんが、SAN上の仮想サーバーよりもI/Oの重いものを開発するために、私が説明したようなワークステーションシステムを使用することをお勧めします. リソースの使用要件がこの種のキットを超えていない限り (その場合、とにかく仮想サーバーをはるかに超えています)、これははるかに優れたソリューションです。ハードウェアはそれほど高価ではありません。SAN、ブレード シャーシ、および VMWare ライセンスよりもはるかに安価です。SQL Server 開発者版には、VS Pro 以降が付属しています。
これには、開発チームが最初から展開に取り組まなければならないという利点もあります。「ワンクリック」で簡単に展開できるアーキテクチャを考え出す必要があります。これは思ったほど難しくありません。 Redgate SQL Compare Proはここであなたの友達です。開発者は、データベース管理の基本的な実用知識も習得できます。
HP の Web サイトに簡単にアクセスしたところ、クアッドコア xeon チップ、4 GB の RAM、1x146 および 4x73 GB の 15k SAS ハードディスクを搭載した XW8600 (現在の xeon ベースのモデル) の定価は約 4,600 ドルでした。ストリートプライスはおそらくいくらか安くなるでしょう。これを、SAN、ブレード シャーシ、および VMware ライセンスの価格と、そのセットアップのバックアップのコストと比較してください。バックアップのために、必要に応じて圧縮された DB バックアップ ファイルをドロップできるネットワーク共有をバックアップに提供できます。
編集: AMD の Web サイトにあるこのホワイトペーパーでは、VM のベンチマークについて説明しています。後ろのベンチマークから、重い I/O と MMU のワークロードは実際に VM のパフォーマンスを低下させます。彼らのベンチマーク (ベンダーが提供する統計であるため、大まかに解釈してください) は、OLTP ベンチマークで 3.5 倍の速度ペナルティを示唆しています。これはベンダーが提供するものですが、次の点に注意してください。
単純な仮想化のベンチマークを行い、ベアメタルのパフォーマンスではなく、準仮想化ソリューションと比較します。
OLTP ベンチマークでは、ランダム アクセス I/O ワークロードが多くなり、ディスク シークの待機時間が長くなります。よりシーケンシャルなディスク アクセス パターン (データ ウェアハウス クエリの特性) はより高いペナルティを持ち、多数の TLB ミスがあるメモリを大量に消費する操作 (たとえば、SSAS は聖書のメモリ ホグ) も追加のペナルティを被ります。 . これは、このタイプの処理のスローダウンが、ホワイトペーパーで引用されている OLTP ベンチマークのペナルティよりもおそらく顕著であることを意味します。
ここで見てきたことは、VM では TLB ミスと I/O が非常に高価であるということです。準仮想化ドライバーと MMU のハードウェア サポートを備えた優れたアーキテクチャは、これらの一部またはすべてを軽減します。ただし、Windows Server 2003 は準仮想化をまったくサポートしていないと思います。また、Windows 2008 サーバーで提供されるサポートのレベルもわかりません。ETL プロセスや SSAS キューブのビルドに取り組んでいると、比較的控えめな仕様のベアメタル ハードウェアと比較して、VM がサーバーの速度を大幅に低下させることは確かに私の経験です。
SAN - もちろん、クラスタリングもありますが、仮想化に関しては、パフォーマンス ヒットが発生します (価値がある場合とない場合があります)。
http://blogs.technet.com/andrew/archive/2008/05/07/virtualized-sql-server.aspx
http://sswug.orgは最近、毎日のニュースレターでそれについていくつかのメモを持っていました
ブレント・オザルによるこのシリーズの記事を追加したかったのです。
私が望んでいた意味で（サーバーを構築するチーム、またはある種の公式マニュアルから）正確に信頼できるものではありませんが、Brent Ozarは非常に尊敬されており、ここですべての問題をカバーする素晴らしい仕事をしていると思います。
VMWareで900人以上のユーザーを対象とした給与システムを問題なく実行しています。これは10ヶ月間生産されています。DBに関しては中規模の負荷であり、IOの問題を防ぐためにVMにドライブスペースを事前に割り当てました。許容可能なパフォーマンスを維持するには、VMホストとVMスライスの両方を定期的にデフラグする必要があります。
ここにいくつかの VMWARE テストがあります.. http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf
確かに、彼らはそれを物理マシンと比較していません。ただし、環境に使用したツールを使用して同様のテストを行うことができるでしょう。
現在、VMWARE 環境で SQL Server 2005 を実行しています。しかし、これは非常に負荷の軽いデータベースであり、優れています。問題なく動作します。
ほとんどの人が指摘しているように、データベースの負荷によって異なります。
やみくもに実装する前に、IT 部門に適切なテストを行うよう説得できるかもしれません。
VMWare のような一般的な製品の代わりに、検討する価値のあるデータベース用に作成された特殊な仮想化製品がいくつかあることに注意してください。
私たちの会社 (200 以上の SQL サーバー) は、現在、いくつかのサーバーにHP Polyserveを展開しています。
HP PolyServe Software for Microsoft SQL Server を使用すると、複数の Microsoft SQL Server インスタンスを大幅に少数のサーバーと集中型 SAN ストレージに統合できます。HP PolyServe 独自の「共有データ」アーキテクチャは、エンタープライズ クラスの可用性と仮想化のような柔軟性をユーティリティ プラットフォームに提供します。
これを展開する主な理由は、ハードウェアの交換を容易にすることです。新しいボックスを「マトリックス」に追加し、各 SQL インスタンスが存在する場所を (シームレスに) シャッフルしてから、古いボックスを取り外します。SQL インスタンス名が変更されないため、アプリケーション チームに対して透過的です。
いいえ、特定のテストなどを指摘することはできませんが、経験上、実稼働データベース サーバーを仮想マシンに配置することは、特に負荷が大きい場合は悪い考えであると言えます。
開発でいいです。おそらくテスト（仮想ボックスの負荷の下で正常に実行される場合、本番環境でも正常に実行されるという理論に基づく）でさえ、本番環境では実行されません。
本当に常識です。ハードウェアで 2 つのオペレーティング システムと SQL サーバーを実行したいですか、それとも 1 つのオペレーティング システムと SQL サーバーを実行したいですか?
編集：私の経験は私の反応を偏らせました。私は、一定の負荷がかかる大規模なデータベースを扱ってきました。負荷が小さい小さなデータベースを使用している場合、仮想化は問題なく機能する可能性があります。
これに関する情報は、Conor Cunningham のブログ記事Database Virtualization - The Dirty Little Secret Nothing is Talking About...にあります。引用するには：
サーバー自体の内部では、パフォーマンスにとって重要なこの領域の多くのことについて、驚くほどほとんど知識がありません。SQL Server のコア エンジンは、次のことを前提としています。
- すべての CPU が同等に強力
- すべての CPU がほぼ同じ速度で命令を処理します。
- ディスクへのフラッシュは、限られた時間内に発生するはずです。
この投稿では、これらの問題についてさらに詳しく説明しています。一般的にこの問題を考えると、利用可能な情報が不足していることを考えると、良い読み物だと思います.
古い回答のある古い質問
このスレッドの答えは何年も前のものです。このスレッド全体のマイナス点のほとんどは、技術的にはまだ正しいですが、関連性ははるかに低くなります。仮想化と SAN のオーバーヘッド コストは、以前よりもはるかに少なくなっています。正しく構成された仮想化ホスト、ゲスト、ネットワーク、および SAN は、仮想化によってのみ提供される優れた復旧シナリオを含む、仮想化の利点と運用上の柔軟性を備えた優れたパフォーマンスを提供できます。
ただし、現実の世界では、構成の細部を 1 つ変更するだけで、すべてをひっくり返すことができます。実際には、仮想 SQL サーバーに関する最大の課題は、仮想化を担当する人々を説得し、協力して適切にセットアップすることです。
皮肉なことに、本番環境を仮想化から外して専用ハードウェアに戻したケースの 100% で、専用ハードウェアのパフォーマンスが屋根を通り抜けました。これらのすべてのケースで、問題は仮想化ではなく、そのセットアップ方法でした。専用ハードウェアに戻ることで、仮想化によってリソースの使用が 5 倍以上改善されることが実際に証明されました。最新のソフトウェアは通常、ノード間でスケールアウトするように設計されているため、仮想化はその面でも有利に機能します。
データに何か悪いことが起こる可能性が大きすぎると思います。
非常に単純な例として、Virtual Server 2005 R2 で SQL Server ボックスを実行し、元に戻すディスクがオンになっているとします (したがって、メインの「ディスク」ファイルは同じままで、すべての変更はパージ可能な別のファイルに行われますまたは後でマージされます）。その後、何かが発生し (通常、128GB の制限またはサイズが何であれ)、深夜に無知な管理者が再起動する必要があり、元に戻すディスクを削除するまで再起動できないことに気付きます。あなたはうんざりしています - 彼が後で分析するために元に戻すディスク ファイルを保持していたとしても、データを一緒にマージする可能性はかなり低いです。
したがって、このスレッドの他の投稿と同じように、開発にとっては素晴らしいことですが、本番環境では良い考えではありません。コードを再構築して再デプロイすることはできますが (これは別のことです。ソース管理用の VM も良い考えではありません)、実際の運用データの方がはるかに重要です。
あなたはこれを間違った角度から見ています。第 1 に、仮想化を「しない」べき理由や、仮想化する必要がある理由について、ベンダーからのホワイト ペーパーを見つけることができません。
すべての環境は異なり、環境で機能することを行う必要があります。そうは言っても、仮想化に最適なサーバーもあれば、仮想化すべきではないサーバーもあります。たとえば、サーバーが NYSE や NASDAQ にあり、数百万ドルがそれに依存している場合のように、SQL サーバーが 1 秒あたり数百万のトランザクションを実行している場合、おそらく仮想化するべきではありません。SQL サーバーを仮想化することの影響を理解していることを確認してください。
仮想化が優れているという理由だけで SQL を何度も仮想化しているところを見てきました。その後、VM サーバーが期待どおりに動作しない場合に文句を言います。
必要なことは、ベンチマークを設定し、展開するソリューションを完全にテストして、できることとできないことを示して、予期せぬ事態に遭遇しないようにすることです。仮想化は素晴らしいものであり、環境に優しく、統合によって節約できますが、SQL Server を仮想化すべきではない理由を監督者に示す必要があり、それを実行できるのはあなただけです。
Vitalization を処理するときに導入される可能性があるセキュリティの問題も考慮する必要があります。Virtualization Securityは PandaLabs による優れた記事で、いくつかの懸念事項をカバーしています。
通常、ソフトウェアを仮想化する際の最大の懸念はライセンスです。
これは、MS SQL に関する記事です。あなたの状況がわからないので、顕著な点を選ぶことはできません。
SQL Server は仮想環境でサポートされています。実際、ライセンス オプションの 1 つがソケット単位であることを確認することをお勧めします。これは、仮想化された (Windows 2008 Server Datacenter などの) システムに SQL Server インスタンスを好きなだけ配置し、マシンが持つプロセッサ ソケットごとにのみ支払うことができることを意味します。
DataCenter はソケットごとにライセンスされ、仮想マシン ライセンスも無制限であるため、それよりも優れています。
ただし、Hyper-V を 2 台のマシンにクラスター化して、1 台が失敗した場合にもう 1 台がスラックを拾うことができるようにすることをお勧めします。