当Amazon Web Services在2018年发布其AWS Graviton Arm处理器时，它的目标是松散耦合的横向扩展工作负载，比如Web服务器、日志处理和缓存，这些实例吸引了SmugMug这样的客户，他们觉得自己在高级计算上付出的代价太高了，而一个较小的内核就可以完成这项工作。基于Arm的计算实例可以替代绝大多数云巨头客户使用的基于x86的服务。

　　亚马逊EC2的副总裁、David Brown,在接受New Stack采访时表示，从很多方面来说，这都是为了启动生态系统。“我们想向生态系统发出信号，Arm服务器芯片将成为现实，我们将把它们推出市场。”

　　准备好生态系统意味着，Graviton2不仅可以快速支持EC2实例，还可以支持越来越多的AWS服务，包括Amazon RDS、Amazon ElastiCache（其中Graviton2实际上是默认的）和像Amazon EKS这样的容器服务。

　　只有在客户选择处理器架构的时候，Graviton才会显现出来；在“绝大多数服务”中，客户将永远不会看到该服务是在Arm上运行的，但他暗示很多客户将会看到。

　　Brown指出，将AWS服务迁移到Arm还有助于使生态系统为客户的工作负载做好准备。“这为我们提供了很多内部经验，涉及客户将会经历的事情，以及确保我们在生态系统中能够接触到各个参与者，并通过我们可以构建的工具和可以帮助您的事情来解决问题。”

　　Graviton2甚至可以作为一个拥有64个vcpu、128GiB内存和4TB本地NVMe存储来运行Amazon EC2和EKS的1U服务器（尽管AWS建议将其用于受限制的位置，如蜂窝基站而不是主流数据中心）。“我们从客户那里听说，他们很希望在前哨站安装Graviton2，就支持生态系统而言，并确保我们能在客户需要的时候提供他们想要的硬件，ARM处理器并不意味着不能在前哨站安装。”

　　AWS还将添加更多基于AWS Graviton2的实例-最新的是计算和网络密集型C6gn，以及为大型内存数据集或计算密集型工作负载而设计的实例，带有或不带有本地NVMe存储。

　　从卸载到整合

　　Brown建议考虑开发类似Graviton的硬件微服务，它可以比整个单片硬件系统更快地建立起来。Brown说，所有的云服务提供商都希望降低在同一个CPU上运行云服务的开销，而AWS Nitro计算核心的运行效率远不止于此。

　　一定比例的处理器（不管它是什么）被虚拟化堆栈和需要在机器上运行的大量其他管理软件所使用。我们注意到的是，除了降低效率之外（因为您使用了本可以提供给客户的10 - 20%的核心用于您自己的工作和管理程序），我们还无法获得我们认为客户需要的那种性能。

　　AWS使用Nitro将越来越多的开销转移到单独的处理器上，以提高性能并使其更加一致。“我们做的第一件事就是移除网络并将其卸载到Arm处理器上。我们卸下了所有的管理控制职能，最终在2017年，我们的CPU使用率达到了零。”

　　由于Arm授予IP许可而不是出售处理器的方式，Arm SoC通常是CPU，GPU和加速器的自定义程序包，并且Amazon添加了许多AWS特定功能。

　　“Graviton2的三分之一是Arm核心，其余部分是我们设计的定制硅，”Brown说。这包括加密内存和提高内存性能。很多工作是确保纠错，并确保内核确实非常正确，并且可以处理可能无法正常工作的内存模块，并保护客户工作负载免受此类故障的影响。“

　　CPU绑定应用程序的核心

　　Arm以移动芯片起家，常常被视为一种降低功耗的方法，而高核心数量使Arm系统很适合并行化，但最近几代Arm也提供了强大的核心。这一组合带来了AWS所关注的性价比。

　　”Arm核心消耗的能量只有可选核心的一半。客户看到了20%的原始性能改进；如果你在同一个基准测试中运行，在Graviton2和最新的英特尔处理器上，Graviton2大约快20%，“Brown说。它还便宜20%左右。因此，你可以得到40%的价格性能改进，Brown说。

　　”我们已经看到客户使用支持ARM64的最新版本的Java获得了巨大的性能优势。我们看到客户也从数据库应用程序中获得了这一好处。他说，只要看到核心的性能，价格就可以了。

　　Brown说，客户通常在移动更多堆栈之前就开始在他们的应用程序层使用Graviton。“它不需要大量的计算密集型；它只是一些CPU受限的最通用的工作负载，如果可用的话，它们会使用更多的CPU。很多云本地工作负载，无论是运行在EC2上的本地工作负载，还是运行在我们的容器堆栈上的工作负载，都将看到显著的性能优势。”

　　这也可以削减其他虚拟机的成本。Duckbill Group首席云经济学家Corey Quinn告诉New Stack，许多IaaS实例的使用率极低。“如果我看一下大规模客户运行良好的大型机队，在某些情况下我们正在谈论数以万计的节点或更多，那么这些方面的CPU利用率是可笑的：平均个位数百分位数。”

　　可观测性服务提供商Honeycomb被更便宜、更具性能的实例的承诺所吸引。“我们是一家SaaS公司，尤其是基础设施SaaS公司，因此我们的大部分运营费用是我们的AWS账单，”首席开发律师Liz Fong Jones告诉New Stack。

　　切换到Graviton2可使公司工程师在40个实例上运行相同的入口工作负载（接收JSON对象并将它们放入Kafka），而不是X64上需要的70个实例，并且性能没有明显变化。他们还可以将CPU利用率提高到更高（50-60％，而不是之前设置的45％），而不会出现使用率高峰时使CPU饱和的风险。Fong-Jones推测这是因为Graviton2内核不是超线程的。“每个核心都是真正的核心，它不是共享的执行单元。”

　　为了获得更好的性能，Honeycomb还将查询引擎工作负载（它是IO和CPU绑定的，并且需要NVMe存储）从Intel Xeon上的存储优化的i3实例转移到Graviton2 M6GD，尽管成本要高出大约10%。她说：“实际上速度是它的两倍。”

　　该公司正在继续将工作负载转移到Arm。前端服务基础架构（不占用大量CPU）现在可以在Graviton1上运行，而Fong-Jones计划纯粹出于成本原因计划切换其Kafka工作负载。对于持续的工作量，该公司使用Compute Savings Plan，并且她希望通过Graviton2的试验能够降低支出水平。

　　Arm准备做什么？

　　当开发人员社区开始评估Apple的新型基于Arm的Mac时，有关在ARM64客户端上可以使用哪些工具的问题一直存在疑问，但是ARM64服务器软件生态系统已经准备就绪，可以在几天或几周内完成一些迁移，Brown建议。

　　“在很大程度上，如果人们在构建应用程序，那么这些应用程序的运行时很有可能是为ARM处理器构建的。例如，Python或Java运行时提供支持ARM的运行时，”Gartner研究总监Raj Bala告诉New Stack。“这一挑战将涉及可能利用ARM无法提供的处理器特定功能的框架。”（商业的、现成的）应用程序可能是最大的挑战——或者可能是Docker容器不是用ARM支撑构建的。“

　　Fong-Jones告诉我们，内部代码肯定不太可能准备就绪。”你可以得到一个可以运行的Ubuntu图像，这已经相当大了。同样，不仅仅是Java和PHP是解释语言，golang也是。如果没有golang对ARM64的支持和交叉编译的支持，我们不可能做到这一点。“

　　但她说，那是比较容易的部分。我们必须做一些准备工作，以验证我们没有任何硬依赖于x86汇编。我们确实有一些相当优化的存储部分，有一些使用AMD64组装，但他们有常规的Go等效物。但挑战在于所有的底层系统架构。”

　　Honeycomb的安全入侵系统是建立在osquery上的，osquery最近才引入了ARM64支持（部分是由于Honeycomb对端口的赞助）。“如果我们部署了一堆这样的服务器，而没有对它们进行适当的入侵检测，我们的安全审核员会对我们非常不满。”

　　该公司依赖于Chef配置管理软件。Chef 15支持ARM64，但Honeycomb使用Chef 13。“Chef 13，至少是由Chef公司提供的，不是为ARM64设计的。所以我们不得不将一些Ubuntu包向后移植，然后转换架构。有些东西需要重新调整，因为如果您运行的是旧的LTS软件，有些软件并不是为Arm而构建的；您必须将其后置。”

　　Fong Jones曾研究过将MySQL转换为Arm以提高性能，“因为各种元数据的数据库扩展是一个瓶颈。”但同样，AWS支持MySQL 8、MariaDB 10和最新版本的PostgreSQL；“我们使用的是MySQL 5.6，我们的语义不允许直接升级到MySQL 8。我们可以使用MariaDB 10，但AWS不允许您在零停机的情况下这样做，因为它被认为是一个不同的数据库引擎。”

　　一如既往，问题的关键在于细节，“这些随机的、奇怪的系统级依赖关系，您必须真正、真正地确定下来。”让代码运行起来——这很容易！“

　　Quinn认为，这些不匹配是并非所有人都喜欢跃上Graviton的一个原因，如果还没有为Nitro移植必要的驱动程序，那么英特尔的最新例子也是如此。”在许多环境中，它需要一个OS更新；反过来，这意味着您需要重新验证和迁移现有的工作负载，而公司在这方面总是很慢。同样的问题阻碍了其他技术的应用，比如自动缩放。“他们还没有更新他们的应用架构，以便在节点加入时无需重新配置一切就能动态伸缩。”

　　Brown指出：“对于一个数据库来说，如果旧版本不支持Arm，而且将来也不会支持Arm，那么向新版本迁移就会有点困难。”

　　“这就是我们认为客户需要权衡投资的地方。在这个行业中，40%的性价比提升并不常见。

　　他建议：”尽可能便宜、快速地尝试对工作负载进行基准测试。“。”然后，您可以投资进行迁移，例如迁移到不同的数据库版本或重写特定于处理器的内核模块，因为40%的性价比证明了这一点。“

　　客户准备好使用Arm了吗？

　　对于新的实例类型，有时存在可用性问题；因为没有足够的M6GD实例，Fong Jones不得不暂停查询引擎迁移12个小时，为了获得spot实例，她不得不接受M6实例（内存更多，时钟速度稍高），以及C6实例，这些都是工作负载所需的。

　　Quinn同意，对可用性的担忧可能是AWS客户对转向Graviton持谨慎态度的一个原因，但他们应该是短暂的。”我能在任何一个AWS地区获得规模化运行的能力吗？这方面的现货供应情况如何，他们能尽快拿到吗？答案显然是肯定的，现在他们有了足够的容量，可以开始将其作为托管服务提供。“

　　Quinn指出，Graviton可能不是企业降低AWS费用的早期选择，也不是最重要的方式。”这是好管家，这绝对有好处但也不是最有效的他们可以做的事情。“

　　”我们的客户群对Graviton和Nitro的了解程度较低，“ Bala证实。当他们打电话时，通常是考虑如何相对于传统处理器来考虑它。”他的回答是，“客户在考虑ARM与x86时，应该考虑到端到端工作负载的兼容性以及性价比。”

　　超越AWS的Arm

　　AWS不会是Arm云服务器的唯一选择，但迄今为止，它是最重要的。

　　Oracle云基础设施将在2021年初以虚拟机或裸机的形式提供Arm系统（使用Ampere公司的硅，带两个插座和160个核心），用于基础设施任务，如代码转换以及运行容器和Kubernetes。

　　自2017年以来，微软一直在为Azure构建带有Arm处理器的Windows服务器系统。在Azure中使用的Project Olympus OCP机箱可以容纳不同的Intel或Arm主板，微软已经测试了运行在Arm硅上的Windows服务器，包括Ampere Altra、Fujitsu和Marvell ThunderX2。

　　当时，大多数云工作负载都是基础设施即服务，由于客户希望虚拟化的应用程序很少可用于Arm架构，因此微软没有计划公开提供Arm上的Windows服务器。

　　相反，现在在Azure中运行的ThunderX2 Arm服务器被用来降低运行内部Azure基础设施（如存储、索引和搜索）的成本。在今年的armdevsummit大会上，技术研究员Arun Kishan（他在Windows内核团队工作）指出：“今天，我们在ARM64上使用Windows服务器来探索微软内部存储和虚拟机托管服务。”

　　Bala建议，对于开发人员来说，在Arm硅上同时使用Windows和macOS可能是将来更广泛地采用Arm服务器的转折点。“开发人员将希望在本地计算机上迭代开发和构建，然后再推送到最终推送到prod的CI/CD平台。”