データベースサーバーとデータストレージの仮想化技術の長所と短所
昨日、パフォーマンスと復元可能性について話し合ったところ、仮想化環境がどれほど多くの優れたものをもたらすことができるかを理解しました。しかし、パフォーマンスについて少し懐疑的であるので、ここで質問します。それは少しGIS固有かもしれませんが、gis-usersで彼らはデータベース固有のものであると言いました...;）
データベースサーバーは、仮想化によってパフォーマンスが大幅に低下しますか？私はテクノロジーを細部まで理解していませんが、どういうわけかそれは「ブラックボックス」であり、ハードウェアで処理する必要があります。また、PostGISが提供するすべてのトリックで、ディスクアクセスは許可されますか？ （クラスタリング、インデックスなど）-断片化されたクラスタリングは、クラスタリングがないようなものです！
大きな利点は、メンテナンスとスケーラビリティです。深刻なハードウェアの誤動作が発生した場合、数分以内に、またはリアルタイムで別の物理マシンに移行できます。
誰が経験を持ち、このトピックに関する優れたWebサイトや文献を紹介できますか？最近のフォスギのいくつかのことと、ESXiとネイティブサーバーの社内ベンチマークのいくつかを覚えていますが、それが良いかどうかはどうにも決められません。
これは、「状況によって異なります」という質問の1つです。
パフォーマンスは、リソース、競合、構成、およびVMエンジンに依存します
ncontended VM Host：適切にリソースを割り当てた場合VM競合しないハイパフォーマンスがローカルに接続されている、またはSANストレージ、CPUリソースの競合が少ない、メモリのオーバーコミットまたは競合がない、高速の専用ネットワークアクセスなど、通常は適切に調整されたVMエンジンで非常に良好に実行されます。正確な結果はVM使用されているシステム、リソースへのアクセスを提供する方法などに依存します。
低い競合率と優れたストレージが保証されたハイエンドVPSプランで素晴らしい結果を得ることができます。
Contended/under-resourced VM Host：他の3つのアプリケーションサーバーおよびファイルサーバーと同じボックスに配置した場合、すべて同じRAID 5を共有する配列との戦いRAMおよびCPU、それはひどく実行されます。
安価なオーバーサブスクライブおよびオーバーコミッティのVPSホストに配置すると、同様に悪い結果が得られます。 RAMがホストのディスクで実際にスワップされている場合、何も高速になることはありません。
"In the cloud"：EC2、Azureなどに配置すると、パフォーマンスはサービスの競合率、ユーザーが使用しているストレージ、他のユーザーが行っていること、 QoSがどれほど優れているかなど、他にもたくさんあります。
少なくともEC2の場合、ディスクサブシステムのパフォーマンスは恐ろしいものであり（標準のVMでは少なくとも2012年は）、RAM少なくともインデックスをキャッシュするのに十分な数がある場合にのみ正常に動作します。Amazonは新しいI/Oの高いインスタンスの方が良いかもしれませんが、ベンチマークはまだ見ていません。
通常、中間の結果が得られます高品質のハイエンドの仮想プライベートサーバーホストなど、まともなディスクを使用した軽く競合するホスティングを選択した場合。
直接vs VM保証
VM設定に依存する、ファイルの順序などについての具体的な保証。ファイルをベースとするVMを使用していますか？rawブロックデバイスを使用していますか？iSCSI SANを使用していますか？ VMエンジンが構成され、正確にどのVMシステムを使用しているか。
最良の場合
最良の場合-オールパラバートドライバー、VT-x、VT-IO、ホストリソースへの無制限のアクセスなどを備えたシステム-おそらく、ホストにかなり近いパフォーマンスが得られます。 VMストレージのホストファイルではなく直接ブロックデバイスを指定すると、ホスト側の断片化なしで適切なファイルの順序が得られます。厳密にどれだけ近いかは、特定のハードウェア、ホスト、ゲストに依存します。構成など;ワークロードでベンチマーク。
fsync（）と書き込み耐久性
VMで注意することの1つは、ディスクシステムがfsync（）について真実を伝えていることを確認する必要があることです。 VMを大幅に高速化する非常に簡単な方法は、fsync（）要求を無視することです。 VMホストがクラッシュするか電源が失われるまでは問題ありません。その時点でデータベースが絶望的に破損する可能性があります。VMホストはfsync（）を尊重する必要がありますゲストOSのディスクフラッシュコマンドを尊重してリクエストを送信するか、電源が失われた場合でも消えない不揮発性書き込みキャッシュを提供する必要があります。一部のSANはSSDを使用しているため、他のほとんどのシステムはバッテリーバックアップRAIDコントローラキャッシュメモリを使用します。 VMは、1秒あたり数百を超えるトランザクションを処理できるため、fsyncまたは書き込みキャッシュストレージを無視している可能性が高く、データを食べる前にどれを見つける必要があります。
しかし、なぜ？
（更新）：Chris Traversが指摘したように、なぜDBサーバーを仮想化する必要があるのですか？レプリケーション、ハートビート、フェイルオーバーをDBサーバーレベルで処理し、レプリカの昇格を介して移行して、ベアメタルの完全なパフォーマンスを取得してみませんか？
私はVMが与えられたという考えでこの元の応答を書きました、そして問題は最良の結果を得る方法でした。DBサーバーの最良の仮想化はまだ私の心の中で、つまり、私はかなり小さなサイトしか管理していません。
一般に、VM上のデータベースサーバーについて疑問があります。前の回答のとおり可能であることに疑いはありませんが、特にPostgreSQLの複雑さの損失として私は印象を受けます。この場合、異なるIPアドレスまたはポートであれば、仮想化なしで同じシステムで複数のクラスターを実行できます。
プロ側で話題になるのは、サーバーを統合できるということです。これは、同じサーバーで複数のインスタンスを実行することが合理的に実行できない他のRDBMSシステムで最も役立ちます。場合によっては、パフォーマンスにある程度の柔軟性を提供することがあります。特にローエンドのアプリケーションの場合、これらは説得力のある利点になる可能性があります。
ただし、これらは、VMが非常にブラックボックスであり、特にクラウド上で実行している場合、ハードウェアを制御できないという事実に対して重み付けする必要があります。これは、そのようなサーバーが特に影響を受けやすいディスクI/Oは、多くの場合、ユーザーの制御外にあり、ネットワークストレージでこれを軽減することが可能です。
したがって、私が見る方法は次のとおりです。仮想化は、発生している特定の問題を解決する場合、各クラスターのディスクI/Oを制御できる環境にすでにいる場合に役立つソリューションです。ただし、多くの場合、問題を探すためのソリューションであり、複雑さの勝利ではありません。この質問をしている場合、それはあなたにとって正しい解決策ではありません。