云杉网络主要帮助用户在云数据中心部署SDN解决方案,解决网络虚拟化、网络安全以及混合云管理的问题.
智囊团分享人：亓亚烜博士，毕业于清华大学自动化系，国内最早从事SDN技术研究的学者。曾在国际会议上发表论文20余篇，拥有中国发明专利3项和美国发明专利1项，深耕网络安全及SDN领域近十年，于2011年创立云杉网络并担任CEO。
大家好，我是云杉网络亓亚烜，名字不好读，叫我yaxuan即可。今天主要跟大家交流下SDN与网络虚拟化的东西。希望多多提问，我会分享云杉的实战经验。
云杉网络主要帮助用户在云数据中心部署SDN解决方案，解决网络虚拟化、网络安全以及混合云管理的问题。
SDN的出现，源于2006年的Openflow技术。那时候第一次可以用API（Openflow协议）直接控制交换芯片上的流表，使得很多依赖复杂网络协议的应用都变得可以简单有效实现了。
- SDN出现之前，网络行为的控制，需要通过网络设备上的控制平面实现，也就是CCIE们的考试内容。
- SDN出现之后，控制工作转移到了软件上，因此效率大大提高。但要用Software代替（部分代替）以前网络专家做的工作，对Software的要求就非常高。
因此，SDN从一开始，核心就在控制器设计上，如何设计控制器成为所有的秘密所在。
记得当年Nicira做的控制器，Onix，就有很多有意思的故事：
- 这个控制器可以卖代码，但是100w美金起；
- Google用了Onix；
- 曾经有一个持枪劫匪（据说是亚裔），入室抢走了Nicira的一台开发服务器。
控制器的价值和重要性可见一斑
从控制器的设计说起，主要是三点：
- 控制器能控制什么？
- 控制器能控制多大规模？
- 控制器如何保证控制质量？
第一：能控制什么，决定了SDN能实现什么。
比如能控制服务器上Hypervisor里的vSwitch，那么就可以实现虚拟机的隔离、安全等。如果还能控制接入交换机，例如ToR架顶交换机，那么就可以控制物理及虚拟设备。如果进一步能控制防火墙、IDS、AD、甚至传输设备，那么NFV和DCI也就能实现了。
第二：能控制多大规模。
通常，规模不能小，没有数千个虚拟交换机，或者数十个物理交换机，控制器的意义就不大。因为，人也能做好这些事情。因此，常见的都是面向数据中心或云平台的大规模部署。
规模大了之后，控制器负载会极速增加，一个交换机在特殊情况下，有可能每秒钟会配置1000次（实际生产环境中的结果）。那么上千个交换机就会有百万次的配置可能。这对控制器的冲击非常大。
因此控制器一定要设计成多层次，每层次多集群的部署。否则遇到特殊情况，例如新上机柜，或者断电重启等，控制器一旦不能及时处理需求，那么会产生大规模的网络震荡，严重影响业务运行。
第三：控制器的质量。
这个其实跟控制论有关，就是要通过反馈，消除震荡。分布式系统里，有最终一致性的说法，有些类似吧。控制器每发一条指令（每秒可能发上百万条），都有可能失效。失效的原因是控制网络抖动，交换机处理不过来，或者设备不可用等，情况非常复杂。
要确保控制器发出指令和最终系统状态是一致的，就需要一系列的反馈装置。这些反馈节点通常是部署在Hypervisor上及Switch上的App。这些反馈装置一样需要高可用，通常采用多层次实现，非常复杂。
开发控制器这么多年，大部分时间都用在这里了：）接下来，我继续讲SDN应用。
前几天在硅谷跟Insieme和PlumGrid交流。SDN在硅谷的看法是，It's done。也就是说SDN已经成熟了。创新空间在向上（业务）走，这也是云杉的发展方向。
这里总结下SDN的三类应用（都是硅谷验证过的）。
SDN第一类应用：网络虚拟化
就是给用户提供一个虚拟网络，也就是大家常说的virtual L2。这个用vSwitch，ToR等都可以做，VLAN，VxLAN都能实现。这个已经成熟。也就是说，就L2来说，各种解决方案都有了。但是有了virtual L2之后，就带来了两个问题：一个是网络服务问题，另一个是网络规模问题。
SDN第二类应用：网络服务
最近大家常讨论“上云”的问题。两种方法：
- 一种是应用上云，就是将应用改写成CNA（cloud native application），这个不是SDN要解决的问题，需要各类NoSQL，Docker等大神来做。
- 另一种就是如何将现有业务直接搬到云端，例如一个网上银行业务，搬上去之后，还要满足合规性需求。
这个难点在，现有业务通常都有网络服务，比如异构防火墙，以及所谓Service Chain的功能，但在Virtual Network中，这些功能的添加都变得非常困难。这里其实有很大的商业机会，云杉在做，一些传统安全企业也在做，硅谷则是类似vARMOUR，PlumGrid，Embrane等在做。OpenStack中也有Service Chain的提法，但很遗憾目前还没能商用，并且很难说是因为技术问题。
最近VMware等也提到了micro segmentation的问题，其实从某种方面来说也是在将ServiceChain的云端实现。
这里真正的创新，肯定不是用传统方法，具体需要很多努力才能真正解决未来的云中安全问题。
SDN第三类应用：网络扩展
这个问题最有意思。因为L2网络本身不能大，大了谁也吃不消，包括QFabric。凡是做大L2的产品，目前还没有看到在生产中部署设计最大规模（比如10000个万兆口）的例子。原因很简单，L2要广播，数学上不允许你搞太大。
但是，virtual L2其实可以做大，比如跨数据中心的virtual L2。做法就是，virtual
L2随用户的应用需求动态变化；同时结合vSwitch，ToR（VxLAN Gateway）以及SDN-transport，实现围绕业务的动态virtual L2。
最终实现的效果就是，在若干数据中心的Cloud Fabric （spine-leaf DCN + multi-channel DCI）实现成千上万个动态的virtual L2网络。每一个virtual L2网络的节点数不多（理性对待广播），但分布可以横跨多个数据中心，而且构建速度极快。
这样为用户带来的结果是：你不需要两地三中心，但你的每个业务都是两地三中心部署。
以上是从SDN最重要的三类应用的讲解。
- 其中，第一个已经Done；
- 第二个适合小公司创新来做；
- 第三个需要跟大玩家一起搞。
今天分享这些吧，希望能对大家有一点点参考价值，欢迎大家与我及云杉网络团队切磋交流。
问答环节：
问：我是搞SDN控制器开发和solution architect。关于刚才的分享有几个问题想请教下。第一个关于控制器，控制器有Proactive和Reactive两种方式，感觉你主要指的是reactive 是么？
答：Proactive是control命令，Reactive是监控（反馈）。Proactive系统和Reactive系统分开设计，不能有任何时序依赖关系。
问：这个没看明白。你是说Proactive和Reactive 打个比方，一个是主动rpc；一个是notification的意思么？
答：Proactive包括Openflow命令，VLAN、VxLAN配置，Port管理等，这个都是自上而下，义无反顾的：）packet-in等，即使有，一定要Hypervisor本地处理，不能进入Reactive环节。Reactive主要是做流表校验，流量统计等，反馈真实的交换机配置状态和运行状态给Controller。Controller根据Reactive的统计信息，React给交换机，这个是跟Traffic 转发完全无关的过程，就是要保证最终一致性。
问：这个Proactive和Reactive是针对控制器对交换机的流表下发模式吗？
答：不是，所有配置都是Proactive的。Reactive做校验以及一些其他重要功能，形成一个闭环。
问：请教下为什么CNA（cloud native application）应用不需要SDN呢？
答：CNA主要是开发者的工作吧，SDN在整个转化过程中，不是主要部分。
问：关于SFC，现在有两种倾向，一是用nsh sch做，一是裸包做，你觉得哪个比较合理呢？
答：我觉得Flow做靠谱，包做难度太大，莫不成把每台Hypervisor都变成防火墙？再加一个MIPS处理器？另外，在Virtual Network里，当信息足够的时候，未必需要传统的方式解决所有问题。
问：如果可以的话，云杉的控制器，大约每秒多少个flow？
答：每秒处理1M指令，单台x86，普通配置即可，因为可以分层+集群、负载均衡做。压力最主要来自Reactive那边，是对Flow的全貌的获取和分析。Proactive这边，本来就不复杂，而且还可以控制速度。一层主要过滤统计信息（来自Reactive），二层做分析。二层控制器是作为一个Configuration Tool 就是Mgnt层面的。所有Mgnt都在第三层，第二层在每个数据中心部署，最底层在每个Rack或Server部署。
转载自：云头条
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
