标签： 中立科普

关注星融元

上一篇中星融元Asterfusion提出了全面创新的高性能网络方案，并已经从四个方面做了详细的分析，那么，今天大家继续跟着小编来细品这个方案~

自动感知虚拟计算世界的变化

虚拟计算节点的动态变化（创建、删除、迁移、停机、启动等）是云计算的最本质特征之一，也对云网络提出了一个最基础的需求：

云网络需要自动感知虚拟计算世界的变化，随之调整自身的逻辑拓扑、连接关系、策略设置等，成为一张随需而动的虚拟网络。

以802.1Qbg为代表的边缘虚拟化网络技术试图为云计算提供一个计算资源和网络资源交互感知的架构，相应地，对虚拟网络边缘的控制与调度也成为支撑这种交互感知的关键点。

星融元Asterfusion云网络以802.1Qbg为基础构建虚拟网络边缘交换的整体框架。

图10：自动感知虚拟计算世界的变化

在星融元Asterfusion云网络中：

• 网络与计算一样，都以资源池的形式被Cloud OS自动化地统一管理和调度，任何对于网络的操作，都以软件调用REST API的形式完成，不需要管理员再手工地进行任何配置；
• 以802.1Qbg为基础完成虚拟计算世界到虚拟网络之间的映射，属于同一虚拟网络的虚拟计算节点，无论其真实物理位置在云中的何处，都被以全局规划、统一分配的方式与其所属的虚拟网络完成关联映射；
• 通过与Asteria Fabric Controller（AFC）和Cloud OS的联动，对于虚拟计算世界发生的任何动态变化，星融Asterfusion云网络都可以同样动态地自动发生变化。图10中，当属于蓝色虚拟网络的某虚拟计算节点VM-A从物理服务器Server1迁移到Server2，“变成”VM-A‘时，星融元Asterfusion云网络通过与Cloud OS之间的控制通道能够即时获取相关信息（物理服务器、所连接的物理交换机和端口、虚拟网络映射信息等），从而自动完成虚拟网络的调整与部署。
• 也可以通过AFC完成，进一步提升整体效率，降低Cloud OS的压力和复杂度。

基于硬件加速的VXLAN虚拟网络

架构在传统网络之上的云面临着如下限制：

• VLAN（Virtual LAN）支持虚拟网络数量太少（少于4K）
• 虚拟网络二层广播域范围受限（无法跨越三层域）
• 影响虚拟计算节点的可迁移性（跨三层域迁移需要变更IP地址）

VXLAN（Virtual eXtensible LAN）的出现帮助云网络成功克服了上述问题，因此成为云中虚拟网络的不二之选。

但是因为传统网络自身的封闭性，使其无法被Cloud OS通过REST API自动化地统一管理和调度。

因此云计算的建设者们不得不抛弃了在传统网络上部署VXLAN的思路，转而在服务器内部通过使用CPU的计算力构建“软件模拟虚拟网络”，来规避传统网络无法被软件定义这一障碍。

所以，更贴切地说，今天的云中广泛部署的SDN，Software Defining Network，其实应该是Software Simulated Network，即软件模拟虚拟网络。

图11：基于硬件加速的VXLAN虚拟网络

如图11，左半部分所示，软件模拟网络的缺点也如其优点一样，是显而易见的：

• 服务器CPU的大量计算力被用于模拟网络，而不是用在虚拟计算上带来更高的回报；
• 同时，花费不菲成本建设的底层网络使用效率极低，相对于能力来说，基本处于限制状态。

可以说，在今天基于软件模拟网络的云中，云计算的建设者面临着“里外里双重浪费”的局面。

在星融元Asterfusion云网络中，这样的局面不会存在。如图11，右半部分所示：

• VXLAN被从服务器的计算空间中卸载到底层网络的硬件交换机上，所有VXLAN相关的操作（隧道建立、维护，报文封装、去封装，虚拟网络多实例与隔离）全部由高性能的硬件完成；
• 曾经大量耗费在软件模拟虚拟网络上的服务器CPU计算力最大程度释放出来被用于完成更多的虚拟计算任务，从而提升整体的ROI；
• 在Cloud OS看来，对星融Asterfusion云网络的操作运维体验，与操作运维计算空间中的软件模拟网络并无二致，同样是点击两下鼠标、或者调用几个REST API，即可完成对星融元Asterfusion云网络的管理；
• 基于PICFA™的支持，星融元Asterfusion云网络一举将云中虚拟计算节点的容量提升到千万量级，同时赋予云网络更高的性能和更优的质量。

因此，星融Asterfusion云网络让云计算中的网络真正回归到网络自身，“计算的归计算，网络的归网络”。

基于BGP EVPN的虚拟网络控制平面

VXLAN很好地解决了前述的问题，但是，因为在最初并没有考虑为其设计独立的信令与控制平面，因此在VXLAN中所有隧道信息、路由信息都是通过人工静态配置和通过数据平面广播学习的方式来完成的。

也正是如此，在VXLAN环境中，部署、配置、变更等全部依赖于人力，效率低下、出错风险高，而且基于广播的学习导致VXLAN中泛洪流量频发，继而致使整网效率低下。

为了解决这个问题，基于原有的MPLS/BGP VPN理念与模型，IETF设计并开发BGP Ethernet VPN（简称BGP EVPN）标准，作为包括VXLAN在内的三种虚拟网络的独立控制平面，BGP EVPN成功地为VXLAN构筑了独立于数据平面的控制平面。

基于BGP的多协议承载能力自动在VXLAN站点之间传播多租户的隧道信息、路由信息、链路状态信息，彻底摒弃了人工静态配置和广播学习的缺点，使VXLAN网络的运维复杂度大幅降低、效率大幅提升。

BGP EVPN让在大规模生产环境中部署VXLAN成为可能。

图12：基于BGP EVPN的虚拟网络控制平面

星融元Asterfusion云网络也将BGP EVPN作为虚拟网络独立的控制平面，并且将其与创新的PICFA™融合在一起，形成超大容量、快速收敛、自动管理的虚拟网络解决方案。

在星融Asterfusion云网络中：

• 不但所有虚拟网络的二层转发表以分布式的方式承载在所有网络交换机上，三层主机路由表也被分布到所有网络交换机上，从而使得云中虚拟网络的容量增长100倍至千万量级；
• 交换机的多实例能力将不同租户的不同虚拟网络加载在不同的路由空间中，彼此安全隔离、互不影响；
• 具备多协议能力的BGP承载多租户的路由信息在VXLAN站点之间自动交互，不再依赖人工配置确保转发路径与逻辑的正确性，将手工配置出错的风险降至最低；
• 虚拟网络上出现广播流量的可能性被降至最低，有效地提升了虚拟网络为云中业务提供服务的性能与效率；
• 独立的控制平面，标准化的协议交互，让多家厂商的互通对于用户来说不再是不可能的任务。

融合到转发平面的高性能NFV

NFV（Network Function Virtualization，网络功能虚拟化）是指将一些常用的网络功能以虚拟化的形式部署在云中为运行在云中的业务提供服务，常见的这些网络功能包括四层SLB（Server Load Balancing，服务器负载均衡）、NAT（Network Address Translation，网络地址转换）、DDoS（Distributed Denial of Service，分布式拒绝服务）攻击流量识别与统计。

在当前架构的云中，这些网络功能的虚拟化实现与软件模拟虚拟网络的思路类似，即：如果某个租户的某一种业务需要，就在服务器的CPU上用软件模拟出所需的网络功能来。

以SLB为例，假设有1,000个租户，每个租户有10个业务需要使用SLB，那么就在服务器上创建出10,000个虚拟机，再在这些虚拟机上加载SLB软件为每个租户的每个业务服务；保守估计，这样地场景需要2-3机柜的服务器来专门运行这10,000个SLB的虚拟机。

图13：融合到转发平面的高性能NFV

但在可编程交换芯片的支持下，星融Asterfusion创造性地将这些常用的NFV功能在云交换机的转发平面中编程实现，从而提升了云网络的整体性能和使用效率，帮助用户解决了在计算空间中，部署大量虚拟计算节点使用软件模拟NFV，所带来的计算空间性能降级、运维复杂度升高、NFV效率低下等问题。

如上所述的需求，即便再增加一个数量级，仅仅一台星融Asterfusion云交换机就能够轻松地支撑。更为重要的是，这样的NFV功能是在不影响交换机正常转发性能的前提下提供的。

为云中业务提供端到端的QoS

QoS（Quality of Service，服务质量）能力是衡量网络为业务提供服务的质量的最直接标准，一般来说，QoS能力由网络设备的多等级业务标记、多优先级队列发送、拥塞发现与控制、拥塞避免、传送带宽控制等功能构成。

遗憾的是，在今天的云网络中，QoS几乎无从谈起…
运行在计算空间中的软件模拟虚拟网络将底层的物理网络当作一根物理线路，虚拟网络自身缺乏基本的QoS能力，被当作物理线路的底层网络的QoS算法又只能根据所传送流量的外层报文头特征做出QoS判断，而真正能够描述不同租户、同一租户不同业务的优先级特征信息全部被封装在VXLAN隧道中，底层网络设备根本无法识别，QoS算法也不具备处理隧道内层信息的能力。

有了可编程交换芯片的支持，星融Asterfusion云网络成功地解决了这一问题。

图14：面向租户业务的综合QoS策略

在星融元Asterfusion的云交换机中：

• 对网络流量进行QoS处理时，能够提取、查找、比对、标记的不仅包含外层报文头的各种特征信息，而且包含封装在VXLAN隧道内的租户信息、租户虚拟网络信息、业务信息；
• QoS算法的输入参数也包含上述两部分信息，从而确保算法所作出的决策是针对不同租户或者同一租户的不同业务，而非简单地针对物理线路。

更值得一提的是，在提供高性能、大容量等能力的同时，基于PICFA™架构的星融元Asterfusion云网络还具备真正意义上的端到端QoS能力。

基于创新性的数据平面转发协议，PICFA™架构的星融Asterfusion云网络能够按照用户需求，动态地从底层网络的所有Spine交换机中分配一部分出来，让这部分Spine交换机专门为某一种业务（或某一类应用、某一些虚拟网络、某一群租户）服务，从而确保达到预期的服务质量和商业目标。

图15：PICFA™为不同租户/关键业务提供端到端的QoS保障

如图15所示，在基于PICFA™架构的星融元Asterfusion云网络中，所有Spine交换机能够被动态地划分为三组，其中第三组可以被指定用来承载VIP租户和关键业务，这组Spine交换机将会被PICFA™从物理上与其他Spine交换机隔离开来，运行在HULL架构（High-bandwidth Ultra-Low LatencyArchitecture）所描述的资源使用率较低的状态下，真正做到了物理隔离，让低优先级租户的流量与尽力传送型业务流量对VIP租户和业务的影响降至0，完全达到SLA（Service Level Agreement）所规定的服务质量保证——极低的网络延迟和近似于0的丢包率。

全面支持DevOps

DevOps是一种新型的软件产品交付模型，它将与软件产品生命周期过程中的各个相关部门（例如研发、测试、运营等）以一种空前的方法连接了起来，并且对他们的沟通、协作等提出了更敏捷、更快速、更频繁的要求。

Asterfusion云网络全力助推云计算进入新时代

星融元Asterfusion云网络是为云计算时代设计的全新一代云网络架构，这个架构完美地解决了当前的云网络方案所面临的诸多挑战。

• 充分释放服务器CPU计算力，降低TCO
  基于纯粹的SDN理念和领先的虚拟化技术，星融Asterfusion云网络在底层网络的可编程、高性能硬件平台上构建了面向云中租户与业务的虚拟网络，将大量的服务器CPU计算力从“软件模拟虚拟网络”的压力中释放出来，从而使得服务器CPU计算力的使用效率得到近乎翻倍的提升。
• 大幅提升底层网络的使用效率，提升ROI
  传统的云网络架构将花费不菲成本构建的底层网络定义为“粗但是傻”的线路，底层网络大量的功能与性能处于闲置状态。星融元Asterfusion云网络将底层网络重新定义为“粗并且灵”的智能网络，让云中租户与业务服务的虚拟网络直接承载在上面，提供虚拟化、多租户的同时，支持NFV等增值功能，让云的ROI“里外里”地增长。
• 超高性能、超大容量的虚拟网络
  星融Asterfusion的专利算法PICFA™将网络对云的支撑能力提升100倍，将单数据中心可制成的虚拟计算节点数量一举提升到千万量级，为大规模公有云向更多的租户提供业务支撑打下坚实的基础。
• 面向租户与业务的端到端QoS
  星融元Asterfusion云网络是真正具备面向不同租户和不同业务的端到端QoS能力的云网络，作为QoS算法决策依据的参数不仅仅是底层网络的线路特征信息，而且包含了不同租户和不同业务的特征信息；同时，星融元Asterfusion的PICFA™专利算法天然具备将不同优先级的租户、业务、网络分布到不同底层硬件网络并且充分隔离的能力，从而让QoS真正成为端到端的能力。
• 全面开放的软硬架构彻底融入云
  在星融元Asterfusion云网络中，软件的网络操作系统与硬件的交换机平台被彼此解耦，网络彻底解除了对用户的锁定，开放的架构与软件定义的接口让网络真正成为云中的基础设施之一，所有对网络的操作全部通过软件定义的方式进行，并且将Cloud OS对虚拟网络及各种网络功能的管理复杂度降低两个数量级。

我们看到，星融元Asterfusion为云计算构建新一代超大容量、超高性能、超高效率的云网络已经做好了充足准备，摩拳擦掌，蓄势待发！

关注星融元

“ 在高性能的Asterfusion云网络中，全面开放的设计理念与整体架构确保它与云计算环境的无缝融合。”

云计算给传统网络带来的挑战

云计算从2000年中首次出现，至今如火如荼大行其道，它成为当今世界发展最快、影响面最大的IT基础设施支撑技术之一，而数据中心（也就是云计算的载体），这些年来也一直保持着强劲增长和快速演变的趋势。

图1：云计算数据中心的新兴发展趋势

这些新兴的发展趋势包括：

• 云中虚拟计算节点的飞速增长

虚拟计算节点指在物理服务器上通过使用虚拟化技术提供的具备独立计算能力的虚拟机（VM，Virtual Machine）、容器（Container）和虚拟桌面（VD，Virtual Desktop）。

在2000年，即云计算的早期阶段，每台物理服务器能够支持的虚拟计算节点的数量仅仅限于十几个；当云计算发展到了今天，随着物理服务器性能的不断提升与虚拟化技术的越来越轻量化，单台物理服务器能够支持1000个容器已经成为现实。

• 云中租户数量越来越多

随着云计算技术的逐渐普及，越来越多的传统IT用户深切体会到其弹性扩展、按需使用、快速部署等便捷之处；云平台在稳定性越来越高的同时性能也不断提升，针对大规模云的运维能力的也在持续增强，这些都使得公有云能够为越来越多的租户提供虚拟私有云服务。

在今天世界知名的公有云上，同时运行着100,000+租户的10,000,000+虚拟计算节点的案例并不少见。

• 云中部署的关键业务越来越多

在云计算的早期阶段，只有那些对性能和可靠性要求并不严苛的应用（如Email、文件传输、网站等）被迁移到云端；

得益于云计算自身的飞速发展，如今，越来越多的关键业务已经被迁移到云端（如高频交易系统、大数据分析系统、人工智能训练系统、区块链平台等）。

如何基于无差别构建的云平台为关键业务和普通业务提供差异化的服务将成为未来云运营的主要关注点之一。

• 云中基础设施的融合

CloudOS负责在云中统一、垂直管理所有的基础设施资源（计算、网络和存储），而自动化部署业务、资源动态调配等需求的提出与实现，都要求云中的基础设施资源不再以彼此分离的方式存在，而是在管理层面被整合为“融合基础设施”。这就要求部署在云中的设备要通过DevOps、RESTful API等方式主动将自身纳入到CloudOS的统一管理中。

遗憾的是，在云计算如火如荼发展的今天，作为云计算三大支撑基础设施之一的网络却未能跟上云计算整体的发展步伐，从而使传统网络需要面对来自云计算的各种挑战…

• 大规模、多租户虚拟网络的共存与隔离
  在同一张云上，往往同时承载了大量的租户，每个租户都需要有属于自己的多个网络来支撑部署云中的业务，因此，传统网络要有能力将自身虚拟化成多个属于不同租户、彼此之间又完全隔离的网络。这样的网络虚拟化对于租户的业务来说是完全透明的，业务并不需感知自身是运行在虚拟网络之上的。
• 虚拟计算节点的爆炸性增长
  传统的网络面对的是由数量较少的物理服务器和物理存储设备构成的计算世界和存储世界，因此也按照这样的模型架构自身的系统，但是在云中，这一模型被彻底颠覆，网络面临的外部世界从单台服务器、单个存储节点爆炸性地增长为成千上万的虚拟计算节点和软件定义存储节点，数量增长了2-3个量级。
• 虚拟计算节点的频繁动态迁移
  云计算为业务系统提供了对计算资源的按需申请、动态调配，这就意味着虚拟计算节点在云中的物理位置需要随时进行动态迁移，而这一迁移在逻辑上又必须保持静态不变（即无论如何迁移，该计算节点在逻辑上仍处于同一个虚拟网络），这就要求网络必须感知服务器内部虚拟计算节点的生命周期（创建、迁移、删除等）。
• 虚拟化云网络的自动化部署与运维
  同一张云承载了大量租户的海量业务，同时运行的这些业务频繁发生的变化也要求底层支撑网络随时应需而变、动态调整，所有的这些变化和调整都要通过云操作系统的统一控制和管理而实现。传统网络提供的以命令行、SNMP网管为核心的部署运维工具根本无法满足云中网络自动、快速调整的需求。
• 虚拟网络功能网关的分布式部署
  除了基础的交换机以外，网络中存在各种功能网关（NFGW，Network Functionality Gateway）设备，这些NFGW与交换机等一同构成网络为上层业务提供服务。在传统网络中，所有的NFGW一般以独立设备、集中部署的资源池形式存在。同样的模型部署到云中，将会导致大量无谓的东西向流量，致使整体效率大幅降低。

图2：传统网络游离于云计算整体架构之外

“那么，在这样的限制之下，今天的云计算是如何使用传统网络？又是如何面向租户构建虚拟网络的呢？”

运行在计算空间中的“软件模拟虚拟网络”

为了规避上述问题带来的限制，今天的云计算运营者采用了“在计算空间中用软件模拟虚拟网络”的思路：

图3：运行在计算空间中的软件模拟虚拟网络

在之前的文章，我们提到过，“软件模拟虚拟网络”虽然解决了传统网络无法解决的问题，满足了云计算运营者对网络的需求，但也有着显而易见的缺点，下面来展开说说这些缺点吧：

• 侵占服务器计算力
  软件模拟虚拟网络的所有虚拟网元完全运行在服务器的CPU上，大量的CPU计算力被用于运行虚拟网络，无法用于创建承载业务的虚拟计算节点，致使服务器CPU计算力使用效率低下。
  相反地，承载云的底层物理网络却处于非常轻载的运行状态，使用效率也非常低。随着摩尔定律逼近天花板效应，这样的效率低下将愈演愈烈。
• 虚拟网络性能受限
  网络已经进入100G时代，而服务器内部的网卡与CPU之间的通道（一般是PCIe）却仍然停留在G比特时代，成为无法逾越的瓶颈。
  相对于处理计算任务，x86架构的通用CPU处理网络流量有着天然的性能劣势，而热点业务在云中是一种常态，海量报文在瞬间涌向集中的热点，致使这样的性能劣势被进一步放大。
• 网络使用效率低下
  在IT时代已经发展进化了很长时间的、基于高性能交换硬件、面向网络流量转发处理而设计的网络，在云中只被用于最简单的承载通道，所有网络的高级特性和性能均无法使用。
  一方面是服务器中CPU计算力的捉襟见肘和使用效率低下，另一方面却是底层网络的基本闲置和低效使用。
• 端到端QoS能力缺失
  底层网络一般具备很强的业务质量保证（QoS，Quality of Service）能力，能够在高性能的硬件平台上为重要业务提供质量保障的传送通道。而软件模拟虚拟网络则不同，其软件模拟的属性往往使其不具备类似的能力；而且，因为软件模拟虚拟网络在底层网络上以隧道形式传送，致使上层业务无法利用底层网络的QoS能力。
• 维复杂度高
  云计算的管理员在运维软件模拟虚拟网络时，面向的是运行在云中每一台物理服务器上的各种虚拟网络节点，其数量往往比云中的底层网络节点高出两个数量级。面向如此之多的虚拟网络节点的运维复杂度和效率是无法忽视的问题，而这个问题现在仅仅是被DevOps和软件自动调度等工具暂时掩盖了起来而已。

综上所述，
传统的底层网络因其自身不开放等原因不被云计算所接受，而在物理服务器的世界中用软件模拟出来的虚拟网络又面临着以上诸多问题。

未来的云网络将何去何从？

全面创新的高性能网络方案

基于对云网络需求的深刻理解和对构建软硬件一体化系统核心技术的全面掌握，星融元Asterfusion为云计算数据中心设计了新一代的云网络解决方案。

在高性能的星融元Asterfusion云网络中，全面开放的设计理念与整体架构确保其与云计算环境的无缝融合，云中租户的虚拟网络和分布式网络功能网关被从计算空间中卸载出来，直接承载在可编程和高性能的Asterfusion硬件平台之上，独创的专利算法PICFA™通过整合一个交换网络中所有硬件系统的交换能力，来为云中多租户和多业务提供一个容量为千万量级虚拟计算节点的超大规模分布式虚拟交换系统，同时，星融元Asterfusion能够自动感知虚拟计算世界的变化，相应的自动调整虚拟网络以及各种适配策略，并且为不同的租户、不同的业务提供不同的QoS保障。

那么，星融元Asterfusion高性能都体现在哪些方面?能带给我们怎样的惊喜呢？

无缝融入到云中的Asterfusion全开放云网络

基于对客户需求、云、网络产业现状及未来发展趋势的深刻理解，和所掌握的软件、硬件核心技术，星融元Asterfusion为云计算环境提供全开放的云网络解决方案。解决了传统云网络在开放性方面所面临的各种挑战，无缝地将云网络彻底融入到云中，使网络与计算、存储一起成为真正意义上的“云基础设施”。

图4：Asterfusion帮助云网络真正融入云计算

高性能、可编程的Asterfusion硬件平台

基于业界最领先的可编程交换技术与芯片，星融Asterfusion打造了超高性能的可编程硬件平台作为其全线产品的载体；基于这个载体，为云计算交付“不妥协性能的灵活性”的云网络解决方案。

图5：高性能、可编程的Asterfusion硬件平台

与传统交换芯片将报文处理和转发逻辑固化在芯片硬件中不同，可编程交换芯片是能够通过软件来按需调整的。
在以可编程交换芯片为核心的交换系统中，业务与控制软件不再受限于底层芯片的能力，可以根据业务的需求进行开发与定制；通过为不同的需求、不同的场景定制不同的报文处理和转发逻辑，芯片的各条流水线能够协同工作，在不损失系统整体性能前提下，将这些需求在芯片的报文转发层面实现。

图6：传统交换芯片与可编程交换芯片

可编程交换芯片不仅是一次交换芯片硬件技术的发展，更是SDN理念在支撑网络的硬件芯片层面的一次伟大实践；
可编程交换芯片让网络在保持高性能的前提下，前所未有地拥抱了软件定义这一未来发展趋势。

在星融元Asterfusion云网络中，根据交换机在网络中所处位置与所承担角色的不同，运行在交换机转发芯片内部的软件被有针对性地进行了转发与处理逻辑上的优化，从而使得星融Asterfusion云网络以更好的性能和能力为各种上层业务提供支持。

图7：根据不同的场景动态优化资源分配与转发逻辑

如图7所示，同样的Asterfusion CX硬件平台能够被按照其在底层网络中的不同角色进行资源划分与转发逻辑的优化。这些不同的角色包括：

• Spine交换机（图7中的❶）：主要承载云中所有Leaf交换机之间的所有流量，这个角色的主要优化方向在于在尽可能多地将系统资源划分给FIB表的同时，要具备大容量的多租户区隔能力，即要支持创建和维护相当数量的BD（Bridge Domain）和VRF（Virtual Route Forwarding）。
• 服务器ToR交换机（图7中的❷）：主要承载云中虚拟计算节点之间的东西向流量，完成各种内部业务/应用的高速、大容量交换，这个角色的主要优化方向是尽可能多地将系统资源划分给FIB表，以承载尽可能多的二层MAC转发表项和三层主机转发表项。
• 网关ToR交换机（图7中的❸）：主要承载云中提供对外业务的虚拟计算节点与外部世界（互联网或企业内联网）之间的南北向流量，是云中业务对外提供服务的转发通道，这个角色的主要优化方向是尽可能多地将资源划分给三层路由表，同时要支持诸如负载均衡、地址转换一类的各种网络功能。

运行在高性能硬件平台上的云网络

在星融元Asterfusion云网络中，曾经运行在物理服务器内部、计算空间中的虚拟网络回归到底层的高性能网络硬件平台之上，帮助服务器将大量的CPU计算力从“软件模拟虚拟网络”的重负中释放出来，更高效地为计算服务。

图8：运行在高性能硬件平台上的Asterfusion云网络

在星融元Asterfusion云网络中，云计算面对的是同样开放、将自身彻底融入到“云计算基础设施”中的网络，而非传统网络那样游离于云之外、封闭的体系又与架构、独立不互通、手工配置管理的局面。

星融元Asterfusion云网络的开放性确保了云管理平台对网络基础设施（虚拟网络和底层网络）的统一、自动管理，为租户对虚拟网络的操作提供了与虚拟计算、虚拟存储同样的体验：点击两下鼠标即可，其余所有的事情，包括跨越不同设备、机架、数据中心、甚至是可用区域的对网络的配置，全部由云管理平台通过软件调用星融元Asterfusion云网络的REST API自动完成。

虚拟网络直接承载着云中不同租户的不同业务，而不同的业务对虚拟网络的需求又由该业务自身的特性决定。

那么，如何在一张无差别构建的底层网络上构建出具备不同能力的虚拟网络以适应不同的上层业务需求，就成为了云网络的不得不面对的难题。

星融元Asterfusion高性能硬件平台的可编程性完美地解决了这一难题。

在星融元Asterfusion云网络中，所有虚拟网络的处理逻辑完全可以根据业务需求来优化、定制甚至重构，网络功能的灵活性从此不再被蚀刻在ASIC中固化的处理逻辑所禁锢，让云网络世界再度焕发出前进与创新的光芒。

性能与灵活性从来都是一对同时出现的矛与盾。

随着ASIC交换芯片的能力越来越强，网络的性能自然而然地被大幅提升，二十年前的网络工程师根本无法想象今天的网络能够在1U的空间内交付3.2Tbps甚至6.4Tbps的交换能力；

遗憾的是，越来越高的性能背后隐藏的潜台词则是网络承载业务的灵活性在不断丧失。

可编程交换芯片的出现完美的解决了这一难题。可编程交换芯片同时兼具了传统ASIC的超高性能和基于软件编程的业务灵活性，使得“通过软件灵活定义业务逻辑+通过高速芯片转发业务流量”成为可能。

星融元Asterfusion基于对网络各种业务和云计算需求的深入理解，基于可编程硬件平台构建云网络，为云计算交付具备“不妥协性能的灵活性”的星融Asterfusion云网络。

PICFA™从容应对千万量级的虚拟计算节点

今天，即便是对于一个可容纳5,000台物理服务器的中小规模的云数据中心，将其最低虚拟计算节点容量设计为5,000,000是一个最正常的需求。

但是，在当前的商业以太网交换芯片市场上，为1RU高的Leaf交换机设计的交换芯片的FIB表项空间的容量最常见的只有128K。

由此，5,000,000和128K的矛盾就尖锐地显现出来了；而造成这种矛盾的根本原因，就是底层网络依据传统架构、传统模型和传统理念所设计的集中式方案。

星融元Asterfusion全面创新地提出了PICFA™
（Protocol Infinity Cloud FabricArchitecture，协议无限云网架构）。

PICFA™采用独创的分布式路由算法和与之相配合的转发逻辑，完全重构了云网络的控制平面与数据平面，彻底抛弃了传统网络中低效的集中式存储结构与转发逻辑，将云网络对云中虚拟计算节点的容量支持一举提升100倍至千万量级，同时大幅提升转发性能，使网络不再成为云计算容量的限制因素，从而为云网络从计算空间向底层物理网络的迁移打下坚实的基础。

图9：PICFA™从容应对千万量级的虚拟计算节点

在部署了PICFA™的星融元Asterfusion云网络中，所有租户的所有虚拟网络信息被动态、智能、均衡地分布在全网的所有Spine和Leaf交换机上，充分利用所有交换机的所有表项空间，由此，单台网络设备的FIB容量不再成为云的容量限制，虚拟机数量获得量级的提升，服务器计算力被充分利用！

相关阅读：对！这届GNTC唯一捧得双奖的黑马就是我们！

-未完待续-

关注星融元

本篇我们从开放的高性能硬件架构、软件系统与硬件平台的分离与解耦、DevOps工具、RESTful API、容器架构、内存数据库Redis、与主流Cloud OS——OpenStack的完全集成这几个方面聊聊星融Asterfusion云网络的开放性。

开放的高性能硬件架构

传统网络硬件平台的架构，因受生产者的商业模式、设计理念等限制，通常采用私有的架构，为使用者提供一个网络黑盒，并且与其上层网络操作系统紧密耦合，将使用者牢牢锁定在该平台之上。
基于这样的网络架构来设计的IT系统，用户在日常运维、故障定位、备件更换、网络扩容、升级换代等方面都需要高昂的成本。

星融元Asterfusion云网络则采用完全不同的理念与架构，来设计其高速网络硬件平台。如图1：

图1，开放的高性能交换硬件平台

星融元Asterfusion硬件平台的优势：

• 开放的架构：系统采用简洁、开放的架构设计，又基于业界成熟的BMC（Baseboard Management Controller）、COME（Computer-On-Module Express）、第三方的高性能可编程交换芯片等方案，来构建模块化的系统。

• 业界知名商业交换芯片：高速交换子系统采用业界知名的交换芯片设计，用户不仅可以享受海量出货芯片的成本红利，还能拥有完全透明开放的架构，不携带任何硬件层面的专利与锁定，与前面提到的“专有芯片+私有硬件”的方案形成了鲜明的对比。

• 可编程交换芯片：星融Asterfusion紧密跟随网络领域最先进的技术发展动向，采用可编程的交换芯片作为交换子系统的核心，使用户的需求在硬件转发层面被快速响应，让云的快速迭代不再受18-24个月的ASIC开发周期的限制。

• 功能丰富的高性能交换系统：星融元Asterfusion的云网络不但能够为云中业务提供丰富接口类型（10G/25G/40G/100G）、全线速的转发，而且还能够在硬件网络上为云中业务提供L4SLB（Layer 4 Server Load Balancing，四层服务器负载均衡）、1:1 NAT（1:1 Network Address Translation，一对一网络地址转换）等功能。

值得一提的是，星融元Asterfusion云网络的整体架构设计完全遵循了业界最领先，公司已经广泛部署和使用的Scale-wide架构（按需自由扩展架构），将原本封闭在大型机架式网络设备中的CLOS交换架构开放到网络拓扑设计当中去，帮助用户在只采用盒式网络设备的前提下仍然能够搭建出大规模的扁平化云网络，使用户在享受高性能、按需自由扩展的同时，最大限度地降低云网络的TCO（Total Cost of Ownership，总拥有成本）。

图2，基于Scale-wide架构的大规模Asterfusion云网络

例如，在图2中，

1. 位于Leaf层的128台（64对）CX532P，每台的32个100G接口被分成两组，16个向下接入服务器，16个向上接进Spine层，并且通过使用100G-25G的1-to-4 Breakout功能，将所有100G接口拆分成64个下行25G接口和64个上行25G接口，通过上行25G接口分别接入到Spine层的64台CX532P。
2. 位于Spine层的64台CX532P，每台的32个100G接口通过使用100G-25G的1-to-4 Breakout功能，将所有100G接口拆分成128个下行25G接口，接入Leaf层的128台（64对）CX532P。
3. 数据中心的每台服务器通过双25G链路分别连接到一对Leaf层的CX532P的下行25G接口，组成高可靠的接入层，每台Leaf层的CX532P的64个25上行接口分别上行到64台Spine层的CX532P，这64台Spine层CX532P总共能够接入128台（64对）Leaf层CX532P。
4. 这样的Spine-Leaf网络模块，总共能够提供128 x 64 = 8,192个25G接入接口，可以为4,096台服务器提供双25G上行的高可靠（接入层Active-Active热备和负载分担）和高性能（1:1收敛比，全线速）接入方案，整网提供204.8T的交换容量和8,192,000虚拟计算节点的支撑能力，即每服务器50G的上行接入能力和1:1000的虚拟化比。

软件系统与硬件平台的分离与解耦

SAI是由微软最早提出并实现的，用来描述交换芯片与操作系统之间接口的软件抽象层。

简单来说就是，SAI为运行在交换芯片上的网络操作系统屏蔽了底层芯片的差异，让相同的网络操作系统可以在不同架构或不同品牌的交换芯片上平滑迁移，大幅度降低了软硬件系统适配和驱动带来的复杂度及工作量。

SAI目前已经得到绝大多数交换芯片厂商的支持，成为事实上的工业标准。

图3，彻底解耦的软件系统与硬件平台

星融元Asterfusion在AsterNOS中全面集成了SAI，在硬件平台的设计中也选择了多款支持SAI的可编程交换芯片。
因此，在星融Asterfusion云网络中，软件系统与硬件平台是完全分离解耦的架构。
正如图3所示，AsterNOS不仅能够运行在任何支持SAI接口的硬件平台之上，Asterfusion硬件平台也能够运行所有支持SAI接口的操作系统。

最终将用户从传统网络“软件系统与硬件平台紧密耦合”的黑盒中解放出来。?

当然，对于中小规模、不具备自行开发能力、不具备软硬系统集成能力的客户，推荐选择星融Asterfusion的“AsterNOS + Asterfusion硬件平台”一体化解决方案，来降低部署的复杂度，加快部署的速度。

高性能内存数据库解耦交换机内部模块

网络操作系统中各个控制模块需要多种形式的交互，来交换信息、同步状态、协同工作。

在传统的网络操作系统中（如图4所示），这种模块间的交互往往通过直接建立点到点连接的方式进行，从而在各个模块之间形成了一张全连接的交互网络（Full-mesh）。

这种架构的网络操作系统有着很多弊端，

• 模块之间紧密耦合，架构复杂，其中一个模块出现问题，就会影响系统整体的稳定性；
• 操作系统内部的各种状态信息分散。
• 操作系统自身的备份复杂程度及风险很高。
• 传统网络操作系统的架构非常不利于扩展。

图4，软件模块解耦的网络操作系统

也就是说，任何模块都能够作为生产者将自身的关键信息存入这个数据库，并且按需更新、获取、删除。

该模块在重新启动之后，能够从数据库中恢复当前的各种配置及状态，从而不影响正常工作；

任何模块也能够作为消费者关注数据库中其他模块的变化，当某个模块在数据库中的存储信息发生变化时，数据库能够将这一变化发布给所有关心该模块的消费者，从而完成模块间信息与状态的同步。

基于数据库的信息与状态统一存放与管理机制，能让操作系统的稳定性、可扩展性、高可靠性得到大幅度的提升。

基于容器架构的网络操作系统，轻松支持第三方应用

相较于Hypervisor的VM（Virtual Machine，虚拟机）虚拟化技术，容器（Container）虚拟化技术以轻量化、高效率、低成本、与微服务架构的紧密结合等优势在最近几年中得到大规模的部署。

为了充分利用这些优势，微软为云计算发布的开源网络操作系统SONiC（Software for Open Networking in the Cloud）也采用了容器架构。在SONiC中，网络操作系统的软件模块以容器的方式运行在Linux内核之上，从而使得SONiC整体的可扩展性、稳定性、开发及运行的效率大幅度提升。

AsterNOS以SONiC为内核，并且在其上开发了现代云网络操作系统所必需的控制平面、RESTful API、用户界面、DevOps支持、运营管理等功能。

图5，AsterNOS系统架构[/caption]

AsterNOS将标准Linux内核之上的容器环境开放给了第三方应用。

也就是说，任何曾经运行于x86虚拟化世界中的运维管理工具都可以直接运行在AsterNOS上。在不带来任何额外开发工作量的前提下，为云网络的自动化运维管理提供与原有方法完全一致的体验，大幅提升云网络运维效率。

举个栗子，在基于“软件模拟虚拟网络”的云中，为了获取每个租户的虚拟网络的流量统计信息，管理员需要在每一台物理x86服务器上安装自动统计与收集工具，再将所有这些工具的统计结果全部汇聚到Cloud OS；而一张面向公众运营的云中，物理x86服务器的数量是以数千、数万为单位计算的，所以这样一个简单的运维需求在“软件模拟虚拟网络”的云中所带来的复杂度及管理流量的压力可想而知。

图6

但是在AsterNOS的云网络中，每一个这样的运维工具只需要运行在每个ToR（Top of Rack，架顶）交换机上即可，而ToR交换机的数量相比物理x86服务器来说，只有其1/50左右。

因此，AsterNOS基于容器的开放架构将会大幅度提高云网络的运维效率。

Asterfusion云网络支持DevOps

DevOps是一种新型的软件产品交付模型，它将与软件产品生命周期过程中的各个相关部门（例如研发、测试、运营等）以一种空前的方法连接了起来，并且对他们的沟通、协作等提出了更敏捷、更快速、更频繁的要求。

例如，互联网时代的软件产品一般都要求版本以天为单位快速迭代更新，继而测试部门也要按照相同的节奏完成产品质量保证所必须的工作。同样，运营部门也需要快速地更新升级运营环境以保证业务系统的正常运行及良好的用户体验。

对于网络来说，DevOps模型的大规模普及意味着网络也要在如此频繁、快速的迭代过程中具备灵活、敏捷及自动的调整能力。Asterfusion云网络能够很好地支持在开发、测试、生产环境中广泛部署的NETCONF、Ansible等DevOps工具。

图7，Asterfusion云网络支持DevOps

NETCONF（NetworkConfiguration Protocol）是IETF于2006年标准化的，用于取代SNMP（SimpleNetwork Management Protocol）的网络管理协议，并于2011年进行了更新。

NETCONF克服了SNMP饱受诟病的安全性差、可扩展性差、效率低等缺点。

（图7中）运行在AsterNOS内部的NETCONF Server能够与来自于DevOps平台的NETCONF Client建立连接，并且按照预先定义好的管理数据结构，接受来自DevOps平台的配置管理请求、或者提供系统内部的各种配置、统计、状态信息给DevOps平台。

Ansible是一款极具代表性的DevOps工具，它能够将运营环境中大量的重复性工作以“Playbook”的方式进行自动化，从而为管理员降低工作负载，提升工作效率。

Ansbile不需要被管理对象（服务器或网络设备）安装任何客户端，而是通过标准的SSH通道进行交互，所有需要被管理对象执行的命令和返回给服务器的结果都在这个标准通道中传递。

Ansible的这种架构在很大程度上降低了自身的运维与管理复杂度。

Asterfusion为AsterNOS开发了符合Ansible标准的AsterPlaybook，通过AsterPlaybook，Ansible服务器能够快速、便捷地完成对Asterfusion云网络自身的自动化运维。

同时，对于任何以容器模式运行在AsterNOS内部的第三方应用，也能完全融入到基于Ansible的DevOps环境中去。

Asterfusion云网络通过RESTful API开放所有能力

相较于其他架构，REST因简洁、高效、弹性、开放等特性被越来越多的应用系统所采用，经过十多年的发展，已经成为基于Web应用系统的事实标准。

相应地，如果一个系统提供的API（Application Programming Interface，应用软件编程接口）符合REST架构风格，通过这样的API，这个系统能够与其他REST系统完成软件编程级的对接，这样的API就被称为RESTful API。

在云计算时代，一个系统是否能够提供RESTful API，直接决定其是否开放、是否能被融入到云中。

星融元Asterfusion云网络系统正是通过一系列RESTful API将网络的能力全部开放出来，从而将云网络完全融入到云计算软件定义、弹性调度、按需扩展、自动运维的世界中。

图8，Asterfusion云网络开放所有能力

在星融元Asterfusion云网络中（图8）：
AsterNOS所提供的网络基础能力通过RESTful API开放，通过调用AsterNOS的各种人机交互界面（命令行、WebUI、控制面板等）API完成配置管理、参数设置、状态查询等任务；

Asteria Fabric Controller通过调用AsterNOS的RESTful API，将原子级的网络基础能力封装为网络业务能力，为使用者屏蔽操作细节，以降低复杂度并提升效率；

通过调用Asteria Fabric Controller和AsterNOS的RESTful API，任何REST架构的Cloud OS、DevOps平台、第三方应用都可以用SDN的方法自动化地管理、调度Asterfusion云网络。

Asterfusion云网络与OpenStack的集成

OpenStack是一个开源的Cloud OS，被用来在数据中心内部统一管理和控制所有的计算、网络和存储资源。

图9，OpenStack——开源、开放的Cloud OS

无论是云管理员还是云用户，都可以通过OpenStack提供的控制面板和WebUI按需部署、自动调度云中的各种资源。

OpenStack是一个开放的系统，由若干子项目/模块构成，Nova（计算资源管理）、Neutron（网络资源管理）、Cinder（块存储资源管理）等。为了维持其开放性、与现有基础设施的兼容性，OpenStack的很多模块都定义了RESTful API标准，第三方系统只要按照这个标准提供对应的API，即可实现与OpenStack的无缝对接，从而被OpenStack集中管理、自动调度。

通过提供符合标准的RESTful API和插件，星融元Asterfusion云网络具备与OpenStack的Neutron和Octavia（负载均衡服务）的对接能力。

图10，Asterfusion云网络与OpenStack的集成

由图10我们可以了解到：

OpenStack的其他模块通过调用预先定义好的API来使用Neutron和Octavia模块提供的虚拟网络和负载均衡服务；

• Asterfusion为Neutron和Octavia模块提供的插件（也称为驱动），将他们对虚拟网络执行模块（例如OpenvSwitch）和负载均衡执行模块（例如HAProxy）的API调用映射为对Asterfusion网络RESTful API的调用；
• 通过如上的调用，将OpenStack中的虚拟网络和负载均衡全部从计算空间中卸载到Asterfusion云网络上，大幅提升虚拟网络和负载均衡的性能，同时降低部署和维护的复杂度；
• 对于OpenStack自身和运行在其上的业务系统来说，这一切过程都是透明的，不需要做任何的调整或再开发。
• 通俗的说：在OpenStack上仍只需要点击两下鼠标，即可在高性能的Asterfusion云网络上完成虚拟网络和负载均衡服务的部署。

Asterfusion云网络帮助云计算进入新纪元

Asterfusion云网络是一个面向云中业务与应用的Cloud SDN平台。
全面开放、统一管理、自动调度、面向业务的Asterfusion云网络，为云计算大幅降低TCO、提高ROI，并提升运营效率。

图11，在这个面向业务与应用的Cloud SDN平台上，

1. 所有租户的虚拟网络不再由运行在计算空间中的软件来模拟，而是直接承载在Asterfusion交换机搭建的底层物理网络上，从而最大限度释放计算空间的计算力，充分利用底层硬件网络资源提供超高性能、超大容量、租户隔离、功能丰富的虚拟网络；
2. 物理网络与虚拟网络全部通过Asteria Fabric Controller集中管理，通过单一入口的管理点降低云网络运维的工作量，并且轻松完成虚拟网络到物理网络的映射、发生故障时的关联分析、网络资源使用情况的分析与优化等高级运维任务；
3. Cloud OS通过软件编程的方法调用Asteria Fabric Controller提供的业务级的RESTful API，自动化地完成按照业务需求对云中虚拟网络的运维任务，CloudOS无需关注云网络的部署细节，只需要关注业务对云网络的需求即可；
4. Asteria Fabric Controller将从Cloud OS接收到的业务级请求翻译、分解成AsterNOS能够理解的原子级操作，通过调用AsterNOS的RESTful API，完成对支撑业务的云网络的自动部署、运维、优化，再将结果反馈给CloudOS，从而将云网络完全融入到Cloud OS的统一管理架构中。

图12，Asterfusion云网络不再游离于云之外

至此，星融元Asterfusion云网络不再游离于云之外，而是与计算、存储一起图片全面开放图片，共同成为云计算时代的“云基础设施”！

关注星融元

自从2006年云计算正式诞生以来，只用了短短十年的时间，就已经发展到可以大规模在生产网络中部署及承载关键业务了。

我们纵观整个IT发展历史，在基础设施层面发生如此大的变革，云计算毫无疑问是首当其冲的。

在这么短的时间跨度内，云计算之所以能够有突飞猛进的发展，与亚马逊、谷歌、微软、阿里等这些老牌IT巨擎以及新锐互联网力量的勇于探索是密不可分的。

当然也与计算与存储技术在云计算时代的快速发展和自我调整有着紧密的关系。

被游离的云网络

当前的云网络游离于云计算的整体架构之外

计算、网络和存储
被并称为云计算的三大支撑基础设施

在云计算时代，计算和存储紧紧跟随了云的发展步伐，率先完成了架构的演进——

• 系统从自我封闭到全面开放；
• 架构从硬件主导到软件定义；
• 管理从手工配置到自动调度；
• 运维从以设备为中心到以业务为中心。

遗憾的是：网络，作为云中三大基础设施之一，却因为自身封闭的原因未能跟上这一步伐，从而使自身游离于云计算的整体架构之外。当前云网络封闭的表现主要在于以下几个方面：

• 软硬件一体化
  私有的网络操作系统只能运行在私有的硬件平台之上，云计算的运营者不但无法享受硬件标准化带来的成本红利、有效降低TCO（Total Cost of Ownership，总拥有成本），而且往往面临着被底层网络锁定的风险。
• 封闭在黑盒中的网络能力
  因为历史原因，很多网络设备只能通过低效的命令行方式、逐设备地进行部署配置，即便提供了集中控制器，也只是从网络维护的视角出发提供了一个简单的图形化的管理界面，并未将其与云中的业务与运营需求紧密结合。
• 无法支持云中常用的DevOps工具
  DevOps（Developmentand Operations，开发运维）已经成为云以及网络运维的主要手段，各种自动化工具也在今天的云中大量部署、使用，但是传统网络却无法有效地集成或支持这些DevOps工具。
• 面向设备而非业务的管理框架模型
  传统网络即便提供了统一控制器进行集中管理，其管理框架往往也是按照设备管理的模型进行设计，一个业务对网络提出的需求往往需要管理员人为地拆解成针对若干设备的若干配置需求逐一配置，在设计、执行、维护等方面的复杂度都非常高。

也正是上述原因，当前的云计算运营者采用了“在计算空间中用软件模拟虚拟网络（如下图）”的思路，来规避封闭的网络给云计算带来的限制。

所以在“软件模拟虚拟网络”的云中，云计算运营者使用软件开发了各种虚拟网元（虚拟交换机、虚拟路由器、虚拟防火墙、虚拟负载均衡等）用来模拟云中租户需要的网络。与传统网络设备不同，这些虚拟网元完全具备软件定义、开放接口等能力，从而使得云对虚拟网络的各种需求，包括自动配置、动态调整、按需伸缩等，全部通过Cloud OS（Cloud Operating System，云操作系统，也称为CMP，Cloud Management Platform）对这些虚拟网元的自动调用来完成。

而位于底层的物理云网络，仅仅被作为最简单的三层IP通道来承载由“软件模拟虚拟网络”封装在隧道中的云业务流量。

这种解决方案虽然满足了云计算运营者对网络的需求，但缺点也是显而易见的：

侵占云中计算力、性能与效率低下、运维复杂度高、欠缺业务质量保障等。

我们很遗憾地看到，在网络与云之间形成了一种“因为底层网络不开放，所以用软件模拟；因为软件模拟，所以导致底层网络使用效率越来越低”的恶性循环，而这一恶性循环产生的根源就是网络自身的开放性。

云网络的回归之路

全开放的Asterfusion云网络有效弥合云与网络之间的鸿沟

针对传统云网络在开放性方面所面临的各种挑战，星融Asterfusion为云计算环境提供全开放云网络的解决方案，无缝地将云网络彻底融入到云中。
下面来看看星融Asterfusion是如何帮助云网络真正融入云计算的（如下图）：

1. 底层硬件平台基于开放架构、商用可编程交换芯片设计，在为上层软件提供高性能运行环境的同时，彻底抛弃传统网络硬件私有、黑盒的设计理念。
2. 运行在硬件平台上的标准Linux内核为上层应用提供开放的操作系统内核支撑，使得当前主流的DevOps工具能够直接运行在网络设备上，任何第三方应用也都能以容器的形式运行在这个标准的Linux内核之上。
3.  AsterNOS是一款开放、智能、易用、高性能的网络操作系统，以SONiC/SAI为内核，为Asterfusion云网络提供设备级的控制平面，同时支持RESTful API能力开放、主流DevOps工具集成、主流Cloud OS集成、高性能内存数据库等云计算时代的必备功能。
4. 对SAI（Switch Abstraction Interface，交换机抽象接口）标准的支持将AsterNOS和Asterfusion的交换硬件平台彻底解耦开来，AsterNOS可以运行在任何遵从SAI标准的硬件平台之上，Asterfusion交换硬件平台也能够支持任何遵从SAI标准的网络操作系统在其上运行。
5. AsteriaFabric Controller（AFC）是为云计算环境设计开发的Cloud SDN Controller，与运行着AsterNOS的交换机系统共同组建一个面向云中业务与应用的Cloud SDN平台，在这个SDN平台上，所有的网络能力均以RESTful API的形式向Cloud OS开放，Cloud OS完全以自动化的形式、从业务的视角对云网络进行部署、调度，无需再关注网络底层的细节。

在部署了Asterfusion云网络的云中，使网络与计算、存储一样，自下而上形成了层次分明的“开放硬件世界”、“标准内核世界”和“自动管理世界”，从而使得Cloud OS能够对三大基础设施完全一致地统一管理、按需伸缩、自动调度。实现了网络、计算、存储一起成为真正意义上的“云基础设施”。

– 未完待续 –