我有一个小的虚拟化环境，托pipe一个内部数据库后端的小型网站。 我目前已将我的Web服务器和数据库服务器分离到运行在相同硬件上的单独虚拟机上。
但是，我想知道是否更好的策略可能是将dev / prod数据库服务器整合到同一个VM上，但使用不同的实例？ 我使用SQL镜像来实现冗余，所以我理论上从4个SQL虚拟机到2个虚拟机。优点是可以pipe理更less的虚拟机，更简单的资源分配，并保证dev和prod在同一个补丁/服务包级别。
这种方法有什么缺点？ 如果我在Windows服务器上安装默认的MSSQL实例，我可以再次运行安装程序来创build第二个（已命名）实例并将其用于其他环境？ 最后，如果我将两个分配给同一个VM，是否可以将不同的实例放在不同的IP地址后面？
拥有较less的虚拟机pipe理是减less服务器蔓延的一个很好的动机！ 使用MSSQL实例将开发与生产环境分离起来非常简单。 通常和描述它一样简单 – 再次运行安装程序以创build第二个（已命名）实例。
然后可以使用SQL Server Configuration Manager将命名实例绑定到所需服务器上的任何IP地址。 它是在SQL Server Network Configuration >> Protocols for <INSTANCE NAME> 。
这样做的缺点包括标准的性能问题，但如果这些stream量很低，则几乎肯定不会遇到任何问题。
您当然可以设置多个MSSQL实例并将它们绑定到不同的IP。 不过，如果是为了分裂生产和开发环境，我会推荐它。
我更愿意在完全不同的物理服务器/虚拟机上进行开发和生产，以免开发资源消耗生产资源。 在开发机器上出现失控进程/代码的情况并不罕见，这些进程/代码会消耗所有东西，并使得机器瘫痪。 这显然不利于生产。 开发环境的停机时间不应影响生产。
很明显，你的主机仍然有一个共同的标准，所以任何错误的东西仍然有可能会把你固有的共享虚拟机资源的所有东西都取下来，但是你至less不会在虚拟机中产生争用。
生产操作系统的安全性与开发安全完全不同，并且是相互排斥的[相当典型的]情况。 在这种情况下，你回到不同的服务器。
编辑：
我明白这个影响不大，这是你必须自己去衡量的。 但请记住，性能不佳的查询也可能会影响服务器的使用寿命。 如果这不是你的生产环境的问题，那么你会好的多个实例。 你可能会想要在你的SQL实例上设置最大内存限制，这将有助于缓解这一点。
更简单的方法是在同一个SQL Server实例中使用两个数据库; 这是我会做的，除非我有令人信服的理由需要两个不同的例子。
无论如何，是的，你可以很容易地在同一个（物理/虚拟）服务器上有两个实例。 你只需要再次运行安装程序并指定你想安装一个命名实例。