221–230 of 303 posts
Also about "make-or-break": they've been saying this for all of Intel's products since at least 2022 *yawn*
Earlier quoted context omitted.
I bought a bundle with 512GB of RAM and an older 24-core EPYC (7F72) + supermicro motherboard on ebay a bit over a year ago, it was really an amazing deal and has made for a truly nice NAS. If you're okay with stuff that's old enough that you can buy decommissioned server stuff, you can get really high-quality gear at surprisingly low prices. Companies decommission hardware on a schedule after all, not when it stops…
I'm curious, what is the powe draw for such a system? Of course, it heavily depends on the disks, but does it idle under 200W? I personally feel like I will downscale my homelab hardware to reduce its power draw. My HW is rather old (and leagues below yours), more recent HW tends to be more efficient, but I have no idea how well these high end server boards can lower their idle power consumption?
Earlier quoted context omitted.
I had no idea we had socket counts so high, do you know where I could find a picture of one?
It's bit cheating because it's cluster based system: https://www.hpe.com/psnow/doc/a50004268enw So 4 sockets per chassis, up to 8 chassis in a complete system. Afaik OS sees it as single huge system, that is kinda their special sauce here.
Earlier quoted context omitted.
The biggest one for me is the way AWS security groups & IAM work. In AWS, it's straightforward to say e.g. "permit traffic on port X from instances holding IAM role Y". You can easily e.g. get the firewall rules for all your ec2 instances in a structured format. I really would not look forward to building something even 1/10th as functional as that.
And you think just anyone can set that up? No sys admin/infra guy needed? Seems pretty risky.
Meanwhile lots of enterprise firewalls barely even have a concept of "zones". Its practically not even close to comparing for most deployments. Maybe with extremely fancy firewall stacks with $ $MAX_INT service contracts one can do something similar. But I guess with on-prem stuff things are often less ephemeral, so there's slightly less need.
Earlier quoted context omitted.
I'm one of those people, and I don't agree. Before I drop 5 figures on a single server, I'd like to have some confidence in the performance numbers I'm likely to see. I'd expect folk who are experienced with on-prem have a good intuition about this - after a decade of cloud-only work, I don't. Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. I've estimated…
> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?
Earlier quoted context omitted.
> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?
The biggest one for me is the way AWS security groups & IAM work. In AWS, it's straightforward to say e.g. "permit traffic on port X from instances holding IAM role Y". You can easily e.g. get the firewall rules for all your ec2 instances in a structured format. I really would not look forward to building something even 1/10th as functional as that.
Earlier quoted context omitted.
> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?
BGP based routing is a major pain in the ass to do on-prem. If you want true HA in the datacenter you are going to need to utilize BGP.
Earlier quoted context omitted.
> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?
IAM comes to mind, with fine grained control over everything. S3 has excellent legal and auditory settings for data, as well as automatic data retention policies. KMS is a very secure and well done service. I dare you to find an equivalent on-prem solution that offers as much security. And then there's the whole DR idea. Failing over to another AWS region is largely trivial if you set it up correctly - on prem is typ…
Earlier quoted context omitted.
Yes there are scheduling issues, Numa problems , etc caused by the cluster in a box form factor. We had a massive performance issue a few years ago that we fixed by mapping our processes to the numa zones topology . The default design of our software would otherwise effectively route all memory accesses to the same numa zone and performance went down the drain.
Wait, does a single CPU chip have numa within it now, or are you only talking about multi-socket machines?
These sorts of core-density increases are how I win cloud debates in an org. * Identify the workloads that haven't scaled in a year. Your ERPs, your HRIS, your dev/stage/test environments, DBs, Microsoft estate, core infrastructure, etc. (EDIT, from zbentley: also identify any cross-system processing where data will transfer from the cloud back to your private estate to be excluded, so you don't get murdered with egr…
The main cost with on-prem is not the price of the gear but the price of acquiring talent to manage the gear. Most companies simply don't have the skillset internally to properly manage these servers, or even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. For those that do, your scaling example works against you. If today you can merge three ser…