Would you put a MS SQL VM and a MS Exchange VM on the same host?
-
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@Grey said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@JasGot said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
What are the "musts" for a MS SQL VM and a MS Exchange VM on the same Hyper-V Server Host?
Or is it a "No...No".More of a "when wouldn't you?" Only time you'd not have them on the same host is when you are short on resources. In an SMB, I've never seen where you wouldn't put them on the same host. Even in the Fortune 100, they are often on the same host.
Exactly. It's more about utilization. If it's a 2950 running those two things for a 5000 user company, then you're fucked.
And to some degree it can be also be a matter of peak performance or latency if you will. Some workloads are low constant utilization of resources while other will consume a lot of resources but not constantly.
The MS SQL VM might be one of those. It might run very consuming SQL jobs that will starve the other VMs on resources or it will just take too long to complete.
That might be a case when you want something on different hypervisors. And you might even want different hardware. For "peaky" workloads you often want high frequency cores, which means fewer of them, and very high speed disk subsystem.
Think Ferrari versus 18 wheeler. Both are high capacity and expensive. One is high speed/little cargo and the other is low speed/lots of cargo.
That's just part of the capacity equation. Even if you split the, you still need each individual system to have the ability to handle the peaks of each. So you don't gain by separating them. If you combine them, you at least still get increased capacity for non-shared-peak times that you lose if you split.
Really, until you can't buy hardware big enough to handle both on one system, you want them together.
-
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@Grey said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@JasGot said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
What are the "musts" for a MS SQL VM and a MS Exchange VM on the same Hyper-V Server Host?
Or is it a "No...No".More of a "when wouldn't you?" Only time you'd not have them on the same host is when you are short on resources. In an SMB, I've never seen where you wouldn't put them on the same host. Even in the Fortune 100, they are often on the same host.
Exactly. It's more about utilization. If it's a 2950 running those two things for a 5000 user company, then you're fucked.
And to some degree it can be also be a matter of peak performance or latency if you will. Some workloads are low constant utilization of resources while other will consume a lot of resources but not constantly.
The MS SQL VM might be one of those. It might run very consuming SQL jobs that will starve the other VMs on resources or it will just take too long to complete.
That might be a case when you want something on different hypervisors. And you might even want different hardware. For "peaky" workloads you often want high frequency cores, which means fewer of them, and very high speed disk subsystem.
Think Ferrari versus 18 wheeler. Both are high capacity and expensive. One is high speed/little cargo and the other is low speed/lots of cargo.
That's just part of the capacity equation. Even if you split the, you still need each individual system to have the ability to handle the peaks of each. So you don't gain by separating them. If you combine them, you at least still get increased capacity for non-shared-peak times that you lose if you split.
Really, until you can't buy hardware big enough to handle both on one system, you want them together.
There can be gain to be had because you can optimize the hardware for different workloads. You don't get that in one system. And there can be gain to be had to separate them when you have latency sensitive workloads because you can avoid the noisy neighbor problem.
There also the fact that as you increase capacity on one server you will get to a point of diminishing return on your investment. You get less value for money as you get into higher end range of CPUs for instance.
You just have to know where you are on the scale of performance versus cost and how demanding the workloads are and what latency requirements there are.
I just wanted to point that out because I often see the latency part being forgotten when talking about capacity. But sure, if you take peak latency and VM interference into account when talking about capacity then it's all good.
-
And there is also the fact that servers are dominated by the cost of CPU, RAM and storage and not so much the server itself. So in some situations it can make sense to spend roughly the same money divided on two hypervisors instead of on one.
But it of course also depends on how many workloads you have. If you can handle everything on one midrange server then it wouldn't make sense to buy two.
-
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
And there is also the fact that servers are dominated by the cost of CPU, RAM and storage and not so much the server itself.
Sure, but even if the cost was equal, there are so many benefits for performance to being on just one. On the almost impossibly rare occurrence that both VMs hit peak at the exact same millisecond, then the two approaches are break even if the cost was the same. But the other 99.99% of the time (literally, or actually far more) you get the advantage of what would otherwise be idle resources. Any IOPS, RAM, or CPU not used by the other VM is available for the one that could use it. This not only makes it all faster, it also lowers the potential for peak time collisions by moving each workload out of the way faster.
Plus a single host costs less to maintain and operate.
-
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
And there is also the fact that servers are dominated by the cost of CPU, RAM and storage and not so much the server itself.
Sure, but even if the cost was equal, there are so many benefits for performance to being on just one. On the almost impossibly rare occurrence that both VMs hit peak at the exact same millisecond, then the two approaches are break even if the cost was the same. But the other 99.99% of the time (literally, or actually far more) you get the advantage of what would otherwise be idle resources. Any IOPS, RAM, or CPU not used by the other VM is available for the one that could use it. This not only makes it all faster, it also lowers the potential for peak time collisions by moving each workload out of the way faster.
Plus a single host costs less to maintain and operate.
We had a SQL server that would peak for about 30 seconds. It just depends on what it is running. Same thing with an Oracle server, it would just kill everything for up to 20 seconds or so.
-
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
We had a SQL server that would peak for about 30 seconds. It just depends on what it is running. Same thing with an Oracle server, it would just kill everything for up to 20 seconds or so.
Sure, can peak on an individual VM for a bit, but if you have more horsepower available, it'll shorten the peaks, and the only time you are concerned is, well never because each VM should be sized to handle peak, but you only have a "peak" cap when both peak at the same time - and even if each do it for 30 seconds once in a while, the chances that that 30 seconds is at the same time, especially once you add way more overall power, drops to essentially never.
The issue with "killing everything" means that you are dealing with a single system that was designed for only one VM to hit peak, not two (or more.) By definition, a peaked VM as we are describing can't kill the system because the system has the capacity to handle both peaks at once. So you can't compare to a system where it was sized for half that workload, of course that will have problems but not because they are on shared hardware, but because that shared hardware was the wrong size.
-
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
We had a SQL server that would peak for about 30 seconds. It just depends on what it is running. Same thing with an Oracle server, it would just kill everything for up to 20 seconds or so.
Sure, can peak on an individual VM for a bit, but if you have more horsepower available, it'll shorten the peaks, and the only time you are concerned is, well never because each VM should be sized to handle peak, but you only have a "peak" cap when both peak at the same time - and even if each do it for 30 seconds once in a while, the chances that that 30 seconds is at the same time, especially once you add way more overall power, drops to essentially never.
The issue with "killing everything" means that you are dealing with a single system that was designed for only one VM to hit peak, not two (or more.) By definition, a peaked VM as we are describing can't kill the system because the system has the capacity to handle both peaks at once. So you can't compare to a system where it was sized for half that workload, of course that will have problems but not because they are on shared hardware, but because that shared hardware was the wrong size.
But it's just not cost effective to scale vertically ad infinitum. There is a sweet spot where you get the most performance per $ and it's not in the high end, it's in the mid range or low mid range. So two mid-range servers that cost (TCO) the same as one high-end will have more computing power combined.
Just got to find the sweet spot and if you are over it you add a another hypervisor instead of buying a bigger hypervisor.
-
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
But it's just not cost effective to scale vertically ad infinitum. There is a sweet spot where you get the most performance per $ and it's not in the high end, it's in the mid range or low mid range. So two mid-range servers that cost (TCO) the same as one high-end will have more computing power combined.
Just got to find the sweet spot and if you are over it you add a another hypervisor instead of buying a bigger hypervisor.Of course, which I mentioned. Pretty much until your architecture changes, it's far cheaper to go bigger in a single box. Given the power of small systems today, almost no SMB ever even looks at anything but the entry level equipment level because even a single mid-range server is normally far beyond the needs of even a company of a thousand or more users. Exceptions, but generally.
It's extremely rare to find workloads where two smaller servers don't cost at least a little more than having the same resources combined. Generally having the power combined is far cheaper, even ignoring it's overall massive performance and operational benefits. Again, exceptions, but in nearly all cases.
It's always been the rule of thumb that you scale vertically until you just can't anymore. Horizontal scaling is far more complex and expensive than vertical scale, but it can go much larger. The thing is that in the 1990s, we had so little vertical headroom that we all went horizontal all the time, we had to. Today, essentially no SMB needs to because we can always grow vertically.
Even ~10 years ago, the SQL Server rule of thumb was that it was cheapest to go vertically until you topped 128 physical processors and several TB of RAM. That would, even then, thousands of cores and you could go much larger today. Vertical scaling is so much more efficient in so many ways, it's nearly unbeatable (for cost and performance.)
-
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
Vertical scaling is so much more efficient in so many ways, it's nearly unbeatable (for cost and performance.)
Not when you have many workloads and there are lots of things that proves this. But I know you're the master of relentless posting so I'm just respectfully going to bow out
-
@Pete-S said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
@scottalanmiller said in Would you put a MS SQL VM and a MS Exchange VM on the same host?:
Vertical scaling is so much more efficient in so many ways, it's nearly unbeatable (for cost and performance.)
Not when you have many workloads and there are lots of things that proves this. But I know you're the master of relentless posting so I'm just respectfully going to bow out
How does "many workloads" even factor in? Nothing you've mentioned gives a reason for your position. There's no logical reason and nothing in the real world supports that horizontal scaling somehow saves money. This goes against all industry knowledge, common sense and observation. Even your own examples, you pointed out that the factors you were using were wrong and didn't show what you were using them to show. Just posting unsupported random misinformation and "bowing out" before we ask for some explanation just makes it seem like you were just saying those things to say them and don't believe them yourself.
In your last "example", the more workloads you have, the more horizontal scaling wastes money. Vertical scaling specifically crushes horizontal in cost/performance the more numerous and disparate the workloads are. Vertical scaling is where you get the huge cost/performance benefits of shared hardware. And, of course, people trying to make shared hardware look bad with underspec it or misconfigure it and try to say that that makes it bad, but you can underspec or misconfigure anything. Mathematically, vertical scaling works better. It's plain physics, you can't just state that physics aren't real and act like you have special insider knowledge of the universe that no one else has and cannot be demonstrated with real computers.
