4 ms·

What exactly is considered when putting a dc together that jumps you from knowing that instead of maybe a very large/massive cluster of whatever 1024 core serve

by swozey 3y ago

What exactly is considered when putting a dc together that jumps you from knowing that instead of maybe a very large/massive cluster of whatever 1024 core servers your project needs a mainframe? I've been in cluster infra for like 15 years and couldn't tell you pretty much anything about mainframes other than a few names of them and processors. Is it some sort of determined raw performance metric, teraflops of some processing work?

jl6 3y ago
The #1 reason by far for buying a mainframe is that you already have mainframe-based applications that you need to keep running. I’m not sure what kind of orgs (if any) are buying mainframes today as new customers, but I imagine it would have to be a use case something like… a niche scaling challenge, or an outsourcing arrangement where the relationship with IBM is not just vendor lock-in but is some kind of partnership, or you have specialist compliance requirements, or contractual service level obligations, or you need to provide absolute guarantees about the performance/availability/security of the whole stack from hardware up. Some organizations will pay $$$$$$$ to have one ass to kick rather than herd multiple vendors.
indrora 3y ago
Mission criticality, insane parallelism, and a few others. With modern mainframes, you can configure two processors (or more!) to run in perfect lockstep. If one of them disagrees, the system can immediately see why and how. Run three processors in lockstep and you have quorum: One disagrees? Kill it, clone one of the others, keep going. Or, isolate it, snapshot the disagreement, hold it hostage (but alive!) and bring in a clone of the others. One of the guarantees of IBM Z/System is "Every read is perfect, every write works." You don't have 2-3 bits of ECC, you have nearly fully redundant RAM. Oh now it has to be encrypted in transit, at rest, and in process? Not a problem, it can do that without changes in code. IBM's mainframes take SIMD a step further. Let's say you're parsing JSONL. With a little work, you turn a traditional serial process into a parallel one, and what would be a massive map-reduce problem is just a matter of openMP coordination. Or better yet, since it's just lines, you can make the system pretend it's a tape full of records that happens to be interleaved by, magically, a bunch of local cores! Amazing. Oh, and now the boss says you need to have physical redundancy. Why stop there? Run your application, in lockstep, across multiple systems separated by miles. Don't need it in lockstep? That's fine, your application still thinks it's running inside one head when it's running inside many independent heads. Oh you need to take down us-west-2b? Hold on let me move that entire workload to us-west-1a. There's also Kubernetes... Here's a good talk on such things: https://www.youtube.com/watch?v=3-NC6ntYAy4 https://www.youtube.com/watch?v=3-NC6ntYAy4

by swozey 3y ago

jl6 3y ago

The #1 reason by far for buying a mainframe is that you already have mainframe-based applications that you need to keep running. I’m not sure what kind of orgs (if any) are buying mainframes today as new customers, but I imagine it would have to be a use case something like… a niche scaling challenge, or an outsourcing arrangement where the relationship with IBM is not just vendor lock-in but is some kind of partnership, or you have specialist compliance requirements, or contractual service level obligations, or you need to provide absolute guarantees about the performance/availability/security of the whole stack from hardware up. Some organizations will pay $$$$$$$ to have one ass to kick rather than herd multiple vendors.

indrora 3y ago

Mission criticality, insane parallelism, and a few others. With modern mainframes, you can configure two processors (or more!) to run in perfect lockstep. If one of them disagrees, the system can immediately see why and how. Run three processors in lockstep and you have quorum: One disagrees? Kill it, clone one of the others, keep going. Or, isolate it, snapshot the disagreement, hold it hostage (but alive!) and bring in a clone of the others. One of the guarantees of IBM Z/System is "Every read is perfect, every write works." You don't have 2-3 bits of ECC, you have nearly fully redundant RAM. Oh now it has to be encrypted in transit, at rest, and in process? Not a problem, it can do that without changes in code. IBM's mainframes take SIMD a step further. Let's say you're parsing JSONL. With a little work, you turn a traditional serial process into a parallel one, and what would be a massive map-reduce problem is just a matter of openMP coordination. Or better yet, since it's just lines, you can make the system pretend it's a tape full of records that happens to be interleaved by, magically, a bunch of local cores! Amazing. Oh, and now the boss says you need to have physical redundancy. Why stop there? Run your application, in lockstep, across multiple systems separated by miles. Don't need it in lockstep? That's fine, your application still thinks it's running inside one head when it's running inside many independent heads. Oh you need to take down us-west-2b? Hold on let me move that entire workload to us-west-1a. There's also Kubernetes... Here's a good talk on such things: https://www.youtube.com/watch?v=3-NC6ntYAy4 https://www.youtube.com/watch?v=3-NC6ntYAy4