本篇我们从开放的高性能硬件架构、软件系统与硬件平台的分离与解耦、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云网络不再游离于云之外，而是与计算、存储一起图片全面开放图片，共同成为云计算时代的“云基础设施”！