Skip to main content
开放网络的先行者与推动者—星融元
加入我们技术支持(Support)  TEL:(+86)4000989811

标签: 中立科普

云网络的回归之路-全开放篇(上)


关注星融元


自从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能够对三大基础设施完全一致地统一管理、按需伸缩、自动调度。实现了网络、计算、存储一起成为真正意义上的“云基础设施”。

– 未完待续 –

相关文章

云原生、全栈可编程的下一代SDN解析与实践丨传统SDN架构演进


关注星融元


多年以前,由于基于传统协议的控制平面缺乏灵活性,无法满足多样的业务对数据平面的转发需求,软件定义网络(SDN)被提了出来。业界希望通过一种转控分离、开放解耦的架构,让网络资源能够被上层应用通过标准的API,更加灵活的按需分配。在这种架构下,SDN控制器提供北向接口给上层应用,实现网络资源的动态管理;并通过OpenFlow、NETCONF、SNMP、RESTCONF等南向接口控制底层网络设备数据平面转发行为及设备管理。

可见,SDN控制器的架构以及南向接口是SDN的关键技术点,不夸张的说,这两方面是决定整个SDN方案成败的关键因素。

在控制器领域,尽管OpenDaylight,ONOS和Ryu等开源系统已经逐渐被各个厂家和用户所接受,但由于南向接口OpenFlow的天然缺陷以及单体架构控制器的日渐臃肿,使得基于传统架构和技术的SDN解决方案,迟迟无法达到最初的设计理念,很难适应业务对网络的需求。

从本期开始,小编将连续出三篇系列文章,以ONOS(开放网络操作系统)为例,详细分析控制器的架构、网络设备可编程接口的发展趋势,解析以去中心化、云原生、协议无关为设计目标的下一代SDN体系结构,并分享星融在这方面的最新实践

什么是ONOS?

ONOS是领先的开源SDN控制器,被广泛应用于构建下一代SDN / NFV解决方案。它为SDN提供控制平台和管理网络的组件(例如交换机和链接),并运行网络应用程序提供通信服务。如果您熟悉传统的嵌入式交换机操作系统,则会发现ONOS可以管理整个网络而不是单个设备,可以大大简化多台交换机的软硬件配置管理和部署。如果您熟悉SDN控制器,则应该感到宾至如归,因为ONOS是一个可扩展的模块化的分布式SDN控制器。

接下来我们看看ONOS的设计原则和总体架构。

ONOS的设计遵循四条基本原则:

  1. 高可用性,高可扩展性和高性能;
  2. 要对网络资源进行高度抽象并简练地表示出来;
  3. 要做到协议无关及硬件无关;
  4. 网络应用程序的模块化。

ONOS的总体架构 图1 ONOS的总体架构

ONOS整体架构可分为三层,分别为:

  1. 北向接口(NBI),应用程序使用这些接口来了解网络状态(例如遍历拓扑图、拦截网络数据包),并控制网络数据平面。
  2. 分布式核心,负责管理网络状态,并将状态的变化通知给网络应用程序。核心层内部使用的数据库是可扩展的分布式键/值存储数据库Atomix。
  3. 南向接口(SBI),由共享协议库和特定设备的驱动程序构成的插件集合。

接下来我们主要介绍下分布式核心和南向接口层如何通过P4runtime协议与设备交互。

分布式核心

ONOS分布式核心由许多子系统组成,子系统负责网络拓扑、主机跟踪、数据包拦截、流编程等的维护和管理。主要的子系统有:

  • Device Subsystem- 管理网络设备集群
  • Link Subsystem- 管理网络链路
  • Host Subsystem- 管理主机及其在网络上的位置
  • Topology Subsystem- 管理网络拓扑及实时状态的更新
  • Packet Subsystem- 允许应用程序收发业务报文(从/往网络设备)
  • Path Subsystem-计算/查找网络设备之间或终端主机之间的路径
  • FlowRule Subsystem- 管理网络设备的流表规则

这些服务大多是使用分布式表(映射)构建的,而这些表存储在atomix数据库中,接下来让我们来看下Atomix数据库。

它可以跨一组分布式服务器进行扩展,并实现故障时的容错处理。Atomix是构建分布式系统的通用工具,它是一个基于Java开发的系统,其支持以下功能特性:

  • 分布式数据结构,包括maps、sets、trees、counters
  • 分布式通信,包括直接消息传递和发布/订阅
  • 分布式协作,包括locks、leader elections、barriers
  • 管理群组成员

Atomix在ONOS中的一个重要作用是协调ONOS的所有实例,主要体现在两个方面:

首先,ONOS具备水平可扩展的能力,在任何时间运行的ONOS实例的数量取决于工作的负载情况和在出现故障时为保证系统可用性所需的备份情况。Atomix group membership原语用于确定可用实例的集合,从而可以检测到已转换的新实例和已失败的现有实例。

其次,每个ONOS实例的主要工作是监视和控制网络中物理交换机的子集。ONOS采取的方法是为每个交换机选择一个主实例,只有主实例可以向给定的交换机发出(写入)控制指令,而所有实例都可以监视(读取)交换机状态。这些实例使用Atomix leader-election原语来确定每个交换机的主实例(主控制器)。如果一个ONOS实例发生故障,则使用相同的原语为交换机选择新的主控制器。当有新交换机上线时也采用相同的方法来为其选举主实例。

接下来看看ONOS是如何实现对P4Runtime的支持。

P4Runtime

在传统SDN方案中,OpenFlow一直被看做是控制底层网络数据平面的理想接口之一,但由于硬件支持度不高,在实际部署中并未达到预期效果。

P4Runtime作为一种控制器和网络设备之间的数据转发控制接口,和OpenFlow同样具备协议无关性,是一套基于Protobuf和gRPC框架定义的协议。通过P4Runtime协议,SDN控制器可以控制配置支持P4的网络设备。现在P4是数据平面可编程的主流代表,其匹配域和动作域可以任意定制,流表流水线也可以根据网络需求的改变而修改。

ONOS是如何支持流水线可变性的呢?

首先,ONOS为了解决这个问题,在Core层诸多子系统中横向扩展了一个子系统,叫做PI 框架。PI = Protocol/Program/Pipeline Independent,代表了协议无关、程序无关、以及处理流水线的无关。
PI框架是围绕着P4和PSA进行建模的,但PI框架在设计上是面向通用的协议无关思想的,能容纳未来各种协议无关的语言或者协议,目前仅仅是适配到了P4语言。PSA(Portable Switch Architecture)就是P4设备的一个通用架构描述,类似OpenFlow的TTP(Table Type Patterns)。PI架构里包含了一些类、服务和设备驱动的功能描述来建模和控制可编程数据平面,定义了抽象的表项和计数器等等。

PI框架在ONOS中的架构设计 图2:PI框架在ONOS中的架构设计

首先,最底层是协议插件,有P4 Runtime和gRPC;往上一层是Driver子系统,有P4Runtime、Tofino和BMv2等;最上层是核心层也是PI框架核心所在,它包含了PI模型、FlowRuleTranslation子系统和还有Pipeconf子系统等三大模块。而流水线流表可变性 实现的关键,就是这个FlowRuleTranslation子系统,下文统称为“流表翻译子系统”。

PI框架向上既可以支持pipeline无感知的应用,比如之前针对OpenFlow设备编写的程序 ;也可以支持对Pipeline有感知的应用,也就是针对特定的P4程序编写的控制应用。

接下来介绍下流表翻译子系统:

FlowRule Translation 图3 FlowRule Translation

PI框架里的流表操作涉及到三个阶段的转换操作,分别对应Pipeliner、Interpreter、P4Info这三个元素,也就是上图中的蓝色部分,是我们pipeconf(.oar)应用里的内容。

如果我们使用FlowObjective来下发决策,就会经过Pipeliner把它转换成FlowRule,当然我们也可以直接使用FlowRule。然后P4设备驱动会调用PI框架的FlowRuleTranslation 子系统,借助Pipeline Interpreter把FlowRule转换成PI Table Entry,它是PI框架对一条表项的抽象。最后PI Table Entry会在南向协议插件的P4Runtime Client中借助P4Info转换成P4 Runtime Message这个通信报文,然后在网络中传递给P4设备。如上图3所示,流表操作主要就是三次转换。

介绍完分布式核心和P4Runtime,让我们来看看ONOS的发展现状。

ONOS的发展现状

随着ONOS 2.0版本的发布,当今的ONOS架构提供了一个稳定的基础平台,包含了许多的功能特性,例如简单的第三方应用开发、轻松的分布式集群部署、服务自动导入、已存在大量的第三方应用和拓展组件。

但是,ONOS架构当前也同样存在一些限制,比如有限的资源隔离、基于平台的应用仅支持java或JVM-based语言开发;比如应用/服务水平扩展困难、组件无法迁移到平台之外(控制平面功能无法卸载到设备);再比如与NFV的集成受限且对NFV的支持也同样有限等等。尽管上述限制在本质上都是技术性的,但它们还是限制了ONOS在一些重要的行业场景中的应用,因此我们必须解决ONOS的这些限制。

ONF(Open Network Foundation)正在开发一个新的开源架构Micro ONOS(µONOS)以提供真实网络控制、零接触配置和可验证安全的网络,并使运营商可以完全控制其网络 ,这也是下一代SDN的发展趋势。

相关文章

连接未来的SONiC!


关注星融元


什么是SONiC?

在构建公有云平台Azure的过程中,微软逐渐意识到传统网络设备的局限性。

于是成立了SONiC(Software for Open Networking in the Cloud)/SAI(Switch Abstraction Interface)开源项目,目标是针对Azure对网络的需求,基于标准的Linux内核重新构建一个开放的网络系统软件。

并且,微软没有将这个系统做成封闭的,而是以开放、开源、社区的模式运作;

SONiC/SAI最近几年的蓬勃发展在很大程度上也是得益于此…

SONiC/SAI概念

图1:SONiC/SAI概念

在SONiC/SAI定义的开放架构中,传统网络设备软硬件一体的封闭架构被打破,软件和硬件被彻底解耦;就好像今天的Windows/Linux操作系统能够运行在任何第三方基于标准设计的PC/Server硬件上一样,SONiC/SAI网络软件系统也能够运行在任何符合标准的网络硬件平台之上啦!

SONiC/SAI给整个网络产业带来的最根本变革是:

  • 软硬件解耦的理念和标准化的软硬件接口定义,分别让网络软件系统和硬件平台飞速发展;
  • 网络软件系统的演进,也可以让快速迭代、按需定制、社区共建成为可能;
  • 网络软件的开发形成了全新的共建、共享、开放的网络生态系统,快速推进网络自身的发展。

SONiC/SAI全新的理念、开放的架构,很快获得了云计算时代的用户、厂商的青睐,成为云计算时代构建网络软件系统的首选。

也正因此,SONiC/SAI被OCP(Open Compute Project,开放计算项目)吸纳,成为OCP网络组的两个子项目。

SONiC系统架构

SONiC构建在Linux系统之上,并且利用键值数据库(redis)、容器技术(docker)、标准化硬件接口定义等技术,使其成为一个软硬件彻底解耦、软件模块松耦合(loose coupling)、高可靠、易于扩展、开源开放的网络软件系统。

SONiC架构图

图2:SONiC系统架构

从图2我们可以看到:

  • 运行在用户空间的SONiC系统,只有为数很少的模块(pmon、swss和syncd)与Linux内核之间存在交互关系,从而保证了系统的稳定性。
  • 以redis键值数据库为交互中心,redis为SONiC的所有软件模块构建了一个松耦合的通信载体,同时提供数据一致性、信息复制、多进程通信等机制。
  • 采用了最新的容器架构,除SONiC CLI和SONiC Configuration这两个软件模块以外,构成SONiC系统的其他各个软件模块均被隔离在独立的Docker容器中。使用者无论需要增加新的功能,还是改变一个Docker,都不需要做太大的变化,只对一个局部做出改变即可!

星融元基于SONiC构建的网络操作系统

星融是国内最早参与SONiC社区的公司之一

经过几年的发展,SONiC已经成为云计算领域极具发展前途的开源社区之一。

星融(Asterfusion)创始团队的核心成员来自于华为、Cisco、Broadcom等知名网络企业,对于网络和云计算领域的技术和产品有着深刻的理解,创立星融之前就已经在积极跟踪、深度参与SONiC及其社区。

作为新一代云网络供应商的星融自成立之初就正式加入了SONiC社区,成为国内最早参与SONiC社区的云网络公司之一。

国内最早参与SONiC社区的云网络公司之一。

图3:SONiC社区成员

SONiC社区活跃的成员大致可以分为以下几类:

  • 互联网巨头/云计算公司:阿里巴巴、百度、滴滴、Docker、Facebook、京东、LinkedIn、Microsoft、腾讯等
  • 传统网络设备供应商:Arista、Cisco、Dell、Juniper、Ruijie等
  • 白盒网络设备供应商:Celestica、Edgecore、Quanta等
  • 新一代云网络供应商:Apstra、Asterfusion等
  • 网络交换芯片供应商:Barefoot、Broadcom、Cavium、Centec、Innovium、Marvell、Mellanox等

可见,SONiC社区已经形成了从最低层芯片到最上层大规模用户的全面生态系统,这个生态系统从硬件芯片、系统架构、系统集成、大规模应用等各个层面促进着SONiC的发展与成熟。

AsterNOS网络操作系统

星融致力于为云计算时代的用户提供新一代云网络解决方案。

为了提供全开放、高性能、业务可视的云网络解决方案,星融以SONiC为内核,构建了新一代的网络操作系统——AsterNOS。

AsterNOS整体架构

图4:AsterNOS整体架构

AsterNOS构建在标准的Linux内核与SONiC/SAI之上,基于SONiC的标准功能,星融为AsterNOS开发了一些增强特性💪🏽:

  • 增加了VLAG、BGP EVPN、PICFA™、REST API等功能来提升系统整体可用性;
  • 通过REST API将网络的所有能力开放出去,使系统能够被第三方云管平台集中管理、自动调用;
  • 基于REST API提供了Web UI,让用户能够通过图形化的界面来操作和管理云网络;
  • 应用编排、业务调度、资源管理、策略管理等运维和运营的增强特性,使系统能够支持云管理平台的业务统一规划、自动部署;
  • 集成了Python、Ansible、NETCONF等DevOps工具,使得系统能够与DevOps平台自动对接;
  • 开放标准的Docker容器环境,支持第三方应用直接在网络系统中运行。

另外值得一提的是,星融还为AsterNOS提供了可编程

  • 基于可编程交换芯片的高性能硬件平台
  • 统一控制器:Asteria SDN云网控制器(AFC)

AsterNOS、AFC和高性能的可编程硬件平台一起为云计算提供新一代的SDN云网络方案:

星融云网络方案整体架构

图5:星融云网络方案整体架构

星融积极回馈SONiC社区

秉承开源、开放的精神,星融积极回馈SONiC开源社区。
截至2020年4月,星融已经向社区贡献了多个Bug Fix,其中有21个通过社区评审,并被合并进入主线版本。

这21个Bug Fix具体如下:

 20个针对SONiC系统,分布在路由协议(FRR、docker-fpm-frr、vrfmgrd)、应用模块(dhcp-relay、libteam、lldp)、VXLAN隧道(vxlanorch)、ACL模块(portsorch)、安全保护(copporch、ebtables)、服务质量保障(qosorch)、系统与配置管理(sonic-sfp、config、hostcfgd)、系统仿真(vstests)等模块。

除了上述Bug Fix以外,星融目前正在计划将自行开发的增强功能也贡献给SONiC社区,帮助社区进一步提升SONiC的可用性、易用性。

星融可以帮助企业用户使用SONiC

针对企业用户,在部署SONiC和基于SONiC进行的二次开发过程中遇到的一些难题,星融从以下几个方面,可以帮助企业用户顺利使用SONiC。

搭建本地Git仓库

很多企业用户通过github.com下载、编译SONiC源代码的过程并不顺利,往往会碰到无法连接、下载速度慢继而导致编译失败等问题。

针对这样的问题,星融在云端为企业用户搭建了位于本地的Git代码仓库,定时、自动地克隆源服务器上的相关内容以提供本地镜像,需要使用时只要连接到这个本地的Git代码仓库即可。

提供技术咨询服务

针对企业的生产环境,星融编制了全面的测试用例,在基于各种交换芯片的硬件平台上对SONiC系统中的各个软件模块进行了详尽的功能、集成、性能及压力测试,并且将测试过程中发现的问题修正后反馈给社区。

在这个过程中,星融积累了对SONiC系统的深刻理解,能够提供全方位的SONiC技术咨询服务,帮助企业用户清楚明白地使用SONiC。

提供一站式SONiC解决方案

对于希望使用原生SONiC的企业用户,星融能够帮助用户在选定的硬件平台上快速地完成开源、开放云网络系统的构建与部署;对于希望使用一站式解决方案的用户,星融可以基于AsterNOS、可编程交换硬件平台及AFC的支持,提供Turn-key方式的交付与部署,帮助用户轻松享受新一代的云网络技术为IT系统带来的“速度与便捷”。

功能与特性的定制开发

经过三年的发展,星融目前已经拥有了将近80名具备SONiC经验的开发/测试工程师,其中不乏具备架构能力的技术专家。因此,对于客户提出的针对网络的特殊功能需求,星融能够提供定制开发服务,将客户对需求的等待时间从18-24个月缩短到2-4周。

相关文章

走向可编程、开放与解耦之路


关注星融元


今天,用于流量采集和预处理的前端设备的功能越来越强大。随着实现技术的不断进化、可视化系统整体方案的复杂度越来越高、网络运维和信息安全中可视化系统应用部署越来越广泛,行业对前端设备的功能、集成度和成本要求也越来越高。

那么,在过去、现在和将来,可视化系统前端设备都经历了何种发展历史、形成了什么样的现状、又即将面对何种发展趋势?


前端设备的现状

今天主流的前端设备都是由传统网络设备逐步演化而来,其主要组成部分包括:

➤ 线路卡。主要功能包括接入和输出,即从分光器(或者生产网交换机的镜像端口)接入需要预处理的业务流量、将经过预处理后的业务流量输出到可视化分析、安全分析等后端系统。

➤ 业务卡。主要功能是对所接入的原始业务流量按照后端系统的需求进行各种预先的深度分析处理,降低后端系统的流量处理负载、提升整体系统的性能。

➤ 交换卡。主要功能是在多块线路卡和业务卡之间构建一个高速交换通道,形成一个具备高接口密度和高业务处理性能的整体系统;通常,交换卡会采用正交连接器或高速背板来和线路卡、业务卡进行互联。

业务卡所提供的流量预处理是整个前端设备最核心的能力,也是对后端系统来说最核心的价值所在。因此,接下来的讨论从业务卡开始。

业务卡的发展历史与技术路线

在过去十多年的发展历程中,随着产业基础支撑技术的发展,今天的业务卡所采用的架构也对应地形成了四种技术路线。

➤ FPGA(Field Programmable Gate Array)

具备和交换芯片类似的L2、L3和L4功能,但是针对报文的L7特征提取和分析等能力则非常有限。在这种架构中,灵活的L2、L3和L4-L7的报文处理都需要用Verilog这样的高级电路开发语言消耗FPGA的逻辑单元形成计算能力来实现。

➤ NPU(Network Process Unit)

能提供较丰富L4能力,也有较高性能的L7特征匹配分析能力。历经数代发展后,最后一代号称能够提供100G的L7协议分析处理能力的NPS在2016年被Mellanox收购后正式宣告停止后续的发展路标,大量采用NPS进行前端设备研发的厂商失去了技术支持,后续供货陷入高成本、备货周期不可预测、随时可能会停产的尴尬境地。

从另一个侧面看,所有NPU核心芯片厂家一致认为,用NPU实现L2-L4的功能,灵活有余而复杂度太高,且成本太高,用NPU实现L4-L7的功能以满足DPI的需求,则处理能力不足,在应对复杂场景时,心有余而力不足。

因此,对于今天需要对流量进行深度处理的市场(包括本文所述的可视化系统前端设备和防火墙、多业务路由器等)来说,NPU基本是一个已经被证明的在市场和技术上双重失败的典型案例。

➤ 以MIPS多核处理器为核心的SoC

SoC(System on Chip,片上处理系统)能够提供超高的系统集成度、丰富的I/O资源和灵活与性能兼备的加速子系统,而MIPS本身也能基于其强大的通用计算能力提供高性能的L4-L7的深度分析处理能力,自然而然的,两者相结合的架构可以为DPI分析需求提供高性能和灵活性兼具的解决方案。因此,从2010年开始的近十年间,以MIPS多核处理器为核心的SoC架构一直承担着L4-L7深度分析处理的主要任务。今天,MIPS处理器的指令集架构正在逐步被通用计算指令集(如X86和ARM)取代。

➤ 通用计算处理器(CPU)

今天的X86和ARMv64通用处理器,通过充分发挥SIMD指令集的效率,能够提供比肩MIPS/SoC片上加速单元的L4-L7特征分析处理能力,其通用计算能力也为报文分析提供了非常强大的软件生态支持。

(注:SIMD,Single Instruction Multiple Data,意指“单指令流多数据流”,是一种采用一个控制器来控制多个处理器同时对一组数据(又称“数据向量”)中的每一个分别执行相同的操作从而实现空间上的并行性的技术。在微处理器中,单指令流多数据流技术则是指一个控制器控制多个平行的处理微元对数据向量进行并行。)

线路卡的来龙去脉与前世今生

正因为早期的业务卡多从FPGA/NPU做起,而FPGA/NPU可以在提供业务处理能力的同时提供必要的L2-L4处理能力和端口I/O能力,所以早期的业务卡往往会混合着端口I/O、L2-L4处理及L4-L7处理三种能力,而且,每端口I/O的成本和FPGA/NPU的计算能力成正比。但是,从各种真实应用场景的实际情况来看,高密度I/O端口之间的L2-L4路由需求和需要强大计算能力的L4-L7深度处理需求之间并不能简单地按照线性比例部署,因此,为成本及灵活性计,L2-L4和L4-L7必须解耦,而这种解耦的要求直接导致了从业务卡中分化出线路卡的结果(就像从路由器中分化出了交换机⼀样)。

一般的,线路卡通过计算力不强、但I/O密度高、L2-L4功能相对完善的ASIC芯片来提供流量的接入、汇聚、过滤等标准的L2-L4处理。典型的线路卡实现采用了Switch芯片(交换芯片):

➤ 传统交换芯片中,Broadcom和Marvell是具备绝对市场统治地位的供应商,其芯片按照交换机的逻辑实现了经典的L2查表、L3查表等处理流程。在用作可视系统的前端设备时,前端设备的控制面软件通过特别的控制管理,可以利用交换芯片实现相当一部分前端设备的处理逻辑。但是,由于前端设备处理逻辑的查表键值与匹配流程和Switch芯片的经典流程并不完全相同,随着可视化系统对前端设备灵活性的要求越来越高,随着新网络协议和业务层出不穷,经典查表流程已经不能满足前端设备的L2-L4处理要求。

➤ 而事实上,类似的问题也出现在标准网络交换设备在日常的组网中,例如,根据多重隧道内层报文进行特征匹配,或者根据报文各层字段组合进行组合特征匹配,或者在一个处理流程中实现L2、L3和L4的并行处理、甚至对报文的负载部分进行修改等功能。虽然这些功能并不需要特别强大的计算能力,但是当标准Switch芯片不支持这些功能时,人们不得不将需要如此处理的流量提交到业务卡上去处理。

➤ 通常,对于每1个单位成本实现的1Tbps容量的L2-L4的Switch ASIC方案,需要2单位成本实现100Gbps的业务处理能力,这意味着,为了实现标准Switch芯片不能支持的L2-L4功能,我们可能需要多达20倍成本的业务卡才能实现这些功能。

➤ 事实上,今天的路由器、防火墙、NFV(Network Functionality Virtualization,网络功能虚拟化)在很多场景下,也在为了解决交换芯片并不容易实现的L2-L4灵活处理流程而不得不采用昂贵的计算资源来实现这些流程,也就是说,“支付20倍的实现成本”在一些特定的L2-L4需求和深度的L4-L7需求面前,是一个普遍的现象。

线路卡的未来

当交换机标准处理流程已经固化到ASIC之后,我们是否能够为新出现的L2-L4处理流程找到昂贵计算资源之外的低成本实现方案?能!答案就是可编程交换芯片。可编程交换芯片其实就是为了解决这样一种尴尬的场景而出现的新技术。可编程交换芯片通过使用高级语言灵活定义查表键值和处理流程,用和传统交换芯片同样的成本实现了(几乎)任意L2-L4的流程要求。

幸运的是,前端设备所有的L2-L4非标流程都可以得益于可编程交换芯片的灵活性,而不必支付比标准交换芯片更高的成本。当然,我们也可以看到,多业务路由器、防火墙和NFV里面相当一部分利用计算资源实现的L2-L4层非(Switch芯片处理流程的)标准能力,也完全可以由可编程交换芯片实现!更有甚者,L4-L7的部分内容特征识别和过滤也可以在可编程交换芯片中实现。

DPI是最具代表性的后端系统之一。为了便于说明问题,以下我们以DPI为例来讨论未来的架构。

DPI对芯⽚计算能⼒的要求

今天的DPI系统是一个对网络处理能力和计算能力都有很高要求的综合系统。一个典型的DPI系统需要具备如下技术能力:

➤ 报文的L2-L3过滤、缓存和重组

➤ 报文的L4-L7特征匹配处理

➤ 邮件、下载、网页内容的还原与搜索

➤ 运营商移动系统信令解码

➤ 视频和音频数据流的解码

➤ 用户身份分析和行为关联

由于前端设备和DPI往往被传统可视化系统的实现混为一谈,我们将DPI的技术能力实现方式用前端设备业务卡的四条技术路线进行一下适应性梳理:

从上述对比可以看出,基于FPGA和NPU的前端设备在DPI系统中已经失去了任何竞争优势,我们基本可以提前得出结论:在FPGA和NPU实现的前端设备上提供DPI,将给最终用户带来极大的投资损失;MIPS多核也许还会在一段时间内保持技术竞争力,但最终通用计算将成为DPI实现的重要选择。

DPI的未来趋势

➤ 随着HTTPS等加密流量的持续增加,特征匹配在大部分场景下将失去效果,机器学习将在DPI实现中扮演日趋重要的角色;

➤ 随着DPI系统部署规模的持续增加,应对流量潮汐现象的虚机调度也日趋重要;

➤ 随着DPI系统中对视频音频处理需求的增加,计算功耗的消耗更大幅增加,同时,报文对内存缓存和外存缓存的要求也日趋增加。

结合这些趋势,我们可以看到,采用MIPS多核处理器来解决DPI的问题,从短期来看,可以在L4-L7特征匹配和信令解码方面做到同等性能比X86更低的功耗,但是从长期来看,缺乏机器学习生态系统支持、缺乏虚拟机调度支持,缺乏大容量内外存储器,会让MIPS多核处理器在未来大规模部署DPI系统时,限制DPI的未来扩展能力。

机架式设备的限制

从上面逐步梳理分析来看,X86/ARMv64这样的通用计算CPU才是大规模DPI系统实现和部署的未来之路,那么,是否意味着将X86放到前端设备的机架中,就能为用户提供高集成度的DPI方案呢?答案依然是否定的。原因在于,机架有限的插槽空间会限制X86 CPU的选择,插槽空间小意味着对功耗要求的苛刻,意味着当前高端通用CPU很难在插槽中获得真正落地,意味着当系统需要GPU加速、需要内存和外存等大量缓存的时候,作为插槽单板的X86很难提供和独立服务器可以比肩的扩展能力。

当前我们知道,在正交或者ATCA中放置的X86 CPU,比主流服务器上的CPU落后两代,主频和核心数量也是主流服务器的70%以下,这样的X86 CPU,根本不足以提供DPI需要的计算性能。

成本是第另一个重要的问题。前端设备的机架插卡空间,每个槽位不仅仅意味着物理空间的成本,更意味着对机架交换板和电源成本的分担,这两者给本来就比通用服务器性能要低一半的X86插槽带来了一倍以上的成本增加。因此,用X86集成到前端设备中,放弃通用服务器低成本的横向扩展能力,这样的技术路线无法支持DPI的部署规模和功能特性持续演进。

未来DPI整体架构的判断

未来,试图整合DPI、存储和可视分析的一体化前端设备会随着网络可视分析系统规模的扩大而越来越无法适应业务可视分析对软件复杂度和系统规模的要求。相反,就像今天互联网服务商的业务全部云化、5G业务正在云化⼀样,随着通用计算CPU算力的持续提升,随着可编程交换芯片标准化和灵活度的持续提升,我们相信,业务可视分析也正在向“云”进行演化:

➤ 各种L2-L4的预处理和部分L4-L7的深度处理会被软件可定义、芯片可编程的智能可视交换机取代;

➤ 高密度I/O端口和灵活L2-L4层处理流程,并含有少量L4-L7内容特征识别过滤能力的“智能”线路卡将成为盒式智能可视交换机;

➤ 盒式智能可视交换机实现了80%前端流量的处理,还有20%前端流量处理,例如用户身份和数据面的关联、 报文会话重组、去重、(合法)解密等,会迁移到通用计算CPU中,以流量预处理NFV的方式实现;

➤ DPI流量分析则会进一步向后端系统迁移,形成混合了L7元数据生成、大数据分析与机器学习的DPI分析私有云。

最后,总结一下。

在Asterfusion的整体解决方案中,通过“智能可视交换机+流量预处理NFV”提供的VaaS(Visibility-as-a-Service,可视即服务)将会成为重要的IT基础设施之⼀;以VaaS为前端的可视化系统私有云,会按照标准私有云的建设方式,用通过SDN交换机互联的、可以大规模横向扩展的服务器集群来进行硬件基础设施的建设。此时,我们更欣喜地看到,无论是VaaS前端,还是可视化系统私有云后端,所有的基础设施都会被简化成智能可视交换机和标准服务器两种硬件。Asterfusion星融正是这样的简洁、归一、标准和优雅的软硬件开放系统的重要方案提供商。Asterfusion的开放软硬件平台将为可视化系统提供极具性能、成本和扩展能力优势的基础设施。

相关文章

了解云网络的十五年演进史,只看这一篇!


关注星融元


云中的网络自从诞生以来,一直就是热门话题。

2005年前后出现的、基于隧道技术的二层虚拟网络逐步部署和在生产环境中的验证,

云网络(更确切地说是虚拟化网络)才走上了相对正确的发展道路。

二层虚拟网络(Layer 2 Overlay Virtual Network),指采用隧道技术在底层网络上构建出来的供每个租户使用的虚拟网络。根据需求,每个租户可以拥有一个或者多个二层虚拟网络;对于租户的虚拟计算节点来说,运行在二层虚拟网络上并不需要满足任何特殊要求,与运行在标准的Ethernet/IP网络上并无二致。也就是说,原先的业务、工具、协议完全可以无差别地运行在这样的二层虚拟网络之上而不用做任何改动。

但是,云计算的本质(虚拟化、虚拟节点迁移、虚拟节点二层可达)却使得二层虚拟网络对底层网络提出了特殊的需求,而这些需求在传统的园区物理网络中是根本不需要考虑的。简单总结下来,这些特殊的需求包括:同一张物理网络承载多个租户的虚拟网络、租户的虚拟网络所用的IP地址空间可以重叠、属于同一租户的虚拟计算节点能够在物理服务器之间(即不同的物理交换机之间)迁移、虚拟计算节点迁移时不允许更改其IP地址等。

为了满足上述需求,云中的二层虚拟网络大致经历了如下几个发展阶段:

三层方案:三层架构的底层网络承载运行在服务器中的二层虚拟网络

三层架构的底层网络承载运行在服务器中的二层虚拟网络

这种方案中的底层网络完全沿用了园区网络的架构,从上到下分别是核心、汇聚和接入三层,因此称为三层方案。而二层虚拟网络的所有功能,包括VXLAN(Virtual eXtensible Local Area Network)和VTEP(VXLAN Tunnel End Point)及其相关功能,则完全运行在物理服务器内部的vSwitch上,底层网络只是被用作最简单的转发通道,以隧道的方式来转发物理服务器发送的二层虚拟网络流量,根本不用关心二层虚拟网络的任何细节信息。

二层方案-框式Spine:底层网络由三层架构进化为以框式Spine为核心的二层架构

底层网络由三层架构进化为以框式Spine为核心的二层架构

当性能瓶颈和可扩展性限制在三层方案中愈演愈烈时,二层架构的CLOS交换网络被引入到新一代数据中心网络的设计中来,底层网络由三层架构演进为二层架构。CLOS交换网络一般由两层交换机搭建而成,位于网络核心层的被称为Spine交换机,位于接入层、用来接入服务器的则被称为Leaf交换机(或ToR交换机,Top of Rack),Spine和Leaf之间则采用full-mesh全连接。这个时期的二层架构CLOS交换网络的Spine一般由两台(或多台,取决于Leaf交换机的上行接口数量)大容量的框式交换机(称为Spine交换机)承担,Leaf则是由具备48个10G接口和2-6个高速上行接口(40G或100G,向上连接到Spine)的1RU高盒式交换机承担。显而易见,这样的架构通过减少报文转发的跳数和在Spine/Leaf之间构建负载分担的多链路很好地解决了三层方案的性能瓶颈问题,也通过框式Spine的纵向扩展能力(Sale-up)在一定程度上解决了可扩展性的限制。在这种架构的网络中,二层虚拟网络仍然运行在物理服务器中的vSwitch上,底层网络依然只是被用作最简单的转发通道来转发物理服务器发送的二层虚拟网络流量。

二层方案-盒式Spine:二层方案的核心由框式Spine进化为盒式Spine

二层方案的核心由框式Spine进化为盒式Spine

云数据中心的规模越来越大,框式Spine和Scale-up终于也面临可扩展性有限和性价比太低的挑战,于是性价比更高的较大容量盒式Spine和横向扩展能力(Scale-out)被引入到CLOS网络的设计中。

在以盒式Spine作为核心的架构中,多个盒式Spine被部署在核心层,取代了原先的两个框式Spine,并且利用CLOS架构天然的横向可扩展性,为云计算带来了在交换性能、可扩展性、性价比几方面综合最优的底层网络。在这个方案中,二层虚拟网络依然运行在物理服务器中的vSwitch上,底层网络依然只是最简单的传送通道。

显而易见,在这三种方案中,二层虚拟网络都是运行在物理服务器内部,由vSwitch软件占用物理服务器CPU的计算力来模拟的,因此我们将这三种架构统称为“vSwitch方案”。而后,第四种方案出现了——硬件/EVPN方案,它最大的不同是:二层虚拟网络的功能开始从物理服务器向底层网络迁移。

二层虚拟网络的功能开始从物理服务器向底层网络迁移

  • 基于“硬件/EVPN方案”的云网络,采用高性能硬件平台构建底层Underlay网络;
  • 属于所有租户的二层Overlay虚拟网络从物理服务器的计算空间卸载到高性能的底层Underlay网络上,将被二层Overlay虚拟网络耗费的大量CPU计算力释放出来;
  • 使用MP-BGP EVPN为二层Overlay虚拟网络构建独立的控制平面,降低维护复杂度、提升系统整体效率。

“硬件/EVPN方案”的优点显而易见,它将二层虚拟网络中非常耗费计算力的功能从物理服务器迁移到底层网络的物理交换机上,让二层Overlay虚拟网络回归到底层Underlay网络的高性能硬件平台之上,不再大量耗费物理服务器CPU的计算力,因此其性能和效率显然优于“vSwitch方案”。

同时,“硬件/EVPN方案”采用高性能网络硬件平台实现封装、去封装等功能,进一步提升二层Overlay虚拟网络的整体性能。并且,独立的MP-BGP EVPN控制平面为二层Overlay虚拟网络提供多租户的路由空间隔离,隧道的自动发现和部署,数据平面广播的有效抑制。

从2005年至今,云网络一路发展演进到“硬件/EVPN方案”,云中的二层虚拟网络需求似乎已经得到了完美的解决。

只是,遗憾的是,二层虚拟网络对计算节点容量的巨大需求与Leaf交换机转发信息表项空间的局限性之间存在着不可调和的矛盾!

这对矛盾使得“硬件/EVPN方案”无法真正在生产环境中部署。先进的架构的确解决了云的性能问题,却也成为限制云的整体规模增长的瓶颈。

为了解决这对矛盾,Asterfusion(星融)为下一代云网络打造了全面创新的分布式架构——PICFATM,Protocol Infinity Cloud Fabric Architecture,协议无限云网架构。PICFA采用独创的分布式路由算法和与之相配合的转发逻辑,完全重构了云网络的控制平面与数据平面,彻底抛弃了传统网络中低效的集中式存储结构与转发逻辑,将云网络对云中虚拟计算节点的容量支持一举提升100倍至千万量级,同时大幅提升转发性能,使网络不再成为云计算容量的限制因素,从而为云网络从计算空间向底层物理网络的迁移打下坚实的基础。

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

分布式虚拟路由表

基于创新的整网FIB融合架构、协议无限的可编程能力、深度报文检测能力、开放透明的网络操作系统和统一开放的硬件平台设计, Asterfusion(星融)云网络将为云计算构建下一代高性能网络,将网络真正融合到云中,为我们在云网络之路上的探索翻开新的篇章,完美地解决大规模云数据中心的关键需求:

  • 底层网络容量Scale-wide扩展:每张底层网络可支持从768到4,096台物理服务器
  • 超大规模虚拟网络容量:每张底层网络最大可支持64,000租户和16,384,000虚拟计算节点
  • 丰富的接口类型:从10G光/电到400GQSFP56-DD
  • 线速交换性能:VXLAN隧道的封装与去封装和NSF的处理完全不影响交换性能
  • 丰富的NSF:包括L4LB、NAT、DDoS等最常用的NSF功能
  • 端到端的QoS能力:0丢包率、超低延时确保SLA
  • 应用可视化:基于深度报文头检测的网络遥测功能帮助云中关键业务优化运行
  • 与CloudOS的深度融合:可被CloudOS自动、集中管理,将DevOps扩展到网络

对星融元产品感兴趣?

立即联系!

返回顶部

© 星融元数据技术(苏州)有限公司 苏ICP备17070048号-2