Live data from Hacker News

Proposed server purchase for GitLab.com

about.gitlab.com

31–40 of 327 posts

Re: Proposed server purchase for GitLab.com

#31
post #4

If you are looking for performance, do not get the 8TB drives. In my experience, drives above 5TB do not have good response times. I don't have hard numbers, but I built a 10 disk RAID6 array with 5TB disks and 2TB disks and the 2TB disks were a lot more responsive. From my own personal experience, I would go with a PCIe SSD cache/write buffer, and then a primary SSD tier and a HDD tier. Storage, as it seems you guys…

So, the 8TB drives are fine if you're doing sequential writes, mainly doing write-only workloads, or have a massive buffer in front. In my experience, the PCIE drives they mention (the DC P3700) are incredible. They're blazing fast (though the 3D X-Point stuff is obviously faster), have big supercaps (in case of power failure), and really low latency for an SSD (150 microseconds or so). They're a pretty suitable alte…

True about RAID6, I was just commenting on performance. A 2TB will spank an 8TB in any configuration.

I would think that GitLab's workload is mostly random, which would pose a problem for larger drives. The SSDs are a great idea, but I've only seen 8TB drives used when there are 2 to 3 tiers; with 8TB drives being all the way on the bottom. I'm not sure how effective having a single SSD as a cache drive for 24TBs of 8TB disks will be.

Re: Proposed server purchase for GitLab.com

#32
D5: You want a local boot drive, and you want it to fall back to PXE booting if the local drive is unavailable. Your PXE image should default to the last known working image, and have a boot-time menu with options for a rescue image and an installer for your distribution of choice.

Re: Proposed server purchase for GitLab.com

#33
> We want to dual bound the network connections to increase performance and reliability. This will allow us to take routers out of service during low traffic times, for example to restart them after a software upgrade.

does not really agree with

> Each of the two physical network connections will connect to a different top of rack router.

Sure, you can do it with something like MLAG, but that's really just moving your SPOF to somewhere else (the router software running MLAG). Router software being super buggy, I wouldn't rely on MLAG being up at all times.

> N1 Which router should we purchase?

Pick your favorite. For what you're looking for here, everything is largely using the same silicon (broadcom chipsets).

> N2 How do we interconnect the routers while keeping the network simple and fast?

Don't fall into the trap of extending vlans everywhere. You should definitely be routing (not switching) between different routers. You can read through http://blog.ipspace.net/ for some info on layer 3 only datacenter networks.

You'd want to use something like OSPF or BGP between routers.

> N3 Should we have a separate network for Ceph traffic?

Yes, if you want your Ceph cluster to remain usable during rebuilds. Ceph will peg the internal network during any sort of rebuild event.

> N4 Do we need an SDN compatible router or can we purchase something more affordable?

You probably don't need SDN unless you actually have a SDN use case in mind. I'd bet you can get away with simpler gear.

> N5 What router should we use for the management network?

Doesn't really matter, gigabit routers are pretty robust/cheap/similar. I'd suggest same vendor as you go for whatever your public network routers.

Also, consider another standalone network for IPMI. I can tell you that the Supermicro IPMI controllers are significantly more reliable if you use the dedicated IPMI ports and isolate them. You can use a shitty 100mbit switches for this, the IPMI controllers don't support anything higher.

> D5 Is it a good idea to have a boot drive or should we use PXE boot every time it starts?

PXE booting at every boot is cool, but can end up sucking up a lot of time. If you have not already designed your systems to do this, and have experience with PXE, then don't.

> The default rack height seems to be 45U nowadays (42U used to be the standard).

You may not have accounted for PDUs here. Some racks will support 'zero-U' PDUs, but you'd need to confirm this before moving on.

> H3 How can we minimize installation costs? Should we ask to configure the servers to PXE boot?

Assume remote hands is dumb. Provide stupidly detailed instructions for them. Server hardware will PXE by default, so that's not really a concern. IPMI controllers come up via DHCP too, so once you've got access to those you shouldn't need remote hands anymore.

> D2 Should we use Bcache to improve latency on on the Ceph OSD servers with SSD?

Did you consider just putting your Ceph journals on the SSD? That's a lot more standard config then somehow using bcache with OSD drives.

Re: Proposed server purchase for GitLab.com

#34
If you're committed to having a robust architecture (this may not be financially viable immediately) you should study the mistakes that Github have made, e.g. https://news.ycombinator.com/item?id=11029898

Geo-redundancy seems like a luxury, until your entire site comes down due to a datacenter-level outage. (E.g. the power goes down, or someone cuts the internet lines when doing construction work on the street outside).

(This is one of the things that is much easier to achieve with a cloud-native architecture).

Re: Proposed server purchase for GitLab.com

#35
For such a big expenditure, some prototyping first? Maybe buy a mainboard or two and some CPUs/HDDs/SSDs and benchmark them on your specific workloads. Also look into using something like bcache if going all-SSDs is too expensive.

Re: Proposed server purchase for GitLab.com

#36
post #17
post #5

Earlier quoted context omitted.

Thanks! The decision to move to metal was because of performance problems https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ It is nice that we'll save on costs but we anticipate a lot of extra complexity that will slow us down. So if it wasn't needed we would have stayed in the cloud. But it is interesting that both our competitors (GitHub.com and BitBucket.org) also moved to metal.

I've been following the technical discussions around this move, and I'm wondering if you guys looked at making architectural changes to shard your data into more manageable chunks? Naively it seems like you should be able to reduce your peak filesystem iops by sharding the data at the application layer. That does introduce application complexity, but it might shake out as being less work than the operational complexi…

We have sharding on the application layer in GitLab right now https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7273 and we're using it heavily to split the load among NFS servers.

Then we have to think about redundancy. The simple solution is to have an secondary NFS server and use DRBD. For the shortcomings of that read http://githubengineering.com/introducing-dgit/

The next step is introducing more granular redundancy, failover, and rebalancing. For this you have to be good in distributed computing. This is not something we are now so we rather outsource it to the experts that make CephFS.

The problem of CephFS is that each file need to be tracked. If we would do it ourselves we could do it on the repository level. But we rather reuse a project that many people have already made better than go through the pain of making all the mistakes ourselves. It could be that using CephFS will not solve our latency problems and we have to do application sharing anyway.

Re: Proposed server purchase for GitLab.com

#37
I'm surprised to see that GitLab is using Unicorn. Isn't Unicorn grossly inefficient, because each of the worker processes can only handle one request at a time. Are web application processes actually CPU-bound these days?

I don't know much about the Ruby web server landscape, but might Puma (http://puma.io/) be better?

Re: Proposed server purchase for GitLab.com

#38

I'm surprised to see that GitLab is using Unicorn. Isn't Unicorn grossly inefficient, because each of the worker processes can only handle one request at a time. Are web application processes actually CPU-bound these days? I don't know much about the Ruby web server landscape, but might Puma ( http://puma.io/ ) be better?

I was wondering the same. For my projects Puma has been awesome and better than Unicorn.

Re: Proposed server purchase for GitLab.com

#39

I'm surprised to see that GitLab is using Unicorn. Isn't Unicorn grossly inefficient, because each of the worker processes can only handle one request at a time. Are web application processes actually CPU-bound these days? I don't know much about the Ruby web server landscape, but might Puma ( http://puma.io/ ) be better?

For "grossly inefficient" I imagine it depends. If you're loading most of the app prefork then the memory overhead for more processes is pretty low. (Disclaimer: Dunno much about ruby deployments)

Re: Proposed server purchase for GitLab.com

#40
post #32

D5: You want a local boot drive, and you want it to fall back to PXE booting if the local drive is unavailable. Your PXE image should default to the last known working image, and have a boot-time menu with options for a rescue image and an installer for your distribution of choice.

Thanks, added to the article with https://gitlab.com/gitlab-com/www-gitlab-com/commit/ef3c7e1c... (will take some minutes to roll out).
Post reply on HN