OSF SDN在云计算网络虚拟化中的应用
感谢张卫峰老师辛勤付出。
今天讲的这些我基本不懂，需要多学习。
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之上再包装一个平面。