Tony Ding's Blog
Keep Learning
最近在学习Neutron，本文的目的是从整体角度来梳理一下思路和并作备忘，本文就OpenStack Neutron的发展及基本架构作一个简单总结分析，并不涉及Neutron具体的技术细节，随着工作学习的深入，会分享总结一些具体的技术细节讨论帖。 openstack网络架构发展 OpenStack的网络最初是由Nova-network来提供的，租户间的隔离采用VLAN技术。在2010年OpenStack第一个版本Austin正是发布时，Nova-network便已作为正式组件发布，起主要功能是为虚拟机提供私有IP和浮动IP，通过IPtables和Ebtables提供安全功能，为网络管理提供三种网络模型：Flat Network、Flat DHCP Network和VLAN Network。Nova-network的网络里，物理机上同一租户的虚拟机通过Linux Bridge与服务器的物理网卡相连，以此来将数据信息发往外网或其他服务器上虚拟机，每个租户至少占用一个VLAN隔离域，租户内的虚拟机如果通过DHCP获取IP，必须有对应子网的Dnsmasq进程。 Nova-network的优势是拓扑简单、报文转发流程少且转发效率高等优势，但也存在功能较少、只支持二层转发、不便于扩展、不支持重叠地址的多个私有网络、不能提供高级网络服务，隔离方式只支持VLAN，没有提供VXLAN和NVGRE的成熟可用方案。 OpenStack在Diablo版中Quantum以发展项目的形式首次出现，在Essex版中有了试用版的Quantum，直到Folsom版本Quantum才正式发布。在G版本中，因为名称Quantum已经被一个公司注册，所以在H版本中更名为Neutron，现在我们发现，OpenStack的文档中很多命名都还是基于Quantum命名的，如qr-xxx,qvbxxx等，其中q即quantum的缩写。 Neutron 网络架构 上图（引用2）很好的表达了neutron的架构。Neutron只有一个主要的服务进程neutron-server,它运行于控制节点，提供RESTful API作为访问Neutron的入口，neutron-server接收用户的HTTP请求，最终由遍布于计算节点和网络节点的各种Agent来完成。 Neutron提供众多API资源对应Neutron的网络抽象，其中L2的抽象network、subnet和port被认为是核心资源，其他层次的抽象，如router以及其它高层次的服务则被定义为扩展资源（Extension API）。 为了更容易扩展，Neutron以Plugin的方式组织代码，每一个Plugin支持一组API资源并完成特定的操作，这些操作最终由Plugin通过RPC调用相应的Agent来完成。这些Plugin又被做了一些区分，一些提供基础二层虚拟网络支持的Plugin成为Core Plugin，它们必须至少实现L2的三个主要抽象，管理员需要从实现的Core Plugin中选择一种。Core Plugin之外的其他Plugin被成为“Service Plugin”，如提供防火墙服务的Firewall Plugin。在H版本中Neutron实现了一个ML2 Core Plugin，它采用了更加灵活的结构进行实现，通过Driver的形式可以对现有的各种Core Plugin提供支持，ML2 Plugin的出现意在取代目前的所有Core Plugin。 Agent一般专属于某个功能，用于使用物理网络设备或一些虚拟技术完成某些实际的操作，比如实现router具体操作的L3 Agent。 Neutron中Core Plugin完成二层网络隔离的相关配置和实现互通性的虚拟机的报文转发，现在的种类很多，使用时只能选择一个。另一种Service Plugin主要实现三层网络功能以及三层以上的业务应用功能，如Meter/Router/FWaas/LBaas/VPNaas等，每种应用的底层Service Plugin也可能会有多种，基本只能选择其中一个来使用。Neutron支持的Core Plugin举例如下： - Open vSwitch Plugin - Linux Bridge Plugin - Cisco UCS/Nexus Plugin - Cloudbase Hyper-v Plugin - Nicira Network Virtualization Platform Plugin - Brocade Neutron Plugin - Big Switch Controller Plugin - NEC OpenFlow Plugin
24 Aug 2016 #OpenStack #Neutron
什么是Open vSwitch 官方对Open vSwitch(OVS)的含义是这样说的： 顾名思义，Open vSwitch即开放虚拟交换标准！具体点说，Open vSwitch是在开源的Apache2.0许可下的产品级质量的多层虚拟交换标准！它旨在通过编程扩展，使庞大的网络自动化（配置、管理、维护），同时还支持标准的管理接口和协议（如NetFlow， sFlow， SPAN， RSPAN， CLI， LACP， 802.1ag）。总的来说，它被设计为支持分布在多个物理服务器，例如VMware的vNetwork分布式vSwitch或思科的Nexus1000V. 在虚拟环境下的虚拟机之间进行的网络行为，包括内网通信、外网通信、QoS服务、安全监控和管理部署等，都给网络设计和运维带来了困难，因为VM之间的流量在服务器内部，并不是所有的流量都到服务器之间的物理交换机上；此时Open vSwitch的出现给这些问题的解决带来了希望，因为Open vSwitch不仅支持LAN/VXLAN/NVGGE等隔离方式，并且支持QoS服务和SFLOW等监控功能,并且还支持OpenFlow协议。 Open vSwitch的产生与发展 要追溯Open vSwitch的产生就不得不提Openflow和SDN，即Software Defined Networking，软件定义网络。随着互联网的发展，今天的互联网业务对互联网提出了越来越高的传输质量要求，针对如何修改网络来满足新业务的需求，出现了改良派和革命派两种不同的做法。改良派提议在原有基础设施的基础上增添新的协议，而改革派认为需要推到一切重来。OpenFlow就是改革派提出的一种新型网络交换模型，通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，是网络作为管道变得更加智能，OpenFlow协议给网络带来可编程的特性，大大增加了网络的灵活性。后续会专门开一篇帖子来学习讨论openflow协议。 2006年，SDN诞生于美国斯坦福大学Clean State项目，该项目的最终目的是要重新发明英特网，当年，斯坦福大学的学生Martin Casado领导了一个关于网络安全和管理的项目Ethane，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制。受此项目启发，Martin和他的导师Nick McKeown教授(时任Clean Slate项目的Faculty Director)发现，如果将Ethane的设计更一般化，将传统网络设备的数据转发(data plane)和路由控制(control plane)两个功能模块相分离，通过集中式的控制器(Controller)以标准化的接口对各种网络设备进行管理和配置，那么这将为网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。于是，他们便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus Networks的论文，首次详细地介绍了OpenFlow的概念。该篇论文除了阐述OpenFlow的工作原理外，还列举了OpenFlow几大应用场景，包括：1)校园网络中对实验性通讯协议的支持(如其标题所示);2) 网络管理和访问控制;3)网络隔离和VLAN;4)基于WiFi的移动网络;5)非IP网络;6)基于网络包的处理。当然，目前关于OpenFlow的研究已经远远超出了这些领域。 Martin Casado Open vSwitch是一个有Nicira Networks（已被VMWare收购）主导的开源项目，Martin Casado正是Nicira创始人之一及CTO，并且Open vSwitch源码的第一个Commit正是Martin Casado作为程序员提交的，这个Commit也奠定了多年以后开源云计算平台中最受欢迎而且也是部署最为广泛的开源虚拟交换机。需求决定产品，正是由于在企业级云中，需要各种丰富的网络功能，VMware才于n年前就推出了vSwitch、vDS等虚拟交换机。正是看到了云中的网络是一块大市场，Cisco才与VMware紧密合作，以partner的形式基于VMware kernel API开发出了自己的分布式虚拟交换机Nexus 1000V（功能对应于VMware的vDS）。可惜的是，这两款产品都是收费的。Citrix倒是基于Open vSwitch快速追赶，推出了自己的Distributed Virtual Switch解决方案，但是不好意思，也是收费的。开源云的标杆OpenStack在2011年下半年推出了一项宏大的计划，启动了Quantum项目，志在通过引入Open vSwitch，为Open Stack Network模块勾勒出“Connectivity as a service”的动人前景。也正是基于Openstack社区的快速壮大，open vswitch成为了虚拟交换的真正标准。 Open vSwitch架构 该图简单但很好的展示了Open vSwitch的结构框架，Open vSwitch支持OpenFlow协议，上层可统一接收SDN控制平面及OpenFlow控制器的指令。Open Switch定义了一系列Flow Table，通过它来控制包的流向和结构，open vswitch对外提供统一的南向接口，可以接受外部控制器下发的流表，也就是说Open vSwitch是可以被远程控制。Open vSwitch内部分为用户和内核两层，即所谓的用户态和内核态。 用户层（态）
10 Aug 2016 #Open vSwitch