Live data from Hacker News

Proposed server purchase for GitLab.com

about.gitlab.com

301–310 of 327 posts

Re: Proposed server purchase for GitLab.com

#301
post #176

Earlier quoted context omitted.

That is pretty awesome. Should the SSD's for the fast storage be on the OSD nodes that also have the HDD's or should it be separate OSD nodes?

The fact that you're asking this question on Hacker News leaves little doubt in my mind that you and your team are not prepared for this (running bare metal). I read the entire article, and while you talked about having a backup system (in a single server, no less!) that can restore your dataset in a reasonable amount of time, you have no capability for disaster recovery. What happens when a plumbing leak in the data…

They don't need another datacenter. AWS has had more issues they NYI's datacenters have had in the past year. There are many companies that are based out of a single datacenter that haven't had any major issues.

Re: Proposed server purchase for GitLab.com

#302
post #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 outsid…

Exactly this. I don't think that if you take into account __all__ parameters bare metal is cheaper. My other problem is that they are moving from cloud to bare metal because of performance while using a bunch of software that are notoriously slow and wasteful. I would optimise the hell out of my stack before commit to a change like this. Building your own racks does not deliver business value and it is extremely erro…

The RMA process is pretty much a moot point at this scale. It simply doesn't make sense to buy servers with large warranties. Save the money, stock spares, and when a component dies replace it. In the long run it will come out to cost a lot less. I'd much rather pay much less knowing a component may fail here and there and you buy a new one.

As far as moving from cloud to bare metal, another thing to take into consideration (that this was replied to), if you don't architect your AWS (or other cloud solution) to take advantage of multiple geographic regions, the cloud won't benefit you.

I 100% agree that there should be more than one region deployed for this service. As others have said, all it takes is 1 event and the site will be down for days to weeks to months (It may not happen often, but when it does, you go out of business). The size and complexity of this infrastructure will make it nearly impossible to reproduce on short order in a new facility. If I were the lead on this I would have either active / active sites, or an active / replica site.

I would also have both local (fast restores), and off-site backups of all data. A replica site protects against site failure not data loss and point-in-time recovery.

Re: Proposed server purchase for GitLab.com

#303
post #300

Earlier quoted context omitted.

Not really, although I agree with your reasoning. The other is issue is capex. When I deploy 240kW pods, if I use 80% breakers, I have to deploy 25% more PDUs than if I have 100% breakers. Since my cabinet number is usually evenly divisible by N*PDUs, this impacts overall capital.

We are talking about 1 to 2 cab density here so capex doesn't carry that much weight. Having a little headroom on your power circuits is also incredibility important, and not every facility will sell 100% rated breakers. It may make more sense to be in a facility with 80% rated breakers than 100%, even with the added capex of an extra PDU or two. Goes back to my previous comment. What is important to you, at the pod…

That's fair and accurate.

Similarly, ensure spare room in the cabinet for adjustments, that thing you forgot, and small growth. Much better to have 70% full and not need the space then to have no free RU and need the space.

Re: Proposed server purchase for GitLab.com

#304
post #56

Earlier quoted context omitted.

Do you have a disaster recovery plan that starts with "A meteor has destroyed our primary data center."? I do; that's my default scenario. If you can survive that, you can survive all sorts of smaller issues like network congestion, data center power problems, grid power problems, and zombie plagues (or flu, which is more likely.)

Depends on what you mean by 'survive'. I'd call a backup in google nearline sufficient for the meteor scenario, but that's going to be very slow and unpleasant to depend on for milder problems.

It's not sufficient. How quickly could you procure new hardware, install that in a datacenter, make it fully functional, and restore your backups? The answer is likely weeks/months. Could your business survive being offline that long? It sounds unlikely.

Re: Proposed server purchase for GitLab.com

#305

Yeah, link aggregation doesn't work how they think it does. And not having a separate network for Ceph is going to bite them in the arse. GitLab is fine software but fuck me, they need to hire someone with actual ops experience (based on this post and their previous "we tried running a clustered file system in the cloud and for some reason it ran like shit" post).

Ceph should get a separate network which is only used for re-replication in case something happens. Consider a node goes down.

Another thing I might recommend is a third network (just a simple 1GB and a quality switch) for consensus. Re-replication can max the network out and further cause consensus fails, causes more re-replication winding down everything ... If that's not possible, add firewall rules to prioritize all consensus related ports high.

Re: Proposed server purchase for GitLab.com

#307
Servers:

C1: Have a look at the FatTwin Line for more Disks per U. More PCIe Slots too.

Disks

D3: Check the measurements, having it not fit is painful

D4: More, smaller drives. Make sure you go PMR not SMR if you do go for 8TB

Network

N1: The "SDN" aspect of the supermicro one is not really any different than any other. Look at https://bm-switch.com/ and get one that supports Cumulus Linux. Buy one with an x86 CPU. If you want to do "SDN" things or run custom monitoring, not dealing with PPC is great.

N3: Probably not needed, but not terribly expensive if it provides benefit.

N4: see N1, no.

N5: Cheap 1G switch that supports cumulus, x86, probably broadcom \ helix4

Networking General:

- I wouldn't advise using the 10GbE Copper --Go for 25GbE with DAC, it's basically the same price, Mellanox NICs are small/cheap

- Transit is cheap, you can get 500Mbps on a 10G port for $325/mo from Cogent

- If your bandwidth needs to scale up, data center locations matter more than you think

25GbE adapter -- minimal additional cost for 2.5x the perf, lower latency as well: http://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=2...

a 32 port 100GbE switch is about $7000-12,000 -- you can break that down to 128x 25GbE, and use the 25GbE ports running at 10GbE mode for your carrier uplinks. Could even do 100GbE to your Ceph nodes if you wanted, but be aware of PCIe bottlenecks -- x8 is about 64Gbps, x16 will do 125Gbps. Dual port 40G on x8 or dual port 100G on x16 will not provide more than those numbers.

Consider Supermicro NVMe servers (Ultra series) for DBs, and 2.5in NVMe SSDs instead of PCIe.

Rack: Don't assume 45U 40-48 is common. Consider buying 2 racks.

Power:

19kW seems high for a single rack, you will need a good datacenter to support that density. Density costs money more racks is cheaper generally.

208v * 30A = 5000W usable per feed, unless they are talking about

208v 3-phase, which gets you 8600W usable per feed, which again is only 17kW and you need 18-20kW.

helpful reference: http://www.raritan.com/blog/detail/3-phase-208v-power-strips...

You can only use 80% of your power provided.

You also need Rack PDUs, higher density PDUs cost more money consider buying port-switchable PDUs. Raritan makes good ones.

Ask supermicro (or your reseller) for a "Power Sheet" it will tell you almost exactly how much power your server will use. I've had good luck with ThinkMate

Hosting

H1: Yes, too many to mention

H2: Do it yourselves

H4: yes

Hosting general: Cross connects cost money, a number of facilities offer free xconnects, this can add up.

Other notes: - You want a small toolbox in the data center

- Buy more cables than you think you'll need

- You'll always forget something

- There are a number of companies that will lease you servers for pretty decent rates

Re: Proposed server purchase for GitLab.com

#308
post #301

Earlier quoted context omitted.

The fact that you're asking this question on Hacker News leaves little doubt in my mind that you and your team are not prepared for this (running bare metal). I read the entire article, and while you talked about having a backup system (in a single server, no less!) that can restore your dataset in a reasonable amount of time, you have no capability for disaster recovery. What happens when a plumbing leak in the data…

They don't need another datacenter. AWS has had more issues they NYI's datacenters have had in the past year. There are many companies that are based out of a single datacenter that haven't had any major issues.

Backblaze comes to mind.

Re: Proposed server purchase for GitLab.com

#309
post #302

Earlier quoted context omitted.

Exactly this. I don't think that if you take into account __all__ parameters bare metal is cheaper. My other problem is that they are moving from cloud to bare metal because of performance while using a bunch of software that are notoriously slow and wasteful. I would optimise the hell out of my stack before commit to a change like this. Building your own racks does not deliver business value and it is extremely erro…

The RMA process is pretty much a moot point at this scale. It simply doesn't make sense to buy servers with large warranties. Save the money, stock spares, and when a component dies replace it. In the long run it will come out to cost a lot less. I'd much rather pay much less knowing a component may fail here and there and you buy a new one. As far as moving from cloud to bare metal, another thing to take into consid…

"As far as moving from cloud to bare metal, another thing to take into consideration (that this was replied to), if you don't architect your AWS (or other cloud solution) to take advantage of multiple geographic regions, the cloud won't benefit you."

Yep, this is why scaling starts with scalable distributed design. We were moving a fairly large logging stack from NFS to S3 once, for the same reason Gitlab is trying to move to bare metal now. Moving off cloud was not an option, moving to a TCO efficient service was. NFS did not scale and there was the latency problem. I think moving to bare metal cannot help with scale as much as a good architecture can. We will see how deep the datacenter hole goes. :)

Re: Proposed server purchase for GitLab.com

#310

Earlier quoted context omitted.

+1 EDIT: Funny, every single documented, proven link for the last several years has proven me and GP correct and all you nay-sayers wrong.

I believe the downvotes are due to "+1" not adding anything to the conversation, as opposed to people disagreeing with the sentiment.

Isnt it ironic that a (+1) on HN will get downvotes yet thats basically what every single HNer seeks to see in their requests on git. :-)
Post reply on HN