How Neutron Virtualizes Network

1、WHY 为什么要网络虚拟化

• 1. 数据中心的现有网络不能满足云计算的物理需求；
• 2. 数据中心的现有网络不能满足云计算的软件化即SDN要求。

1.1 现有物理网络不能满足云计算的需求

• （1）大容量的MAC表项和ARP表项
  虚拟化会导致更大的MAC表项。假设一个互联网云计算中心的服务器有5000台，按照1:20的比例进行虚拟化，则有10万个虚拟机。通常每个虚拟机会配置两个业务网口，这样这个云计算中心就有20万个虚拟网口，对应的就是需要20万个MAC地址和IP地址。云计算要求资源灵活调度，业务资源任意迁移。也就是说任意一个虚拟机可以在整个云计算网络中任意迁移。这就要求全网在一个统一的二层网络中。全网任意交换机都有可能学习到全网所有的MAC表项。与此对应的则是，目前业界主流的接入交换机的MAC表项只有32K，基本无法满足互联网云计算的需求。另外，网关需要记录全网所有主机、所有网口的ARP信息。这就需要网关设备的有效ARP表项超过20万。大部分的网关设备芯片都不具备这种能力。
• （2）4K VLAN Trunk问题
  传统的大二层网络支持任意VLAN的虚拟机迁移到网络的任意位置，一般有两种方式。方式一：虚拟机迁移后，通过自动化网络管理平台动态的在虚拟机对应的所有端口上下发VLAN配置；同时，还需要动态删除迁移前虚拟机对应所有端口上的VLAN配置。这种方式的缺点是实现非常复杂，同时自动化管理平台对多厂商设备还面临兼容性的问题，所以很难实现。方式二：在云计算网络上静态配置VLAN，在所有端口上配置VLAN trunk all。这种方式的优点是非常简单，是目前主流的应用方式。但这也带来了巨大的问题：任一VLAN内如果出现广播风暴，则全网所有VLAN内的虚拟机都会受到风暴影响，出现业务中断/
• （3）4K VLAN上限问题
  云计算网络中有可能出现多租户需求。如果租户及业务的数量规模超出VLAN的上限（4K），则无法支撑客户的需求。
• （4）虚拟机迁移网络依赖问题
  VM迁移需要在同一个二层域内，基于IP子网的区域划分限制了二层网络连通性的规模。

1.2 云计算的 SDN 要求

• 云架构往往是多租户架构，这意味着多个客户会共享单一的物理网络。因此，除了提供基本的网络连接能力以外，云还需要提供网络在租户之间的隔离能力；同时云是自服务的，这意味着租户可以通过云提供的 API 来使用虚拟出的网络组建来设计，构建和部署各种他们需要的网络。

2. Neutron 网络虚拟化

在实际的数据中心中，网络可以分为三层：

• OpenStack Cloud network，
• 机房intranet （external network）
• 以及真正的外部网络即 Internet。

External 网络和Internet 之间是数据中心的 Uplink 路由器，它负责通过 NAT 来进行两个网络之间的IP地址（即 floating IP 和 Internet/Public IP）转换，因此，这部分的控制不在 OpenStack 控制之下。

• OpenSack Cloud network：OpenStack 所管理的网络。
• External network：数据中心所管理的的公司网（Intranet） ，虚机使用的 Floating IP 是这个网络的地址的一部分。
• Internet：由各大电信运营商所管理的公共网络，使用公共IP。

这是 RedHat 提供的一个 OpenStack Cloud network 网络架构：
2.1 网络（L2 network）
网络（network）是一个隔离的二层网段，类似于物理网络世界中的虚拟 LAN (VLAN)。更具体来讲，它是为创建它的租户而保留的一个广播域，或者被显式配置为共享网段。端口和子网始终被分配给某个特定的网络。这里所谓的隔离，可以理解为几个含义：

• 跨网络的子网之间的流量必须走 L3 Virtual Router
• 每个网络使用自己的 DHCP Agent，每个 DHCP Agent 在一个 Network namespace 内
• 不同网络内的IP地址可以重复（overlapping）

根据创建网络的用户的权限，Neutron network 可以分为：

• VLAN network（虚拟局域网） ：基于物理 VLAN 网络实现的虚拟网络。共享同一个物理网络的多个 VLAN 网络是相互隔离的，甚至可以使用重叠的 IP 地址空间。每个支持 VLAN network 的物理网络可以被视为一个分离的 VLAN trunk，它使用一组独占的 VLAN ID。有效的 VLAN ID 范围是 1 到 4094。
• Flat network：基于不使用 VLAN 的物理网络实现的虚拟网络。每个物理网络最多只能实现一个虚拟网络。
• local network（本地网络）：一个只允许在本服务器内通信的虚拟网络，不知道跨服务器的通信。主要用于单节点上测试。
• GRE network （通用路由封装网络）：一个使用 GRE 封装网络包的虚拟网络。GRE 封装的数据包基于 IP 路由表来进行路由，因此 GRE network 不和具体的物理网络绑定。
• VXLAN network（虚拟可扩展网络）：基于 VXLAN 实现的虚拟网络。同 GRE network 一样， VXLAN network 中 IP 包的路由也基于 IP 路由表，也不和具体的物理网络绑定。

2.1.1 Provider network
Provider Network 是由 OpenStack 管理员创建的，直接对应于数据中心的已有物理网络的一个网段。这种网络有三个和物理网络有关属性：

• provider:network_type (网络类型，包括 vxlan, gre, vlan, flat, local)
• provider:segmentation_id (网段 ID， 比如 VLAN 的 802.1q tag, GRE 网络的 Tunnel ID, VXLAN 网络的 VNI)
• provider:physical_network (物理网络的逻辑名称，比如 physnet1, ph-eth1, etc)

这种网络是可以在多个租户之间共享的。这种网络通过计算和网络节点上指定的 bridge 直接接入物理网络，所以默认的情况下它们是可以路由的，因此也不需要接入 Neutron Virtual Router，也不需要使用 L3 agent。使用这种网络，必须预先在各计算和网络节点上配置指定的网桥。
创建 provider network：

• local 类型的：neutron net-create NAME --provider:network_type local
• flat 类型的：neutron net-create NAME --provider:network_type flat – provider:physical_network PHYS_NET_NAME
• vlan 类型的：neutron net-create NAME --provider:network_type vlan --provider:physical_network PHYS_NET_NAME --provider:segmentation_id VID
• gre 类型的：neutron net-create NAME --provider:network_type gre --provider:segmentation_id TUNNEL_ID
• vxlan 类型的：neutron net-create NAME --provider:network_type vxlan --provider:segmentation_id TUNNEL_ID

2.1.3 Tenant network
Tenant network 也有 local，flat，vlan，gre 和 vxlan 等类型。但是，tenant 普通用户创建的 Flat 和 VLAN tenant network 实际上还是 Provider network，所以真正有意义的是 GRE 和 VXLAN 类型，这种网络和物理网络没有绑定关系。
创建 tenant network 的过程：

• 1、管理员在 neutron 配置文件中配置 tenant_network_types，其值可以设为一个所支持的网络类型列表，比如 “vlan,gre,vxlan”。其默认值为 “local“，因此需要改变。该值表明该 OpenStack 云中允许被创建的 tenant network 类型。
• 2、运行命令 neutron net-create <net_name>
• 3、neutron server 逐一根据该配置项尝试创建 network segment，成功则立即返回

2.1.4 Provider network 和 Tenant network 的区别

• Provider network 是由 Admin 用户创建的，而 Tenant network 是由 tenant 普通用户创建的。
• Provider network 和物理网络的某段直接映射，比如对应某个 VLAN，因此需要预先在物理网络中做相应的配置。而 tenant network 是虚拟化的网络，Neutron 需要负责其路由等三层功能。
• 对 Flat 和 VLAN 类型的网络来说，只有 Provider network 才有意义。即使是这种类型的 tenant network，其本质上也是对应于一个实际的物理段。
• 对 GRE 和 VXLAN 类型的网络来说，只有 tenant network 才有意义，因为它本身不依赖于具体的物理网络，只是需要物理网络提供 IP 和 组播即可。
• Provider network 根据 admin 用户输入的物理网络参数创建；而 tenant work 由 tenant 普通用户创建，Neutron 根据其网络配置来选择具体的配置，包括网络类型，物理网络和 segmentation_id。
• 创建 Provider network 时允许使用不在配置项范围内的 segmentation_id。

这个文档 http://superuser.openstack.org/articles/tenant-networks-vs-provider-networks-in-the-private-cloud-context/ 对这两个概念有很全面的阐述。

3. Neutron中的网络连通性

一个标准 OpenStack 环境中的物理网络配置往往包括：

• Internet（Pulic network）：传统意义上的公共网络，使用往往由电信运营商提供的公共IP。
• 外部网络（External network）：数据中心 Intranet，从这里分配浮动IP地址。
• OpenStack 内部网络：

OpenStack 内部网络有细分为：

• 管理网络（management network）：提供 OpenStack 各个组件之间的内部通信，以及 API 访问端点（Endpoint）。为安全考虑，该网络必须限制在数据中心之内。
• API 网络：其实这不是一个单独的网络，而是包含在外部和内部网络中。API 的 Endpoint 包括 publicurl 和 internalurl，其中，publicurl 包含的是 externa network 的 IP 地址，internal network 包含的是 management network IP 地址。为了简单起见，提供给内外网络访问的API的 publicurl 和 internalurl 相同，而只给内部网络访问的 API 只使用 internalurl。
• 数据网络（data network）：除管理网络以外的其它网络，往往还可以细分为下面几种。它们可以合为一种，也可以从性能方面考虑分离出一种或几种作为单独的网络。

这几种网络，在物理交换机上，往往都使用 VLAN 来做网络隔离。现在讨论的只是租户网络即虚机之间通信的网络，在 Neutron 的实现看来，该网络的连通性包括几个层次：

• 同主机和不同主机上一个网段内的虚机之间的连接性：虚拟二层网络，走物理二层（VLAN）或者三层（GRE/VxLAN）网络。
• 不同网段内的虚机之间的连通性：经过物理（VLAN）或者 Neutron Virtual router
• 虚机和外部网络之间的连通性：经过物理路由器（给 VLAN 虚拟网络实用的物理交换机连接的路由器）或者 Neutron Virtual router

4、Neutron 租户网络的安全性（security）

• Neutron 还提供数据网络与外部网络的隔离性。默认情况下，所有虚机通往外网的流量全部走网络节点上的 L3 agent。在这里，内部的固定 IP 被转化为外部的浮动 IP 地址。这种做法一方面保证了网络包能够回来，另一方面也隐藏了内部的 IP 地址。
• Neutron 还是用 Linux iptables 特性，实现其 Security Group 特性，从而保证访问虚机的安全性。
• Neutron利用网络控制节点上的 network namespace 中的 iptables，实现了进出租户网络的网络包防火墙，从而保证了进出租户网络的安全性。
  细节参考：http://www.cnblogs.com/sammyliu/p/4658746.html

5、Neutron 租户网络的高可用性（HA）和扩展性（Scalability）

OpenStack 云中可能用于成千上万台虚机，成千上万个租户，因此，Neutron 的数据网络的可用性和扩展性非常重要。Neutron 中，这些特性包括几个层次：

• 软件架构上，Neutron 实现OpenStack 标准的去中心化架构和插件机制，有效地保证了其扩展性
• 
• Neutron 为每个 provider/tenant network 分配一个唯一的 segmentation_id。该 ID 的数目是影响可扩展性的因素之一。在规模不大的私有云中，往往是用 VLAN 模式，简单、可靠、能够满足规模要求；而在大型的私有云或者公有云中，往往使用 VxLAN。
  
• 分布式 Virtual Router （DVR） 和 分布式 DHCP agent

• L2 Population 和 ARP Responder：这两个功能大大减少了网络的复杂性，提交了网络效率，从而促进了扩展性。
• 高可用：虽然 Neutron 在高可用实现方面走在了 OpenStack 所有组件的前列，目前已经实现了多种 L3 Agent 的 HA 方案，但是，这些方案目前还不是很成熟，大都是在 Juno 版本中添加的，而且现在还在持续优化中，离正式进入生产环境还有一些距离。但是，我们可以相信，再经过两三个版本，这些功能就能够进入生产环境。