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

标签: 解决方案

新型数据中心建设中的“第三张网”——独立的流量采集网



关注星融元


在数字化技术日益普及的今天,计算力成为核心生产力,数据中心随之成为数字化时代的“新基建”,新型数据中心已经成为国家经济发展的重要命脉和关键基础设施。同时,数据中心面临的网络安全威胁也越来越多,运维精细化要求也在不断提高。

在这样的大背景下,政府、金融、电力、运营商、互联网等重点行业的数据中心除了部署串接的安全设备外,也部署了大量的旁路监测系统,如网络性能分析系统NPM、应用性能分析系统APM、回溯分析系统、网络流量分析系统NTA、安全态势感知系统、入侵检测系统、APT攻击检测系统、防病毒系统、数据库审计系统等。

不同类型的旁路监测系统往往来自不同的厂商,传统的部署方案往往采用各自独立的“点”状部署模式,形成一个个“安全烟囱”,不仅给信息资源的共享造成极大阻碍,也降低了各监测系统的工作效率,增加了建设和运维成本。

传统的分散“点”状部署模式

图1:传统的分散“点”状部署模式

传统的分散“点”状部署模式面临的问题主要体现在:

  1. 流量采集困难随着监测系统的增多,每个监测系统都需要业务网络交换机做流量镜像,而交换机镜像口一般不超过2个,从而导致新监测系统无法接入;并且随着镜像流量的增加,对业务网络交换机的性能也会有较大的影响。
  2. 扩展性较差由于各自独立的部署模式,当新增加前端监测链路或后端监测系统时,都需要重新进行网络规划,变成“拉链工程”。
  3. 资源无法复用各监测系统独立部署探针,完成去隧道、分片重组、去重、SSL解密等预处理需求,其中不少预处理功能需求是重叠的,从而造成重复建设和成本增加。
  4. 流量调度困难分散的部署模式,无法做到统一的流量调度,无法应对“护网行动”等紧急流量调度要求。

部署模式全新升级,痛点难点逐个击破

随着网络规模的扩展,传统“点”状部署模式正逐渐被抛弃,取而代之的是网络架构上的全新升级,通过建设统一的流量采集网,实现流量的统一采集、统一处理、统一分发。流量采集网的定位是统一的大数据采集和预处理平台,是继业务网络、管理网络之后部署的又一张专用网络,即“第三张网”。流量采集网的基本架构如下图所示:

星融元流量采集网的基本架构

图2:星融元流量采集网的基本架构

流量采集网采用CLOS网络架构,用户可根据采集点数量、流量规模、后端系统数量等灵活地调整网络规模,实现系统的平滑收缩/扩容。基于上述的流量采集网架构,该方案具备如下优势:

  1. 清晰的部署平面网络架构上进行了全新的设计,分成业务网络、流量采集网、监测系统三个清晰的部署平面,不同平面之间互不干扰,最大程度保障业务网络健壮性和安全性。
  2. 统一的流量采集每个监测点位的流量只需统一采集一次,之后可按需智能分发给各种监测系统,节约业务网络交换机的镜像口,降低对交换机的性能影响。
  3. 全采全监,按需调度流量采集尽量覆盖所有网络节点,实现全网无死角监控,让安全威胁无所遁形,全网覆盖,按需输出,针对不同的监测系统提供定制化的数据源。
  4. 一次建设,弹性扩展前端新增监测链路或后端增加监测系统时,仅需在流量采集网开通相应端口即可,无需重新的网络规划设计;基于CLOS架构,支持平滑的流量监控网的横向扩展,整体系统架构无需变动。
  5. 资源整合,降本增效流量采集网统一完成去隧道、分片重组、去重、SSL解密、打时间戳、报文截短等后端监控系统不擅长处理的预处理功能,替代各监测系统独立部署的各种探针,实现资源整合,降本增效。
  6. 集群管理,灵活调度借助于集群管理系统,实现统一的策略下发,为用户屏蔽复杂的策略分解和集群内的流量选路过程,实现了真正意义上的全网策略统一下发和灵活的流量调度,满足“护网行动”等紧急流量调度需求,提升了运维管理效率。

星融元提供的图形化管理界面

图3:星融元提供的图形化管理界面

相关文章

园区网络无线漫游的实现策略之分布式网关设计


关注星融元


什么是无线漫游?

无线漫游是指终端在不同AP覆盖范围之间移动且保持用户业务不中断的行为。

实现WLAN漫游的两个AP必须使用相同的SSID和安全模板(安全模板名称可以不同,但是安全模板下的配置必须相同),认证模板的认证方式和认证参数也要配置相同。

跨三层的无线漫游场景示意图

园区网络的无线漫游策略是为了解决什么问题?

在跨三层的无线漫游场景中,因为所在的IP子网发生了变化,终端不得不获取新的IP地址以适应新的网关,这势必会造成终端网络的断联。

  • 避免漫游过程中的认证时间过长导致丢包甚至业务中断。
  • 保证用户授权信息不变。
  • 保证用户IP地址不变。

传统的园区网络中最常见的无线漫游解决方案

方案1:尽可能将需要漫游的区域规划在一个二层网络里,由于同在一个子网,所以不需要再建立隧道去处理漫游后的数据报文流量,而是本地直接转发

方案2:通过在新旧网关之间建立隧道,把漫游后的终端流量通过隧道传输到原来的网关进行转发

方案1:同一子网下直接转发

AC只对AP进行管理,业务数据都是由本地直接转发

用户的数据报文到达AP后,不经过CAPWAP的隧道封装而直接转发到上层网络。AC只对AP进行管理,业务数据都是由本地直接转发
优势:数据流量不经过AC,AC负担小
问题:二层网络越大越不安全,这样的园区漫游有相当大的限制条件

方案2:建立capwap隧道转发

AC不但进行对AP管理,还是AP流量的转发中枢

业务数据报文由AP统一封装后到达AC实现转发,
AC不但进行对AP管理,还是AP流量的转发中枢。
用户的数据报文经过CAPWAP隧道封装后再由AC转发到上层网络。

优势:数据流和管理流全部经过AC,可以更容易对无线用户实施安全控制策略。
问题:复杂的配置和低效的流量转发路径。

转发模型特点
二层漫游直接转发由于二层漫游后漫游终端仍然在原来的子网中,所以漫游后接入的AP和AC对二层漫游用户的流量转发和平台新上线的用户没有区别,直接在本地完成直接网络转发,不需要通过隧道转发回原网关中转
二层漫游隧道转发由于二层漫游后漫游终端仍然在原来的子网中,所以漫游后接入的AP和AC对二层漫游用户的流量转发和平台新上线的用户没有区别,直接在本地完成直接网络转发,不需要通过隧道转发回原网关中转
三层漫游直接转发原AP和原AC之间的业务报文不通过CAPWAP隧道封装,无法判定他们是否在同一个子网内,此时设备默认报文需返回到原AP进行中转
三层漫游隧道转发原AP和原AC之间的业务报文通过CAPWAP隧道封装,此时可以将他们看作在同一个子网内,所以报文无需返回原AP,可直接通过原AC中转到上层网络

新一代云化园区:基于分布式的网关设计,高效实现园区无缝漫游

云化园区网络在全三层组网的基础上借鉴了云网中分布式网关的概念,即:在每一台接入交换机上运行统一的分布式网关,实现对上层业务无感知的终端无缝漫游。分布式网关的另一个好处是实现了终端(一般为服务器)通过网卡配置Bond双上行到不同的Leaf,无需堆叠和MC-LAG。

园区网络分布式的网关设计

  • 当移动终端发生漫游时,分布式网关的作用尤为重要,因为漫游后的接入Leaf上已经配置了网关信息,并且自动学习和同步了漫游终端的IP/MAC信息,因此漫游后的终端可以高性能的接入网络(所发信息无需再到一个“集中的网关”上去兜圈子),并且漫游过程中业务不断连(即确保不丢包,因为漫游后的接入Leaf上已经有了该漫游终端的所有信息);
  • 对于网络管理员来说,只需要在网络初始化时一次性配置好所有分布式网关的信息即可,无需在运行过程中动态调整,从而进一步降低运维的复杂度。

相关文章

新一代云化园区网络架构,根除网络广播风暴难题


关注星融元


广播风暴(broadcast storm)简单的讲是指当广播数据充斥网络无法处理,并占用大量网络带宽,导致正常业务不能运行,甚至彻底瘫痪,这就发生了“广播风暴”

当一个数据帧或包被传输到本地网段 (由广播域定义)上的每个节点就是广播;由于网络拓扑的设计和连接问题,或其他原因导致广播在网段内大量复制,传播数据帧,导致网络性能下降,甚至网络瘫痪。二层广播风暴问题会导致灾难性的网络故障。然而广播风暴的产生存在很多原因:

广播风暴产生的原因1:网段划分不合理

当网段划分不合理,很多设备处于同一个网段内,网络充斥了大量ARP、DHCP广播包,便很容易在园区二层域产生广播风暴,影响到正常的网络通信。

广播风暴产生的原因2:冗余设计造成的网络环路

交换机之间为了冗余、带宽提升或错误连接难免会产生一个封闭的物理环路;环路时,数据包会不断的重复传输,引发广播风暴。

广播风暴产生的原因2:网络病毒

一旦机器被感染依靠二层广播扩散的网络病毒,就会损耗大量的网络带宽,引发广播风暴。

广播风暴常见的解决方式

  1. 综合运用排除、替换和网线插拔等方法,一步一步地定位引发广播风暴的故障点,查出原因定向解决;
  2. 在交换机上开启广播风暴抑制功能(这需要交换机本身支持),避免因硬件损坏或链路故障导致的网络瘫痪;
  3. 在二层网络中应用破环技术,比如运行生成树协议(STP),通过一定的算法在逻辑上破坏网络中存在的环路
  4. 在局域网内部署防病毒服务器,并保持病毒库版本的实时更新。

新一代云化网络架构,极限压缩二层域避免广播风暴

借鉴云数据中心网络的发展经验,对园区网络进行云化改造是大家一致认同的解决方案。在星融元的云化园区网络解决方案下,我们选择用当前数据中心广泛应用的,极具扩展性的Spine-Leaf网络架构来搭建园区的全三层IP路由网络。

区别于传统园区的“接入-汇聚-核心”三层结构,在这种创新的全三层IP路由网络中,我们将L2的工作范围限制在接入终端和其所连接的接入层交换机端口之间。即在确保以太网能正常工作的前提下,最大限度地压缩L2区域,彻底消除以太网广播在网络中的传播,从而将广播带来的各种复杂度、脆弱性和安全风险彻底排除。

也就是说,每个接口就是一个广播域,终端之间二层隔离,因二层广播机制而产生的安全风险都将不复存在。

云化网络架构,极限压缩二层域避免广播风暴

避免使用生成树协议,释放交换机的大带宽能力

  • 利用Spine-leaf网络结构,星融元云化园区网络在物理上就是一个天然无环的网络,因此也不需要人为地阻塞掉一半的物理线路使其处于不工作状态,相较于同样规模的传统架构园区网络,无需浪费掉一半的线路资源,即,在同等线路带宽的投入下,云化园区网络可接入终端的数量是传统园区网络的一倍(或者,在同等接入终端数量的前提下,云化园区网络所需要投入的带宽资源是传统园区网络的一半);
  • 如前所述,借助IP协议的各种L3能力,无环的云化园区网络能够做到超大规模,网络中交换机的数量不再受STP的理论限制,几百台、上千台的交换机组成的云化园区网络能够接入几十万的终端,组建超大规模的园区网络;
  • 最后,当将网络中各种额外的复杂因素去除掉以后,整个网络的建设与运维难度都会大幅度降低,节省网络建设者的综合成本。

深入底层架构的全面变革,星融元发布云化园区网络解决方案


关注星融元


都在谈云化园区,你有多少受益其中?

园区网络正在逐步跨入万物互联的物联网时代,各类智能终端的爆炸式增长和数字经济下的创新应用对园区网络提出更严苛的要求。借鉴云数据中心网络的发展经验,对园区网络进行云化改造是大家一致认同的解决方案。

但是,市面常见云化方案思路多是围绕一个综合性的SDN控制器进行整个园区网络的建设——将原本很多复杂、繁琐的运维和部署工作集中在统一的控制器上,通过可视化Web界面完成整网的运维和部署。

这的确很大程度上简化了日常运维工作,不过变革还不够彻底——虽然对外呈现了一个光鲜亮丽的SDN控制器,但底层仍然是僵化、复杂、臃肿的传统网络架构。很多传统园区正在经历的麻烦事,例如复杂的安全策略增删、广播风暴定位、WIFI频繁掉线、网络扩容困难等等,在这般“云化”之后仍然存在,治标不治本。

传统云化园区网络与下一代园区网络的对比图

彻底的云化变革,将”精简“与“高效”根植于底层网络架构

星融元的园区网络云化思路侧重网络架构本身,针对复杂、臃肿的传统园区网络架构,我们用Spine-Leaf、Arp-to-Host、分布式网关等云数据中心领域先进的技术理念,对园区的底层网络架构进行了全面的变革。相较于传统组网方案,星融元的全三层横向扩展组网方案可降低园区建设运营成本40%以上。

星融元新一代云化园区解决方案架构图

01 效仿云网架构的物理网络

多级Spine-Leaf架构:破除网络性能瓶颈,网络更易扩展

传统园区网络的“接入-汇聚-核心”三层架构自下而上逐层收敛,层级越往上,设备性能要求越高。随着网络规模的不断扩展,整个网络的性能瓶颈将聚焦在核心交换机上。

在云计算和大数据旺盛的带宽需求驱动下,云数据中心网络早已转型为无阻塞的多级Clos结构(Leaf-Spine),而在当下万物互联的物联网时代,云化园区网络亦采用了早已成熟的多级Clos结构。

无阻塞的多级Clos结构(Leaf-Spine)

无阻塞的多级Clos结构(Leaf-Spine)

并且,随着园区规模的从小到大,这个多级的Clos网络能够从一级横向扩展至多级,使得网络能够接入的终端数量从几十个扩展到几十万个不等,并且,扩展的过程中原有的网络架构完全保持不变,新扩展的模块与原有模块架构完全一致,最大限度地降低了维护的复杂度。

多级CLOS架构下的园区规模扩展

多级CLOS架构下的园区规模扩展

全三层路由组网:压缩二层域,根除广播风暴

通过一系列技术手段,我们将二层广播域压缩至交换机的每一个物理端口。终端仅和其所连的接入层Leaf接口上的网关IP进行二层通信,网关负责完成后续的三层路由转发——这从根源上彻底阻断了二层广播风暴发生的可能性,也阻断了依赖二层通信的网络病毒的传播路径。

全三层组网

全三层组网

去堆叠/MC-LAG/STP:充分利用带宽,不增加运维难度

传统园区网络架构下,为避免网络环路引入了以生成树(STP)为代表的一系列防环协议,但其核心思想都是人为阻塞一部分端口,冗余下来的链路只能做闲置备份。虽然后来出现了堆叠、MC-LAG等新技术,但因技术原理复杂,给运维部门带来了额外的工作量和故障风险。

在星融元新一代云化园区网络下,多级CLOS架构是天然无环路的,配合轻量级的等价多路径路由(ECMP)机制,可以在保证最高链路利用率和最低复杂度的前提下实现组网高可靠。

CLOS架构天然无环路

CLOS架构天然无环路

02 更贴合业务的网络虚拟化

轻量级的路由隔离方案:轻松实现一网多用

在大规模的园区部署实践中,为了保证安全高效的网络环境,不同的业务类型或部门会有严格的网络隔离需求。传统的做法是通过ACL策略做访问控制,或者建立两张独立的物理网络,其代价就是巨大的配置和维护工作量,或者更高的建设成本。

在星融元的云化园区方案中,我们的思路是使用轻量级的虚拟路由转发(VRF)技术进行隔离,让多种业务可以复用一张物理网络。(对于超大规模、网络空间复杂且重叠的园区网络,也可以完全复制云网中主流的VXLAN技术方案)

一网多用

一网多用

接入层的分布式网关:更高效的无AC园区漫游

在跨三层的无线漫游场景中,因为所在的IP子网发生了变化,终端不得不获取新的IP地址以适应新的网关,这势必会造成终端网络断连。

传统园区网络一般是尽可能将需要漫游的区域规划在一个二层网络里,但二层网络越大越不安全;二是在新旧网关之间建立隧道,把漫游后的终端流量传输到原来的网关来转发,而这又导致复杂的配置和低效的流量转发路径,影响了漫游性能。

星融元云化园区网络在全三层组网的基础上借鉴了云网中分布式网关的概念,即:在每一台接入层交换机上都运行统一的分布式网关,并且自动学习和同步了漫游终端的IP/MAC信息。如此一来,终端漫游过程中既不会有业务断连,流量也无需到某个集中式网关上“兜圈子”。

园区网络分布式网关

分布式网关

03 软硬解耦的开放式网络

传统园区网络中各种私有的网络协议、沉重的机框设备搭载着封闭的网络操作系统、网络无法随着业务的发展进行灵活的调整。

星融元的云化园区网络是一个全面解耦的开放式网络,采用全盒式设备的精简组网模式,搭载以开源开放的SONiC为内核而设计的网络操作系统——AsterNOS

相关阅读:AsterNOS是一款怎样的网络操作系统?

  • 大容量全盒式单芯片交换机组网,高密度端口、高性能转发、端口类型丰富
  • AsterNOS提供容器化环境和丰富的可编程接口,助力网络功能二次开发,并可无缝对接网络控制器和云管平台

星融元的云化园区网络是一个全面解耦的开放式网络

相关产品一览

让用户从园区网络的云化转型中切实获益

园区使用者

  1. 上网更流畅、更稳定
  2. 跨楼层/楼栋移动,WiFi不掉线,体验类比4G/5G网络

园区网络工程师

  1. 除IP地址以外,同一层设备配置相同,开局自动部署上线,运维简单少背锅
  2. 网络环路、广播风暴以及复杂的STP/堆叠技术,统统不复存在

园区建设运营方

  1. 极简运维降低了运维技能要求和人才招聘难度
  2. 高可靠组网+100%带宽利用率,无广播风暴更省心
  3. 软硬解耦,自主可控,避免单一厂商锁定

相关文章

下一代园区网络,何必再有“堆叠”?


关注星融元


传统的园区网络中,企业和供应商多是使用盒式交换机和框式设备来构建网络。当他们意识到在某些情况下,框式设备过于昂贵而且不够灵活,各自独立的盒式交换机又不便于统一管理。于是,堆叠架构诞生了。

01 堆叠式架构,让人欢喜让人愁

交换机的堆叠架构自20世纪90年代提出,其部署价值有目共睹。

比如,简化管理。堆叠后的交换机可以被视为一个逻辑实体,具有统一的管理界面,简化了管理和操作。高可用性方面,堆叠系统可以将不同物理交换机的端口进行链路聚合,使得下行链路具备更高的带宽和弹性。堆叠系统在逻辑上虚拟成一台交换机,所以也不需要为避免产生环路而去人为阻塞线路。此外,可堆叠交换机给中小企业提供了一个成本更低的选择——既有与框式设备类似的可扩展性,但又能更灵活地按需付费。

不过,随着有线、无线和物联网设备的快速增长,这种架构在下一代的园区网络中逐渐暴露出不少缺点。下面这几点相信一线的运维人应该深有感触。

  • 厂商锁定。堆叠不是一个标准的协议,不同供应商的可堆叠交换机使用不同的电缆、连接器和软件,甚至同一供应商的不同交换机都不能混合使用。当堆叠中的交换机已经停止销售,但你却还需要进行扩展,那就必须整体更换。
  • 有限的扩展性和带宽。虽然我们能按需增加堆叠成员,但由于堆叠带宽的限制,大多数供应商限制了堆叠组内设备的数量。(有些供应商会提供双向的吞吐量数据,可能会让客户误以为拥有两倍于实际的堆叠带宽)
  • 堆叠分裂的风险。扩展或删除堆叠设备可能会导致服务中断,因为这个过程需要重新启动堆叠组下的所有设备。当故障或错误操作发生时,堆叠组可能分裂成2个或更多,导致业务受到影响。
  • 软件引起严重故障。运行堆叠技术会给交换机软件增加很多复杂性(例如堆叠组管理、分裂检测等)。在现实中,堆叠组内的多台设备高度关联,一损俱损,软件问题甚至可以导致整个堆叠组的瘫痪。
  • 物理拓扑结构受限。出于控制平面的时序要求和带宽的考虑,支持堆叠部署的交换机使用的是专有的电缆,这便把参与堆叠的交换机物理位置限制在了同一个机房甚至一个机柜内。

02 彻底抛弃堆叠方案,可行吗?

云计算发展的初始阶段,云计算网络架构是参照传统的园区网络来构建的。在市场需求和技术推动之下,云网络经历了20年的蜕变和升华——无论是整体网络架构还是在硬件设备、可扩展性、运维能力等方面,云网络都比传统网络更加先进。

如今星融元已将基于云的开放架构重新引入园区网。基于CLOS的Spine-Leaf架构保留了堆叠式架构的优点,同时也解决了其中的一些缺陷。

星融元的云化园区网络架构中,我们彻底的抛弃了堆叠方案,转而采用基于L3能力实现的一种可靠度更高、扩展性更强、但复杂度约等于零的方案。

堆叠架构对比园区Spine-Leaf架构

图1 堆叠架构对比Spine-Leaf架构

在这种方案下,不会有堆叠复杂的组网逻辑、纷繁的设备配置、脆弱的状态同步等机制——整个园区设备组网将如同一台具有成千上万个接入端口的超大型虚拟交换机,可以进行统一的运维管理

  • 接入终端并不需要为此方案做出任何调整,依然是通过两条(或多条)的线路、采用通用的Bond技术,上连到不同的接入Leaf;
  • 接入Leaf通过使用ARP学习、32位主机路由、BGP同步等功能,利用L3网络天然的高可靠、多路径能力,达到跟传统堆叠一样的效果;
  • 不涉及复杂的堆叠软件开发,因此系统的稳定性非常高,不会因为复杂的堆叠逻辑引入潜在的Bug;
  • 利用L3网络的ECMP负载分担能力,可以充分利用交换机之间的所有带宽传递报文,网络性能更高。
 堆叠式架构云化园区网络架构
部署1.堆叠电缆连接(或业务口连接+堆叠配置)
2.增强配置(分裂检测,负载均衡模式)
1. Spine层和Leaf层之间使用通用线缆连接
2.配置本机接口和peer信息
高可用性物理设备之间的链路聚合全三层网络,天然避免广播风暴和以太环路;运行BGP和ECMP;使用分布式网关设计
物理拓扑结构限制在一个房间或机柜内没有物理限制
管理堆叠组作为一台逻辑设备Spine-Leaf集群作为一台逻辑设备
软件升级需要堆叠组重启,有业务中断在不中断的情况下单独升级每个设备
扩展需要根据当前堆叠的网络拓扑结构进行设计(链形加入到两端,环形需要拆环)按照标准CLOS架构的扩展
接入可扩展性以48口交换机为例最大堆叠成员数为8
最大8 x 48 = 384个接入端口
[2层CLOS,48口交换机作为Spine]最大48 x 48 = 2304个接入端口
[3层CLOS,64口交换机作为3级CLOS的Spine]最大48 x 48 x 64 = 147456个接入端口

03 同样支持交换机“多虚一”,但配置更简单,扩展更灵活

在星融元的云化园区网络架构下,运维工程师仅需完成基础的网络连接和集群相关配置,即可建立起交换机集群。集群内的多台交换机也可虚拟成一台逻辑交换机——同层设备使用同一套配置文件模板,具有统一的管理界面,配置将自动同步到集群成员(与堆叠系统类似),新增设备仅需人工完成最基础的接线操作即可通过ZTP顺利上线。

园区网络优势:多台交换机虚拟成一台逻辑交换机

图2 多台交换机虚拟成一台逻辑交换机

在Spine-Leaf架构下,集群的规模可以非常大而不必担心堆叠带宽的问题。例如,在48口接入交换机的堆叠系统中,下行端口的最大数量是48×8(因为堆叠成员限制),但在星融元的云化园区网络架构中,这个数量可以很容易地扩展到48×48(Spine层也使用48口交换机),甚至在3层CLOS架构中是48x48x64(以64口交换机作为3级CLOS的Spine为例)。

园区网络:可扩展的多层CLOS架构
图3 可扩展的多层CLOS架构

04 同样实现高可靠,但网络更精简,带宽利用更充分

传统的园区网络为提高组网的可靠性并避免以太网环路和广播风暴等问题,部署了很多复杂的功能(如堆叠、MC-LAG、STP)。星融元的云化园区网络方案采用天然无环路的Spine-Leaf架构,全三层路由组网,全网链路基于ECMP多路径负载分担,在保证高链路利用率和低复杂度的前提下实现了组网的可靠性。

园区网络:全三层的组网

图4 全三层的组网

不仅仅是去堆叠,星融元云化园区网络解决方案还蕴含着多层次的创新点,从架构到建设到运维,我们基于开放云网理念和技术所带来的变革,都将帮助园区网络的拥有者和运营者架构极简、更可靠、更安全、更高性能的网络。

相关文章

替代IB交换机,如何选择数据中心100G低时延网络设备?


关注星融元


对比IB专网,基于以太网的 RDMA(或 RoCE)可能是目前性价比最高的方案了,我们唯一要解决的难题就是如何构建出一个无损以太网环境。CX-N系列超低时延交换机提供不输专用IB交换机的性能,可帮助构建承载RDMA应用的高性价比融合无损以太网。

2010年后,数据中心的业务类型逐渐聚焦为三种,分别是高性能计算业务(HPC),存储业务和一般业务(通用计算)。这三种业务,对于网络有着不同的诉求。

  • HPC业务:分布式计算集群,多节点进程间通信对于时延要求非常高
  • 存储业务:对通信可靠性的要求非常高,网络需要实现绝对的0丢包
  • 一般业务:规模巨大,要求网络低成本、易扩展

一般业务的需求,或许传统以太网还能勉强应付,但一旦面向的是高性能计算和存储业务,则实在难以为继。存储从硬盘驱动器(HDD)发展到固态驱动器(SSD)和存储类内存(SCMs),使得存储介质延迟缩短了 100 倍以上;算力也从通用CPU发展到各类支持并行计算的分布式GPU、专用AI芯片等等…反观网络却越发成为数据中心性能提升的瓶颈——通信时延在整个存储的E2E(端到端)时延中占比已经从10%跃迁到60%以上。

试想宝贵的存储资源有一半以上的时间是在等待通信空闲;昂贵的处理器,也有一半时间在等待通信同步…这滋味怎一个“酸爽”了得!

为什么如此虐心虐肺?——这可能需要从传统的TCP/IP协议说起了。
在典型的IP数据传输中,当网络流量以很高的速率交互时,发送和接收的数据处理性能会变得非常的低效,这其中主要有两个原因。

首先,处理时延高:TCP协议栈在收/发报文时,需要做多次上下文切换,每次切换需耗费5μs~10μs左右时延;多次数据拷贝,严重依赖CPU进行协议封装,协议栈本身就有数十微秒的固定时延。

其次,消耗CPU:TCP/IP还需主机CPU多次参与协议栈内存拷贝。网络规模越大,网络带宽越高, CPU在收发数据时的调度负担越大,导致CPU持续高负载。当网络带宽达到25G以上(满载),绝大多数服务器,至少50% CPU资源将不得不用来传输数据。

面对传统TCP/IP协议栈的低效,RDMA技术应运而生

这里我们不妨先回过头来看看数据中心网络流量传输的实际情形。

当前,越来越多的新兴业务应用建设于公有云之上。终端用户看似简单的一个访问行为,会在数据中心内部产生一系列连锁反应——数据信息在web应用服务器,大数据分析服务器,存储服务器、运营数据显示系统之间一通传递之后,最终才会将访问结果推送到终端,这就导致数据中心网络中的东西向流量剧增,甚至占据了80%的网络带宽,出现了大量的远程内存访问需求。

TCP/IP数据传输与远程直接内存访问的对比

与TCP/IP数据传输相比,远程直接内存访问(Remote Direct Memory Access, RDMA) 可以让数据直接从一台服务器的存储器传输到另一台服务器,无需中央处理器、CPU缓存的干预。这样不仅节省了大量CPU资源,同样也提高了系统吞吐量、降低了系统的网络通信延迟,尤其适合在大规模的并行计算机集群网络中应用。据测算,用 RDMA代替 TCP/IP 进行通信,使得网络化 SSD 存储的 I/O 速度提高了约 50 倍。

我们很容易注意到,应用程序执行RDMA读取/写入请求时的确是走了捷径,但是网络传输侧的压力却依旧存在。

云计算时代的数据中心不断抛出“既要又要还要”的复杂网络需求,有人曾经为此构建了类似这样的网络——

  • 低时延的IB(InfiniBand)网络:用于高性能的分布式计算网络
  • 无丢包的光纤通道(Fiber Channel)网:用于存储区域网络(SAN)
  • 低成本的以太网(Ethernet):用于一般的IP业务网

IB专网的架构图

各取所长,看起来很完美对不对?

非也!

IB专网和FC专网的性能很强,但是价格昂贵,是以太网的数倍。而且,两种专网需要专人运维,会带来更高的维护成本。

我们暂且拿IB专网细说一番:InfiniBand是一种封闭架构,交换机是特定厂家(目前主要是Mellanox)提供的专用产品。要构建这样的无损网络,服务器需要专用的IB网卡,专用的IB交换机,价格一般是普通网络设备的五到十倍,相应的还会带来配套设施成本增加(如线缆、模块、监控、电耗等);而且,IB是私有协议,无法做到与其他网络设备互通互访。另外IB 专网运维依赖原厂,故障定位困难,且解决问题时间较长,网络的升级也取决于Mellanox产品发布的进度,无法做到和业界统一。

存储网络(SAN)创建FC专网的情况也与之类似,尽管性能和扩展性都不错,但仍旧需要专用设备。

综合以上,无论从建设成本还是运维角度来看,上述方案都并非是一个最佳选择。

RDMA究竟需要怎样的网络?

RDMA各类网络技术的比较(via.ODCC智能网络无损技术白皮书 2021)

通过上表我们不难看出,基于以太网的 RDMA(RoCE)可能是目前性价比最高的方案了。这种情况下,我们唯一要解决的难题就是:如何构建出一个适合RDMA传输的以太网环境,让RDMA真正发挥出极致性能。

网络传输好比是快递运输。如果遇到了堵车,一定时间内运量就会大幅减少,运输效率大大降低,如果还不小心弄丢了包裹就需要重新发货,耗时更多。这就是我们常说的网络拥塞和丢包。

  • 一般来说,数据中心内部发生网络拥塞有如下技术原因:
  • 上下行非对称设计。网络设计通常采用非对称的方式,上下行链路带宽不一致(即,收敛比)。当交换机下联的服务器上行发包总速率超过上行链路总带宽时,上行口就会出现拥塞。
  • ECMP。数据中心多采用Fabric架构,并采用ECMP来构建多条等价负载均衡的链路,通过设置HASH因子并HASH选择一条链路来转发,该过程没有考虑所选链路本身是否有拥塞,所选择的链路流量饱和时,就会发生网络拥塞。
  • TCP Incast。当服务器向一组节点发起请求时,集群中的节点会同时收到该请求,并且几乎同时做出响应,从而产生了“微突发流”,如果交换机上连接服务器的出端口缓存不足就会造成拥塞。

丢包对网络数据传输性能的影响也是巨大,如下图所示[1] :0.1%的丢包率,将导致RDMA吞吐率急剧下降;2%的丢包率,会使得RDMA的吞吐率下降为0。

丢包对网络数据传输性能的影响

我们需要 “0丢包、低时延、高带宽”的无损以太网,但这绝非易事

  • 0丢包:会抑制链路带宽,导致低吞吐,同时会增加大流的传输时延;
  • 低时延:降低交换机队列排队,容易导致低吞吐;
  • 高带宽:保持链路高利用率,容易导致交换机的拥塞排队,导致小流的“高时延”。

云计算时代下,你需要怎样的数据中心基础网络设备?

从上述“0丢包、低时延、高带宽”三大要素出发,落到实际层面上便对承载云基础网络的交换机提出了以下具体要求。

1. 支持构建无损以太网的关键技术

  • 流量控制技术 – 用于解决发送端与接收端速率匹配,做到无丢包;
  • 拥塞控制技术 – 用于解决网络拥塞时对流量的速率控制问题,做到满吞吐与低时延
  • 流量调度技术 – 用于解决业务流量与网络链路的负载均衡问题,做到不同业务流量的服务质量保障。

星融元CX-N系列超低时延交换机,支持传输RoCE流量和面向数据中心的高级网络功能(如:PFC、ECN、ETS、DCBX),并通过PFC死锁预防机制、VLAG以及先进的拥塞控制算法等,帮助构建高可靠的无损以太网。
【演示视频在线观看:PFC、ECN…】

2. 设备本身具备尽可能低的转发时延

在设备转发时延方面,我们以采用业界领先的可编程超低时延交换芯片的星融元CX532P-N以太网交换机,对比Mellonox的SB7700 IB交换机进行了对比测试。
结论是:星融元超低时延以太网交换机的端到端性能,可全面超越IB交换机。

星融元CX-N系列与IB测试的数据对比图

3. 全盒式设备提供高密度接口,组网灵活易扩展

得益于高密度高性能端口的规格设计,我们可以从容地选用不同规格的CX-N系列云交换机搭建出Spine-Leaf架构*的两层网络,以实现大规模计算/存储集群的接入与承载。

Spine-Leaf架构相对传统三层组网架构,具有无阻塞转发、可扩展性强和网络可靠性高等优势。而且在这样的网络架构中,任何两台服务器之间的通信不超过三台交换机,进一步降低了网络流量的转发时延。

CX-N系列产品的规格表

4. 存储+高性能计算+一般业务三网合一,SDN智能运维

存储+高性能计算+一般业务三网合一,SDN智能运维

(此外值得一提的是,CX-N系列超低时延交换机搭载的是星融元为云计算时代设计开发的开放网络操作系统,它以标准的Linux、SONiC和SAI为内核,可与第三方云管平台无缝融合,并且提供Cisco风格的命令行;该交换机的硬件平台也全面遵从OCP所制定的开放性原则,涉及的技术标准和开发规范完全开放,确保用户拥有的是一个完全透明的开放系统。)


[1] Zhu, Y., H. Eran, D. Firestone, C. L. M. Guo, Y. Liron, J. Padhye, S. Raindel, M. H. Yahia and M. Zhang,Congestion Control for Large-Scale RDMA in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication (SIGCOMM ’15), London, United Kingdom, 2015.
[2]https://www.odcc.org.cn/download/p-1437654565852237825.html ODCC智能无损网络技术白皮书
[3]https://info.support.huawei.com/info-finder/encyclopedia/zh/%E6%99%BA%E8%83%BD%E6%97%A0%E6%8D%9F%E7%BD%91%E7%BB%9C.html
[4]https://blog.csdn.net/SDNLAB/article/details/88746460

相关文章

星融元企业级SONiC创新实践分享


关注星融元


9月19日,2020 SONiC产业生态研讨会如期而至,大会邀请了来自微软、思科、英特尔,三大运营商、BAT等芯片公司、白盒厂商、互联网等国内外知名企业的行业大咖,共话SONIC产业生态。作为国内SONiC研究团队里的中坚力量,星融应邀出席本次大会,并由公司副总裁李明玉先生做了主题为《企业级SONiC创新实践》的精彩分享。

01.日趋繁荣的SONiC产业和生态

SONiC全名Software for Open Networking in the Cloud,由微软于2016年正式发布的基于Debian GNU/Linux可以运行在多家网络设备上的开源交换机操作系统,主要用于数据中心交换机。

SONiC经过几年的发展, 已经成为在云计算领域生命力非常旺盛、极具发展前途的开源社区之一。开放的基因注定吸引大量的产业链合作伙伴,形成了从最低层芯片到最上层大规模用户的全面的生态系统,这个生态系统正在从硬件芯片、系统架构、系统集成、大规模应用等各个层面促进 SONiC 的发展与成熟。该产业链在很多场景下并不是串联的关系,而是进一步解耦产业链的过程,最终实现一个更好的经济成本,以及更快的迭代速度。

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

作为新一代云网络供应商的星融自成立之初就正式加入了 SONiC 社区,成为国内最早参与 SONiC 社区的云网络公司之一,秉承开源、开放的精神,星融积极回馈 SONiC 开源社区。

星融是唯一提供企业级SONiC发行版的厂商
https://www.nextplatform.com/2020/05/12/is-microsofts-sonic-winning-the-war-of-the-noses/

通过上图可以看出,在这些为社区做出贡献的企业中,星融是唯一提供企业级SONiC发行版的厂商,星融贡献的这些commits,都是实实在在的缺陷修复和优化,除了SONiC,在LFN/FRR等相关开源生态也有星融贡献的身影。

02.星融基于开源NOS的探索历程

从第一个面向开放网络架构的开源网络操作系统–OpenSwitch(OPS)到现在的SONiC,开源NOS走过了曲折的开拓之路。星融一直是开源的参与者和推动者,自2014年AsterNOS1.0诞生,经过三年的孕育和成长,如今的AsterNOS已经发展到第三代。AsterNOS3.0 构建在标准的 Linux 内核与 SONiC/SAI 之上;基于 SONiC 提供的标准功能,星融为 AsterNOS开发了增强特性,并研发了一系列支持AsterNOS运行的硬件平台,帮助企业搭建全开放的云网络架构。

星融基于开源NOS的探索历程

03.企业级的SONiC发行版介绍

云厂商只是把SONiC作为生产环境的操作系统,但是作为企业级产品的AsterNOS3.0,则是服务于各行业客户,这就决定了AsterNOS的设计理念不同于云厂商,主要表现在四个方面:

1、客户需求导向:面向不同行业使用场景,理解不同客户的需求差异性,合理规划,快速响应。

2、产品品质稳定:友好的使用体验,完善的质量保证机制,在全生命周期交付中,质量保证一致。

3、兼容性:版本迭代上,特性能够向前兼容,与社区同步发展;面对不同芯片平台,能够合理兼顾芯片差异化和特性兼容性

4、提供持续的交付能力和服务能力

AsterNOS支持VXLAN & EVPN开发

围绕开源做商业产品,去满足企业用户的不同需求,并不容易,从系统选择到持续快速迭代,对技术要求都很高,然而星融做到了,并努力做到更好。

网络虚拟化(网络Overlay)的特性,是星融基于SONiC平台开发中,面临的第一个大需求,包括VXLAN & EVPN等技术,行业对网络Overlay的关注持续增加,但开源解决方案迟迟没有跟上,不能满足用户实际需求。一方面是社区网络虚拟化发展的缓慢,一方面又有需求的强烈呼唤,尽管考虑过巨大的研发投入之后存在与社区融合困难的风险,但是星融还是坚定地选择了自研,并克服了困难重重,最终实现全部需求。事实证明这是正确的决定,因为直到现在,网络overlay在社区进展仍然缓慢,L2VXLAN、隧道管理、EVPN等特性仍不完善。

AsterNOS VXLAN & EVPN实现方案

AsterNOS VXLAN & EVPN实现方案

AsterNOS和社区版SONiC现状对比

AsterNOS和社区版SONiC现状对比

AsterNOS上REST API的实现

2018年星融先于社区支持REST API

AsterNOS REST API和社区mgmt-framework的融合

从实践中得到的一些经验总结

  • 结合SONiC社区路标,合理规划,自研还是同步社区
  • 自研特性要在方案上考虑未来如何与社区方案融合
  • 不要忽视芯片SDK适配的风险和工作量,特别是芯片强相关特性
  • 长周期项目,注意关注社区相关动态,及时同步,避免分叉
  • 合理制定企业版和社区版的发行和同步策略

04.构建企业级SONiC,需要站在服务全生态的高度

开放网络操作系统为行业的创新提供了技术基础,帮助各大云厂商陆续搭建起开放的云网络架构,更好地满足业务需求,与此同时,网络产品和解决方案的交付模式也发生了变化(详见下图):

服务全生态的示意图
新型模式需要一种新型的技术供应商,能够服务全生态 ,正如星融这个可以信赖的合作伙伴,秉承开源开放的合作理念,和社区、合作伙伴相互促进,共同发展,共同成长。我们知道,网络设备开发是相对小众的技术领域,需要专业的软硬件的技能、开发经验和管理能力,星融多年的沉淀,已经打造了这样一支专业、全面、可靠的团队,他们对行业需求理解透彻,轻松驾驭硬件、芯片的设计开发,活跃在各大开源社区/生态并积极做出贡献,具有全面的支持能力。构建企业级SONiC,星融一直站在服务全生态的高度。


多年的积累,持续的创新,国内企业在SONiC生态实践的探索道路上,星融始终是一支重要的可以依赖的力量。依托“完善的软件架构+ 完备的硬件系列 + 完整的解决方案”,星融匠心打造的全生态解决方案能够帮助企业更好地使用SONiC,构建开放的云网络架构,做好底层的基础设施建设!

完善的软件架构+ 完备的硬件系列 + 完整的解决方案

相关文章

对星融元产品感兴趣?

立即联系!

返回顶部

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