HPE公司“The Machine”项目深度剖析

简介:

HPE公司已经最终敲定了近期服务器架构领域最具野心的架构设计方案,这就是The Machine项目。

HPE公司“The Machine”项目深度剖析Machine节点板模型

在今天的文章中,我们将尝试解读HPE公司为The Machine系统作出的“完全不同”这一评价:包括其目标、所用技术以及发展现状。这是否真的是一款完全不同于以往的服务器?下面一起来看。

The Machine被称为一台内存驱动型计算机,其拥有一套非易失性内存建立的通用资源池,可供大量专用计算核心加以访问。其中,数据无需在不同服务器的处理器间往来移动,而是始终驻留在内存当中——各不同处理器则持续访问整体数据集中的对应子集。

其目标不仅是解决大规模数据在服务器间移动所带来的低速互连弊端,同时亦是为了在无需配合高成本DRAM的前提下利用内存内计算实现更高处理速度。该项目的主要优势在于将计算性能与能源功率改进至新的量级,且这种计算能力能够扩展至高速分析、高性能计算乃至其它现有工作负载当中。

这种颠覆性设计几乎涵盖到服务器中的每一个层面,从单一芯片设计、各系统芯片、光子芯片与消息收发协议、服务器主板、CPU-内存访问与架构、机架、网络结构、操作系统代码乃至应用堆栈及其IO都将经过重新设计。

这绝对是一场前所未有的发展壮举,甚至超出了HPE自身的控制能力——即使其将The Machine切实投放市场,保守的用户及开发商恐怕也不会加以采用。

The Machine无疑是HPE手中一笔风险极高的注码,下面我们将具体解读其系统与当前开发状态。

核心概念

The Machine项目的实质基本上就是利用大量处理器通过一条光子互连通道对一套通用型内存资源池进行访问。

HPE公司“The Machine”项目深度剖析 

The Machine项目的基本概念。

我们可以概括出The Machine项目的五大技术属性:

  1. 异步专用核心处理器或节点。
  2. 基于光子的CPU到通用内存池互连通道。
  3. 通用型非易失性内存资源池。
  4. 新型操作系统。
  5. 软件编程模式。

计算核心

项目中使用的计算核心面向各类专用工作负载,这意味着其并不一定需要属于x86核心。换言之,设备中可以使用ATOM、ARM或者其它架构类型组合,亦可以是单插槽配合多核心。

The Machine中的处理器包含一块系统芯片(简称SOC)配合部署内存与光子互连。该系统芯片属于计算单元,可链接至8条DRAM通道(可能为DIMM,我们将在后文的模型系统中具体探讨)。该互连机制首先接入一套结构交换机,而后再接入共享内存资源池。

HPE公司“The Machine”项目深度剖析 

备注:单一节点上的一块系统芯片通过该结构(桥接或者交换)接入其它节点中的持久性内存,且无需涉及旁邻节点的系统芯片。

光子机制将芯片与激光发射器相结合,旨在利用光信号通过网络结构以实现高于线缆内电流的信息传输速度。

The Machine项目的系统芯片运行有一套定制化Linux,且互连机制通过光子结构接入大规模通用内存资源池。

此内存应该会使用HPE公司自家的忆阻器技术,其有望在具备成本效益的单一设备当中提供持久存储、内存与高速缓存功能。

HPE公司表示这套大规模内存资源池的容量可高达数百PB,且相关内存同样具备高速与持久两大特性。

访问内存

我们估计,The Machine项目中的处理器将以不同于现有服务器x86处理器那样直接通过芯片内置中间缓存接入DRAM的方式实现内存访问。x86处理器使用的这套方案由于DRAM自身的易失性而需要将数据存储在其它大规模介质当中——例如磁盘或者SSD,这将显著降低整个访问流程的执行速度。换言之,The Machine项目使用的应是一套内存级结构模式。

The Machine项目将彻底颠覆现有访问模式。其内存应该以忆阻器技术为基础,即彻底替代现有服务器中的芯片内置缓存与DRAM,不过忆阻器方案由于DRAM以及2015年4月出现的相变式内存技术而不得不延后发布时间。惠普公司CTO兼The Machine项目之父Marin Fink表示,这套系统将分三个阶段进行交付。

此项目将为内存驱动型系统并采用Linux:

  1. 阶段一(0.9版本):基于DRAM的系统,初始系统将通过机架级规模提供320 TB DRAM资源池,用于模拟持久性内存。
  2. 阶段二,The Machine将利用相变式内存,即非易失性存储级内存。
  3. 阶段三将为基于忆阻器的系统方案。

阶段一可以视为可工作原型设计,阶段二则为过渡性系统,阶段三则为完整的忆阻器系统。

SanDisk公司的ReRAM曾于2015年10月被纳入HPE公司的内存驱动型计算方案。我们认为其ReRAM亦有可能在阶段二方案内取代相变式内存选项。

阶段二中的各服务器节点(包括CPU、DRAM以及光学互连机制)将共享一套速度低于DRAM的中央非易失性内存资源池,其服务器节点(系统芯片)规模上限可达数千台。HPE公司的现有Apollo机架可用于支持这一设计方案。

阶段三随后将采用忆阻器共享式中央资源池。如果各服务器节点仍然保留本地DRAM,那么意味着HPE公司在开发纯忆阻器资源池方面未能成功。不过即使如此,我们仍然可以选择二级内存结构或者NUMA模式。

产品化时间表

The Machine项目的开发进度已经一拖再拖。举例来说,惠普实验室主任Martin Fink曾在HP Discover 2015大会上向与会者们宣布,“The Machine项目的可工作原型将在明年的大会上与大家见面。”结果已经很明显,Fink在2015年Discover大会后发布了一篇博文,题为《加快The Machine开发进度》——换言之,The Machine的进度已经延后。

他当时写道:

我们正在构建硬件以处理目前尚不存在的数据结构与应用程序。同样的,我们还需要编写出目前尚不存在的代码以运行在这套硬件之上。为实现这项目标,我们在目前可用的最佳系统之上进行硬件模拟,例如HPE Superdome X。我们通过该模拟方案总结出的硬件特性将可用于指导软件方案的持续改进。我们将从软件开发工作中总结的经验共享至硬件团队。这是一种良性循环。

我们还看到一套各组件贴有对应标签的节点基板,其基本展示了此硬件的工作原理:

HPE公司“The Machine”项目深度剖析 

通过上图,可以看到其中包含处理器系统芯片、本地DRAM、由介质控制器访问的非易失性内存以及通过由光纤交换机控制的光学适配器实现的板外通信机制。

那么The Machine项目中共享式内存资源池是否由各节点中持久性内存提供?看起来确实如此。

因此可以基本判断,在这种情况下,对本地板载持久性内存的访问速度要快于通过光纤交换机及光子链接接入的板外持久性内存。这套设计方案与NUMA的情况基本一致。

另外可以看到,各系统芯片包含有一块处理器及其计算核心以及缓存内存; 因此,如果实际情况确实如此,那么CPU可以使用一套由缓存、DRAM、本地NVM以及远程NVM共同构成的四层式内存结构。

另外,如果情况属实,那么The Machine项目应该没必要使用忆阻器全面替代全部内存存储层。不过需要强调的是,这项假设是由HPE公司技术专家Keith Packard所提出。因此最终结论如何目前尚无法确定。

设备硬件

关于The Machine项目的更多硬件信息,Keith Packard已经于2015年8月的一篇文章中进行了说明。其在5U空间的64位ARM处理器节点内提供32 TB内存。全部此类节点皆可实现内存层级互连,意味着每块单一处理器皆可对任意系统上的内存进行访问,从而实现指令加载或者存储。这些节点包含“一块64位ARM系统芯片,配备256 GB纯本地RAM外加一套现场可编程门阵列(简称FPGA),用以实现NGMI(即下一代内存互连)协议。”

存储

NGMI及其它概念亦在Packard于2016年2月发布的以下视频中进行了讨论:

“存储部分将包含四套内存(各自容量为1 TB),且各自拥有独立的NGMI FPGA,”我们了解到。“特定系统芯片可在无需其它节点内系统芯片参与的前提下访问其内存——NGMI桥接FPGA将通过光子接口与其它节点上的FPGA进行通信。在相关bug彻底解决后,这些FPGA最终将被替换为应用指定型集成电路(简称ASIC)。”

每个节点的持久内存都将被聚合至单一中央光纤连接内存(简称FAM)资源池内,其不具备缓存一致性。

“可以将8台这种节点塞进一台5U机柜当中,其处理器总数为8块,且拥有32 TB内存。十台这样的机柜可被纳入一台机架(共包含80块处理器与320 TB内存),且多台机架亦可通过同样的‘结构’进行互连,最终使系统内的各处理器从高达32 ZB的资源空间内进行寻址。”而这也正是我们正在热切期待的首套The Machine实例方案。

Packard在谈到320 TB机架时表示:“我能够支持那些目前甚至完全无法通过单一地址空间实现的任务。”

各计算单元(系统芯片)在理论上能够实现异步运行。其持久内存将成为介于各异步处理器——即大端与小端——之间的通信结构。各处理器能够同时对同一数据进行操作。我们随后可将成百上千套机架加以结合,从而利用其直接接管现有数据中心。

HPE公司“The Machine”项目深度剖析 

The Machine – Packard在视频中给出的节点设计示意图。

由于各处理器只能实现256 TB空间寻址——除了IBM提供的处理器方案之外——因此320 TB内存访问存储带来的难题需要通过光纤连接内存映射方案加以解决。HPE公司构建起一套75位地址空间,因此其能够最大支持32 ZB容量上限。

而到这里,我们甚至还没有谈到任何软件相关话题。Packard的视频长达45分钟,感兴趣的朋友可以耐心观看以了解相关信息。

评论意见

HPE公司计划于本月28号召开的HPE Discover伦敦大会上公布The Machine当前状态及开发进度的更多细节信息。

另外,感兴趣的朋友也可以点击此处查看HPE Labs系列博文(英文原文),并借此了解The Machine项目的背景信息。

The Machine项目真实存在,而且HPE公司将推出原型方案以供开发者们查看、接触以及试用——具体途径包括设于HPE内部的设备以及面向客户的alpha测试站点。

通过Packard的视频,大家应该能够进一步了解HPE The Machine项目的现状及其驱动因素。开发可以通过利用The Machine开发项目更好地同HPE建立沟通关系。而对于HPE方面来讲,其也肯定会对此表示欢迎,毕竟开发者支持是一个项目获得成功的关键所在。

不过要为这套新系统开发应用,开发者们必须彻底抛弃原有标准化服务器架构系统。The Machine相较于现有方案能够提供量级水平的性能提升,而HPE公司也愿意为此投入大量研发资金。

当然,也希望其不要重蹈Superdome mark 3的覆辙。事实上,英特尔的3D XPoint目前就面临着类似的窘境。

根据我们的估计,首款The Machine原型方案将于未来三到九个月内公布。总之,提前祝HPE好运!



原文发布时间为:2016年11月29日

本文作者:黄雅琦

本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

相关文章
|
2月前
|
运维 安全 API
OpenAI Agents API 正式发布:Codex 底层能力开放后,开发者的角色如何转变
OpenAI于2026年9月10日推出Agents API公测版,开放Codex托管运行底座,提供会话管理、自动上下文压缩、多智能体编排及可替换沙箱等能力。开发者专注业务逻辑,平台接管模型调用、工具编排与状态维护,按token与容器时长计费,无平台附加费。
|
缓存 移动开发 JavaScript
PCIe 参考时钟架构 (Refclk Architecture)
PCIe 参考时钟架构 (Refclk Architecture)
8545 0
PCIe 参考时钟架构 (Refclk Architecture)
|
6月前
|
JSON NoSQL API
开源项目观察|ds4:本地 Agent 推理,不只是把模型跑起来
Redis作者antirez新开源项目ds4(DwarfStar 4),是专为DeepSeek V4 Flash设计的轻量级本地推理引擎。聚焦Agent场景,支持OpenAI/Anthropic API、Disk KV Cache复用、工具调用精准映射与长上下文优化,在MacBook等高端个人设备上实现高效端到端推理。
1695 3
开源项目观察|ds4:本地 Agent 推理,不只是把模型跑起来
|
测试技术 Apache Linux
怎么做服务器压力测试?
项目做好了,能不能顺利上线? 一般来说我们需要做一下压力测试来判断。比如该项目上线后预计每天一百万的接口访问量,并且访问时段主要集中在早八点到晚八点,那么平均下来 RPS 大约是 22 次左右·····
14680 0
|
存储 域名解析 网络协议
Linux网络管理
这篇文章开始学习Linux的网络管理,通过这篇文章带大家了解,怎么在Linux中查看自己的网卡,怎么通过配置文件配置自己的网络、IP,以及怎么查看自己的IP,了解获取IP的方式,最后完成一个服务器的初始化。
1219 1
|
存储 关系型数据库 MySQL
深度评测:PolarDB-X 开源分布式数据库的优势与实践
本文对阿里云开源分布式数据库 PolarDB-X 进行了详细评测。PolarDB-X 以其高性能、强可用性和出色的扩展能力在云原生数据库市场中脱颖而出。文章首先介绍了 PolarDB-X 的核心产品优势,包括金融级高可靠性、海量数据处理能力和高效的混合负载处理能力。随后,分析了其分布式架构设计,包括计算节点、存储节点、元数据服务和日志节点的功能分工。评测还涵盖了在 Windows 平台通过 WSL 环境部署 PolarDB-X 的过程,强调了环境准备和工具安装的关键步骤。使用体验方面,PolarDB-X 在处理分布式事务和实时分析时表现稳定,但在网络问题和性能瓶颈上仍需优化。最后,提出了改进建
|
前端开发 API Python
WebSocket技术详解:如何在Python Web应用中实现无缝实时通信
在Web开发的广阔领域中,实时通信已成为许多应用的核心需求。传统的HTTP请求-响应模型在实时性方面存在明显不足,而WebSocket作为一种在单个长连接上进行全双工通信的协议,为Web应用的实时通信提供了强有力的支持。本文将深入探讨WebSocket技术,并通过一个Python Web应用的案例分析,展示如何在Python中利用WebSocket实现无缝实时通信。
752 3
|
虚拟化 Docker 容器
Minikube - Kubernetes本地实验环境
为了方便大家本地开发和体验Kubernetes,社区提供了可以在本机部署的Minikube。本文介绍利用阿里云的镜像地址在Windows/Mac/Linux上来部署和配置Minikube
245910 94
Minikube - Kubernetes本地实验环境
|
数据采集 分布式计算 并行计算
Dask与Pandas:无缝迁移至分布式数据框架
【8月更文第29天】Pandas 是 Python 社区中最受欢迎的数据分析库之一,它提供了高效且易于使用的数据结构,如 DataFrame 和 Series,以及大量的数据分析功能。然而,随着数据集规模的增大,单机上的 Pandas 开始显现出性能瓶颈。这时,Dask 就成为了一个很好的解决方案,它能够利用多核 CPU 和多台机器进行分布式计算,从而有效地处理大规模数据集。
1051 1
|
前端开发 UED 开发者
uni-app:去除导航栏&跨域的问题&blobe查看图片&v-deep&页面操作 (五)
本文介绍了几个前端开发技巧:1) 如何通过设置 `navigationStyle` 为 `custom` 去除顶部导航;2) 解决跨域问题的方法,包括使用 `dotenv` 加载全局变量和配置 `devServer` 的代理;3) 使用 Blob 和 FileReader 查看图片;4) 利用 `v-deep` 深度作用选择器修改样式;5) 修改页面左上角返回按钮的行为。
735 0