Proposed server purchase for GitLab.com

I would strongly consider doing this via pure L3 routing. This is a scale at which the benefits of L2 fabric switching vs L3 multihomed routing (yes, routing decisions on every node) begin to be interesting decisions.

A few things to watch out for, if your team doesn't have a lot of experience in direct management of dedicated servers/datacenters:

- There is an increased risk of larger/longer very rare outages due to crazy circumstances. Make sure you have a plan to deal with that. (I've had servers hosted at a datacenter that flooded in Hurricane Sandy, and another where an electrical explosion caused a >3 day outage..)

- It's easy to think you'll rely on managed services, but that rarely works out well. It also can become very, very expensive -- possibly more so than cloud-based hosting.

- Specifically, regarding H1, H2: Dedicated hardware is substantially cheaper than cloud-based hosting, but if you rely too much on managed services you negate a large portion of the savings. Consider that most service providers will be both more expensive and less competent than doing it yourselves. Also, having your own team have direct knowledge + their own documentation of the setup will be beneficial.

- I'd recommend budgeting for and ordering some extra parts to keep on hand for replacement, if you are having datacenter ops handle hardware or can have an engineer located relatively close to your datacenters. (A few power supplies, some memory, a couple drives - nothing too crazy.)

- Supermicro's twins systems are great. In the past I've gone with their 1U models vs. 2U to slightly reduce the impact of unit downtime. (Having to take one 2U Twin down affects four nodes. It sounds like you'll have to decide on balancing that against the increased drive capacity, in your case.)

The FatTwin chassis has similar density, and can support either 1U half width or 2U half width systems in a particular chassis. Typically I use 1U's for app / web servers and 2U's for lower end database / storage. Separate 2U servers for higher end database and 4U servers for bulk storage.

HPE has the Apollo 2600 / XL170r 2U chassis, which I think is somewhat inferior but still a reasonable choice. Dell sells the same thing as the C6300. I really prefer a 4U chassis though from a cooling and power supply perspective, but Dell or HPE may have a better international story for you.

You absolutely should not buy the 2630v4 CPU. I say that because the lower-end Intel CPUs do not support maximum throughput for memory and QPI. The 2630v4 is 8.0GT/s QPI and 2133MHz DDR4. A better solution low-watt part is 2650Lv4 (9.6GT/s QPI and 2400MHz DDR4). I have a guide that I created (and use myself) to determine comparative $/performance of Intel CPUs based on SPEC numbers [1]. If you can go up to 105W the 2660v4 is probably your best bet. Presuming that you're targeting 12-15kW per rack, a 105W part should allow you to deploy between 60-80 hosts per rack.

Also, don't use a W-series CPU that draws 160W. That's crazy power draw per-socket. If you want a super high-end CPU for your database server, I suggest a 2698v4 -- but normally I would go with 2680v4 or 2683v4 depending on the part cost.

In terms of hard drives, absolutely you should specify HGST over Seagate. At some point you may want to dual source this, but if you're only going with one vendor right now HGST is the best option. He8 or He10 8TB are your best bet in terms of cost and availability right now, although start thinking about He10 10T drives. The newly announced He12 drives shouldn't be on your radar until Q2 2017. Stock spares, maybe 2-3% of your total drives deployed, but at least 5-6 drives per site. You don't want to get caught out if there is a supply shortage when you need it most. Your business depends on ready access to considerable quantities of storage.

The P-series Intel SSDs are probably not going to be cost effective for your use case. But they are considerably better in terms of IOPS and remove the need for an HBA or RAID controller. Consider a Supermicro 2U chassis with 2.5" NVMe support, which will allow you to go considerably denser than the PCIe form factor. However, I think it's too early to go with NVMe unless you truly need beyond-SSD performance.

Don't PXE boot every time you boot. This creates a single point of failure (even if your architecture is redundant), and you will regret this at some point. However, DO PXE boot to install the OS.

Don't use 128GB DIMMs. They are not cost effective today.

There is only one solution for database scaling: shard. You'll either shard it today, or you'll shard it tomorrow when the problem is much harder. Scale up each host to what is easily achievable with today's hardware, and if push comes to shove retrofit to get over a hump that arises in the future, but know that you MUST shard in order to keep up with demand. Scaling up simply does not work.

There's a lot more to say, but without doing my job for free in a HN comment, the best advice I can offer is:

1. Simplify what you hope to accomplish in the first round. This is a lot to achieve at once. I think you'll have a hard time achieving the fanciness you want from a software perspective while also forklifting the entire stack over to physical hardware. It's perfectly fine to have something be good enough for now.

2. Find people who have done this before and get their advice. Find a VAR you can trust.

3. Plan, plan, plan, plan. Don't commit until you have a plan, make sure the plan is flexible enough to change course without tossing everything out, and plan to do a good enough job to survive long enough to figure out a better plan next time.

4. Get eval gear, qualify and test things, and make sure that what you think will work does work.

[1] https://docs.google.com/spreadsheets/d/1bbbeMCmqt5pZCb_x2QMW...