GitLab想离弃云，但...

我们社区对于我们提出离弃云的提案进行了审查，这是我们从社区听到的一番心声。

临近2016年年底时，我们曾表示要离弃云、改用裸机，还介绍了我们的硬件提案。2016年12月，锡德（Sid）及其团队收到内容满是忠告和警告的成百上成的评论和电子邮件后，决定让GitLab.com继续留在云端。本文总结了我们获得的一些出色的社区支持和反馈，末尾介绍了我们如何致力于让GitLab.com在云端保持快速而稳定。我们所做的决定绝不仅仅基于下面这些，而是我们想为各位好好总结一下所有公开分享的值得关注的东西。

不妨从成本这个主题开始说起

我还在Koding的时候，我们做出了从AWS迁移到裸机的类似举动。成本很惊人。原本每月花2万美元从AWS享用的系统要花20万美元。我长期以来一直在说：一旦你达到了一定规模，AWS不再明智。Geraint

我们有140台服务器托管在纽约市持续了大概10年，托管的机器越来越多，而合同并没有给我们需要时添加机柜的灵活性。我们基本上不得不取消以前的合同，签一份新的合同，支付升级费，支付机柜安装费等费用。到了我们每月支付1.4万美元的托管费觉得吃不消时，我们决定将自己的所有服务器从纽约迁移到爱沙尼亚的塔林，我们在那里自行构建了个小型数据中心。因此，我们得以将托管费缩减至原来的十分之一。 Dmitri

不仅仅有拥有和更新硬件的成本，还有随之而来的其他各项成本。设计网络、优化性能和调试一切。突然你遇到了容量问题，因为你不可能有100台备用的服务器堆叠起来、准备投入使用，或者能够在短短2分钟内将它们启动起来，现在应该怎么办？自动扩展吗？daenney

应用程序架构远比使用云还是裸机来得重要。添加更多的裸机硬件来解决这个问题比使用云实例完全来得更容易、更具成本效益。对于一些人来说，这确实让裸机成为一种更好的选择。mohctp

迁移到自己的硬件几乎肯定会提高性能，缩短意外停机时间，并大幅降低成本。包括雇用更多的工程师，你的成本预计是头24个月花在云服务上的成本的40%-50%左右。如果你的硬件生命周期是36个月-48个月，24个月后就会看到节省大幅费用。bobf

我认为，他们会低估GitLab的长期成本。如果遇到第一次故障后，他们需要出钱请人从哥伦比亚特区开车30分钟赶来救急（而且做到24/7/365），这时他们就会认识到自己想要手头有多少的备用硬件。manacit

性能怎么样？

云服务提供商对客户要负的最大责任依次是安全性、耐久性、可用性和性能。你们这些人大大低估了做好头三点所面临的复杂性。Mritun

谷歌里面很少有团队在专用机器上运行。在专用机器上运行的规模庞大，无论指他们的基础设施规模还是团队规模。我倒不是说总是选择云提供商；我只是重申，你最好确信自己需要这么做。boulos

不过作为云提供商，你要努力为一群客户提供共享资源。自行部署系统的公司没必要共享，它们可以针对自己的需求来进行专门的优化。Taneq

我认为，遇到故障后的弹性和恢复、迁移以及多数据中心高可用性将成为关注的问题。从云迁移到裸机确实带来了性能和简单性，但是没有提供遇到网络中断和硬件故障后恢复过来的多条途径。wpostma

听起来他们没有针对云而设计，现在正在品尝后果。云的取舍和性能特点与数据中心不一样。如果你对此作了计划，那很好。你的软件因此会很可靠。如果你以为会得到数据中心的特点，可能会遇到问题。Wandernotlost

让GitLab.com继续是一种大规模吃自己的狗粮（eat-your-own-dog-food-at-scale）环境是明智的。如果其中一个运行内部系统的客户遇到了性能问题，他们就不能说：GitLab.com使用全然不同的架构，所以你全靠自己。他们需要GitLab.com尽可能接近标准产品。twaleson

由于性能，他们正从云迁移到裸机，同时使用一堆速度奇慢、浪费严重的软件。我会先优化自己的堆栈，然后致力于做这样的变化。构建自己的机架并不带来商业价值，它是极易出错的过程（我可是深有体会）。 StreamBright

针对我们的存储提案的忠告

别搞乱存储。32台文件服务器提供96TB？这与网络re:ceph是同一个问题。你的故障域是什么？维护运行这套东西的专职员工要花多少费用？* Spooky23

我认为，如果你切换到这个硬件，IOPS可能会大幅下降。你可以看一下这个CephFS集群中的大约60个7200转速驱动器。算一下，如果假设那些驱动器每个都能做到100个读取和100个写入IOPS，写入时执行3x复制（加上日志写入），就根本不会得到你想要的数字。Nicholas

我认为，GitLab的工作负载大多是随机的，这会给大容量驱动器带来问题。固态硬盘（SSD）是个好主意，但我只看到有两三个存储层时才使用8TB驱动器，8TB驱动器一直在底层。我不确信让单单一只SSD充当24TB（8TB磁盘）的缓存驱动器有多高效。lykron

还有我们选择的8TB驱动器

如果你寻求高性能，别使用8TB驱动器。按照我的经验，5TB以上的驱动器没有良好的响应时间。我没有确凿的数字，不过我用5TB磁盘和2TB磁盘搭建了一个10只磁盘的RAID6阵列，2TB磁盘的响应速度要快得多。lykron

仅仅简单说几句。我之前运行行约300TB的可用Ceph存储。离8TB驱动器远点。为什么你使用FatTwin？老实说，这种服务器给你带来了什么？您需要更多的旋转硬盘，更少的内核和内存。就当前配置而言，你每个机架单元能得到什么样的性能？halbritt

关于我们的网络提案的反馈

别搞乱网络。你有过在Supermicro SDN上运行同样或相似工作负载的经历吗？你在凌晨打电话过去时，那家Supermicro 增值分销商（VAR）的首席执行官会接电话吗？* Spooky23

我不会使用10GBase-T，因为它是为桌面使用设计的。我建议，最好是使用25G SFP28（AOC-MH25G-m2S2TM），但10G SFP+AOC-MTG-i4S）也行。交换机的速度和类型需要与网卡（你们连接到了与提议的10GBase-T网卡不兼容的SFP +交换机）相匹配。wmf

我没有看到它被提到，但你们对网络策略有什么样的方案。你们是否准备运行双协议栈IPv4/IPv6？仅仅运行IPv4？还是内部只运行IPv6，但通过NAT64连接至公开内容？但愿IPv6在协议栈中会有一席之地。看到大厂商还没有使用IPv6真是件憾事。tomschlick

不要陷入在每个地方都扩展虚拟局域网（VLAN）这个陷阱。你绝对应该在不同的路由器之间路由（不是交换）。

“我们应该为Ceph流量设立一个单独的网络吗？”是的，如果你希望自己的Ceph集群在重构期间仍然可以使用。在任何一种重构事件过程中，Ceph都会导致内部网络挂起。devicenull 

社区对于Ceph有什么要说的？

我领导着一个技术运维团队，该团队将我们的基础设施从公共云（约400个实例）迁移到了私有云（约55台物理服务器），最后迁移到了Kubernetes（6台物理服务器）。我们实际上混合运行Kubernetes和OpenStack，把应用程序和服务放在Kubernetes，把所有数据存储放在OpenStack。我之前对Ceph做了大量的测试；虽然它增添了灵活性，但是就数据库使用而言，你无法达到裸机本地磁盘的I/O性能。就存储而言，我喜欢保持简单。我依赖在久经考验的标准文件系统（ext4和ZFS）上运行的Linux操作系统，并在软件层构建冗余机制。Chris

我们在裸机上的Ceph和Gluster方面遇到过灾难事件。我认为，相比云本身，这更多地表明了分布式文件系统的不成熟（和难度）。codinghorror

你需要确保没有一种你可以构建的架构让你没必要运行CephFS集群。CephFS是很酷，但现在它是单一故障点，而且有许多要注意的地方。如果你消除它带来的抽象层，编写自己的应用程序来处理某种分布式存储系统，那么性能和稳定性将大有改善。Nicholas

关于Ceph方面的炒作，一定要格外小心。Ceph在冗余性和吞吐量方面是不错，但在IOPS方面不好，Rados IOPS很差。我们在配备120只SSD的120 OSD集群上无法超过6万的随机读写IOPS。late2part

如果你使用CephFS，其他每个人都想使用其他的云存储解决方案，那么这实际上会让你与用户相脱节，并为云存储扩展方面拥有相关工具和经验的竞争对手留出了前来提供支持的余地。Rapzid

迁移到裸机会怎样影响GitLab团队？

你们的核心竞争力是代码，而不是基础设施，所以在你们的团队和组织努力打造所有这些新功能是需要付出代价的，这个代价是你们无法预测的。分析云与裸机的总体拥有成本并不像比较托管成本、硬件和设施那么简单。ninjakeyboard

对于迁移到裸机，我想说的另一个问题是，你失去了支持。云提供商有整个团队、网络、系统和数据中心可供你使用，这已包括在你所付的价格中。你确信自己准备好与云提供商同样的水平来调试网络问题和系统问题吗？这是一项艰难的工作。l1x

我认为，你们低估了运行自己的基础设施所需要的人数。你需要能够配置网络设备的人员，需要在数据中心换掉出故障的网卡/驱动器的人员，需要管理厂商关系的人员，还需要从事容量规划的人员。thebyrd

就让我们完全丢弃x86吧

何必让自己被英特尔服务器牢牢束缚？CPU到内存的最大带宽是68 GB/s。这个速度对于快速处理数据而言很糟糕。IBM的POWER8系统拥有CPU到内存带宽是230 GB/s的服务器，其他的更是达到320 GB/s ...

... POWER8 CPU具有与英特尔不同的架构：PPC64，所以你可能需要重新编译一些代码，或者让一些英特尔系统处理只能在x86_64上运行的工作负载。MBH

我们正在后退一步，使用一种无聊乏味的解决方案

我们想要智能化扩展，构建出色的软件；我们不想成为一家基础设施公司。我们在积极克服云端扩展GitLab.com面临的挑战，并以此为乐，因为为我们解决这个问题也就为本地使用GitLab的全球最大企业解决了这个问题。

大多数扩展方面的难题之所以发生，是由于Git面临频繁的读取操作：看看我们下面的Git读取/写入性能图表下面，你就能看到：每300次读取，才有10次写入。我们试图通过在云端运行CephFS来解决这个问题，但是它违背了我们使用最简单、最无聊乏味的解决方案来解决问题这个宗旨。

平均300次读取才有10次写入

我们如何回归基本面？

1. 我们将所有存储分散到多个NFS分片（NFS shard），并去除了堆栈中的CephFS。

2. 我们创建了Gitaly（https://gitlab.com/gitlab-org/gitaly），那样我们不用依赖NFS实现横向扩展，并通过缓存来加速Git访问。

Gitaly将为我们整个堆栈中所有的Git访问充当单一接口。有了Gitaly，gitrpc通过网络来传输，磁盘实现本地访问，而不是所有磁盘访问都通过网络来进行。它还将用于改进我们对Git资源使用情况的监控，以便做出更合理的决策；目前我们只是对流程进行采样。

我们希望社区能像过去那样热情地对我们使用的Gitaly指出不足和意见。你对软件架构有什么看法？像这样的缓存层可以扩展吗？触发了什么警报？我们迫不及待地想听到你们的反馈！

我们想感谢我们的社区、客户、团队和董事会给予的所有大力支持，你们共同让GitLab成为一个不可思议的产品。

云头条编译｜未经授权谢绝转载

相关阅读：