パフォーマンス上の理由から、データベースのパーティション分割は仮想化環境で意味がありますか？
物理ハードウェアでSQLサーバーを実行している場合、データベースデータとログファイルを別々のディスクまたはRAIDアレイに配置すると、パフォーマンス、回復力、およびメンテナンスにメリットがあります。データベースを個別の物理ディスクとRAIDアレイにパーティション化することもオプションです。簡単に言えば、スピンドルが多いほど良いです。
SQLサーバーが仮想環境で実行されている場合、スピンドルの概念は異なる方法で適用されます。多くの場合、仮想ディスクがマップされている物理ディスクを直接制御することはほとんどありません。これは、物理ディスクの場合と同じように、データベースをパーティション化したり、データとログファイルを別々の仮想ディスクに分割しても意味がないことを意味しますか？
仮想環境で引き続き適用されるデータベースを分割する他の理由があることを理解しています。たとえば、大きな読み取り専用テーブルは、1回だけバックアップする必要がある別のパーティションに置くことができますが、これはこの投稿の主題ではありません。
これは古い質問ですが、私はこれに遭遇し、1つの特定のコメントにびっくりしました。元の質問は「混乱」していることを示唆しています。問題は完全に明確で、データベース管理については厳密ではありません。何よりも、仮想環境でのサーバー仮想化とストレージプロビジョニングの分野に該当します。この質問は別のStackExchangeサイトに適していた可能性がありますが、問題が理解できないことを容認できないため、傲慢に質問を却下しました。
検索エンジンによってここに落とされる可能性のある他の人のためにここに何か有用なものを残すために、質問をよりよく説明し、この件に関して最善のアドバイスをします。
データベースサーバーを展開する場合、OS、データファイル、ログファイルを別々のディスクセットに配置することがベストプラクティスであると考えられています。ランダムな例として、3つのRAIDアレイで構成されるサーバーがあるとします。
OS 1の場合はRAID 1に2台のHDD、データベースデータファイルの場合はRAID 10に4台のHDD、データベースログファイルの場合はRAID 10に4台のHDDこのセットアップは、IOを分離し、データファイルとログをOSから分離するだけでなく、パフォーマンス、復元力、メンテナンスの理由から行われました。
では、データベースサーバーを仮想環境に展開する場合はどうでしょうか。仮想環境に物理ディスクはありません。仮想マシンのディスクを物理ディスクに1：1でマッピングしない限り、実際にはありません。これは、通常の仮想サーバーファームで行われるものとは異なります。その場合でも、物理ディスクと仮想サーバーの間に仮想化レイヤーが存在し、ディスクが実際に接続されている物理コントローラーではなく、仮想ディスクコントローラーに接続されている物理ディスクを提示します。
それで問題は何ですか？例として、小さな仮想サーバーのデプロイメントを考えてみましょう。仮想化クラスターで実行されている一連のラックサーバーと1つのSAN RAID 5とRAID 6の一連のディスクグループで自動ストレージ階層化。すべての仮想ディスクはSAN。
ここで、仮想データベースサーバーに個別の物理ディスクグループをどのように割り当てますか？または多分あなたはしませんか？それがここで尋ねられた質問でした。有用な回答はありませんでした。当然のことながら、回答は特定の展開に大きく依存する複雑な質問です。一部の設定では、仮想ディスクの種類と特定の物理ディスクを非常に厳密に制御できますが、その他の設定では、すべてを自動的に処理するブラックボックスのようなものがあります。
上で概説した簡単な「1 SAN」の例では、実際にそうする必要はないと言います。しかし、あなたはまだしたいかもしれません。 IOの最終的な物理ディスクを実際に制御できない場合でも、データを分割することには他の利点があります。将来、新しい仮想環境に移行した場合、異なる既知のパフォーマンス特性を持つ個別のLUNを取得しますか？データがすでにいくつかの仮想ディスクに分割されている場合、適切なIO機能を備えた新しいLUNに移動する方がはるかに簡単です。多くのハイパーバイザーでは、また、仮想ディスクにさまざまなIO=優先順位を与えることができます。これにより、いくつかの追加の制御が可能になります。スナップショットの動作をより正確に制御することも可能になります。同じサーバー上の他のデータベースやOS自体と共有する必要はありません。
基本的に、これは、パフォーマンス要件、データベースのサイズ、ハイパーバイザーとストレージソリューション、そしてその他多くの要因に要約されます。いくつかの役立つヒントを指摘したと思います。事前に計画します。 SAN/NASソリューションを備えた仮想環境は多くの点でブラックボックスのように見えますが、それらの多くは、従来の直接ストレージと同じパフォーマンスと冗長性の目標を達成する方法を備えています。
クエリがそれを利用できるようなものである場合、パーティションの削除は、仮想環境でもパーティションを作成する非常に良い理由です。
仮想環境と非仮想環境でディスクが重要であることを証明できます。1日の終わりに、ハイパーバイザーレイヤーが追加されているかどうかにかかわらず、物理現象です。最終的にはディスクに永続化する必要があるため、書き込みの場合は2倍になります。
必要なデータがSQL Server（ベーステーブル）内のメモリになく、クエリがそれを読み取る必要がある場合、データは絶対にディスクに移動して読み取られます。
たとえば、ディスク秒/読み取りと書き込み、およびディスク読み取りバイト/秒と書き込みバイト/秒のperfmonカウンターをオンにします。これにより、SQL Serverが要求しているデータの量がわかります。したがって、スピンドルの問題は常に重要です。
トランザクションログとデータディスクを分離することが2つの主な理由で重要でした：
1-ACIDコンプライアンス。データディスクに障害が発生した場合でも、「ログの末尾」のバックアップを取り、DBを復元できます。
2-トランザクションログは、書き込みが多く読み取りが少ないため、データドライブを混在させることも、読み取りだけを行うこともできます。ワークロードに基づいてそれらを分離すると非常に役立ちます。
仮想化について少し混乱しているかもしれません。どの仮想化プラットフォームを使用していますか？私はまだあなたがドライブをマップすることをあなたが選択することを許可しないものに遭遇していません。ハイパーバイザーが使用可能なホストのリソースを最大限に活用する方法を決定できるようにするデフォルトの構成と設定がありますが、オーバーライドして「仮想ドライブC：/を物理ドライブにマップする」ことを許可しないオファリングを見たことがありませんC：/、D：/〜D：/ "など.
質問に答えるには、いいえ、2つの仮想ドライブC：/とD：/があるが、どちらも物理ドライブC：/にマップされている場合、仮想ドライブ間でデータベースファイルを分割してもメリットはありません。 。ネットワークドライブも使用する場合は、信じられないほどのネットワーク構成がない限り、外部ドライブへの書き込みは高価で時間がかかるため、実際にはパフォーマンスが低下する可能性があります。そのパフォーマンスの向上が必要な場合は、新しい仮想ドライブを作成し、それを物理ハードウェア上の別の非ネットワークドライブにマッピングすることをお勧めします。
同じ構成の仮想サーバーに別の高負荷DBを配置しないようにしてください。両方が同時に物理ドライブにアクセスしようとすると、待機中のパフォーマンスが失われるためです。他のDBがそのドライブを使用してビジーである間の、そのドライブの読み取り/書き込み時間。
全体として、追加の物理ドライブを追加し、ハードウェアの2つの物理部分にmdfファイルとtlogファイルを分割するまでのパフォーマンスが心配な場合（おそらくリソースの制約がすでにあることを示しています）、次の場合は仮想化しないことをお勧めします。すべて可能な。非常にトランザクションが多く、リソースを大量に消費するDBは、すでに不足しているマシンリソースを複数の仮想クライアントとハイパーバイザーに分割することで本質的にパフォーマンスを低下させるため、仮想化の最適な候補ではありません。私が管理している現在の設定では、まさにこの理由により、DB以外のすべてを仮想化しています。