谁能想得到,最终愿意在超大规模云平台上坚守x86架构的,居然很可能是谷歌。
亚马逊云科技过去几年来一直努力推动其Graviton产品线,包括去年3月开始生产的Graviton 2,以及去年11月公布、目前仍处于预览非量产状态的Graviton 3芯片。总之,AWS各大区域与数据中心正在全面迎接ARM新势力的到来。
如今,微软也开始在Azure云上发布新实例(同样为预览版),显然也想在ARM服务器芯片领域一展身手。这些实例基于Ampere Computing制造的80核心“Quicksilver”Altra Arm服务器芯片,这款芯片最初公布于2020年6月,能够以3 GHz最高主频容纳80个计算核心。虽然由Ampere Computing Altra处理器支持的全新Azure D系列与E系列实例引发了不少关注,但让人奇怪的是微软为什么不提前一年甚至更早就着手发布,也不清楚微软为什么不使用原定于2020年第四季度提供样品、去年秋季正式供货的128核“Mystique”Altra Max开发新实例。但无论如何,Mystique处理器能够与微软目前部署的Quicksilver芯片实现插槽兼容,所以微软也完全可以根据需求将Altra Max芯片快速接入供应链、服务器及其数据中心。
有心的朋友可能还记得“Siryn”芯片,也就是采用Ampere Computing“A1”原研核心的芯片方案。我们对它已经基本失去期待,毕竟它不太可能使用Altra品牌,而且“A1”这个名称也不符合市场受众对技术及最终产品的期待——枯燥乏味的名称往往令人们失去关注和讨论的兴趣。而且纵观Ampere Computing的整个计算路线图,我们会发现超大规模企业和云服务商想要的是完整的技术体系、而非特定某款芯片产品。甲骨文、腾讯、阿里巴巴乃至微软等都想为自己的公有云选择最合适的芯片,而Ampere Computing方面目前值得期待的将是搭载A2核心的下一代芯片。这款新品预计将在2023年推出。
但推出跟批量出货完全是两个概念,只要超大规模企业和云服务商没法立刻把这款芯片放进云端上万台服务器,那Ampere Computing的一切路线图就仍然只是空谈。量产、认证与机房建设都需要时间,所以数据中心里这些架构层面的阶段性变化还需要五到十年才能转化为实际影响。话虽如此,目前的ARM服务器芯片确实是形势一片大好,只要不出特别大的意外、ARM公司当初定下的20%到25%的市场占有率目标应该没啥问题。
微软的态度也是相当明确,全力支持ARM服务器芯片在Azure云上遍地开花。在2017年开放计算峰会的演讲中,微软就提到希望让ARM服务器在全部服务器算力容量中占比达到50%。但当时的微软还没有承诺在Azure云基础设施中直接提供ARM算力(只在平台云和软件云部分向用户提供微软软件访问权限),也没提到在ARM上发布Windows Server堆栈(但微软一直在内部使用Windows on ARM运行Azure上托管的原生应用程序)。另外,微软在这场峰会上还公布了“Project Olympus”,以预览形式展示了这些服务器上的Cavium ThunderX芯片与高通Centriq芯片。但随后几年情况大变,高通取消了Centriq产品线,Cavium则被Marvell收购、ThunderX3同样很快被抛弃。这就迫使微软不得不自主设计、或者借Ampere Computing之手开发ARM服务器芯片。目前,不少行业分析师认为微软会采取双管齐下的研发思路。
那么,Azure当中到底部署了多少ThunderX2芯片?我们估计不会太多,否则Marvell怎么会停掉这块可观的业务版块。Azure中又有多少Ampere Computing Altra设备?应该要比ThunderX2多得多。总之,微软正在云基础设施上提供ARM算力,主要用于运行虚拟机内的Linux操作系统。但据我们所知,Windows Server目前还没有登陆ARM平台,而且一旦登陆将给服务器计算架构带来深远影响。有了这些背景,再参考微软在声明中强调的“不会坐视AWS在定义数据中心内的未来ARM服务器方面一家独大”,接下来的局面就已经相当清晰了。
目前微软的Quicksilver ARM实例尚处于技术预览阶段,所以我们对细节了解不多。不过一旦Quicksilver与AWS Graviton 3实例卸下这层神秘的面纱,接下来我们肯定要对这两种ARM服务器实例进行价格/性能分析,同时横向对比两家x86实例的销售情况。下面,我们还用目前已知的参数信息整理出一份表格,用以比较各实例的配置、速度与价格。可以看到,微软已经公布了接下来六种ARM服务器实例类型的基本参数:
首先,每芯片提供8个DDR4内存控制器,意味着Altra CPU能够支持远超当前配置水平的内存容量。ALtra CPU还支持NUMA集群,可用于创建更大的内存地址空间与计算引擎。目前还不清楚这些Azure实例属于单插槽还是双插槽设计。
关于我们另外一个好奇的点,微软同样没有给出答案,这就是既然Altra芯片最多可以支持80核,但为什么新的实例只分别提供32核与64核?也许是因为这些实例用的都是单插槽服务器,而且对应的系统没有DPU来分担网络与存储虚拟化负载,所以只能划出一部分核心运行管理程序堆栈。当然,微软服务器也有可能配备有DPU,只是32核与64核是Ampere Computing芯片的最佳性价比区间。无论如何,实际情况应该就是这两种之一。(当然,也有可能是因为ARM上Hyper-V虚拟机管理程序的运行效率确实低下,那就是二者兼而有之。)
为了帮助大家了解不同Azure ARM服务器实例间的SKU区别,我们整理出下面这张表,同时列出各按需实例的每小时使用成本。(微软也公布了竞价实例价格,但在跨云服务商比较中没什么参考意义,故而省略)。在表中,我们以三年为期计算了超大规模企业与云服务商的实例运行成本,再使用最终得出的结果进行跨云及云内价格/性能比较。(但考虑到目前云端服务器的平均寿命,取四年为期可能更准确。)
Azure上的实例价格跟虚拟CPU(vCPU)数量成线性关系,至少在目前的产品线上看是这样。但底层芯片的成本不可能如此线性,各个实例在特定工作负载上的绝对性能也不会线性扩展。因此,不同实例中的价格/性能表现并非恒定。
根据微软的说明,其中Azure Dpsv5系列实例主要用于运行Web服务器、应用程序服务器、Java与.NET应用程序、开源数据库以及游戏与媒体服务器。Dpsv5实例每核心支持4 GB内存,不提供本地磁盘;而Dpdsv5实例每核心同样支持4 GB内存,同时提供随核心数量扩展的本地存储容量。Dplsv5实例每核心支持2 GB内存,Dpldsv5也一样,只是后者提供本地存储容量。所有这四种实例类型都能从2核扩展至最大64核。而Epsv5实例虽然每核心配备8 GB内存,但最大只能扩展至32核心,而且要到Epdsv5实例才提供本地存储。(建议大家尽快熟悉这些名称,之后我们会反复提及。)
不提供本地存储的实例自然价格更低,而且微软在Azure上提供的各类外部闪存选项也都适用于这些ARM实例。各实例提供2到8个网络接口。微软表示,这些接口可带来“高达40 Gb/秒”的网络连接,相信这里的指标肯定是以虚拟NIC衡量的结果。虚拟NIC数量可能跟各虚拟NIC的传输带宽成反比,我们猜测每台物理服务器的传输通道最大为100 Gb/秒。但如果设有两个以太网端口,那最大传输带宽就是200 Gb/秒。具体如何,还要等预览阶段结束后才能确定。
这里还有个值得关注的重点,我们已经跟Ampere Computing多次讨论过这个问题、也从AWS的Gravtion系列芯片那边听到过类似的说法:一组具有静态时钟速率的真实核心,其性能确定性会优于一组具备可变时钟速率的虚拟核心。
Ampere Computing Altra芯片不提供同时多线程(SMT),所以vCPU就是真实存在的CPU核心。而且Altra芯片各核心的时钟速率是锁定的,也就没有根据特定时间内核心用量调节的可变时钟速率。另一方面,云端服务器的常规用例就是以无数种方式进行拆分,在同时支持大量客户时让每个核心都保持一定的运行强度,这意味着某个或某组核心不太可能长时间保持超频。所以Ampere Computing明显是听取了超大规模企业及云服务商的意见,决定让CPU性能更具确定性。所以Altra芯片会保持时钟速率恒定,而不再为核心采用可能导致争用的虚拟线程技术。
但以上结论也只应用于特定场景。对于高性能计算(HPC)工作负载,运营人员一般会关闭SMT,否则虚拟线程带来的管理开销反而会降低整体性能。对于占用大量线程的工作负载(例如事务处理监控器与关系数据库),由于各核心缓存之间并不存在太多争用问题,所以没必要画蛇添足引入虚拟线程。根据多年以来的实践经验,对于HPC类工作负载,同样属于SMT的英特尔超线程(HT)技术很可能令性能下降10%到20%。但采用IBM“Cumulus”Power 10处理器的Power E1080服务器又有所不同。根据IBM的rPerf基准测试(属于TPC-C在线事务处理测试的I/O未绑定变体),这套全尺寸240核系统的相对性能得分为2250.8,其中每个核心对应一个线程。而随着虚拟线程的开启——即每核2个线程、4个线程乃至最终8个线程——其性能也随之扩展2倍、2.8倍和3.6倍(其中SMT4每核4线程的性能提升明显不如SMT8每核8线程)。
关键在于,SMT会带来极为复杂的影响,而且大多数使用x86架构的云实例都会默认启用,用以提高vCPU密度。SMT确实能为实例提供更多切片与SKU单元,这就让实例层面呈现出的服务器资源比x86 CPU实体更丰富。但我觉得云服务商最好能开诚布公,允许客户灵活选择SMT或者裸机选项。
现在,我们继续聊性能。在关于ARM架构Azure实例的官宣博文中,Azure计算平台产品负责人Paul Nash表示,“新的虚拟机系列实例包含通用型Dpsv5以及内存优化型Epsv5,其价格/性能比较同级别x86虚拟机高出达50%。”
但这个结论还是太过模糊,毕竟其中比较的是“价格/性能比”、而非单一具体产品。因此,我们在上表中调整了微软Azure实例的比较信息。
无论如何,微软在声明中并没有提供太多关于性能或者价格/性能比的具体信息。
Ampere Computing公司首席产品官Jeff Wittich则就声明做出解释,“Ampere Altra VM的性能分别比同代、同级别英特尔与AMD实例高了39%与47%。*除了性能更高,Ampere Altra处理器还非常节能,可帮助用户显著减少总体碳足迹。”
原文中的星标脚注为:“结论来自运行在Ubuntu 20.04 LTS系统上、且兼容gcc 10.2.1, -O3, -mcpu=native, JEMalloc的D16ps v5, D16s v5, D16as v5 Azure虚拟机(基于SPEC CPU 2017 整数运算)。”
明确了一些,但还不够好。SPECrate是CPU领域常用的吞吐量整数测试。对于基准结果,所有SPEC模块都应使用相同的编译器标志进行编译,同时需要在结果中包含一项峰值。测试人员需要运行SPEC测试的多个副本,查看芯片能够承载多大的事务吞吐量。通过SPECspeed2017测试,套件中各基准测试的副本都将在一系列不同条件下运行,由测试人员根据OpenMP选择要使用多少线程,最终得出的结果则以时间为度量、代表整个基准测试在多长时间内能够运行完成。
我们就此事联系了Wittich,反映目前微软的表述太过模棱两可。他则向我们提供了Ampere Computing所发布的、在Azure博文中用到的实际数据:
下表所示,为各实例的原始SPECrate2017整数性能。这些实例分别使用AMD、英特尔以及Ampere Computing提供的最新CPU,同时参考了各实例的每小时运行成本。为了体现各组数字的相对大小,Wittich用性能除以成本,结果就是三者在同等成本下所能提供的SPEC整数运算吞吐量。
这里要澄清一下,上表中的“Altra D16pdv5”为笔误,实际应该是Altra D16psv5实例。微软,你看看自己起的这些实例名称……
这里我们更关注每单位性能对应的成本,毕竟性能需求往往是硬性的,先要明确需要多少性能、再算得花多少钱。为此,我们计算出三种Ampere Computing实例以三年为期(无折扣)的整数运算测试结果:
既然打算在云实例中长期运行负载,那最好能对成本有所把握。这里得到的百分比跟Wittich的计算结果相同。如果我们把AMD和英特尔芯片上的SMT功能关闭,又会有什么不同?这个还是要分情况,如果大家对vCPU数量有硬性要求,那关闭之后您可能只能购买两倍大小的AMD和英特尔实例。这样双方的核心更强大、性能更强,但同时也失去了跟Ampere Computing比较的意义。
我们觉得更合理的方式,应该是回归具有8个真核心的AMD和英特尔芯片,再把性能提升个10%到20%,再重新计算性能价格比。如此一来,AMD“Milan”Epyc 7003实例的SPECrate整数性能将介于50.8到55.4之间,英特尔“Ice Lake”至强SP实例的SPECrate整数性能则介于53.7到58.6之间。Altra实例仍然保持价格优势——比Milan低10.5%,比Ice Lake低19.8%;同时还是拥有更高的性能水平——比Milan高23%到34.2%,比Ice Lake高16.5%到27%。因此,Altra芯片的性价比依旧突出,其每单位性能的对应成本要比竞争对手低三分之一左右。
而谷歌之前曾经说过,只要有20%左右的性价比优势空间,他们就愿意改变CPU架构。
最后一点:微软目前在ARM实例上支持Canonical Ubuntu Linux、Cent OS以及Windows 11专业版与企业版,未来还将支持Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Debian、AlmaLinux以及Flatcar,但并没有提到Windows Server。
我们期待看到AWS Graviton与Azure Altra实例的性能数据对比,这才是接下来的重头戏。亚马逊与微软两大巨头终于要正面开战了,孰优孰劣让我们拭目以待。
好文章,需要你的鼓励
临近年底,苹果公布了2024年App Store热门应用和游戏榜单,Temu再次成为美国下载量最多的免费应用。
云基础设施市场现在已经非常庞大,很难再有大的变化。但是,因为人们可以轻松地关闭服务器、存储和网络——就像开启它们那样,预测全球云基础设施开支可能非常困难。