MSSQL：共有ハードウェア上の個別のインスタンスとしてdevデータベースとprodデータベースを分離しますか？
データベースバックエンドを備えた小さな内部Webサイトをホストする小さな仮想化環境があります。現在、同じハードウェアで実行されている別々のVMでWebサーバーとデータベースサーバーを分離しています。
ただし、dev/prodデータベースサーバーを同じVMに統合し、別々のインスタンスを使用する方がよいのではないかと思います。冗長性のためにSQLミラーリングを使用しているので、理論的には4つのSQL VMから2つに減らします。利点は、管理するVMが少なくなり、リソース割り当てが複雑でなくなり、devとprodの両方が同じパッチ/サービス上にあることが保証されることです。パックレベル。
このアプローチの欠点は何ですか？ WindowsサーバーにデフォルトのMSSQLインスタンスをインストールする場合、インストーラーを再度実行して2番目の（名前付き）インスタンスを作成し、それを他の環境に使用できますか？最後に、両方を同じVMに割り当てた場合、異なるインスタンスを別々のIPアドレスの背後に配置することは可能でしょうか？
管理するVMの数を減らすことは、サーバーの無秩序な増加を減らすための優れたインセンティブです。 MSSQLのインスタンスを使用して、開発環境を本番環境から分離するのは非常に簡単です。一般に、説明したのと同じくらい簡単です。インストーラーを再度実行して、2番目の（名前付き）インスタンスを作成します。
次に、SQL Server Configuration Managerを使用して、指定されたインスタンスをサーバー上の任意のIPアドレスにバインドできます。 SQL Server Network Configuration >> Protocols for <INSTANCE NAME>の下にあります。
これを行うことの欠点には、標準のパフォーマンスの問題が含まれますが、これらがトラフィックが少ない場合は、ほぼ確実に問題が発生することはありません。
確かに、複数のMSSQLインスタンスを設定し、それらを別々のIPにバインドすることができます。ただし、本番環境と開発環境を分割する目的である場合は、これに反対することをお勧めします。
開発リソースが本番リソースを消費しないように、開発と本番を完全に異なる物理サーバー/ VMに保持することを好みます。すべてを消費し、ボックスをひざまずく開発マシンに暴走するプロセス/コードがあることは珍しいことではありません。これは明らかに生産には良くありません。開発環境のダウンタイムは、本番環境に影響を与えるべきではありません。
明らかに、ホストマシンにはまだ共通分母があるので、そこに問題があると、すべてを停止する可能性があります。本質的にVMレベルでリソースを共有していますが、少なくともそうはなりません。 VM内で競合が発生しています。
また、本番OSのセキュリティが開発セキュリティとは完全に異なり、相互に排他的である[かなり一般的な]ケースもあります。この場合、別のサーバーに戻ります。
編集：
影響が少ないことは理解しています。それはあなたが自分で検討しなければならないことです。ただし、クエリのパフォーマンスが低いと、サーバーの寿命が短くなる可能性があることに注意してください。それが本番環境の問題ではない場合は、複数のインスタンスで問題ありません。 SQLインスタンスに最大メモリ制限を設定することをお勧めします。これは、それを緩和するのに役立ちます。
さらに簡単なアプローチは、SQLServerの同じインスタンスで2つのデータベースを使用することです。これは、2つの異なるインスタンスを必要とするやむを得ない理由がない限り、私が行うことです。
とにかく、はい、同じ（物理/仮想）サーバー上に2つのインスタンスを非常に簡単に置くことができます。セットアップを再度実行し、名前付きインスタンスをインストールすることを指定する必要があります。