5 ms·

> Being able to run everything out of a single computer is an incredible virtue, not some curse that must be cast to the clouds. Isn't the problem then: what h

> Being able to run everything out of a single computer is an incredible virtue, not some curse that must be cast to the clouds. Isn't the problem then: what happens when take computer goes down? I'm also on the side of "know your hardware", but the topic of resilience is a different one. Also, perhaps you didn't mean "single computer" in the literal way: it's not incompatible with avoid the cloud, though.

withinboredom 5y ago
I built a production grade cluster for fun. It’s only three nodes… without anything installed on my 40 core cluster, except k8s and longhorn, it’s idling at 30% cpu usage. When I started up a managed cluster on Azure, I was throwing hundreds of euros at their logging storage just idling, so I noped to bare metal.
- KronisLV 5y ago
  This mirrors my experience with K8s, though one can suggest that the software running on the cluster also played a part in it. Have you looked into K3s or other lightweight distros of Kubernetes, though? https://k3s.io/ https://k3s.io/ That's what i turned to when i needed to learn the Kubernetes API and explore running clusters, but didn't like my small VPSes (~4 GB of RAM) failing to launch anything because of the frankly insane resource usage of full K8s clusters.
bob1029 5y ago
I did mean single computer in terms of 1 active primary machine at any given time. Negotiate the advantages of this architecture with the business. For the systems I've built, synchronous log replication is a natural extension of the performance abstraction, and provides fairly robust protection when some manual intervention is allowed.
gjulianm 5y ago
A good thing with "single computer" is that you have less complexity going into it so failures will be less frequent. For a lot of cases, that will be enough. It's also easier to build a resilient system starting from a single machine than from a cluster: less components to replicate to ensure they're redundant.
- jiggawatts 5y ago
  Something I've been telling customers for years is: I would rather have a standalone SQL Server Standard Edition instance on VMware than an Enterprise Edition cluster on anything. Simple means that there's less things to break. This isn't just academic. My experience with clusters is that the clustering itself causes more problems than it solves. (Don't think this is somehow isolated to Windows. ZooKeeper will refuse to start after a power outage for no discernible reason. Etc...)
  - thow-58d4e8b 5y ago
    > My experience with clusters is that the clustering itself causes more problems than it solves. There's also a whole slew of failure modes that are capable of bringing down entire clusters if a single machine misbehaves. Usually to do with situations where the nodes are reachable, but some resource (I/O, latency, bandwidth) is uncharacteristically slow on one of the machines. I'm yet to encounter a distributed system that handles that situation well
    - travisjungroth 5y ago
      Some people see small twin engine airplanes as safer than single engine. Single point of failure and all that. The problem is that the two engines of an airplane aren’t independent of each other in the factors that threaten an engine. Same pilot, same fuel. Separate mechanical parts, but that’s a minority of issues. Most engine-outs in small airplanes are caused by running out of fuel. Your two engines don’t help you there. If anything it’s more likely because of mismanaging the complex fuel system. The most common phase for loss of an engine is on take off (misfueled, mechanical issue). This is what your comment reminded me of. With two engines, you’re more likely to have a mechanical issue on take off. While it’s generally theoretically survivable, handling one-sided power loss on takeoff requires a quick and counterintuitive response. That requires consistent training, more than most pilots do. In a small, recreational twin, the most common outcome for an engine misbehaving on take off is it rolls the airplane, taking down the whole cluster.
  - GiorgioG 5y ago
marcosdumay 5y ago
Well, you either fail the tasks, batch them, or alter them all into another computer. What you choose depends on what problem you are solving.
NikolaNovak 5y ago
We do need to account what is required and what is achievable for each use case. We run an ERP system with >250k self-service users on a single beefy database. There's redundancy in web servers and app servers and proxy servers and whatnot. But in 5+ years and a LOOOOOOT of all kinds of issues -- it's never been that single big LPAR with single big RDBMS that was the issue. And we're not even on a mainframe. And it's not because we got lucky - some single-computer/LPAR/RDBMS stacks simply give us as many 9's as we need for our use-case. (webservers on other hand - they feel like child's toys. I don't understand how these leaky errory cachy things survive... YOU HAVE ONE JOB! And you're not very good at it :P )

withinboredom 5y ago

I built a production grade cluster for fun. It’s only three nodes… without anything installed on my 40 core cluster, except k8s and longhorn, it’s idling at 30% cpu usage. When I started up a managed cluster on Azure, I was throwing hundreds of euros at their logging storage just idling, so I noped to bare metal.

KronisLV 5y ago
This mirrors my experience with K8s, though one can suggest that the software running on the cluster also played a part in it. Have you looked into K3s or other lightweight distros of Kubernetes, though? https://k3s.io/ https://k3s.io/ That's what i turned to when i needed to learn the Kubernetes API and explore running clusters, but didn't like my small VPSes (~4 GB of RAM) failing to launch anything because of the frankly insane resource usage of full K8s clusters.

bob1029 5y ago

I did mean single computer in terms of 1 active primary machine at any given time. Negotiate the advantages of this architecture with the business. For the systems I've built, synchronous log replication is a natural extension of the performance abstraction, and provides fairly robust protection when some manual intervention is allowed.

gjulianm 5y ago

A good thing with "single computer" is that you have less complexity going into it so failures will be less frequent. For a lot of cases, that will be enough. It's also easier to build a resilient system starting from a single machine than from a cluster: less components to replicate to ensure they're redundant.

jiggawatts 5y ago
Something I've been telling customers for years is: I would rather have a standalone SQL Server Standard Edition instance on VMware than an Enterprise Edition cluster on anything. Simple means that there's less things to break. This isn't just academic. My experience with clusters is that the clustering itself causes more problems than it solves. (Don't think this is somehow isolated to Windows. ZooKeeper will refuse to start after a power outage for no discernible reason. Etc...)
- thow-58d4e8b 5y ago
  > My experience with clusters is that the clustering itself causes more problems than it solves. There's also a whole slew of failure modes that are capable of bringing down entire clusters if a single machine misbehaves. Usually to do with situations where the nodes are reachable, but some resource (I/O, latency, bandwidth) is uncharacteristically slow on one of the machines. I'm yet to encounter a distributed system that handles that situation well
  - travisjungroth 5y ago
    Some people see small twin engine airplanes as safer than single engine. Single point of failure and all that. The problem is that the two engines of an airplane aren’t independent of each other in the factors that threaten an engine. Same pilot, same fuel. Separate mechanical parts, but that’s a minority of issues. Most engine-outs in small airplanes are caused by running out of fuel. Your two engines don’t help you there. If anything it’s more likely because of mismanaging the complex fuel system. The most common phase for loss of an engine is on take off (misfueled, mechanical issue). This is what your comment reminded me of. With two engines, you’re more likely to have a mechanical issue on take off. While it’s generally theoretically survivable, handling one-sided power loss on takeoff requires a quick and counterintuitive response. That requires consistent training, more than most pilots do. In a small, recreational twin, the most common outcome for an engine misbehaving on take off is it rolls the airplane, taking down the whole cluster.
- GiorgioG 5y ago

marcosdumay 5y ago

Well, you either fail the tasks, batch them, or alter them all into another computer. What you choose depends on what problem you are solving.

NikolaNovak 5y ago

We do need to account what is required and what is achievable for each use case. We run an ERP system with >250k self-service users on a single beefy database. There's redundancy in web servers and app servers and proxy servers and whatnot. But in 5+ years and a LOOOOOOT of all kinds of issues -- it's never been that single big LPAR with single big RDBMS that was the issue. And we're not even on a mainframe. And it's not because we got lucky - some single-computer/LPAR/RDBMS stacks simply give us as many 9's as we need for our use-case. (webservers on other hand - they feel like child's toys. I don't understand how these leaky errory cachy things survive... YOU HAVE ONE JOB! And you're not very good at it :P )