感谢张卫峰老师辛勤付出。

今天讲的这些我基本不懂,需要多学习。

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之上再包装一个平面。



Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐