导读	2016 年底我们曾说自己要停用云服务，转为使用裸机硬件，并分享了我们有关硬件的提议。2016 年 12 月，在接到数百条提供建议和提醒的评论与邮件后，Sid 和他的团队决定继续在云中运行 GitLab.com。

本文总结了社区成员发给我们的一些支持和反馈，文末我们还总结了通过云环境让 GitLab.com 变的更加快速可靠的计划。我们的决策依据并非仅基于下文列出的原因，不过其中一些有趣的信息还是有必要总结并共享给大家。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

别乱折腾存储了。 32 台文件服务器总容量才 96TB？网络 Re:ceph 也是类似的情况。你的故障域在哪里？为了确保这一切正常运转需要指派的全职员工会产生多少成本？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

平均 300 个读取只产生了 10 个写入

• 我们将所有存储分散到多个 NFS Shard 并从技术栈中取消了 CephFS。
• 我们创建了 Gitaly，这样在横向扩展过程中可以不再依赖 NFS，并能通过缓存加快 Git 访问速度。

Gitaly 将充当整个技术栈中所有 Git 访问的单一接口。通过使用 Gitaly，可以通过网络传输 gitrpc 并对磁盘进行本地访问，借此避免所有磁盘访问都要通过网络进行。这样还有助于改善我们对 Git 资源用量的监视，借此有助于作出更好的决策，不过目前我们尚处在抽样过程中。

在此我们想感谢社区、客户、团队，以及董事会的不懈支持，正因为你们，GitLab 才能成为一个如此出色的产品。

原文来自：http://www.yunweipai.com/archives/18870.html

本文地址：https://www.linuxprobe.com/gitlab-persist-clouds.html编辑员：郭建鹏，审核员：逄增宝

本文原创地址：https://www.linuxprobe.com/gitlab-persist-clouds.html编辑：roc_guo，审核员：暂无