感谢张卫峰老师辛勤付出。
今天讲的这些我基本不懂,需要多学习。
SDN对云计算网络很重要
当前OpenStack Neutron的问题
- SDN网络虚拟化方案一览
- OVS的子项目OVN介绍
- 盛科DVNP架构和应用场景
SDN不是一种具体的技术,而是一种思想,一种理念,一种体系框架。
核心诉求,让软件参与网络控制中,不是让路由协议参与网络控制,让应用参与网络控制。
为了满足这种核心诉求,就需要一种新的架构。

SDN的本质属性:
SDN的核心价值:
- 不在于能够解决传统网络解决不了的问题,而在于比传统网络做得更快捷、更可靠、更省力
如开通虚拟主机,让用户自主控制,不需要客服人员去操作;
- 不是让控制控制一切,而是让控制器去控制用户想控制的部分
如有些设备是数据转发设备,没必要控制器去控制;而有价值的部分才需要控制器控制。在云计算上控制器控制的是最边缘的控制交换机,不需要控制中间的物理交换机。
IaaS云计算网络将SDN的优势发挥到极致
IaaS云计算平台是标准的SDN架构
控制(云计算控制平台)与转发(虚拟或者物理交换机)
开放的编程接口(南向和北向都是开放的接口)
集中化控制(云集中控制所有设备)
可编程API
集中化控制
云平台获取全局信息
OpenStack网络架构
两种组网方式的比较
VLan
优势 :
简单稳定 高性能
缺点:
4KVlan限制
需要在所有物理交换机的所有端口上预配置所有Vlan
物理网络拓扑必须是大二层架构,难以处理更复杂的拓扑。
Tunnel组网
优点:
灵活性高,底层拓扑无关
租户数量可以达16M
缺点:
Encap/Decap带来的性能损耗
不方便将bare-metal server接入虚拟网络
Neutron当前的问题
J版本之前不支持DVR 分布式虚拟路由
J版本支持DVR,但不成熟、DVR用了大量name space,比较重量级,规模大了有压力。
Neutron自身对FwaaS、VPNaaS、Security Group等支持力度较弱
数据校验和错误处理不严谨,容易发生数据不一致
要基于VMwareESX/ESXi支持VPC,要么购买昂贵的NSX,要么用效率很低的方式来做。
SDN网络虚拟化方案一览
纯软件
Juniper Contrail
Vyatta(Brocade)
Nuage9ALU)
Midokura
硬件+软件
Cisco ACI
Centec
虚拟三层路由转发
集中式虚拟网关
OpenStack Juno之前版本
分布式虚拟网关
OpenStack Juno版本
NSX,Contrail,Centec等商业软件
半分布式虚拟网关
绝大多数宣称有VR的平台,如CloudStack,某些商业软件
分布式路由只管东西向三层,南北向还是要走集中网关
SDN网络虚拟化方案1:Neutron作为集中式控制器
Neutron拥有一切拓扑信息,通过plugin实时分发给相应计算节点Agent
Agent根据PACKET学习创建二层转发流表
Agent根据接收的拓扑信息操作kernel路由表,使用namespace做隔离
典型代理是OpenStackNeutron原生态网络
SDN网络虚拟化方案2:独立的集中式控制器
Neutron拥有一切拓扑信息,全部发送给独立控制器
控制器将转换后的信息发送给计算节点Agent
Agent根据控制器指令,proactive创建转发表
Mismatch的报文送到集中控制器去学习
典型代表是Juniper Contrail
SDN网络虚拟化方案3:分布式控制器
UTRON拥有一切拓扑信息,通过PLUGIN写到独立数据库
每个计算节点中的控制器向数据库服务器订阅本节点需要的数据
每个计算节点中的控制器reactive or proactivea创建转发表
Mismatch的报文在本地控制器学习
典型代表是盛科的DVNP(Distributed Virtualized Network Platform)
盛科的方案中,还可以支持硬件VTEP接入物理机
SDN网络虚拟化方案4:集中式控制器+硬件转发
Neutron拥有一切拓扑信息,通过plugin发给控制器
控制器将拓扑信息发到物理fabric网络(整个物理网络对外呈现为一个黑盒)
每台物理交换机里面的agent根据控制器发过来的信息,自行计算形成虚拟转发表,二层和三层
非虚拟化相关的物理转发表项由传统二三层协议形成
典型代表是思科的ACI
OVS 的子项目OVN介绍
OVN:Open Virtual Network
是OVS的开发团队新创建的一个subproject,
用来补充网络虚拟化环境中OVS缺失的功能
主要提供轻量级的控制面功能
不依赖于特定的OVS版本,以独立的进程运行
OVS提供什么:
原生态OVS仅仅提供:
Simple L2 protocol (NV不会使用)
OVSDB(NV 用它来配置resource)
OpenFlow(转发面功能,用来实现NV流表)
L2 Forwarding
现在的OpenStack Neutron仅仅用了OVS转发面功能
OVS需要由额外的agent来控制,参与网络虚拟化
OVS仅仅提供一个Virtual Switch,而OVN提供的是一个完整的Network,包括L2,L3,Security,QoS..
OVN工作原理:
提供一个OVN Plugin
提供一个轻量级的控制面
从Neutron plugin接受拓扑信息
配置OVS,直接在OVS kernel module实现,L2/L3/Security/QoS/Tunnel
支持NvGRE/VxLan/Geneve/STT
可以通过software VTEP接入物理机,也可以通过设备商的SDN交换机接入物理机。
OVN Architecture
OVN意味着什么
OVN还是初级阶段,但一旦成熟,所有商业化方案都会受到威胁
OpenStackDVR也可能被取代。
但网络虚拟化需要的东西远远超过OVN的work scope,
OVN缺少VPN,LB,运维管理等工具,仅仅提供了基础的网络二三层虚拟化功能
而且OVN可能不依赖于OpenStack
对比现有的OpenStackDVR
盛科DVNP架构和应用场景
DVNP:Distributed Virtual Network Platform
全分布式东西向二层Bridge和三层Route转发
全分布式控制器
严谨的数据一致性校验
高效的轻量级的kernel转发面设计
方便地支持虚拟机和物理机混合组网
不购买 NSX就可以支持VMware下的VPC
方便地支持多种hypervisor混合下的VPC
不依赖于任何云平台的任何版本
盛科DVNP架构:无硬件offload
DataFlow in Centec Agent(ingress)

DataFlow in Centec Agent (egress)

盛科DVNP架构:硬件Offload和硬件 VTEP

硬件Offload下的转发面流程

物理机和虚拟机混合组网
Centec cloud manager 提供Cloud Console 命令行和API
管理员通过Cloud Console命令行或者API动态增加、删除bare-metal server,分配local vlan,指定租户和network,并配置到SDN TOR Switch
SDN TOR Switch 将Vlan转换为相应的Tunnel VNI,反之亦然
SDN TOR 需要同时做Bridge/route to tunnel
一些别的实现方式:1虚1,安装OVS,使用docker,都不如使用SDN GW来得高效、简单、方便 。
使用VMware产品的用户面临的问题
市场有大量的存量VMWare产品,这些产品不支持VPC
VMWare 提供driver到OpenStack,但是仅限于legacy vDS支持(无法支持完整VPNC功能)
当前的一些解决方案:
要基于legacy VMWare产品支持VPC,必须能够控制它的vSwitch,但显然做不到。

基于SDN TOR 实现VMWare和VPC
整体架构参考DVNP:硬件Offload架构
云平台获取VM的主机、IP、Mac、local vlan,所属租户
云平台控制SDN TOR,将Local Vlan映射成tunnel,
可以使用OpenStack , 也可以在vCenter之上再包装一个平面。