Gitlab：为什么我们坚持用云？

栏目: 服务器 · 发布时间: 6年前

内容简介：Gitlab：为什么我们坚持用云？

本文基于CC BY-SA许可授权翻译并发布。

2016年底我们曾说自己要停用云服务，转为使用裸机硬件，并分享了我们有关硬件的提议。2016年12月，在接到数百条提供建议和提醒的评论与邮件后， Sid和他的团队决定继续在云中运行GitLab.com。下文总结了社区成员发给我们的一些支持和反馈，文末我们还总结了通过云环境让GitLab.com变的更加快速可靠的计划。我们的决策依据并非仅基于下文列出的原因，不过其中一些有趣的信息还是有必要总结并共享给大家。

先从成本这个话题开始吧

我在Koding就职时，曾做过类似的事情，从AWS迁移为裸机硬件运行。成本变化非常惊人。使用AWS时每月20万美元的成本被缩减至大约2万美元。因此很长时间以来我一直在坚持说，一旦达到某一程度的规模，AWS将不再是最合理的选择。 Geraint - GitLab blog: Going bare metal

过去十几年来，我们在纽约市托管了140台左右的服务器，托管成本与日俱增，并且我们签署的合约不够灵活，无法按照需求随时增添机柜。此时我们基本上只能取消之前的合约，签署新的合约，支付升级费用，支付机柜的安装等费用…… 终于等到某一天，我们已经无力承担每月1.4万美元的托管费用，因此决定将所有服务器从纽约市迁移至爱沙尼亚首都塔林，我们在那里自行构建了一个专用的小型数据中心。借此我们的托管费用降低了10倍。 Dmitri - GitLab blog: Proposed server purchase

成本不仅仅体现在硬件的拥有和更新方面，还体现在伴随硬件的方方面面。 – daenney

成本不仅仅体现在硬件的拥有和更新方面，还体现在伴随硬件的方方面面。网络的设计，性能调优，以及一切东西的调试。突然你就会开始遇到容量不足的问题，你可能并没有已经准备好，随时可以投入使用的100台备用服务器，或者无法在2分钟里将这些服务器顺利投入使用，这时你打算怎么办？自动缩放？ daenney - Hacker News: Proposed server purchase

相比云服务或逻辑硬件部署之争，应用程序的架构其实更重要。遇到这种问题后，简单直接地抛出更多裸机硬件，这样的做法比使用云实例更简单，也更具成本效益。因此在某些情况下，裸机硬件比云服务更适合。 mohctp - Hacker News: Proposed server purchase

转为使用自己专用的硬件，无疑有助于改善性能，缩短偶发的停机时间，并大幅降低成本。就算考虑到雇佣更多工程师的成本，相比使用云服务，改为使用裸机硬件后的前24个月，通常也可以实现40%-50%的成本节约。如果硬件的生命周期是36-48个月，那么24个月后还能节约更多成本。 bobf - Hacker News: Proposed server purchase

我觉得他们可能低估了GitLab长期运行的成本。当他们意识到必须雇佣一个一年365天，一天24小时随时待命，在故障后30分钟内抵达数据中心的人；当他们意识到必须准备多少备用的硬件设备…… manacit - Hacker News: Proposed server purchase

性能问题该怎么办？

云服务供应商最大的责任是保障客户内容的安全性、持久性、可用性，以及性能（优先级逐级递减）。大家伙严重低估了要实现前三点所涉及的复杂性。 mritun - Hacker News: Proposed server purchase

Google内部很少有团队使用专用的物理机。而真正这样做的团队无论在基础架构的规模和团队的规模方面都是极为庞大的。我并不是说就必须只能用云服务，我反复重申的一点是：至少你需要确定自己真的需要这样做。 boulos - Hacker News: Going bare metal

推行自有系统的公司无须使用共享的资源，而且可以结合自己的独特需求对整个系统进行有针对性的优化。– taneq

然而作为云供应商，需要通过共享的资源为一群客户提供服务。推行自有系统的公司无须使用这种共享的资源，而且可以结合自己的独特需求对整个系统进行有针对性的优化。 taneq - Hacker News: Going bare metal

我认为，面对硬件故障的弹性和恢复能力，以及迁移和多数据中心高可用性将成为最关键的问题。从云服务切换至裸机硬件部署，确实能获得更高性能和更简化的系统，但面对网络中断和硬件故障，可考虑的选择变少了。 wpostma - the GitLab blog: Going bare metal

似乎他们一开始并非面向云服务设计的，现在开始承受后果了。相比自有数据中心，选择云服务需要作出不同的取舍，也会遇到不同的性能问题。如果打算这样做，其实也挺好。借此可以获得一套更稳定的软件环境。但如果对数据中心的各种特征采取想当然的态度，迟早还会遇到别的问题。 wandernotlost - Hacker News: Going bare metal

对于GitLab.com来说，在大规模环境里“吃自己的狗食”是种很合理的做法。 – jtwaleson

对于GitLab.com来说，在大规模环境里“吃自己的狗食”是种很合理的做法。这样的话，如果他们自己的客户在自己的本地部署环境中遇到性能问题，他们就没法简单地说：GitLab.com使用了和你们完全不同的架构，所以你们只能自己想办法解决了。客户往往希望GitLab.com本身的系统能够和标准产品尽可能一致。 twaleson on Hacker News: Going bare metal

他们因为性能的元怒因从云服务转为使用裸机硬件，而他们自己也在使用很多众所周知非常缓慢并且糟糕的软件。如果是我本人打算作出如此重大的改动，肯定会先对整个栈进行优化。构建自己的硬件设施无法直接获得业务价值，并且整个过程极易出错（切身经验和感受）。 StreamBright - Hacker News: Proposed server purchase

针对存储提议给出的建议

别乱折腾存储了。32台文件服务器总容量才96TB？网络Re:ceph也是类似的情况。你的故障域在哪里？为了确保这一切正常运转需要指派的全职员工会产生多少成本？* Spooky23 - Hacker News: Proposed server purchase - Spooky23确实警告过我们“我就是个脾气古怪的老家伙”。

我觉得切换到这种硬件后，IOPS指标肯定会大幅下降。你们基本上是在一个CephFS群集中用了大约60个7200 RPM转速的硬盘。自己算算吧，如果假设每块硬盘可实现100个读取和100个写入的IOPS操作，写入方面还会产生3倍的复制操作（外加日志写入），举例你们的目标肯定差得很远。 Nicholas - the GitLab blog: Proposed server purchase

我不禁猜测GitLab的工作负载大部分都是随机的，对于大容量硬盘这会造成一个问题。SSD是个不错的选择，但在这样一种2-3层的设计中，我只看到他们使用了8TB容量的硬盘，每一层都使用了8TB的硬盘。我也不太确定，为单块8TB容量硬盘组成的24TB存储使用一块SSD作为缓存能起到多大的效果。 lykron - Hacker News: Proposed server purchase

以及我们选择使用8TB硬盘的决定

如果追求性能，别使用8TB容量的硬盘。根据我的经验，容量超过5TB的硬盘响应时间都不怎么理想。我没有很具体的数据，但我分别用单块5TB和单块2TB的硬盘组建过10盘RAID6阵列，2TB硬盘的阵列响应速度明显更快。 lykron - Hacker News: Proposed server purchase

就提几个简单的意见。我曾遇到过约300TB的Ceph存储不可用的情况。绝对不要用8TB硬盘。为什么要使用这么臃肿的东西？老实说这样做有什么好处吗？你们需要的是更多数量的硬盘，对处理器内核和内存的要求反而没有那么高。按照目前的配置，每个机架单元能实现多大的容量？ halbritt - Hacker News: Proposed server purchase

有关网络提议的反馈

别乱折腾网络了。在你们那种超级微型的软件定义网络中，你们具备运营相同或类似工作负载的经验吗？当你凌晨两点给CEO打电话时，他会接吗？* Spooky23 - Hacker News: Proposed server purchase

我绝不会用10GBase-T，因为这是为桌面使用设计的。我建议最好能用25G SFP28（AOC-MH25G-m2S2TM），不过10G SFP+（AOC-MTG-i4S）也行。交换机的速度和类型必须与网卡匹配（你们连接到的SFP+交换机跟你们提议使用的10GBase-T网卡并不兼容）。 wmf - Hacker News: Proposed server purchase

虽然没见到有人提过，但你们的网络策略有何规划？是否要运行IPv4/IPv6双栈？仅IPv4？仅内部IPv6同时对外使用NAT64？希望IPv6能在你们的网络栈中占据一席之地。重量级选手都还没用IPv6，让人有些难过。 tomschlick - Hacker News: Proposed server purchase

别掉进将VLAN扩展得到处都是这样的陷阱中。你们绝对会需要在不同路由器之间路由（而非交换）。

“是否要为Ceph流量提供专用网络？”当然，如果你希望重建的过程中整个Ceph群集能继续保持可用状态的话。在任何类型的重建操作中，Ceph会全面跑满整个内部网络。 devicenull - Hacker News: Proposed server purchase

社区对Ceph的看法如何？

我领导的技术运维团队曾将我们的基础架构从公有云（约400个实例）迁移至私有云（约55台物理服务器），并最终迁移至Kubernetes（6台物理服务器）。我们其实混合运行了Kubernetes和OpenStack，应用和服务放在Kubernetes上，所有数据存储放在OpenStack上。我也对Ceph进行了全面的测试，虽然更灵活，但对于数据库这种用例，将无法达到近似于裸机硬件本地磁盘的I/O性能。对于存储，我觉得越简单越好。我主要使用经过实践检验的标准文件系统（ext4和ZFS）运行 Linux 操作系统，在软件层实现冗余。 Chris - GitLab blog: Proposed server purchase

我们以前通过裸机硬件运行Ceph和Gluster时获得的体验非常糟糕。我觉得，本质上来说，这也意味着分布式文件系统在成熟度（以及技术难度）上还不如云服务那么完善。 codinghorror - Hacker News: Going bare metal

需要明确的是，没有任何一种架构可以让你避免运行CephFS群集。CephFS很酷，但目前来说还存在单点故障的可能，并且还有很多需要注意的问题。如果能消除CephFS创建的抽象层，让应用直接处理某种类型的分布式存储系统任务，性能和稳定性都会大幅提升。 Nicholas - GitLab blog: Proposed server purchase

面对有关Ceph的炒作，请淡定 – late2part

面对有关Ceph的炒作，请淡定。Ceph的优势在于冗余和吞吐量，而非IOPS，Rados IOPS指标很差。就算在使用120块SSD组建的OSD群集上，我们也无法获得超过60k随机读写IOPS的指标。 late2part - GitLab blog: Proposed server purchase

如果你在使用CephFS，而其他所有人都希望使用其他云存储解决方案，这等于在你和你的用户之间造成了分裂，并为在云存储的缩放方面具备相应工具和经验的竞争对手制造了可乘之机，他们会趁机抢走你的用户。 Rapzid - Hacker News: Going bare metal

转为使用裸机硬件会对GitLab团队产生哪些影响？

你们的核心能力在于代码，而非基础架构，因此自己团队和组织内部自行努力构建这一切新能力，最终将产生无法预测的成本。云和自行部署环境的总体拥有成本分析，并不是简单地对比托管、硬件，以及设施成本。 ninjakeyboard - Hacker News: Proposed server purchase

你们的核心能力在于代码，而非基础架构。– ninjakeyboard

转为使用裸机硬件的另一个问题是，你们会失去技术支持。云供应商有完整的团队、网络、系统、数据中心等，并且随时听候你的调遣，这些服务也已经包含在你支付的费用中。你确定自己能像云供应商那样自行进行相同水平的网络和系统问题调试吗？这可是个辛苦活。 l1x - GitLab blog: Proposed server purchase

我觉得你们低估了自行运营一套基础架构需要的人数。你需要懂得配置网络设备的人，懂得在数据中心更换故障的网卡和硬盘的人，擅长管理供应商关系的人，以及知道怎样进行容量规划的人。 thebyrd-on Hacker News: Proposed server purchase

咱们还是联手抛弃x86吧

为何将自己牢牢绑在Intel服务器上？ – MBH

为何将自己牢牢绑在Intel服务器上？CPU和内存之间的最大带宽仅为68GB/s，对于高速数据处理这简直太恐怖了。IBM的POWER8系统有服务器能提供230GB/s的CPU至内存带宽，甚至还有高达320GB/s的产品……

…… POWER8的CPU使用了与Intel不同的架构：PPC64，因此可能需要重新编译某些软件，或者为一些只支持x86_64的工作负载保留一些Intel系统。 MBH - GitLab blog: Proposed server purchase

我们都有自己的看法

我只自己组装过台式电脑，顶上的评论与我组装台式电脑的帖子里的评论情况极为相似。挺不错的，我相信随着研究越来越深入，肯定会得出越来越不同的结论，但我本人对组装服务器实在没什么经验，但是看到上面也有人提到了能耗和冷却问题，不知道为啥我竟然觉得挺安心的！ davidbrent - Hacker News: Proposed server purchase

我们打算后退一步选择一种乏味的解决方案

我们希望能智能地缩放，并且能开发出伟大的软件；我们并不想转型成专注于基础架构的公司。因此最终我们决定继续拥抱云服务，借此解决GitLab.com在规模方面遇到的挑战，对于这个决定我们同样感到激动，因为只要我们能解决了这个问题，也就等于解决了全球各地在自己的本地环境中使用GitLab的企业所面临的问题。

有关规模的大部分问题主要源自Git是一种读取密集型工作负载：从下方的Git读/写性能图表中可以看到，大概每300个读取操作才会产生10个写入操作。我们曾试图通过云服务中运行的CephFS解决这个问题，但这样的做法违背了我们针对每个问题使用最简单，最乏味解决方案的价值观。