Quantum

Quantum把云网络抽象为三个组件：network segment,Ports,Virtual Interfaces(VIFs)。network segment代表一个接口互相通信的连接空间；Ports代表network segement的连接点，并且可通过配置定义支持何种接口、谁可以连接过来等。VIFs是虚机里的virtual network控制器、网络服务应用、或任何想要连接到netwrok segment 中的ports的内容。

为什么会有Quantum？

早期的网络是由Nova-network提供的，仅提供基础的网络服务不能满足多租户的网络隔离需求：对于多租户VLAN是唯一的选择，对于数据中心受4K VLANs的限制；实体简单的Linux桥接，没有Qos，ACLs和监控；网络控制节点是整个大型网络的瓶颈，容易出现单点故障。

实例    （图-不同租户和应用有不同的需求）  

    

Quantum提供了什么？

Quantum为其他OpenStack服务管理的接口设备（如,vNICs）提供network connectivity as a serviices(NaaS)。为OpenStack提供网络API，通过API管理OSI模型中的L2和L3，解耦了逻辑和物理的网络。

Quantum架构    （图）  

    

Quantum Server是一个通用的租户API，用来创建和配置虚拟网络；Quantum Server实现了Quantum API及其扩展，通过Network、subnet和port模型管理网络，并为每个port分配地址。Plugin隐藏了后端技术，交由云运营商来权衡选择哪种插件。Agent是一个守护进程来执行实际的每一个物理主机的网络配置。

Plugin agent运行在每个计算节点，连接实例到网络端口，DHCP agent在multi-host模式里，运行在每个计算节点（会有延时），用来控制DHCP服务器的启动和停止，维护DHCP配置。L3 agent 用来实现Floating IP和其他L3特性，如NAT，每个netwrok一个。

Queue用来加强每个quantum组件间的通信，DB用来保存网络模型。部署时DB服务和Queue服务可以与其他OpenStack服务共享。

    在生产环境中建议不要hack Quantum，而是使用Quantum API，自己权衡选用合作插件，并且最好能用Network control，嗯差不多有点SDN的样子了。    

Floating IP和 Router  

Floating IP 用来让外部访问虚机的；Router是用来为虚拟机。访问外网的，并且允许在不同subnets或netwrok的虚拟机互相能够访问到。

NameSpace隔离    （图）  

    

E版的OpenStack在租户的network和subnets里没有namespace共享，租户所有的接口和它们的IP地址、路由、防火墙规则和dhcp过程都在同一个“namespace”。

F版里的Namespace做了以下隔离：接口(网关接口和其他类似“tap”接口)不再出现在你的OS的配置命令,如“route”、“ip”、“ifconfig”里。防火墙/ NAT规则(Iptables规则)作为系统范围的规则也不会再出现在“Iptables "命令。DHCP接口同样不见了。

所以现在Quantum提供OpenStack网络API，通过API管理OSI网络模型中的L2和L3的功能，但现在在Dashboard中只支持L2，L3的管理只能通过命令行。目前支持的插件有Open-vSwitch、Linux Bridge、 OpenFlow (BigSwitch, Floodlight, NEC, Ryu, etc), Midonet (Midokura) 以及 NVP (Nicira /Vmware)。

OpenStack Quantum，OpenFlow和SDN

Quantum是OpenStack网络的抽象(API)，依赖于plugin把抽象的构建和管理网络映射到实体上。基于OpenFlow的网络系统可以通过plugin机制在Quantum抽象层（API）中实现。OpenFlow本身不提供网络抽象，由软件来实现OpenFlow协议；Quantum本身并不直接与switch通信，由plugin实现。这些软件组件可能是一回事，或者Quantum plugin可通过API（如Open vSwitch API）与基于OpenFlow cotroller通信。所以说Quantum不是SDN，但理论上只要有plugin就可以transform anything into SDN。

为什么会有Open vSwtich（OVS） plugin?

OVS检查配置和映射本地OVS环境和中央mysql数据库的一致性，直接Polls到本地OVS实例，通过配置流来实现逻辑数据模型。

Open vSwitch又是什么呢？它是一种软件实现的交换机，用于给一台物理机上的虚机提供虚拟网络服务，它的实现原理蛮简单，就是TUN，TUN其实就是linux内核提供的用于两个进程间交换数据用的。在物理机里的两台虚机实际上就两个进程。

Open vSwitch的目标，是做一个具有产品级质量的多层虚拟交换机。通过可编程扩展，可以实现大规模网络的自动化（配置、管理、维护）。它支持现有标准管理接口和协议（比如netFlow，sFlow，SPAN，RSPAN，CLI，LACP，802.1ag等，熟悉物理网络维护的管理员可以毫不费力地通过Open vSwitch转向虚拟网络管理）。

OVS插件包括两个组件：一个是Quantum服务运行时加载的插件，一个是每个计算节点运行的代理。由插件处理所有的API调用并存储网络数据模型和映射到数据库里，代理搜集配置信息和映射，直接与本地OVS实例通讯实现逻辑数据模型。

    你可以     Try it by yourself     。  

其实关键是这个项目是由Nicira发起和维护的，所有只是在Open vSwitch上实现物理交换机的现有功能，那绝对不是Nicira的风格。

虚拟网络绝不仅仅需要传统物理交换机已有的功能。云对网络的需求，使得Software Defined Network（SDN）越来越火。而在各种SDN解决方案中，OpenFlow无疑是最引人瞩目的。Flow Table + Controller的架构，为新服务新协议提供了绝佳的开放性平台，Quantum项目通过引入Open vSwitch，为Open Stack Network模块勾勒出“Connectivity as a service”的动人前景。