SQL Server VM Sizing – How to Size SQL Server VM Comparable to Bare Metal

SQL Server instances have separate sets of binaries for each installation. For the base engine, you will have separate SQL Server and SQL agent services that can run under separate accounts. They each have their own configurations and users. This is also true for other components like Analysis Services and Reporting Services if you install them.

There are shared components, including Management Studio, Integration Services, and the SQL Browser service. You can find a full listing of shared components here.

Note, you will have several considerations to make when maintaining different instances:

• SQL Version consistency (each instance can be of a different SQL version)
• Memory Settings - Each instance will maintain a memory pool separate from the other instances. You will want to plan out your Max Memory settings for each instance so that the different instances won't compete with each other.
• Possible CPU contention - All instances will make use of the same CPU cores. You can manage the processor affinity mask if you want to reserve threads for different instances, but I haven't had much of a need for that.

Overall, you'll need to keep in mind that all your instances will be competing for resources on the same server, so balance those resources accordingly.

Couple of points of clarification. Nodes and replicas are not the same thing. Nodes refer to the Windows Failover cluster and replicas to AvailabilityGroup instances. So assuming you are running a 2 node WSFC, each hosting a SQL instance in an AvailabilityGroup, then yes, you will need another server to achieve quorum and avoid split brain behavior. The easiest way to achieve this is simply set up a quorum file on another server outside of the cluster, known as Node and File Share majority. Read more on WSFC Quorum Modes.

You don't necessarily need to commission a new server for this. Any server outside of the server will work.