openstack neutron 网络问题探讨

平台介绍：Openstack havana云平台采用neutron vlan模式，openvswitch网络，后端存储ceph。
问题描述：1.平台运行过程一段时间，给vm分配floating ip外部网络不通；
                 2.外部ping正在运行的VM迟延大，同一租户的vm之间没有这种想象。有时会使整个规划的floating-ip网络段ip迟延都大。

请朋友们给点宝贵意见，谢谢！

你这个应该属于网络优化，很多人现在处于使用阶段。

如果你做实验的话，你可以尝试更换网络试一下。下面是一些网络介绍，希望能帮到你

OTV (Overlay Transport Virtualization), 核心思想是通过”MAC in IP”的方式，通过隧道技术穿越L3层网络实现L2层网络的互通。白话一点就是通过软件方式重新定义L2层帧头（有一个标准数据格式叫VXLAN)，再通过L3层的遂道如GRE等发送给接收方，接收方再通过软件方式解析数据帧。很多虚拟交换机都是通过这种方式实现的，如Hyper-v，如Dove。

SDN (Software Define Network), 在上面OTV的基础上，再引入一个tenant租户的概念，再做一个集中式的管理就是SDN了。对于南桥API，有一个标准叫OpenFlow，北桥API由于没有标准，也就有了像OpenDaylight的项目试图以插件的形式统一纷乱的北桥API。

VPLS (Virtual Private Lan Service), 我们不堆砌术语，白话一点VPLS就是我们熟悉的VPN, 和上面的OTV技术类似目的是为了让两个从L3层隔离的L2层网络互通。VPN有基于L2层的VPN技术如MPLS VPN，也有基于L3层的VPN技术如IPSec VPN, SSL VPN等。

MPLS, 自动标签技术，VLAN这种标准技术用在局域网内，VLAN需人工修改物理交换机，部署不方便。但MPLS的标签是通过L3层的路由技术在发送数据帧之前就事先走一遍将要经过的每一个路由器确定好并把标签设置好(通过标准交换的专用协议，或者经过扩展的BGP协议），数据帧再经过路由器时就直接经过L2层的硬件转发就是了，就不必再惊动L3层的路由了，大大提高了转发效率，主要用在广域网中。同时，一路怎么走经过哪些路由器可以在上层通过一个参数很容易的控制，也就是所谓的流量工程。

VEPA (Virtual Ethernet Port Aggregate)虚拟以太端口汇聚器，如果一台物机机上的两台虚机通信的话需通过软件虚拟交换机，虚拟交换机是软交换将占用物理机资源。使用VEPA时，即使同一台物理机上的两台虚机之间的流量也不再由本地虚拟交换机来处理，而是被强制发往到外部物理交换机，然后物理交换机再将数据返回来。我们知道，传统的物理交换机的数据帧是不能从进口出的，所以需要对物理交换机硬件作修改，允许其绕回。优点很明显，减少物理机宝贵的CPU资源，在物理交换机上统一实现流量，安全控制的管理。但缺点也是明显的，所有虚拟机之间的流量在物理节点和物理交换机之间来回了两次，浪费了网络带宽和增加了数据延迟。实际上，目前像openvswitch的软件虚拟交换机能够提供很好的安全控制，所以对于它这种代价我看不值。

VN-TAG, 如VEPA一样也需要对物理交换机做定制，核心思想是在标准以太网帧中为虚机定制增加一段专用的标记VN-Tag，用以区分不同的vif，从而识别特定的虚机的流量。

TRILL (Transparent Interconnection of Lots of Links ) 多链接半透明互联(TRILL), 传统的数据中心一般采用L2层交换机级联 ＋ L3层路由组网架构，无法跨二层进行虚机迁移（因为VM的IP会改变嘛）。另外，这种L2层交换机级联的架构为避免环路需引入生成树STP协议,这样减小了服务器东西间的流量。控制平面上TRILL引入了ISIS这种内部路由协议还建立邻接，绘制拓扑和传递标签，数据平台使用NickName作为转发标识。所以我的理解是，TRILL更像是MPLS在局域网的应用。

FabricPath, FabricPath是Cisco在TRILL标准之上做了一些优化而产生的私有协议。

对于这些技术如何在OpenStack Neutron中使用，我个人的理解是：

1,对于TRILL与FabricPath技术相当于在数据中心内部部署了MPLS一样，对于东西向流量有用，但数据中心应该是南北流量大。同理，PVLAN主要适合大部分为南北流量，少量东西流量的情况。

另外，在OpenStack Neutron网络中，若今后支持multi-host特性，在每一个计算节点上都有那台计算节点上所有tenant网络的网关，这样，在同一个物理交换机之下的所有计算节点上的虚机之间的通信根本不会遇到流量带宽问题。

当然，对于不同物理交换机下的计算节点的虚机的流量由于STP的原因会有稍微有那么一点流量带宽问题，但可以通过调度将那些东西流量大的服务（如hadoop集群）尽量调度到同一个物理交换机下的物理机之上啊。

所以，依我看，目前这方面的需求不是很迫切，除非你的数据中心超大，或者东西向流量超大，这样可以在数据中心内部部署类似于MPLS技术的FabricPath，对两台物理交换机上虚机的流量由L3层软路由变成L2层的类似于标签的硬转发。

2,对于VEPA技术也不是很有必要，因为VEPA主要是通过硬件交换机来弥补一些虚拟交换机的某些功能（如ACL，流量控制）的，而OpenvSwitch虚拟交换机也通过流表控制很容易做到这些。减小了物理机的CPU资源，但增大了流量带宽代价一样要中断浪费CPU资源。

3,对于GRE遂道，缺点主要是一是增加了GRE表头会导致本应由交换机硬件来分片的变成由软件来分片（STT技术可以弥补这一点）；二是GRE广播，且遂道将虚拟二层打通了，广播风暴更厉害。但对于虚机来说，因为虚拟交换机是完全能够知道虚机的IP和MAC地址的映射关系的，根本不需要通过ARP广播来根据IP找MAC地址，目前Neutron中有这类似的blueprint可以禁止广播。所以个人比较看好STT技术，因为目前openvswitch与linux kernel还未实现STT，所以Neutron目前没有STT插件（但有VXLAN和GRE插件）。

4,对于VN-TAG技术，我只能说目前neutron的vif binding特性可以通过软件实现同样的功能。

版主分析的非常透彻，云平台网络的稳定性方案大多数运营商还是采用nova-network或linuxbridge的网络方式，openstack neutron下的可行性网络方案，不知版主有何高见呢？

zjy19811001 发表于 2014-6-13 10:51
版主分析的非常透彻，云平台网络的稳定性方案大多数运营商还是采用nova-network或linuxbridge的网络方式，o ...

没有什么好的想法，不知道你是否有自己的初步想法，说来听听