161–170 of 229 posts
Earlier quoted context omitted.
Data centers used 460 TWh, or about 2% of total worldwide electricity use, according to IEA in 2022. In comparison, 30% of total energy (energy! Not electricity) goes to transport! As another point of comparison, transport in Sweden in 2022 used 137 TWh [1]. So the same order of magnitude as total datacenter energy use. And datacenters are powered by electricity which increases the chance that it comes from renewable…
2% of total worldwide electricity use in 2022 is a shit load of electricity and emissions. Your argument is the same as those who argue "our country shouldn't care about emissions when China is the biggest emitter". If you dive into a detailed breakdown of emissions you'll find that it's a complex hierarchy of categories. You can't just fix "all of transport" or treat it like a "low hanging fruit", just look at how m…
China and the US are in the same order of magnitude in emissions. So NO that's absolutely not the argument I am making.
> Any energy use that's measurable in whole percentage points of global emissions needs addressing
But it isn't! That's my point. Electricity use is about 20% of total energy use. So if we talk about global emissions, data center is only about 20% * 2% = 0.4% of total energy use.
And then if we talk about total emittance, it's even lower because 40% of electricity is generated from nuclear and renewables.
> just look at how much time it's taken for EV penetration to be in any way significant
Yes so let's focus on that instead of data centers. Data centers are not the problem!
EDIT: Also CPUs and GPUs are still becoming more energy efficient. So I'm a bit skeptical of extrapolations which say that data centers will consume a large percentage of US energy. If the number of CPUs and GPUs doubles each 2 years, but energy efficiency doubles too, then overall energy usage doesn't grow so fast. Especially if old CPUs and GPUs are taken out of the system over time because they become too expensive to operate.
We've [1] been using Hetzner's dedicated servers to provide Kubernetes clusters to our clients for a few years now. The performance is certainly excellent, we typically see request times half. And because the hardware is cheaper we can provide dedicated DevOps engineering time to each client. There are some caveats though: 1) A staging cluster for testing updates is really a must. YOLO-ing prod updates on a Sunday is…
> dedicated 10G network to connect your servers Do you have to ask Hetzner nicely for this? They have a publicly documented 10G uplink option, but that is for external networking and IMHO heavily limited (20TB limit). For internal cluster IO 20TB could easily become a problem
I have experience running Kubernetes clusters on Hetzner dedicated servers, as well as working with a range of fully or highly managed services like Aurora, S3, and ECS Fargate. From my experience, the cloud bill on Hetzner can sometimes be as low as 20% of an equivalent AWS bill. However, this cost advantage comes with significant trade-offs. On Kubernetes with Hetzner, we managed a Ceph cluster using NVMe storage,…
You are much better off having a bunch of smaller file systems exported over NFS make sure that you have block level replication. Single address space filesystems are ok and convenient, but most of the time are not worth the cost of admin to get reliable at scale. like a DB shard your filesystems, especially as you can easily add mapping logic to kubernetes to make sure you get the right storage to the right image.
// Taking another slant at the discussion: Why kubernetes? Thank you for sharing your experience. I also have my 3 personal servers with Hetzner, plus a couple VM instances in Scaleways (French outfit). Disclaimer: I’m a Googler, was SRE for ~10 years for GMail, identity, social, apps (gsuites nowadays) and more, managed hundreds of jobs in Borg, one of the 3 founders of the current dev+devops internal platform (and…
K8s has a whole kit of parts which sound really grand when you are starting out on a new platform, but quickly become a pain when you actually start to implement it. I think thats the biggest problem, is by the time you've realised that actualy you don't need k8s, you've invested so much time into learning the sodding thing, its difficult to back out.
The other seductive thing is helm provides "AWS-like" features (ie fancy load balancing rules) that are hard to figure out unless you've dabbled with the underlying tech before (varnish/nginx/etc are daunting, so is storage and networking)
this tends to lead to utterly fucking stupid networking systems because unless you know better, that looks normal.
We've [1] been using Hetzner's dedicated servers to provide Kubernetes clusters to our clients for a few years now. The performance is certainly excellent, we typically see request times half. And because the hardware is cheaper we can provide dedicated DevOps engineering time to each client. There are some caveats though: 1) A staging cluster for testing updates is really a must. YOLO-ing prod updates on a Sunday is…
Are you willing to share example config for that part?
> Hetzner volumes are, in my experience, too slow for a production database. While you may in the past have had a good experience running customer-facing databases on AWS EBS, with Hetzner's volumes we were seeing >50ms of IOWAIT with very low IOPS. See https://github.com/rook/rook/issues/14999 for benchmarks. I set up rook ceph on a talos k8s cluster (with vm volumes) and experienced similar low performance; however…
Additionally, hetzner has an IOPS limit of 5000 and write limit of some amount that does not scale with the size of database.
50G has the same limits as 5TB.
For this reason, people are sometimes using different table spaces in postgres for example.
Ceph puts another burden on top of already-ceph-based cloud volumes, btw, so don't do that.
https://github.com/puppetlabs/puppetlabs-kubernetes What do the fine people of HN think about the size/scope/amount of technology of this repo? It is referenced in the article here: https://github.com/puppetlabs/puppetlabs-kubernetes/compare/...
The general flow was Imager->pre-configured puppet agent->connect to controller->apply changes to make it perform as x
originally it never really had the capacity to kick off the imaging/instantiation. THis meant that it scaled better (shared state is better handled than ansible)
However ansible shined because although it was a bastard to get running on more than a couple of hundred hosts in any speed, you could tell it to spin up 100x EC2(or equivalent) machines and then transform them into which every role that was needed. In puppet that was impossible to do in one go.
I assume thats changed, but I don't miss puppet.
We've [1] been using Hetzner's dedicated servers to provide Kubernetes clusters to our clients for a few years now. The performance is certainly excellent, we typically see request times half. And because the hardware is cheaper we can provide dedicated DevOps engineering time to each client. There are some caveats though: 1) A staging cluster for testing updates is really a must. YOLO-ing prod updates on a Sunday is…
> dedicated 10G network to connect your servers Do you have to ask Hetzner nicely for this? They have a publicly documented 10G uplink option, but that is for external networking and IMHO heavily limited (20TB limit). For internal cluster IO 20TB could easily become a problem
[1]: https://docs.hetzner.com/robot/general/pricing/price-list-fo...