Live data from Hacker News

Proposed server purchase for GitLab.com

about.gitlab.com

281–290 of 327 posts

Re: Proposed server purchase for GitLab.com

#281

Earlier quoted context omitted.

Circuit breakers aren't just there for the amusement value of watching a clustered system go into split-brain mode... I.e. you would also want to be sure that your wiring was rated for 100% utilization, and that other circuit-breaker-like functions exist. Fire is an actual thing, and figuring out the best way to recharge a halon system isn't exactly what you want to be doing.

Yes. That's why they hardwire and use a breaker rated at 100%. In most jurisdiction, code requires breaker at 80% if a plug/receptacle is used. If you are hardwired you can use 100% of your capacity before tripping the breaker. You have incorrectly assumed that I suggested that you ignore breakers. When you hardwire the circuit the electrical code allows you to use a 100% breaker.

What exactly gets hardwired to what? This is surprisingly hard to search for details on.

Re: Proposed server purchase for GitLab.com

#282
post #183

Earlier quoted context omitted.

I recently had to do this. The server I was putting up was rated for 3kW. To determine the expected load, I put it under a dummy load that I reasonably considered the maximum for what I would expect on the server (this was a dev machine, so I picked compiling the linux kernel as a benchmark). I ran that until the power stabilized (SuperMicro servers can measure power consumption in hardware and expose this via IPMI -…

I love the idea of killing the server instead of the circuit, thanks!

Might be better to just throttle the CPU/etc when too much power is being used.

Re: Proposed server purchase for GitLab.com

#283

I'm a cranky old person now, I think this is a crazy approach to take and I would be having a very challenging conversation with the engineer pitching this to me. My underlying assumption is that this is a production service with customers depending on it. 1. Don't fuck with networking. Do you have experience operating same or similar workloads on your super micro sdn? Will the CEO of your super micro VAR pickup his…

Agree, as a dev on a large distributed project(include software/hardware), I don't recommend any team to use distributed storage system in production IF they don't have lots experience on it..especially opensource system.

Re: Proposed server purchase for GitLab.com

#284
post #9
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…

Thanks for commenting! You're right that 2TB disks will have more heads per TB and therefore more IO. We want to increase performance of the 8TB drives with Bcache. If we go to smaller drives we won't be able to fit enough capacity in our common server that has only 3 drives per node. In this case we'll have to go to dedicated file servers, reducing the commonality of our setup. We're using JBOD with Ceph instead of…

I recommend testing and evaluating Bcache carefully before planning to use it in a production system. I found it unwieldly, opaque, and difficult to manage when testing on a simple load; Benefits were mild.

I'm sure it has its uses! But I'd emphatically advise anyone to obtakn hands-on experience with Bcache before planning around it! As I'm sure you are already doing or considering of course :)

Re: Proposed server purchase for GitLab.com

#285
post #95
post #8

Are you sure about the location? I would go with Frankfurt, Germany. Biggest IX in the world and if you want a "low-latency" solution for all users this is basically the middle of everything. NYC will have a worse connection to Asia and I don't want to begin with India or something. While Frankfurt is basically only 70ms away from NY and around 120ms to the west coast, while even south america should be Just as a sug…

> I basically know every DC in Frankfurt, so if you need any help or info in that regard feel free to contact me :-) I (and others I bet) would be interested in a quick summary of the options (and your opinions of them) for facilities in Frankfurt.

There are basically a shitload of datacenters in Frankfurt so I won't talk about every DC, but more of a general overview. It doesn't matter what your budget is or what your requirements are, you will find a DC in Frankfurt.

You basically have the big brands like Equinix (7 facilities in Frankfurt), Interxion (They are currently building their 11th facility in Frankfurt), Telecity (now part of Equinix) but also some local ones like e-Shelter, First Colo or Accelerated. There is also a DC only meters away from the Interxion campus that is called Interwerk and is basically the cheapest DC in Frankfurt, but it has an awesome price/performance ratio and you have access to all peering/transit options of Interxion (via CWDM) and can get a 1/1 rack for under 200 EUR/mo. I have been in that DC for several years and never had a single issue, so if you don't rely on any certificates this is a cheap option.

I was also colocating in the First Colo DC for some time, they are also in the locality around the Interxion campus. It's a pretty small DC but it is more premium than the Interwerk and also is kinda cheap. I personally wouldn't go with Accelerated, since they had multiple issues in the past.

For the big brands I would definitely go with Interxion, they are great, have all the certificates and are premium while not going crazy with their pricing like Equinix does. DigitalOcean, Twitch, etc. they are all in one of the many Interxion facilities in Frankfurt. If Price isn't a concern I would probably go with Equinix FRA5.

DE-CIX is present in around 7 facilities, 3 of them are Interxion and I think 2 Equinix.

Re: Proposed server purchase for GitLab.com

#286
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…

There's no reason you can't have a hot cloud site, and operate in lipo mode (or even scale it up temporarily) if you lose your DC. Best of both worlds.

What is lipo mode? Closest I can guess is a typo for 'limp mode'.

Re: Proposed server purchase for GitLab.com

#287
A few things that Immediately jump out at me.

The 2u fat twins are very dense, You'll need make sure that thy hosting company can actually cool it effectively.

I'd look again at your storage strategy. You'll save a lot of money, and it'll be much easier to debug if you dump ceph.

You have a clustered FS, when you appear to not really need it. By the looks of it, its all going to be hosted in the same place. So what you have is lots of CPU to manage not very much disk space. The overhead of ceph for such a tiny amount of data all in the same place seems pointless. You can easily fit your data set on one 90 disk shelf 4 times over with 100% redundancy.

First things first, File servers serve files and nothing else. This means that most of your ram is going to be a file server cache. Putting applications on there is just going to mean that you're hitting the disk more often, and stealing resources from other apps in a non transparent way.

get four 90 drive superchassis, connect them to four servers(via SAS, direct connect) with as many CPUs and as much ram as possible. JBOD them, either use ZFS, or hit up IBM for GPFS. (well IBM Spectrum Scale). You can invest in a decent SAS controller and raid 6 8 10 disk stripes. But rebuild time will be very high. Whats your strategy for disk replacement? 400 disks means about 1 every four weeks will be failing.

What is your workload like on the disks? is it write heavy? read heavy? lots of streaming IO? or random? can it be cached?

Your network should be simple. don't use cat6 10gig. It's expensive, not very good in dense racks, just use copper cables with inbuilt SPFs, they are cheap, reliable.

Don't use Super micro switches. They are almost certainly re-badged.

Your network should be fairly simple. A storage VLAN, a application VLAN, and a DMZ. (out of band will need a strongly protected vlan as well)

on the buying side, you need a reseller, who is there to get the best deal. You'll need to audition them. They will also help with design as well. But you need to be harsh with them, they are not your friends, they are out to make money.

Re: Proposed server purchase for GitLab.com

#288
I have never run a deployment this large, but I wonder: Only 1 staging server of 64 servers? I have usually tried to at least have a same order of magnitude when testing architecture changes: Sure, it works on my laptop, but how will this change work on 10 servers? Isn't it common to have a full staging setup, with similar dataset sizes?

Re: Proposed server purchase for GitLab.com

#289
post #61

Z1: the word "monitoring" does not appear in this document. You will need to monitor: - ping - latency - temperatures - cpu utilization - ram utilization - disk utilization - disk health - context switches - IP addresses assigned and reaching expected MACs - appropriate ports open and listening - appropriate responses - time to execute queries - processes running - process health - at least something for every bit of…

neither the word "IT salary(ies)"

Re: Proposed server purchase for GitLab.com

#290

Earlier quoted context omitted.

Yes. That's why they hardwire and use a breaker rated at 100%. In most jurisdiction, code requires breaker at 80% if a plug/receptacle is used. If you are hardwired you can use 100% of your capacity before tripping the breaker. You have incorrectly assumed that I suggested that you ignore breakers. When you hardwire the circuit the electrical code allows you to use a 100% breaker.

What exactly gets hardwired to what? This is surprisingly hard to search for details on.

Instead of your plug of your PDU going into a receptacle, the wires that would go into the plug are hardwired to a panel circuit breaker.

This is less common in DCs historically but more and more as folks do 208v 3phase 100A circuits.

Post reply on HN