随着系统级芯片的成熟 ARM服务器将到来

在LinuxCon 2014上，让我们可以预见到ARM处理器架构——世界各地小型设备制造商们深爱的ARM处理器架构——将会出现在服务器世界里。但是在ARM服务器能够量产之前，专门针对数据中心的、标准的硬件平台是必需的。

所以企业Linux 巨头Red Hat 的首席ARM架构师Jon Masters在星期四芝加哥召开的LinuxCon 2014大会上谈论了这个话题。

Red Hat和其他组织——最有名的是Linaro集团，Red Hat也是其中的成员之一——多年来一直在努力让Linux为ARM服务器做好准备，反过来也是一样。但是Masters认为，要说服硬件厂商，让他们相信对ARM在移动设备上有用的东西对于数据中心并不适用。

Masters表示，“很多早期的服务器——不仅仅是ARM，还有其他的架构——利用了我称之为嵌入式的思维方式。”他表示，“所以我仍然亲切地将它们称之为‘嵌入式动物园’，它真正地被用于手机和服务器的设计理念之中。”

这并不是说Masters认为手机厂商制造自己设备的方法有什么不对。他承认，苹果和大量安卓手机制造商将嵌入式设计理念运用得非常好。

但是这些努力之所以能够成功，很大程度上是因为智能手机厂商建设了自己的工具包，所以软件是“焊接”到硬件上，作为一个完全集成的系统。无论他们使用的是现成的ARM系统级芯片组件，还是创建自己的芯片——就像苹果和三星的做法一样——他们生产的每一台设备上的软件通常都会针对自己特定的硬件做无数的适应性调整。

为数据中心重塑系统级芯片(SoCs)

Masters表示，高集成度、省电的系统级芯片(SoCs)概念对于数据中心来说也可以是一个巨大的福音。但是由于每个芯片制造商都按照完全不同的规格设计自己的系统级芯片，这是他们在嵌入式市场中的做事方式，但是这种方式对于服务器来说可不是什么好事。

他解释说，“通用计算平台和嵌入式系统不同。”他表示，“软件并不是和硬件一起交付的。它们并没有集成在一起。人们从自己选择的厂商那里购买硬件，然后他们再另选厂商购买操作系统，他们需要这种方式。”

在这里，我们讨论的也并不仅仅是在Linux和其他一些操作系统之中进行选择。当今的IT管理员们购买服务器的时候，如果他们喜欢，他们就会希望清掉系统自带的Linux版本，然后换上另外一个。然而针对嵌入式市场设计的ARM SoCs无法提供这种保障。

Masters表示，“例如，这里没有标准会告诉你，‘系统究竟会如何启动，你如何才能找到内核’。”他表示，“‘Not’在这块板子上是去那里，在那块板子上又通向另一个方向，但是有一种方式可以做到这一点。不过在这些嵌入式科技中并没有这样的方法。”

Masters也不相信针对嵌入式市场开发的软件解决方案——例如Device Tree和U-Boot通用引导程序——能够适用于服务器。它们根本就无法在硬件之上提供足够的抽象，让管理员能够以可交换的方式对待ARM服务器，这正是管理员们对待现有x86设备的方式。

Masters表示，“我们需要的是标准化的硬件设备。为了引导我们正在使用的系统，我们必须有一定程度的标准化，如果连接服务器上的一个串口存在着二十种不同的可能，这就是个问题。”

ARM进阶

幸运的是，没有人比ARM自己对这些问题理解得更深刻了——也没有一家公司能够通过ARM兼容处理器进入企业数据中心市场获得更多的既得利益。

英国半导体设计企业Cambridge第一次大举进攻服务器市场是在2011年推出了64位的ARMv8-A架构。虽然一些硬件制造商很早就看到了数据中心的机会，并且尝试推出32位的ARM服务器——特别是现在已经解散了的Calxeda——但是那些设计从来都没有取得多少效果，而Masters在LinuxCon大会上说的很清楚，Red Hat至少“没有在32位ARM领域做什么尝试，而且到现在为止也不认为有什么必要这样做。”

最近，为了满足系统集成商在使用ARMv8-A方面的需求，ARM开发了两个新的平台标准，这一工作得到了Linaro的配合，Linaro是一家主流的Linux厂商，也是硬件合作伙伴。

第一个标准是SBSA(Server Base System Architecture)，它描述了ARM系统启动所需要的最小硬件设备。SBSA规范最初是于一月份在Open Compute Project峰会上发布的，其后迅速得到了全行业的支持。

第二个也是更新的一个标准——是于本周二首次发布的，就在LinuxCon大会之前——是SBBR(Server Base Boot Requirements)，这个标准描述了一个ARM服务器系统应该如何启动。

SBBR要求硬件符合两个早期标准的最新版本：UEFI(Unified Extensible Firmware Interface)2.4及其相关规范以及ACPI(Advanced Configuration and Power Interface)5.1

Masters表示，“运行在UEFI平台上的软件有望得到一些功能。”他解释说，“例如，安装操作系统内核的标准方式，获得特定运行时服务的标准方式，就好像是一天里的时间。我不必在我的平台上有一个特定的、针对这个实时时钟的驱动，因为我有一个UEFI RTC驱动，这就可以了。”

同样，强制要求支持ACPI将芯片制造厂商能够设计的系统级芯片的种类限制在了适合通用计算的范围内。

Masters表示，“同样，ACPI不允许极端复杂的嵌入式平台。对于任何一台嵌入式设备我都不建议这么做。它明确地告诉你，你不能采用某种设计理念。它编写的目标是服务器。”

ACPI在交换中提供什么?这位来自Red Hat的男人说，是平台的抽象形式。操作系统内核不需要被告知如何初始化特定硬件平台上的每一个功能，也不需要知道用来访问它们的存储地址。例如，内核可以依赖适当的ACPI功能打开串口。

那么，什么时候呢?

即使有了这些标准，服务器制造商仍然需要用一种让操作系统厂商能够使用的方式来实现它们。为了帮助它的硬件合作伙伴提供可行的设计，Red Hat在七月份推出了它的ARM Partner Early Access Program，在这个计划中的厂商可以了解到这家公司认为针对ARM的企业Linux解决方案应该是什么样子的，而且是在它还在完善自己代码的过程中就开始了解了。

Masters表示，“我们和很多这样的厂商合作，共同审查驱动，并且提前进行讨论，确保他们能够正确进行。”

那么，这位Red Hat的首席ARM架构师认为今天的硬件厂商中，谁做了正确的事呢?也许并不令人吃惊，在LinuxCon大会上，他特别提到了AMD的“Seattle”系统级芯片，这款芯片是AMD在这个月早些时候举办的Hot Chips大会上正式发布的，Masters表示这就是“用完全正确的方式做正确的事。”

Masters表示，“它是一个标准化的、服务器级的系统级芯片。它遵循了AMD通过x86了解到的所有的服务器设计理念，它还采纳了这个行业在过去三年里提出的各种各样的建议和指点。这是一个非常、非常好的设计。”

但是只有现在，全行业的ARM服务器工作才开始走向成熟，AMD公司已经能够生产出这种品质的产品。例如德克萨斯州奥斯汀的Calxeda公司开发了最早的ARM数据中心产品，但是这家公司在十二月停业了——没有享受到AMD目前拥有的“后发优势”。

Masters表示，“Calxeda的那帮家伙真的是非常棒的人，做出了出色的工作。我认为他们的问题是过早地进入了一个新市场。”他说，“你可以早点来参加聚会，你也可以按时到，你也可以迟到。如果你到的时候看到没有人在，那么就有问题了。我认为他们的时机把握的不对。”

按照最新的估计，合适的时间将从今年晚些时候开始，ARM服务器将在2015年年末成为主流。