How Many HCI Nodes for the SMB
-
This is to not convolute the other thread about HCI for @Jimmy9008 ...
In that thread he's asking about three node HCI setups. I often point out that two nodes is nearly always better. I wanted to kick off asking... for an SMB, does he really need to be looking at so many nodes?
-
Advantages to two nodes over three...
- Faster due to vertical growth over horizontal.
- Cheaper in nearly all scenarios, often by a lot.
- Fewer nodes to worry about breaking, more reliable hardware.
- No reason for a backplane switch making it faster and dramatically more reliable.
-
This is purely dependent on the size of the organization and isn't something we estimate easily.
-
@DustinB3403 said in How Many HCI Nodes for the SMB:
This is purely dependent on the size of the organization and isn't something we estimate easily.
It is, for sure. There is a scale of compute need where 3+ nodes are required. But it's really, really rare in the SMB to get that big.
-
@scottalanmiller How would you estimate the needs or an organization that you've not seen?
You must have some inside details on @Jimmy9008 office that I don't.
-
I was under the impression @Jimmy9008 worked in an enterprise size company, not SMB.
Anyway, it's hard to estimate what is needed because it depends on what a company does. To run a typical office you wouldn't need to run anything on-prem at all and the rest could be SaaS.
-
@Pete-S said in How Many HCI Nodes for the SMB:
I was under the impression @Jimmy9008 worked in an enterprise size company, not SMB.
Anyway, it's hard to estimate what is needed because it depends on what a company does. To run a typical office you wouldn't need to run anything on-prem at all and the rest could be SaaS.
Certainly not enterprise. Not by a long way.
-
@Jimmy9008 said in How Many HCI Nodes for the SMB:
@Pete-S said in How Many HCI Nodes for the SMB:
I was under the impression @Jimmy9008 worked in an enterprise size company, not SMB.
Anyway, it's hard to estimate what is needed because it depends on what a company does. To run a typical office you wouldn't need to run anything on-prem at all and the rest could be SaaS.
Certainly not enterprise. Not by a long way.
Ah, I'm sorry . I was probably thinking of someone else then.
-
@scottalanmiller said in How Many HCI Nodes for the SMB:
This is to not convolute the other thread about HCI for @Jimmy9008 ...
In that thread he's asking about three node HCI setups. I often point out that two nodes is nearly always better. I wanted to kick off asking... for an SMB, does he really need to be looking at so many nodes?
Depends on if management forces them to use Microsoft products. The per core licensing model means the most efficient setup is only 16 cores per server, which is really nothing today. Could easily need 3-4 of these.
Get off the windows platform and you can scale so large in a single server there is no need for more than 1, at least at the size of an SMB. Thanks to AMD Epyc it's even a reasonable price point today.
-
@travisdh1 said in How Many HCI Nodes for the SMB:
@scottalanmiller said in How Many HCI Nodes for the SMB:
This is to not convolute the other thread about HCI for @Jimmy9008 ...
In that thread he's asking about three node HCI setups. I often point out that two nodes is nearly always better. I wanted to kick off asking... for an SMB, does he really need to be looking at so many nodes?
Depends on if management forces them to use Microsoft products. The per core licensing model means the most efficient setup is only 16 cores per server, which is really nothing today. Could easily need 3-4 of these.
Get off the windows platform and you can scale so large in a single server there is no need for more than 1, at least at the size of an SMB. Thanks to AMD Epyc it's even a reasonable price point today.
Besides Microsoft there are a bunch of other software that is licensed per core or CPU of the hypervisor.
-
@Pete-S said in How Many HCI Nodes for the SMB:
@travisdh1 said in How Many HCI Nodes for the SMB:
@scottalanmiller said in How Many HCI Nodes for the SMB:
This is to not convolute the other thread about HCI for @Jimmy9008 ...
In that thread he's asking about three node HCI setups. I often point out that two nodes is nearly always better. I wanted to kick off asking... for an SMB, does he really need to be looking at so many nodes?
Depends on if management forces them to use Microsoft products. The per core licensing model means the most efficient setup is only 16 cores per server, which is really nothing today. Could easily need 3-4 of these.
Get off the windows platform and you can scale so large in a single server there is no need for more than 1, at least at the size of an SMB. Thanks to AMD Epyc it's even a reasonable price point today.
Besides Microsoft there are a bunch of other software that is licensed per core or CPU of the hypervisor.
Sure there are, I've even worked with some of them. Every single one I'd question what an SMB business needs said software for. They should be so few and far between that they're the exception that proves the rule.
-
@travisdh1 said in How Many HCI Nodes for the SMB:
@Pete-S said in How Many HCI Nodes for the SMB:
@travisdh1 said in How Many HCI Nodes for the SMB:
@scottalanmiller said in How Many HCI Nodes for the SMB:
This is to not convolute the other thread about HCI for @Jimmy9008 ...
In that thread he's asking about three node HCI setups. I often point out that two nodes is nearly always better. I wanted to kick off asking... for an SMB, does he really need to be looking at so many nodes?
Depends on if management forces them to use Microsoft products. The per core licensing model means the most efficient setup is only 16 cores per server, which is really nothing today. Could easily need 3-4 of these.
Get off the windows platform and you can scale so large in a single server there is no need for more than 1, at least at the size of an SMB. Thanks to AMD Epyc it's even a reasonable price point today.
Besides Microsoft there are a bunch of other software that is licensed per core or CPU of the hypervisor.
Sure there are, I've even worked with some of them. Every single one I'd question what an SMB business needs said software for. They should be so few and far between that they're the exception that proves the rule.
In the SMB, you don't need more than 16 cores either. So then those restrictions do not matter.
-
@travisdh1 said in How Many HCI Nodes for the SMB:
Depends on if management forces them to use Microsoft products. The per core licensing model means the most efficient setup is only 16 cores per server, which is really nothing today. Could easily need 3-4 of these.
That's pretty rare. Each core today is worth many cores a few years ago. A modern 16 core machine is like a 64 core machine from just a decade ago or less. Most companies of even 200 people would actually be fine with four cores and everything more than that is just "well, I'm licensing it, I might as well buy it."
-
@scottalanmiller said in How Many HCI Nodes for the SMB:
That's pretty rare. Each core today is worth many cores a few years ago. A modern 16 core machine is like a 64 core machine from just a decade ago or less.
That's not the case. The per core performance increase has been very modest. Instead of increasing the per core performance Intel & AMD has lowered the frequency and power requirement per core and as a result been able to increased the number of cores per chip instead.
For instance a server CPU that was a monster 10 years ago would be something like the X5690 with 6 cores @ 3.5Ghz. Today you might have something like a 8280 CPU with 28 cores @ 2.7Ghz. It's only about 25% faster per core. But you have 4-5 times as many cores.
Or in AMD's case today you might have the 7702 with 64 cores @ 2.0GHz. That's more than 10 times as many cores compared to 10 years ago, but they are still only about 25% faster.
-
@Pete-S said in How Many HCI Nodes for the SMB:
For instance a server CPU that was a monster 10 years ago would be something like the X5690 with 6 cores @ 3.5Ghz. Today you might have something like a 8280 CPU with 28 cores @ 2.7Ghz. It's only about 25% faster per core. But you have 4-5 times as many cores.
Are you thinking that clock frequency determines core performance? That's only true with the same chip, not between chip designs. Per clock cycle performance is much, much higher today than it used to be.
Remember a 1.7Ghz Pentium III would crush a 3.0Ghz Pentium 4, for example. Clock speed has always been super misleading and never a possible way to measure core performance.
-
@Pete-S said in How Many HCI Nodes for the SMB:
Or in AMD's case today you might have the 7702 with 64 cores @ 2.0GHz. That's more than 10 times as many cores compared to 10 years ago, but they are still only about 25% faster.
Let's use this example. IPC is what matters, clock speed is totally irrelevant and tells us nothing about system performance.
On a per core bases, from 2011 to 2020, AMD went from a per core performance of AMD FX-8150 at 3.15IPC/s in 2011 to AMD Ryzen 9 3950X 10.18IPC/s in 2019. A per core performance improvement of 323%. (Then it increased the core count, by a lot, as well.)
The increase per core in performance over time is normally staggering, it always has been. And this is what Moore's Law references - performance, not timing clock. The frequency is just the crystal timing circuit, it's an important part of a process under the hood, but not relevant to someone in IT, only to chip designers and electrical engineers.
That's why a four core AMD system today is roughly a 13 core system from just eight years ago. That was a LOT of horsepower eight years ago.
-
In the ARM world, which has come along a lot faster, the increase from 2008 to 2018 in per core performance rose by over 1,000%, it's pretty crazy. They went from way behind AMD and Intel, to a bit in front. Like 20% above them when both are at peak (but Intel and AMD have more cores, so per die performance remains far ahead.)
-
@scottalanmiller said in How Many HCI Nodes for the SMB:
@Pete-S said in How Many HCI Nodes for the SMB:
Or in AMD's case today you might have the 7702 with 64 cores @ 2.0GHz. That's more than 10 times as many cores compared to 10 years ago, but they are still only about 25% faster.
Let's use this example. IPC is what matters, clock speed is totally irrelevant and tells us nothing about system performance.
On a per core bases, from 2011 to 2020, AMD went from a per core performance of AMD FX-8150 at 3.15IPC/s in 2011 to AMD Ryzen 9 3950X 10.18IPC/s in 2019. A per core performance improvement of 323%. (Then it increased the core count, by a lot, as well.)
The increase per core in performance over time is normally staggering, it always has been. And this is what Moore's Law references - performance, not timing clock. The frequency is just the crystal timing circuit, it's an important part of a process under the hood, but not relevant to someone in IT, only to chip designers and electrical engineers.
That's why a four core AMD system today is roughly a 13 core system from just eight years ago. That was a LOT of horsepower eight years ago.
You read too many game sites. What you're talking about is not relevant.
-
@Pete-S said in How Many HCI Nodes for the SMB:
You read too many game sites. What you're talking about is not relevant.
I'm talking about the topic at hand.... processor throughput. It's the only relevant thing to what we are discussing. This is standard industry knowledge back in the 70s and 80s. Not sure what gaming has to do with this, but this predated PC gaming in any real fashion as standard stuff IT should know.
-
@Pete-S You state the common lay person myth that clock frequency is how CPU performance is measured. You then state that modern processors are barely faster than old ones that had dramatically less advanced technology. You gave literally zero basis for this statement, you just pulled it out of thin air without even a hint of reasoning for it.
I provided actual MIPS calculations pulled from chip measurements (IPC/s are derived from MIPS on the chips.) You can argue that there are better measurements. But your argument seems to be solely something you made up based on nothing, and claiming that the math and measurements are wrong because "gamers", which is weird because gamers have always been the non-technical people that tend to use the clock cycle numbers because they are "easy" and nothing to do with CPU performance.
Do you have a reason you believe this is wrong? Or are you sticking to "because I said so" and trying to ignore the math and measurements, common sense and long term industry knowledge (and simple observation.)
It takes extremely little effort to see modern CPUs at similar clock speeds and core counts running circles around old processors. I'm not sure how anyone could even suggest otherwise given how visible and obvious this is, and how obvious it is that billions of dollars and decades of CPU research go into nothing else.
Measuring a CPU by clock cycle and expecting to know how fast the resulting computer is is like trying to guess the performance of a car by nothing other than its red line RPM limit. It's not a useless number, if you know everything else about the car, but the gearing, horsepower, and torque are what matter, not the engine RPMs. If you know enough of the engine design, gearing, weight, etc. you can use engine RPMs to estimate certain things, but that's it, on its own, it's meaningless.
Recent example: 11th gen Intel i7 vs. 10th gen Intel i7. The top speed drops from 4.9Ghz to 4.7Ghz, while Intel claims an 11% improvement in web performance. Both CPUs are quad core, HT. i7-10610U vs i7-1165G7. How could the performance leap ahead while clock cycles drop so much, if there isn't something else that matters?
Now while we can claim that Intel is lying, and claim that CPUs are literally moving backwards, this is not realistic. The only significant move backwards that processors ever have made was the high clock cycle Pentium 4 era with clock cycles dramatically over those of the faster Pentium III processors that predated them and, ultimately, ended up replacing them. Until the early 2000s, clock cycles were often "good enough" indicators because all mainline CPU were single core, single thread and similar enough architectures. But the P4 broke all that with a huge step backwards and a massive focus on the "easy for the masses" marketing numbers of clock cycles. That's when, even pretty casual computer users, learned that simple clock cycles didn't tell them anything.
