100 Lines of C, in a Closet (2020) | Hacker News Reader

100 Lines of C, in a Closet (2020)

blog.notryan.com

172 pointsrrampage15 comments

> Plus using your own machines allows you to do immoral stuff, such as pushing 100 MB files, if you feel like it. I have versioned controlled, quite a few mega-repos where the primary content is not text files at all. Shame me all you want, but being able to time-travel through my photo/video collections is fantastic. I don't really care that my 2 GB repo takes 4 GB on disk...

If one wants to avoid the downsides of just checking in big binary blobs, git-annex[1] is fantastic for maintaining archives (not backups). It also tracks locations of files (which of my drives is this file on?) in a completely peer-to-peer eventually consistent manner. It has a nearly unreasonable amount of features in multiple layers, though.

(Tip: set annex.largefiles[2] to avoid messing up your repo when you inevitably type `git add` instead of `git annex add`.)

[1] https://git-annex.branchable.com/

[2] https://git-annex.branchable.com/tips/largefiles/

I used to do the same, without public IP from the VPS.

I just used Cloudflare, and a Go package [1] to lock down access to anyone but Cloudflare (because at the time their tunnels required Argo).

I now also use a VPS that's dirt cheap [2] if you make it IPv6 only (I have 3 in 3 different availability zones for about 1.5€/mo, it's insane). Cloudflare exposes it as IPv4+IPv6.

Compute light stuff comes from the VPS, compute heavy is proxied home instead.

[1]: https://pkg.go.dev/github.com/ncruces/go-cloudflare/origin

[2]: https://www.scaleway.com/en/stardust-instances/

I love this. Somehow people forgot how far simple things such as a VPS, some reverse proxies and some hand-written short tools in whatever language can bring you. For me, crappy little tools is the way to success. Perfection is the opposite of good.

I always remember it, "perfect is the enemy of good enough". I wonder if there's a canonical statement.

worse is better https://en.wikipedia.org/wiki/Worse_is_better

> It can do live migrations to any device on my LAN, with zero downtime. KVM is really cool! It transfers the RAM continuously until it's fully synced. This takes about 30 seconds.

Yes! It can take hours or days if you're moving a large machine with tons of traffic, too. Everything is fast for small n.

This doesn't make it less cool, though.

Question from someone who doesn't know anything about architecting services that require fault-tolerance: are those hours or days-long delays tolerable in transaction/request processing applications? If so, what would be the benefit of transferring a live VM to retain capacity, versus simply starting a new instance from scratch?

The reason these migrations take hours/days is because of you're not stopping the server in the first place. Your clients do not see or feel it, because the performance does not degrade. When the machines sync, the IP is transparently transferred to the new instance, and it continues as is while the now "old" machine is deleted.

Also, we do these migrations not because of HA failovers. If we need that kind of resilience, we'd either setup an active/standby or active/active HA VMs in the first place.

Instead we do this because machine maintenance and/or upgrades. A RAM stick dies, but the server tolerates it, so we leisurely drain the server for maintenance, or we replace the nodes with more powerful ones, so we decommission it by draining, take it out of the cluster, add the new one and remigrate stuff back in.

Also, most of the VMs we migrate doesn't know or have the capability of multi-instance execution. They are designed to work as solo machines. This is another reason we prefer to migrate them.

Lastly that's a multi-tenant system. We're not the admins of many of the systems sitting on that particular cluster, yet we proudly hit >99.98% uptime every month.

TL;DR: Migration is a different modus operandi and is not for scaling or active HA 99.9% of the time. We move these machines around to service the hardware running these, and nobody notices anything.

Nice to see RSS still being discovered in 2020. RSS rules.

Had no idea about DRBD (Distributed Replicated Block Device). Thats my evening sorted...

DRBD was nice to use. Great thing about it is that you can put it below the existing filesystem. I don't remember how it works, maybe it puts metadata at the end of block device so filesystem should be shrinked before

I remember moving a huge NFS partition which was experiencing constant writes to another server with DRBD. With almost zero downtime. So is a nice tool if you want to move a filesystem with such huge amount of files that even iterating over the file tree takes hours

I was eyeing it pretty heavily recently, considering using it in my homelab for distributed ZFS. I wound up using Ceph since Proxmox has native support for it, but I still may try it out.

I’d like to be able to create zpools for DBs to take advantage of snapshotting, but combining ZFS and Ceph on the same underlying disk (even if they are enterprise NVMe drives) is fraught with peril.

You need to know C and bunch of other things which are lost arts since kids are learning computer using “cloud”.

Building a tiny Web server, with dB and stuff was the subject of an old FOSDEM talk.

Sorry, that was unuseful! I looked it up, its called ultra.

https://github.com/MarquisdeGeek/ultra

Maybe it'll inspire someone!

Reply on news.ycombinator.com