【编者的话】本文系SDNLAB微信直播群分享整理而成，分享者分享者许延伟博士分享的是开源SDN控制器DCFabric及云计算高效网络。

许延伟，博士，曾获得国家公派奖学金于日本名古屋大学留学两年。目前任上海宽带技术及应用工程研究中心（上海宽带中心）主任助理、网络集成实验室主任，自2013年主持软件定义网络（SDN）的研究工作，作为项目负责人或主持人承担了多个国家和上海市SDN相关科研项目，参与了CCSA等相关组织的标准制定。提出了基于SDN的大规模交换组网技术：SFabric，并领导了基于SFabirc的中国开源SDN控制器DCFabric设计与开发。

相较于其他开源SDN控制器，DCFabric具有以下的主要特性：
1）基于高效C语言，借助于高效的内存管理能力和多线程优化，DCFabric具有强大的拓扑发现（单实例>1000个交换机）、消息处理和流表下发能力（>100,000 OpenFlow流表/S）。

2）针对数据中心网络流量特点创新地提出了基于流表预先下发和流表聚合的SFabric算法，突破了物理OpenFlow交换机流表数量限制和通信路径建立的抖动等难题，从而实现了基于物理OpenFlow交换机的超大规模组网与高效交换。

3）架构简洁，南向接口只支持OpenFlow和OVSDB，基于四种基础服务，致力于云计算环境下的网络交换。

4）易于扩展，可方便灵活的进行系统定制，实现各种场景下的SDN应用。

当前主流的SDN网络中的流表下发方式主要有两种：前应式（Proactive）和反应式（Reactive）。由于在云计算环境下的NAT等功能的要求，反应式的流表下发是必不可少的。受制于OpenFlow流表下发的不确定性和并发性下发的复杂性，通信路径的建立常会出现由于交换机和控制器之间的多次Packet-in消息和流表下发的交互而带来的长时间剧烈抖动，且随着通信路径的增长而快速恶化。再加上交换机TCAM流表容量有限带来的限制，已有的云计算数据中心内的SDN方案一般采用基于传统交换网上的通道技术的OVERLAY网络方案：控制器只控制网络边界的虚拟交换机。这不仅会带来由于封包、解包所带来的性能下降问题，而且会导致在物理网络上的网络流量的不可视、不可控等问题。

针对上述两个问题，SFabric创新性的提出了“两步式”流表下发法和基于交换机ID的流表聚合，从而提高了控制器的效率和降低了流表数量。当控制器完成网络拓扑发现以后，SFabric首先每一个交换机分配一个唯一的Switch ID，然后会为每对交换机计算两条有向的通信路径。计算路径时主要有两个问题需要考虑：一是到同一个目的交换机的路径应该是收敛的，即到同一个目的交换机的所有路径应该是构成一个以其为根节点的树；二是出于流量均衡等因素，应该把所有的路径在整个网络拓扑中做到均匀分布。

计算好路径以后，控制器就会把路径信息以OpenFlow流表的形式装载到交换机中。由于网络中到每一个目的交换机的路径构成一个树，所以需要下发的OpenFlow流表只需要把目的交换机的Switch ID作为匹配字段即可。由于而不需要关心路径的起始点，所以所有交换机中的流表的个数最多只有n条，其中n表示网络中交换机的个数。因此，SFabric可预先构建好交换机级别的路由规划，从而为后续数据包的端到端单播路径建立做好提前准备。考虑到与其它现有OpenFlow交换机和网卡的兼容 性，SFabric推荐采用VLAN ID作为Switch ID存储字段。

图. 示例网络拓扑和SFabric流表

当SFabric构建好转发路径以后，系统就完成了初始化程序。由于网络中交换机之间的转发路径都已建立，当主机实际通信时，控制器只需在主机的接入交换机上下发对数据包进行打标签的一个流表即可。考虑图1中连接在交换机1和6上的两个主机Host A和Host B（其IP和MAC分别为IP_A、MAC_A和IP_B、MAC_B），当其需要通信时，SFabric首先查询其所对应的接入交换机的Switch ID分别是1和6，然后只需在这两个交换机的Table1分别下发如图中所示的两个流表来对数据包添加Vlan标签。

OverLay网络的主要缺点如下：

1）需要耗费主机的CPU资源进行数据的封包和解包过程

2）封包、解包的低效导致了VM的有限的网络吞吐量（

3）在物理网络上的流量的不可视带来的不可控问题

4）南北向流量都需要从网络节点通过带来的流量瓶颈问题

5）网络配置的复杂性带来的配置困难和低可靠性

为了能更好的发挥SDN在OpenStack中的应用潜力，避免Overlay网络带来的各项难题，我们提出了基于物理OpenFlow交换机和DCFabric的高效网络方案，其主要优点如下：

1）无须封包、解包带来的高网络吞吐量，10 Gbps环境下的虚拟机最大网络带宽可以达到9.3 Gpbs以上；

2）VM的南北向流量可以直接通过物理交换网转发，不仅南北向带宽可以达到线性速度，而且NAT、Floating IP和负载均衡等高级网络功能都可在控制器的统一调度下由交换机来实现；

3）基于标准OpenFlow协议，无厂商绑定，造价较传统网络方案可大幅降低，而且网络可动态线性扩展；

4）物理网络中流量可视带来的可管可控优势，可支持网络安全功能和流量工程等功能扩展，提高系统的灵活性。

Q1:这个控制器的安全机制有那些？
A1：暂时没有考虑控制器本身的安全机制。

Q2:你说的这物理openflow交换机可以介绍一下吗？

Q3:物理网络的流量不可视的不可控是怎么理解，边界网络性能强劲的话，这个不会影响?
A3：是指的在Overlay网络中，虚拟机的流量在物理交换网上不可视可控。

Q4:用vlan id代表一台sdn交换机的switch id，这个交换机就是跑vlan的，难免vlan id会出现一些冲突，为何不用交换机唯一的mac地址字段去代替switch id
A4：应该是用VLAN ID代表一台SDN交换机的ID，是用这个VLAN字段储存交换机的ID

Q5:您上面有说“为每对交换机计算两条有向的通信路径”，这里是指两条可行路径吗？ 然后根据负载均衡条件选择较优的那一条吗？~ 那么，我想问，预置两条路径的道理是什么呢？为什么不是三条或者四条？
A5：两条是指的每一对交换机之间的双向路径。

Q6：我想问一下 您说得流量不可控是怎么理解的？ 还有最后的仿真图上 sorth-north指的是什么 ？
A6：sorth-north指的是云主机和域外的主机通信的流量，即云主机和公网主机的相互访问。

Q7：你介绍的这个流表聚合方式应该不是你们首创的吧？
A7：这种在SDN网络中聚合方式我们之前没有发现过，它的主要思想借鉴了Trill协议

Q8：你好你说得首创的两步式流表下发有那些性能提高呢？
A8：主要是解决了通信路径建立时由于流表的下发没有成功反馈信息而导致的交换机和控制器之间的多次的Packet-in处理流程。

A9：如果数据包中本来是有VLAN Tag的，那么我们会多添加一个。在OpenStack环境中，子网等划分也不依靠VLAN。

Q10：请问一下SFabric中提出的出于流量负载均衡，然后将所有路径在网络拓扑中做到均匀分布，是动态的流量负载均衡还是只根据网络拓扑预先设定路径达到负载均衡？
A10：负载均衡是根据网络拓扑的

Q11：我觉得这个流表聚合有点像ospf，每个交换机到另一个交换机率先建立一条ospf路径，那么每个交换机最多只会有n个流表。（当然，这里并不一定非要是ospf路径，要考虑到全局均匀，只要是可行路径就行）我这里还是想问，这里是预设了两条可行路径吗？为什么呢？
A11：那个两条的意思其实是说双向的两条

A12：我们是通过增加一个vlan标签实现的，其实OpenStack里面是没有vlan的，只有子网

Q13：您好，我想了解一下流表下发的两种模式的，您说的SFabric也都俱备，只不过在主动下发的时候会进行进行流表聚合，尽可能的把多条路径都算出来，后续就算发生链路改变，交换机先前存储的流表也能找到相应的路径，除非变更后的网络找不到路径，才会进行反应式请求对么？
A13：前应式是指的交换机之间的路径的流表是预先下发的；反应式是指的主机通信时在接入交换机上下发的流表。

Q14：还有 刚才说的那个聚合方法也有问题，智能节省中间经由switch的flow entry数，对edge switch没什么效果。所以你们的edge还是以使用ovs为主是吧？

Q15：怎么解决的租户数量的限制吗？
A15：租户的控制是靠的控制器读取OpenStack的租户相关数据

Q20：这个交换机预设id的命名规则是怎么样的呢？ 根据mac地址吗？
A20：交换机ID是自定义的，只要保证不重复即可

Q21：你们的lb 怎么做的？
A21：目前还没有考虑同一对交换机之间的路径的lb

Q22：物理网络的流量不可视的不可控是怎么理解，能举例么？边界网络性能强劲的话，这个不会影响
A22：这里不可视不可控的意思是说 vxlan的流量全部为物理服务器的IP和MAC的流量，这个其实是没有限制的，如果用group流表来实现的话，但是目前我们还没有实现这个功能

Q23：流表聚合是怎么来聚合的，这个能详细介绍一下么？
A23：流表聚合的思就是说利用主机的接入交换机为依据进行路由

Q24：关于path control，你们两个node间，ecmp最大有几条？我好像看到你在讲解中说的是两条？
A24：两条是说为每对交换机计算双向的两个路径

Q25：那就是拓扑实际存在几条ecmp，就会构筑几条ecmp么？
A25：不是的，只计算一条

Q26：双挂两台ovs，单播流量和bum流量怎么走？

Q27：我说的那个知识产权是构筑多条ecmp。这个其实没有技术难度，为啥不做呢？
A27：目前还是人力有限，如果您有兴趣可以提供相关代码，欢迎贡献

Q28：研究这个问题的初衷是基于TCAM的数量不足还是控制器流表下发速度及控制能力不足呢？或者说，这两个问题，再以前的架构中，哪个问题表现的更明显
A28：当网络规模比较大的时候，这两个问题都比较严重

Q29：多条ecmp的话不就会增加流表项数目吗，这系统不是要尽量减少流表项吗
A29：可以用Group流表来实现，目前还没有支持ECMP。

A30：有主备的实现计划

Q31：vxlan是用vetp走的，用evpn传递vxlan信息，怎么和ip地址的多少有关呢？交换机流表不是256k么
A31：博通的芯片目前支持的TCMP的流表差不多是这个数量

Q32：SFabric交换机中的流表的个数最多只有n条，其中n表示网络中交换机的个数，这个聚合还是N条对吧
A32：这是指的聚合后的流表的数量

SDNLAB微信直播群定位为面向网络创新技术的爱好者及从业人员进行交流、学习、分享，吸引了来自高校、云服务提供商、互联网厂商、设备厂商、运营商等单位的从业人员近千人，每周会组织定向的技术及业界动态分享，如果你有需要分享的请加微信：联系。

浪潮成了“风口上的猪”，一个月内，股价翻倍。

5月底，一则消息被疯传：由于信息安全问题，中国政府要求国内金融机构放弃采购IBM，集体转向国产。浪潮似乎早就知道飓风要来，当天高调宣布"I2I"（IBM to Inspur）计划，对IBM主导的高端服务器市场发起正面进攻。

当这个通俗版的故事在资本市场炒得满天飞时，财新挑起了另一个技术版本的争论——“以阿里云去IOE”，阿里云也因此被推向风口浪尖。

“去IOE”的概念最早由阿里巴巴王坚提出。IOE是指IBM小型机、Oracle数据库和EMC存储设备组成的传统IT组合。在“去IOE”实践中，阿里成功以低成本的X86服务器，替代IBM小型机，并不再使用EMC存储。数据库则由开源My SQL和自研数据库OceanBase替代。这件事在IT界引起巨大震动。

长期以来，IOE等国际巨头对传统IT拥有绝对掌控力，在中国占据着千亿美金的市场份额，利益盘根错节。随着阿里云的商业化，阿里巴巴开始向全行业输出“去IOE”能力，倡导完全抛弃物理服务器，采用互联网化的云计算服务。

先看“去IOE”的三种技术路径：

从对IOE依赖度最高的金融机构来看，目前大银行离不开的是IBM的大型机和小型机。由于核心系统对性能和安全稳定性要求比较高，四大行几乎清一色使用IBM。浪潮最主要的产品是低端X86服务器，而单靠X86无法满足银行核心业务需求。大型机，国内尚无替代产品。小型机，浪潮K1是国内唯一取得突破的产品，但目前仅在邮政储蓄部门和建行新疆分行等极少数银行被采用。

最关键的是，IOE长期垄断标准，提供的是一整套解决方案。即使浪潮K1能够替代小型机，价格优势不大，现在也拿不出配套的整体解决方案。

国内也好，国外也罢。目前绝大部分所谓做云计算的公司，都是在用虚拟化技术对传统数据中心进行“云”化，也就是所谓的“私有云”。私有云厂商将VMware这样虚拟机软件，部署于企业现有或新建的数据中心，提供内部类似于云服务的消费与管理方式。这类厂商一般由硬件公司转型而来，通过“云计算”的概念卖硬件软件，IBM、思科、惠普、甲骨文、华为、浪潮、联想的云计算都是如此。

不可否认，私有云和虚拟化技术，确实能够在一定程度上提高原有数据中心的效率和灵活度，不过依然需要大量的前期硬件软件投资，部署周期没有明显降低，运维的难度和人员不减反增。此外，由于物理数据中心的硬件资源限制，私有云无法弹性扩展，解决不了某一时段的资源紧张问题。这种方式好比对蒸汽火车不断翻新，跟真正云计算时代的动车是两码事。

一篇中国移动IT人员撰写的文章，反映了这种“云”化的局限之处：

“早在五六年前，中国移动就着手研究业务支撑系统的云化演进问题。那时候虚拟化技术已经在系统中广泛应用。虚拟化技术能将大的计算资源切成小块，但这些切分出来的计算资源，能否重新组合形成新的计算能力，还有很多技术问题需要解决。倘若资源池内无法进行系统间的灵活调配，不但达不到提升整体效率的目的，反而可能导致系统效率降低。”

3.以云计算“去IOE”

云计算厂商底层采用低成本的X86服务器，部署去中心化的分布式系统。这个系统如同一张庞大的“电网”，不同的“电厂”（X86集群）向“电网”输送源源不断的计算能力，理论上可以无限扩展。企业不用自建数据中心，而是将业务系统部署在云端，“电网”根据企业需要输送计算和存储资源，数据库也由云计算厂商作为通用配置搞定。围绕这张“电网”，第三方解决方案提供商开发各种中间件和模板，帮助企业搞定软件和应用开发。

以亚马逊AWS和阿里云这样的云计算厂商为例。IT从一种硬件、软件产品，变成了一项互联网服务，按需索取。企业不用关心繁重复杂的IT运维；不用购买昂贵的存储设备做数据备份；不用考虑异地容灾而去搭建光纤网络；不用购买流量清洗和防火墙来抵御网络攻击；不用担心被硬件、软件开发商一次次绑架；不用抓破脑袋想到底该买多少服务器，才能满足2年后的业务需求。

针对“以云计算去IOE”的技术路径，业界的抨击主要集中在三点：

1.云计算稳定性难以达到金融机构的要求

这个主要得看云计算厂商的技术实力。从北美的经验来看，已经有约200家银行成功从大型机转为X86。在国内，目前尚无大银行的案例，不过已有不少小银行在采购阿里云的服务。

至于国内云计算厂商的技术实力，可以看看这两组数据：目前工农中建四大行每天各处理的业务量约为1亿笔，而2013年“双十一”支付宝交易为1.88亿笔,依托阿里云实现了零漏单、零故障。天弘基金“去IOE”迁入阿里云后,余额宝之前8个小时的清算时间缩短至30分钟。虽然这两个案例只是服务内部客户，但仍可证明阿里云在金融业务应用方面的性能和稳定性。用云计算为大银行去IOE，只是时间和认知问题，并非技术难题。

2.开放的云计算架构更容易被黑客攻击

很多人认为传统数据中心是封闭的，比云计算更安全。这个想法很天真，这个说法如果成立，除非数据中心是绝对物理隔离的。而事实上，如今非军方设施早已无法做到完绝对物理隔离。如果说网络攻击是一个巨大的战场，是自己建个堡垒安全，还是建立联合武装部队更安全？云计算厂商为企业提供统一的安全防护，黑客要想攻击某一个企业，得先把云计算厂商打垮。云计算相当于把钱存在银行，自然比家里的保险柜安全性更高。

如果说云计算不安全，美国中情局为何将订单给了亚马逊云计算，而不是IBM？

3.云计算的后期运维成本很高

这一点更难站住脚。真正的云计算，硬件、软件、安全、运维已经一体化了，全都作为服务内容打包出售。企业根本不需要关心IT运维的问题，也不用养IT人员。从综合成本来看，云计算解决方案的成本，不到传统IOE解决方案成本的四分之一。

“以云计算去IOE”，对现有的IT利益格局是颠覆性的，一旦推广开来，整个IT界的故事都得重讲。阿里推动“去IOE”，需要破的不是技术的局，而是利益的局。按照阿里惯用的手法，一定是高举高打，以足够震撼的社会事件形成破局之势。

阿里云真正的“罩门”，在于能否像当初做淘宝一样，快速形成云的生态体系，甚至把IOE从竞争对手变成合作伙伴。云计算是类似于电网的生意，未来必定是一家独大，基础设施由一家来做，其他厂商在上面做解决方案和软件应用。目前来看，站在阿里云阵营的有东软、中软、SAP，以及新生派的上海商派。但这些跟国外亚马逊的云生态比，还差得很远。

去IOE的“多米诺骨牌效应”一旦启动，阿里云将面临巨大的挑战，云计算解决Iass层面的问题后，Pass和Sass层面谁来接盘？目前阿里有8000名工程师，不过就算这个数乘以10，也远远满足不了需求。

关于云计算，你需要掌握的必备核心技术

来 源： 发布时间：08-13 点击次数：24