OCP开源工具介绍及进展

2019年6月25日，由浪潮与OCP开放计算社区联合主办的首届OCP China Day（开放计算中国日）在北京正式开启。本届 OCP China Day聚焦人工智能、边缘计算、OpenRack、OpenRMC、SONiC、OAM等前沿技术话题，来自Facebook、LinkedIn、Intel、微软、百度、腾讯、阿里、诺基亚、中国移动、浪潮等资深技术专家分享了最新技术进展。近千名工程师和数据中心从业者参加了此次大会。

OCP是全球最大的开放硬件社区，2011年由Facebook发起成立，其宗旨是以开源开放的方式，重构当前的数据中心硬件，发展面向下一代数据中心的服务器、存储、网络、基础设施等创新硬件。目前，OCP核心会员超过200家。

当数据中心达到一定规模后，封闭技术所带来的设备孤立就会成为数据中心统一管理的直接阻碍，而对于数千台服务器才能配置一个管理员的超大规模数据中心来讲，统一管理是必须配置，而非可选配置。所以，硬件的标准化开放之外，Firmware的开放、BMC模块的开放会逐步成为用户的硬需求。还有“历史悠久”的IPMI发布时并不存在现在意义的大规模数据中心，简单的功能和可怜的扩展性已经远远不能满足现在的数据中心需求，几年前RedFish规范应运而生。要满足下一代数据中心的基础架构改造需求和管理需求，办法只有一个，就是把上述的技术和规范融合起来，形成一个技术生态。在本次OCP China Day上，来自OCP、Intel、浪潮的专家分享了OCP开源工具的介绍及进展。

以下为大会演讲实录：

Rajeev Sharma, OCP Director of Software and Technologies：部件创新是所有大型互联网公司的一致选择，OCP发起了 Open Firmware项目，近可简化部件开发难度，远可为统一IT基础架构打好基础

Rajeev Sharma, OCP Director of Software and Technologies：大家好，我的名字叫Rajeev Sharma，我是OCP的软件项目的总监，今天我想跟大家讲一讲我们在OCP里面的项目。Bill Carter已经给大家看过这个了，我今天要谈的是这一页里面跟软件相关的东西，我也会跟大家谈一谈OSF这个项目，现在它已经是在孵化的阶段。然后我会谈谈Open RMC就是远程控制器，包括和其他软件相关的项目，有ONL、ONE、SAI、SONIC，Zpluy项目是微软这边的项目。

左边你可以看到一个机架，这个机架由不同的组件组成，比如它有计算、存储和网络的部分，我可以给大家解释一下控制的板和计算的板，因为我们的机架上面必须有控制这个机架的相关装置。当然我们也要看一下关于数据板，这个数据板能够做处理甚至我们可以说发生奇迹的部分，比如它是关于存储的，还有服务器的节点。对服务器节点而言，它有这样多不同的部件，它有网络部件和其他的部件，对于这些部件而言，我们还有一个电力的传输，所以对于服务器节点而言是十分重要的。传统上对于一个开放的系统的部件而言，比如对于这个传统的部件而言它受到很多事情的限制。

大家已经参加了这么多硬件的会议，你可以看到这么多的硬件，你在不同的会议上都看到了那么多不断在改变的硬件，所以关于硬件，无外乎要赶上不断变化的市场节奏，Catch up就是要跟上。现在的局限性实在太大了，所以微软选择UES的路径，同样，谷歌和Facebook也选择了Linux的路径，他们觉得这是更好的选择。这是我们看到的一些主要的公司参加到了OFS的项目中，还有更多的公司，有这么多的公司参与到了OSF的项目中，我们看到人们彼此合作谈关于基础架构和协作的方式，最终我们争取能够有一个模式推出来。我的一个朋友谈到五个不同的解决方案，下面我谈谈关于RMC，我们的机架的管理的控制器。

我们一开始先谈的是部件，我们认为咱们能非常好的管理自己的服务器，OCP在功率和机架方面倾注了非常大的精力，我们希望能把机架和功率作为一个整体进行管理。我们的一个应用愿景，硬件在中间，我们把它叫做一个机架的管理器，其他的部分就是功率的使用、存储的硬件，另外一边我们可以看到软件，这些软件可以跟RMC进行呼叫，并且用传统的ABI进行呼叫，我相信大家非常熟悉ABI。右边发生的也是和传统的ABI一样，我们将会使用一个比较低级别的协议或RPMI，我们能够给用户一个机会，他自己觉得哪个API合适就使用哪个，一旦我们有了RMC的解决方案之后，你能够把它放到不同的机架环境当中去，我们现在这个机架的环境，你们能够看到Open 19的解决方案可以支持各种不同的解决方案，前面有一个Open Rack，你可以在上面进行相关的部署。我们看到一些公司希望在电源架上进行装置，以便使得它变成RMC用户友好，大家谈到了非常多关于Open Rack，你可以在交换器上进行实现。右边是新的微软的Olympus系统，你可以把它和Olympus的解决方式结合起来。

微软建造自己RMC的解决方案的方式是如果你看一下，底下有几个不同的模块，更多的是BMC把自己的机架的解决方案建立了起来。如果我们看一下浪潮，我们意识到的也是同样的事情，他们的架构就如同刚才看到的幻灯片，如果看到浪潮和微软的解决方案非常相像，所以我们看到架构上面这么多公司如此相像，我们为什么不一起合作以便拿出一个统一的RMC的解决方案，这就是我们的路径，也是我们在OCP底下看看是不是能对不同的机架解决方案拿出一个统一的解决方案，待会儿浪潮我的朋友会谈谈浪潮拿出RMC的解决方案究竟是什么，我们现在有四个不同的关于网络方面的项目，第一个是Only，它是第一个Open Network部署的环境，也就是公开网络部署环境。

我们再来看第三个开放网络Linux。如果你看一下所有硬件和驱动器的话，你可以在上面进行部署的话，之前的微软的很好的解释了SONiC这部分。下面我们谈一下关于Zipline的项目。IDC能看到有大量的数据增加，到2025年有175个ZB的数据产生出来，当然要看一下边缘的部署以及集中性的使用，我们要看一下使用的场景以及工作负载，对于一个公司他究竟把这些数据放在哪里最合适，也要看一下Zipline能够将这些数据进行压缩，我们能够把既有的系统以及新的数据集进行很好的压缩，所以你可以将这些所有的数据进行有效的压缩，它不光有软件，另外它还有算法以及硬件，所以算法软件硬件全都有。

如果我们谈到压缩的话，我们用了不同的压缩比率，所谓压缩比率在这个幻灯片上就很清楚。如果看一下我们的这些日志数据，你就能看到这个数据从100%通过Zipline降低到了8%，它的效率是非常高的。对于这些基本的规范而言，微软进行了很多贡献并且也进行了硬件的基础设施的规范，我们需要一个高宽带、低延时，非常重要的是RTL注册转换语言的源代码的贡献。如果我们看一下使用场景，这些年都可以进行相关的应用，比如从分析一直到RSD，当然我们这些伙伴不断积极的在这个项目中有所贡献。

这就是我给大家的演讲，感谢大家的时间，下面我请我的同事演讲。

Intel Software Architect Edmund Song：Intel是全球最大的芯片开发商之一，Open Firmware首先就是要Intel来开放firmware，Intel的实践对于整个项目至关重要，Intel正积极参与这个社区项目，并提供了众多的开源工具包

Intel Software Architect Edmund Song：谢谢Rajeev Sharma，大家下午好，我是Edmund Song，来自英特尔软件架构师。刚才我为大家介绍的开放系统部件简称OSM项目，我接下来分享英特尔关于开放式系统部件的具体参考实现以及我们面向云时代这些新的需求，我们在系统部件层面的一些技术创新。

大家看右边这张图是今天云环境中一个非常典型的软硬件的层次架构图，分为上层的各种各样的业务负载，中间的基础架构和资源的管理单元，最下面的硬件资源，包含计算、存储、网络以及各种各样的加速设备。在这层我们的系统部件与我们的硬件紧密配合，形成了支撑云体系架构的基础资源能力，这也是我们今天开放式系统部件项目所关注的主要内容。

在服务器领域，UEFI已经构建了非常成熟的系统部件的生态环境，左边是基于UEFI实现的面向Open System Firmware的具体实现，左边是跟平台硬件相关的功能模块，进一步分为开源的SSP开发包等，右边成为EDK2的开源包。第三层是最上面的黄色框，这块实现了与操作系统的接口，保证跟现有操作系统的无缝对接。所有的功能和模块都可以通过gatehup的链接获取到。基于UEFI的成熟的生态系统，我们可以快速构建一个标准化开放式的系统部件的新的开发模式，用来支撑今天谈到的开放式系统部件所提到的这些新的需求。

MinPlatform是一个开源包，提供了平台最小化的启动功能，通过它我们可以对硬件以及启动流程进行定制，大大提高了我们系统部件的裁剪能力，也可以帮助我们的客户实现系统部件的定制。左边是Min的具体事例，通过与上层的EDK2、下层的SKP开发包，结合可以根据业务需求定义系统部件的功能和启动流程。平台相关的功能模块中除了开源的Min还有一块代码会涉及到芯片的具体初始化，本身这块代码比较复杂，也涉及到一些硬件的具体设计，这块我们通过二进制的FSP开发包的方式发布，为了与平台进行结合，我们将FSP开发包的接口与流程都做了标准化，最新的技术规范是FSP2.0，这个上面有一个具体的链接大家可以访问获取。

FSP2.0将整个芯片的初始化流程标准化为三个阶段，第一个阶段是我们处理器的早期初始化，在我们内存初始化之前利用处理器的片上的缓存系统构建一个最小化的工作环境，第二部分是我们的内存和多处理器的初始化，第三阶段是我们的芯片组的初始化。通过这样一个规范化定义，除了与我们UEFI的原生的启动框架进行支持外，我们也可以很方便的与第三方的启动框架进行集成。

云的大规模应用改变了人们的计算习惯，也对我们的计算架构带来了深远的影响，我们的系统部件层面有什么新的需求呢？第一块是从我们平台的功耗性能指标，这些都是跟我们这种大规模的计算里面的平台TCO息息相关，需要我们系统部件提供更细粒度更加灵活的硬件的配置机制来支持我们今天面向业务或业务驱动的平台性能优化，需要更加实时的平台探针机制支持业务的自动化运维。

第二是从系统的可靠性和安全性角度来看，如何避免系统软硬件升级导致的系统下线时间或最小化系统下线时间。在复杂的云环境中如何避免我们的系统部件被恶意篡改，第三是从系统的运维角度。面对成千上万台服务器，面对本地的云需求与远程的边缘计算的需求，如何快速的应用我们的系统硬件配置，如何对我们的系统部件进行远程更新。如果一个系统出了故障或者问题，如何快速的进行远程定位，包括远程调试，所有的这些需求都影响着我们未来对系统部件的设计。

下面我将简单介绍几个英特尔在开放式系统部件项目中主要参与推动的技术创新。

第一个是PRM也叫平台运行机机制，我们的系统部件提供了很多的运行机服务用来在操作系统之外执行一些最底层的操作，比如电源管理、硬件的配置、硬件系统的出错的处理，支持运行模式的处理器模式叫SMM，SMM是我们处理器的特殊管理模式，它的执行会导致所有的处理器和执行线程都处于挂机状态，随着处理核数不断增加，SMM频繁进出会导致系统性能下降。我们的方案是引入一个PRM平台运行机机制，大家看左边这张图，它的引入将我们过去的运行在SMM的模式状态下的系统运行器的服务从SMM模式移回到我们的内核空间，这样避免我们对其他业务进程的阻塞，降低对系统性能的影响。为了保证跟操作系统的无缝对接，它的接口我们采用跟SMM的运行器服务同样的ACPI的接口。这边最底下是个链接，我们提供最具体的实现案例和ACPI的驱动程序。

启动时间的优化，我们服务器的启动过程非常复杂，通常启动时间都是在分钟或数分钟级别，昨天我们在外面搭建demo的时候服务器启动时间达到7到8分钟，因为上面的内存我们插了很多。这个材料的上半部分是系统部件的启动流程，包括很多步骤，这个图里有11个步骤非常复杂，绿色框是对系统部件进行启动时间优化的关键步骤，主要涉及到我们平台的初始化阶段，比如可以记录我们的内存和处理器的拓扑结构，避免我们在系统重启的时候不必要的初始化操作，或者我们可以利用多核的能力加速启动过程中的内存自解，通过这些都可以加速系统在重启时的启动时间。

下面两张表格是将这些启动层次的优化应用到我们的Minplatform跑在OCP的一个平台的具体的评估结果，两个socket的系统，包括129G的内存。右边这张表格是一个软启动或热启动的结果，系统部件启动之后4到5秒钟可以切入到我们的操作系统，左边是我们冷启动的过程，时间相对长一点，但是也在11秒钟左右可以看到操作系统的启动画面。通过Minplatform的启动能力，可以降低系统重启对系统下线时间的影响。系统部件的在线激活，服务器在它的生命周期中经常会进行一些软硬件升级，其中有些升级会导致我们的系统部件需要做更新并且导致系统的重启，左上角是我们一个系统部件更新重启的流程。首先我们需要将业务进程进行关闭或将业务进程进行迁移，关闭操作系统，重启应用系统部件的更新并重启系统，重新启动操作系统，重新恢复我们的业务进程。在整个流程中我们的系统部件的重启或更新占的时间并不长，但是考虑到中间有操作系统的重启和业务进程的恢复，整个过程会大大影响我们系统的下线时间。所以有没有可能在我们的系统部件的更新流程上做一些优化，尽量降低或避免由于我们的系统部件的更新对重启的需求。

英特尔在跟OCP的合作伙伴共同开发系统部件的在线激活的模式，在这个新的模式中，在应用我们的系统部件的更新之前，首先将我们的业务进程、操作系统植入一个挂起状态，然后对我们的系统部件进行更新并重新激活，最后恢复刚才挂起的业务进程和操作系统，在这个过程中由于避免了操作系统的重启，避免了业务进程的重启，可以大大减少我们的系统下线时间。当然这是一个比较长期的愿景，因为它的实现和支持涉及到硬件、固件、操作系统和驱动程序的支持，非常复杂，所以我们也欢迎上下游的厂商共同加入到我们这样一个系统固件的在线更新的模式中来。

基于远程的系统固件的远程配置，左上角这个图是我们今天云操作系统跟服务器平台的管理接口图，包含带外和带内两个通道，带外一般是RPMI，带内很可惜今天没有业界的规范，在云操作系统处理这些不同的通道上来的不同协议的数据的时候经常会发生困惑，甚至有些硬件配置不同的通道上来的数据无法完全对齐，所以我们需要一个带内和带外统一的硬件管理借口，我们的方案是采用Redfish，是基于现代化的硬件管理接口，最初Redfish定义为RPI的升级，我们对Redfish的资源管理模型对它的数据接口进行扩充形成带内和带外统一的硬件管理接口，用来支持我们的系统部件在这个规模化的云部署中所需要的远程配置接口，比如我们远程启动的能力，比如我们平台的性能和功耗的配置，比如远程的系统固件的更新机制，所有这些我们都可以把它统一到统一的Redfish接口中来。另外是我们带外的BMC和带内的Bys之间需要进行硬件的同步，今天我们的DMTF的Redfish也定义了接口，通过这个接口可以实现基于Redfish的BMC和Bys关于硬件信息更新的同步。

最后呼吁大家共同加入到OCP这个开放式系统固件的项目中来，跟我们一起来完善开发模式，大家一起通过业界的合作，通过技术标准的合作加速我们云时代的技术创新，比如OCP、UEFI、Redfish，谢谢。

浪潮高级技术总监郭洪昌：浪潮牵头成立了OpenRMC项目组，开发完成了全球第一个基于Redfish规范的OpenBMC套件，让OpenBMC成为创新技术生态的一部分

浪潮高级技术总监郭洪昌：谢谢，我是最后一个演讲，我接下来用十五分钟时间介绍一下浪潮在管理这部分，尤其利用开源的软件Stack实现功能，针对OCP开源组织里贡献的情况。这是浪潮的简介，世界上头三大Server vender，我们还有AI全栈式解决方案供应，我们同时还是Open data server的供应商，不再强调了。

我们在解决方案的Stack上包括硬件也包括软件，我们在ODCC针对于中国的BAT提供了解决方案，Openpower我们也在参与，还有OCP，除了硬件我们也在开源的软件，像Openbmc，这就是开源的软件Stack，浪潮做了一些修改和移植，把BMC这些相关的code放到了我们OCP的Server上使用，也基于Redfish，这都是开源的标准。它的好处包括目前经常强调的怎么样能实现带外的管理、管理的易用性，它是开源的，如果用户采用了其他厂商的开源OCP标准的产品，那么它的移植更加的顺畅，所以这个带来用户运维成本的降低，这是我们提供的好处。它的最后一层是最终用户，像我们目前针对中国的比较大的BAT和美国的客户都有采用我们标准化的产品，实现他们业务的需求。

作为基础BMC，我们现在把Open BMC的软件code已经移植到了现在的OCP的Server node上去，从而可以是带外的管理，待会儿可以看到带外管理能实现哪些功能。它是基于Redfish，我们有一个基线，这样能够满足服务器的使用基本需求，同时它也经过了Redfish的互联互通的验证测试，这就是我们讲到的对于开源组织认证和测试的工作。

2019年初英特尔和浪潮一起做了一个基于Open RMC的就是北桥的API标准，在不断更新，OCP网站上大家都可以下载到Spec标准，可以看到相关的细则，这里面有些情况在不断刷新。

这是浪潮的Open BMC的key feature，它可以实现带外的在线升级，通过Web UI的界面，可以通过软件包把FAMware在不占用服务器网络带宽的情况下可以实现FAMware的刷新和维护工作，带给用户的好处还是比较大的，尤其是在用户的管理网络和使用网络之间，希望有些隔离，提供安全性的考量。

右下角最后一个是故障诊断功能，我们把标准服务器上的故障诊断的软件和code基于Open BMC做了移植和开放，这样能够让整个社区其他的软件固件都能识别，从而能实现互通的工作。

刚才强调的是Open BMC，我们看看Open RMC浪潮的架构或拓扑。我们实现的方式，最上面是一个TOPSwitch，它里面有网络端口，我们每个服务器节点带外的管理网络都有一根线和TOPSwitch相连，每一个部件和管理的对象都已经在管理的网络里面，这样就可以实现整机柜的管理和监控的工作，这就是我们整个拓扑的情况。Power Supply如果为中心点的话，可以分为上半部分和下半部分，这样可以有一个半区的管理，实现管理更有序的分布。

这页和ODCC有关，我们都知道ODCC强调的是集中供电、集中散热和集中管理，右上角这个白框里面的示意图和OCP在使用的管理方案，我们每个节点有一个管理板或管理控制的芯片，它可以实现对于风扇总线的控制，它可以通过对散热风扇的调节实现散热的管理，它们会和PSU相连，PSU就是上一页强调的RMC里面的一个管理控制芯片，它可以跟整机柜全局的各个节点实现互联和可见，这样你就可以发一些管理的信号，从而对计算节点做控制，当然你也可以知道整个机柜power的情况、供电的情况，从而可以实现整个整机柜各个管理对象的控制。

这是RMC芯片的逻辑示意图，最中心的芯片是我们用AST2500的芯片，它可以实现跟GPIO相连，GPIO连我们控制的芯片，它可以实现跟PSU相连，PSU的控制信号也能连接到RMC上，通过总线可以实现DEBUG的功能，RMC的芯片是一个枢纽可以实现对于管理信号和管理总线的控制和连接。

这是对RMC、MMC连接的控制的详细示意图，RMC和MMC跟BMC之间有两个不同的网络，是两个独立的网络，这个图画得不是很明确。Network是一个带外的网络，它可以实现基于RG45和TOPSwitch的互联，第二是总线，和BMC直接相连，这里面没有特别明确的画出来。RMC还可以跟PSU、风扇有连接的网络，这样可以实现整个计算节点内部所有部件所有控制信号之间的连接。

这是网络连接的拓扑图，每个计算节点通过BMC的带外管理的网络可以跟TOPSwitch有一个连接，TOPSwitch和RMC之间也有一个网络的连接，再通过一个网管的工作站可以实现完整闭环的带外管理，这就是我们强调Open RMC实现的网络连接的拓扑。Open RMC的Open能达到什么作用呢，就是我们现在看到的，降低成本，实现电源功耗的可管理和可控制，同时也可以降低整个整机柜的故障率，因为它可以实现实时的监控，还可以实现远程的开关机的工作，这都是通过Open RMC实现的。

这是OCP带给所有用户的总体价值。从金字塔的最尖有JDM的模式，跟我们的用户反复论证，能够及时把我们从其他用户那积累的经验跟他分享，我们能够把设计周期大大缩短，这是JDM。接下来我们这些设计如果可行的话能开放到OCP这样的开源组织，开源之后就可以尽可能让这些设计分享给业界的其他友商和客户，能够让生态系统更加壮大。我们积累了一个资源或设计的IP池，能够让这些设计的比较好的理念更好的复用，最后实现用户的成功案例或POC的参考和正循环。

这就是我今天的演讲，感谢各位嘉宾能够坚持到最后参与今天整个一天的OCP的活动，接下来把话筒交给我们的两位主持人做Close speech。

主持人：谢谢Wilson，进入尾声了，我们把组织会议的骨干请上来合影，感谢所有在场和线上的观众，感谢你们对OCP的支持，感谢你们对开源的热情，我们今天就告一段落，我们希望下一次的OCP CHINA DAY再见！