これは、VM上の複数のSQL Serverインスタンスに適していますか？
SQLServerを利用する一連のアプリケーションには次の特徴があります。
- ユーザーはUIを介してDBを作成/破棄するため、DBAの支援なしでDBが表示/非表示になります。
- アプリケーションごとに同じ名前のDBを作成できます（それらは同じ主題に関連しており、アプリは同じセットの人々によって使用されているため）
- DBは多数ありますが、一般的には小さいです。たとえば、合計28 GBのDBが最大70個、合計2GBのDBが最大130個です。
- 一度に使用されているDBはほんの一握りです。
これらの3つのアプリケーションをサポートするために3つのインスタンスでVMを構成することについて質問されました。また、サーバー上の複数のインスタンスの質問が発生すると、DBAは通常悲鳴を上げますが、疑問に思っています。これが、祝福されていないとしても、複数のインスタンスが許容されるシナリオであるかどうか。
複数のインスタンスを実行する大規模な物理サーバーがあります。ただし、VMではありません。したがって、VMで実行するというアイデアは少し不安になりましたが、この方法で複数のインスタンスを管理するのは快適です。
考え？
これはすべて、各インスタンスのリソース消費（CPU/RAM /同時ディスクアクティビティ）と、仮想化環境の全体的な状態に基づいていると思います。仮想化はすべてリソースキューに関するものです。 1つのVM内の3つのインスタンスの累積リソース消費量に基づいて物理環境がボトルネックに達する可能性があると思われる場合は、それを3つのVMに分割することをお勧めします。 VMが小さいほど俊敏性が高く、物理マシンへの全体的な影響が少ないため、パフォーマンスが向上します。 VMが大きいほど、管理する個々のOSは少なくなりますが、リソースの消費者が増える傾向があるため、仮想環境での操作が難しくなります。
全体的な負荷が妥当と思われる場合は、VM上の3つのインスタンスで問題がない可能性があります。全体的な負荷が高く、増大している場合は、現在および将来にわたって安全を確保するために、それらを3つのVMに分割します。