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