Hacker News Reader

Comment by connorshea | Hacker News Reader

I just want to note that the blog post you linked to was never actually published since we decided against pointing fingers when – by and large – the problems weren't their fault and their engineers were quite helpful. See the comment at the bottom of that thread[1] from Sid.

We made mistakes ourselves that were the root of the problems at the time, and based on the update[2] a few months later things definitely improved significantly.

[1]: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... [2]: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

View on HN

Judging by the posts.

Random thought: Go talk to google and get $100k of free cloud credits.

You run 100 instances of n1-highcpu-2 (2 CPU, 2GB RAM), with a local 375 SSD. That gives you 37TB of storage and you're fine for the year.

This is an absolutely ridiculous setup but it could work.

1) Servers don't need to have more memory for caching. Local SSD access is fast enough.

2) Servers have 1Gb uplink. That can be saturated easily by a single local SSD.

3) I'm a firm believer that if you put 8-16 disks in a single box, you're gonna hit a hard limit with the network bandwidth and infrastructure (among other things).

4) Do you need IOPS or do you need storage???

5) Can CephFS shard fairly across a hundred systems?

6) Should CephFS run on raw disks, manage replica itself? and can it handle failure?

Bonus question) Why are we thinking about all of this. You should have just used s3?

> Bonus question) Why are we thinking about all of this. You should have just used s3?

NFS and Ceph both support the standard POSIX file access model, notably including random-access reads and writes on a file without replacing the entire file and consistency models that let you reason about directories and their contents usefully. If your goal is to run the reference implementation of git, or something that is compatible with it, on the filesystem, you absolutely need something that supports this.

You could write something new that speaks the git protocol but is designed to be backed by an eventually-consistent object store instead of a POSIX-compliant file store ... but that seems like an equally big challenge, honestly.

Fun aside. Google wrote a backend to Mercurial so it could be stored on bigtable. They did a talk about it 7 years ago.

http://m.youtube.com/watch?v=ri796Hx8las

And to SVN! https://lwn.net/Articles/194667/

It's not a bad decision; getting POSIX semantics to play well with modern expectations of a highly-consistent and highly-available distributed system is very difficult. But it's a work-intensive decision, and figuring out how to deploy NFS or Ceph at scale might be less work. Especially if Google's SVN/hg developers can work directly with the Bigtable developers on features, and GitLab's developers can't work directly with the S3 team (but can own their own Ceph or NFS stack).

Their Git hosting was also running on that same backend (I was on the team managing those products). But to a previous posters point That is a lot of work both to implement as well as to maintain. If you can just use a distributed filesystem you might save yourself some trouble.

Others have done this with libgit2 storage backends.

Anyone in particular, or anything open source? I could use this for a work project, but the closest I've been able to find is an old project which backed JGit to Cassandra and the Dulwich Swift backend[1].

[1]: https://www.dulwich.io/apidocs/dulwich.contrib.swift.html

We looked at this but it didn't have either the features or the speed we needed. I do think it is very promising.

Yes, write a Git backend using a distributed actor system, like Akka, Orleans or Service Fabric, backed by Table Storage, Bigtable or some other distributed hashtable store. Git maps naturally to this structure, using git hashes as table index.

You'll have a really cheap and very scalable solution that uses low level storage mechanisms yet it will also be really performant because when loaded everything will be served from memory.

For sure, and people are trying to do this on the basis of libgit2. But so far nobody has been able to make it work for all of the cases. Even GitHub is using filesystems as far as I know.

One of the teams I work closely with used JGit's extensibility to run git on top of a KVS: https://medium.com/@palantir/stemma-distributed-git-server-7...

Notably this doesn't require a distributed filesystem.

That looks really interesting, thanks for posting. I added it to our issue https://gitlab.com/gitlab-com/infrastructure/issues/727#note...

Relevant: http://githubengineering.com/introducing-dgit/

For Visual Studio Online and TFS, Microsoft is using libgit2 and some custom ASP.NET code for the upload-pack / receive-pack endpoints, stuffing the data into SQL Azure. No filesystem, no `git` executable.

We're currently at 70TB and we're planning for a 256TB setup https://docs.google.com/spreadsheets/d/1XG9VXdDxNd8ipgPlEr7N... . So that would be a lot of servers. I don't think SSDs for the file storage are affordable. We'll use SSDs for the journals.

I think that's a false assumption. Especially in 2016.

Unless something changed dramatically at GitHub they're a 100% solid-state fleet since 2012 when they started down the "building their datacenter cages" journey.

Whilst you could say as the 500lb gorilla in the market they can afford that luxury, there are other examples, i.e. DigitalOcean, where SSD is a core part of their product and it is offered inexpensively ($5/mo).

Even if you're looking at 3-way replication of your data, meaning you're buying 768TB of storage, the SSD should only tot up to $200-300k for Intel S3510 (or similar).

There's a non-trivial amount of additional effort involved in any kind of "multi-layered" storage (c.f. data on 7200rpm, NVMe cache) over and above just making all of your storage moderately performant in IOPS terms. That has cost too.

If you're rolling your own, you can tune these things.

For example, in this case, since they're IOPs-bound first, and probably network-bound second, you can cram 16 SSDs in a box, and then put a dual-port 25Gig Ethernet NIC up to 2 leaf switches at the top of rack, and then build a CLOS out of 100G spine switches, so that there are essentially never any network bottlenecks for Ceph.

This is very similar to DreamHost's DreamCompute cluster design, though they're using 2x 10G to the servers, and 40G up to the spines, since 25G/100G wasn't available when they built the cluster.

Sorry about that! I was on my phone, and followed the first thing from the linked post/issue; I didn't realize it wasn't published.

No problem, the thread is pretty long, and it's not necessarily easy to tell without understanding how our blog post process works. :)

An alternative to user5994461's suggestion would be to switch from CephFS to a different distributed filesystem. If you need POSIX and can't go directly to S3 you could try ObjectiveFS[1]. Using local SSD instance store and memory for caching you can get very good performance even for small file workloads[2].

[1]: https://objectivefs.com [2]: https://objectivefs.com/howto/performance-amazon-efs-vs-obje...

ObjectiveFS looks interesting but I wonder about the latency if you do many small random reads (this is what we're seeing with git).

Latency for small random reads (16 parallel threads), using the Linux kernel source tree, when hitting in the SSD instance store disk cache have a 95th-percentile latency of 6ms with ~50MB/s throughput. When hitting in the memory cache the 95th-percentile latency is <1ms with ~380MB/s throughput. We have more performance data available at https://objectivefs.com/howto/performance-amazon-efs-vs-obje...

That sounds very good, but I think we prefer Ceph because it is better known. Do you have a comparison between Ceph and ObjectiveFS?

Another option would be to move to HDFS. HopsFS, a new distribution, can scale to over 1m ops/sec: http://www.logicalclocks.com/index.php/2016/10/14/hops-smash...

As someone who has run Hdfs in production on bare metal, I wonder how much you dislik gitlab...

TL;DR - HDFS is rarely the answer, mainly due to pains usually involving crashed nameservers.

HopsFS has multiple redundant, stateless NameNodes.

Reply on news.ycombinator.com