五一期间写的,供大家观影 Austin 用

  • 前言
  • 架构
    • Practical OVN Architecture, Deployment, and Scale of OpenStack
    • OpenStack and Opendaylight The Current Status and Future Direction
    • OpenDay Light – Collaborating with OpenDaylight for a Network-Enabled Cloud
    • Dragonflow – Neutron Done the SDN Way
    • Deploying Neutron Provider Networking on Top of a L3 Provider Network Using BGP-EVPN
    • Overstock.com’s OpenStack Networking Strategy
  • 功能与工具
    • Tap-As-A-Service What You Need to Know Now
    • Skydive, Real-Time Network Topology and Protocol Analyzer
    • Neutron DSCP Policing your Network
    • Troubleshoot Cloud Networking Like a Pro
    • Load Balancing as a Service, Mitaka and Beyond
    • Tired of Iptables Based Security Groups? Here s How to Gain Trem
    • Integration of Neutron, Nova and Designate: How to Use It and How to Configure It
    • SNAT High Availability Service in Neutron for Distributed Virtual Routers
    • Virtual Routers on Compute Nodes: A (Not So) Irrational Decision?
    • F5 Networks – Technically Speaking..Are You in or Are You Out?
  • 开发
    • Understanding ML2 Port Binding
    • Deep Dive into Neutron Upgrade Story
    • Service Function Chaining Technology Analysis and Perspective
    • Case Study Neutron IPAM APIs and External IPAM Integration
    • Neutron Address Scopes
    • Evolving Virtual Networking with IO Visor
    • MidoNet Scalability Testing with Neutron and Open Source Tools
    • Mapping Real Networks to Physical Networks, Segments, and Routed Networks
  • 其他
    • Performance Measuring Tools for the Cloud
    • Project Vitrage How to Organize, Analyze and Visualize your OpeenStack Cloud
    • Intelligent Workload HA in Openstack
    • Senlin Clustering Service Deep Dive
    • Deploy an Elastic, Resilient, Load-Balanced Cluster in 5 Minutes
    • OpenStack Stable
    • Automated Security Hardening with OpenStack-Ansible
    • Open Stack at Carrier Scale
    • Ceilometer, Nova and Neutron – Working Together to Provide a Healthy Network for Your Cloud
    • Distributed NFV & OpenStack Challenges and Potential Solutions
    • Nova Cells V2 What s Going On?
    • Troubleshooting oslo.messaging RabbitMQ issues

前言

此文为目前第一篇 OpenStack Summit 观影指南,笔者在 OpenStack Ausin Summit 期间现场观看了约二十多个 Session,综合之后在 YouTube 上看的一些回放,对 36 个 Session 做了一些介绍和简评,主要集中在网络方面,别的方向一些重要的 Session 也有一些但是不多,为了能让读者看到完整内容,本文主要介绍了在 YouTube 上有完整视频的 Session(Presentation/Keynote 均有完整视频,详见:https://www.youtube.com/user/OpenStackFoundation/videos,在 Youtube 上搜索对应名字即可),对于重要的技术也可能有超出 Presentation 之外的评论,希望能给想用较少时间对 Austin Summit 有所了解的同学有所帮助。

架构

Practical OVN Architecture, Deployment, and Scale of OpenStack

评分:4/5
简介:开头科普了一下 OVN 的架构,一些做的不错的地方,然后着重介绍了这个 Release Cycle 中社区对 Scale 的进展和测试,以及其他一些目标。对 OVN 感兴趣的同学应该看一看。
QQ20160501-2.png-275.4kB
评论
标题虽叫 Practical,但遗憾的是实践的内容并不多,提到了社区做的 Scale 测试,主要是利用 Sandbox 在 20 台物理机上做 2000 个 Hypyervisor 的控制平面模拟,IBM 在实际物理环境中部署过 90 个 Hypervisor 的 Scale,下一步要测试 300 台和 700 台的规模。

关于最近的进展,Scale 上有一定提升,例如 ovsdb-nb 和 ovsdb-sb 分拆到两个进程等,但遗憾的是比较受人关注的 ovsdb 的多进程还在开发中,原生 NAT、摆脱 MQ 等一些关键 Feature 也还没有做完。部署上已经支持了 Puppet OpenStack,同时社区对 Rolling Upgrades 也比较重视,这方面做的也不错。下一步的目标主要还是 OVSDB 的 HA(关键 Feature)、L3 Gateway 和 NAT 的支持(关键 Feature)、Native 的 DHCP、MetaData 等等,还有一段路要走啊。

OVN 刚推出很多人看好,原因最主要是强大的社区,其次刚开始给出的设计文档也不错,遗憾的是刚拿出来的版本距离长期设计目标就差的很远(OVSDB 的 HA 问题,甚至目前还是单进程的!大量的非分布式实现等等),所以就让很多人忧虑 OVN 是不是太晚了,一年多过去了,OVN 社区确实做出了很多努力,但遗憾的是前有 DragonFlow,后有 OpenDaylight OVSDB Netvirt 各种竞争,而且前者发展时间长、已有部署案例,后者在 HA、各种功能(SFC、VxLAN Gateway 等)也有所擅长,而且两者对如何解决数据库/资源同步问题都提出了自己的方案(versioned object、async sync)等,而 ovn 社区目前还没有考虑过这个问题,只能说留给 ovn 的时间已经不多了啊。

OpenStack and Opendaylight The Current Status and Future Direction

评分:4.5/5
简介:开头科普了一下 OpenDaylight 的架构,然后介绍了在 OS M 版和 ODL Beryllium 版上的进展,特别是 V2 版 Driver 的情况,值得一看。
评论
V2 Driver 是一个关键性但复杂的事情,主要是增强了 HA 和 Scalability,这也得益于 OPNFV 的不断测试。其中的关键问题之一是数据库的不同步。做过类似 SDN 与 OpenStack 对接的开发者都知道,因为事涉两个系统,两个数据库,所以保持数据一致性是一个很麻烦但有很重要的问题,一旦处理不好,轻则状态不一致,重则大量脏数据充斥两个系统还无法轻易删除,最终无法维护。ODL 选择了一个相对简单一些的方案,就是将一个 Sync 操作拆开,拆一部分为独立的循环,这个思路可能是和以前的 Neutron agent 学的?

QQ20160501-3.png-231.8kB

我们可以看到 API 返回过程实际是没变的,仍然是直接写数据库然后就返回,但此时状态时 Pending 的,由另一个独立线程周期去取 Pending 的数据,然后交给 ODL,这样来保证 API 操作的即时性和状态的一致性。

轻量测试框架看起来对用户不会有很大的影响,但是对开发真会方便很多,跑和 OpenStack 的集成测试不需要专门跑 ODL 了,简化很多。支持了基于 Port binding 的 OVS DPDK 集成(这样你可以混布 DPDK 和 非 DPDK 了!),100% 通过 Tempest 测试。在新版的 ODL 上,HA、稳定性、各种 Feature 也增强很多,可以认为 ODL 和 OpenStack 集成已经很靠谱了。

在下一个版本中,一方面是 v2 的继续增强,一方面是 SFC、FD.io、BGPVPN、L2GW 等这些的增强。按照 FD.io 的文档,FD.io 社区的计划也是通过 ODL 与 OpenStack 集成,按照目前的资料 FD.io 的性能特别是多流性能上就超出 OVS DPDK 一大截,值得期待。SFC 有其他 Session 做介绍,这里就不多说了。最后做一点科普,OpenDaylight 可以作为纯软的 OpenStack SDN 后端,具体的模块是 netvirt,也是以 OVSDB 来控制 OVS 完成网络功能,目前功能的完善程度还是比较高的。

Read More →

Netfilter 为每种网络协议定义了一套钩子;

  • 内核的任何模块可以对每种协议的一个或多个钩子进行注册;
  • 排队的数据包被传递给用户空间并异步进行处理。

钩子点

  1. pre_routing:路由查找前,ip_recv(),在此之前,只简单检查协议版本号、包长度、检验和等
  2. local_in:目的地址为本机的数据包,ip_local_deliver()
  3. forward:经过防火墙转发、目的地址非本机,ip_forward()
  4. post_routing:最终送入物理介质前,适合snat或统计
  5. local_out:本机产生并发送的包

以上几个钩子位置如图(wei: ip_fragments 现在应该是ip_fragment 吧):

LinuxNet1

注册的钩子函数都将返回下列返回值之一(wei:定义于include/uapi/linux/netfilter.h):

  1. NF_ACCEPT:接受并递交;
  2. NF_DROP:完全丢弃;
  3. NF_STOLEN:钩子将对数据包开始处理,Netfilter放弃该数据包的所有权
  4. NF_QUEUE:包发往用户空间,等待用户空间程序处理
  5. NF_REPEAT:请求Netfilter再次调用这个钩子

wei代码里还可以看到还有 NF_STOP,看介绍是接受并阻止后面的钩子继续处理)

 

Netfilter 的内置功能模块有系统初始化配置脚本加载到内核,再由内核自动调用,各模块功能相互独立,如 Filter 在需要过滤控制时加载,NAT 在需要NAT时加载。注册中比较重要的数据结构是 nf_hook_ops ,注册和卸载分别调用 nf_regerister_hook() nf_unregerister_hook() 函数。

nf_hooks 是一个二维数组 nf_hooks[NPROTO][NF_MAX_HOOKS] NPROTO 表示当前内核允许的最大协议数,(wei:位于uapi/linux/net.h#define NPROTO AF_MAXAF_MAX 目前为41,具体见 include/linux/socket.h PF_**,与 AF_** 一致,其中 local UNIXROUTE NETLINK),NF_MAX_HOOKS 表示对任一协议组需要用的钩子的最大数目。其类型是 list_head,可以理解为双向链表,(wei:它有一个变量属性是 __read_mostly,这个是gcc自己实现的语法,可以参考这里:https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Variable-Attributes.html,在这里目的为放入cache中,关于 list_head 的使用可以看这里:http://oss.org.cn/kernel-book/ldd3/ch11s05.html

nf_hook_ops 其定义在 include/linux/netfilter.h

struct nf_hook_ops {
    struct list_head list;

    /* User fills in from here down. */
    nf_hookfn   *hook;
    struct module   *owner;
    void        *priv;
    u_int8_t    pf;
    unsigned int    hooknum;
    /* Hooks are ordered in ascending priority. */
    int     priority;
};

其中,list 是链表指针,hook 是钩子函数指针,其格式格式为 nf_hookfn

typedef unsigned int nf_hookfn(const struct nf_hook_ops *ops,
                   struct sk_buff *skb,
                   const struct nf_hook_state *state);

 
struct nf_hook_state {
    unsigned int hook;
    int thresh;
    u_int8_t pf;
    struct net_device *in;
    struct net_device *out;
    struct sock *sk;
    int (*okfn)(struct sock *, struct sk_buff *);
};

hooknum 表示钩子函数挂在哪个钩子点上,如 NF_IP_PRE_ROUTING 等,定义于uapi/linux/netfilter_ipv4.h

 priority 表示优先级,数字越小优先级越高。

 

钩子的注册主要依赖 nf_register_hook() 函数:

int nf_register_hook(struct nf_hook_ops *reg)
{
    struct nf_hook_ops *elem;
 
    mutex_lock(&nf_hook_mutex); //互斥锁
    list_for_each_entry(elem, &nf_hooks[reg->pf][reg->hooknum], list) {
        if (reg->priority < elem->priority)
            break;
    } //宏,用于遍历链表
    list_add_rcu(&reg->list, elem->list.prev); //把链表项插入到RCU保护的链表elem->list.prev的开头
    mutex_unlock(&nf_hook_mutex);

#ifdef HAVE_JUMP_LABEL
    static_key_slow_inc(&nf_hooks_needed[reg->pf][reg->hooknum]);
#endif

    return 0;
}

  Read More →

本文由王为撰写,首发于 UnitedStack 官方博客和官方微信公众号,转载前请联系作者。

文章里 MidoNet 的分析不多,其实很值得研究,关注的同学可以一起探讨。

文章基于我在 ArchSummit2015 深圳 会议上的演讲整理而成,所以可能讨论的不够细致。

前言

当我们提到 OpenStack 的网络,很多人会望而生畏,说 OpenStack 网络好复杂、Neutron 难以维护、Overlay 网络性能低下…… 这样的印象阻碍了 OpenStack 特别是 Neutron 在企业的部署脚步,事实上从 OpenStack 诞生起,其网络的模型和设计就一直在进化并且保持着高效、快速的迭代,特别是从 Neutron 诞生,Legacy 网络、Provider 网络、L3 HA、L2 Population、DVR、DragonFlow 相继提出,我们看到 Neutron 在其每一个 Cycle 都在向企业级的生产软件靠近,本文将尝试对 OpeStack 的网络发展做一个综合性的总结和比较。

从 Nova-network 说起

我们知道最初 OpenStack 只有 Nova 和 Swift 两个组件,所以 Nova 除了提供基础的计算服务,包括调度、块设备和网络也一并由 Nova 提供,当时的网络是什么样呢?为什么现在还有很多 Superuser 还在使用 Nova-network?

最开始,大家期望中的 OpenStack 网络是什么样的?

  1. 能给虚拟机提供 IP 地址;
  2. 虚拟机在需要时可以连通外网;
  3. 相同网络下的虚拟机之间允许内部通信;
  4. 一些虚拟机还希望能获得一个外网 IP 来对外提供服务。

最后特别对于公有云,租户间还需要保证网络隔离。

基于以上需求,Nova-network 提供了这样的参考模型(VlanManager+MultiHost):

1

首先,dnsmasq 进程绑定在租户的网桥上,用于提供 DHCP 服务,提供 IP 地址;然后,计算节点上配置默认路由并将一个网口连接至公网,这样虚拟机按默认路由发送的报文将被网桥以节点的默认路由送出,发往公网的接入层;同一租户的网络处于同于 Vlan,通过网桥广播允许其互相通信;不同租户的虚拟机如果则通过节点上的路由表路由到对应网桥并转发(见上图);如果虚拟机需要公网 IP,则可以在计算节点上直接起 NAT 规则对应到相应内网 IP。

整个模型很简单明了,全部使用 Linux 中较为成熟的网络技术, 所有路由选择由本地决定,不依赖某个单点,这个在 Nova-network 中被称为 MultiHost,是Nova-network 的重要特性,所以其一出世就获得了很多人的青睐。

但是 Nova-network 的缺点也是很明显的:

  1. 因为 Vlan 技术固有缺陷,一个 Region 下无法服务太多租户;
  2. 路由实现粗糙,路由决策和 NAT 依赖 IP 地址,所以很难实现Overlap IP,用户的 IP 管理不自由;
  3. 前面说不同租户(其实是不同网络)之间似乎可以在没有公网IP的情况下互香通讯,但这是有条件的,再看前面的图,我们看到如果想在计算节点下做路由决策,让数据包成功封装另一个租户的 Vlan,我们需要这个计算节点拥有另一个租户的网桥,而且因为这个链路的非对称性,对方节点也需要相同的要求。因为 Nova-network 的网桥是按需建立的(不然太多),所以其实这种通信是无法保障的。

最后,Nova-network 提供的网络高级功能很有限,只有基本的安全组,很难满足用户需求,而且将网络紧耦合在计算服务中也不符合云计算的架构,所以社区最终成立了 Neutron 项目。

Neutron 的艰难前行

Neutron 的诞生承载着大家对面向大型云基础设施的网络服务的期望,它在一开始就着手设计了基于 Overlay 网络的网络模型,通过先进的 VxLan 和 NVGRE 协议, Neutron 克服了很多在 Nova-network 中无法解决的网络问题。Overlay 网络是什么的,简单的说,它是一个逻辑网,运行在物理网之上,一般要求物理网 IP 可达,然后通过 UDP 等三层传输协议承载二层,形成 L2 over L3 的模型,这样我们就可以实现突破物理拓扑的任意自定义网络拓扑、Overlap IP 等。

2

首先针对 Nova-network 面临的几个问题,VxLan、NVGRE 等都支持上千万的租户数量,远远满足一般需求;其次通过 L2 over L3,用户完全实现了自定网络拓扑,没有 IP 地址的限制;不同网络间拥有不用的 VxLan tag,当需要在不同网络下互相通信时,可以通过路由器路由转换 VxLan tag,不再有种种限制。

针对 Nova-network 的高级功能匮乏的问题,借助灵活的网络模型和虚拟路由器的实现,Neutron 拥有自定义路由、VPNaaS、FWaaS 和 LBaaS 等多种高级功能。此外,由于 Neutron 定义良好的北向接口和 Plugin-extension 架构,它可以支持大量厂商的设备,用户拥有彻底的自主选择权,厂商拥有高度的自主开发空间。

既然我们说的这么好,为什么很多人对其都不满意呢?原因也很多:

  1. Neutron 使用了 Namespace、Open vSwitch、网桥、veth、iptables 等技术,其中有些内容,特别是 OVS 对很多人都是比较陌生的,而且在一开始,其稳定性也受人质疑,这让人们有了充分的质疑理由;
  2. 南北向通讯和跨网络通讯都依赖于网络节点,而这个节点在默认的模型下是单点。
  3. Overlay 网络的默认性能并不能让人满意,需要专业工程师或厂商设计方案和调优。

软件的复杂度随着软件功能的丰富和接口的复杂性的上升几乎是必然的,Open vSwitch 的稳定性和性能也一直在提升,所以社区决定要发动力量主要解决第二个问题。

首先是 HA,企业 IT 系统首先关心的,莫过于系统的稳定性,一个可靠的 HA 方案是社区首先考虑的。很多网络服务的高可用都是借助 VRRP 协议的,Neutron 也不例外,通过 Keepalived + conntrackd,实现 Master 和 Slave 共同维护 VIP,一旦 Master 挂掉了,VIP 将自动飘到 Slave 节点上,因为 conntrackd 始终在自动拷贝session 信息,所以理论上可以实现用户的无感知自动切换。

3

L3 HA 确实实现了高可用,但是东西流量还是没有优化啊,这里面一大原因是 VxLan本来支持组播的,但是 OVS 目前支持有限,我们总是不得把一些无效的 ARP 广播发送出去。比如说下图中,A 的广播包其实只对 3 和 4 有用,但是 2 和 5 也收到了:

4

如何优化,这里的问题是虚拟机不知道通信对方的位置,可是 Neutron 知道啊,Neutron 数据库中保存着每一个 Port 联接的虚拟机信息、其 IP、MAC 地址、其宿主机信息等等,所以如果有新的虚拟机建立起来,连接了网络,那么 Neutron 就往所有 Agent 发送消息,告诉他们新的 Port 的所有信息,大家就低头检查看看自己是不是也有这个网络的虚拟机,如果有就更新流表规则,将来要请求这个 IP 的 ARP 可以直接回应,如果没有就忽略。这就是 L2 Population 和 ARP responder。

OK,更加优化了一步,但是他也有问题啊,就是

  1. 因为消息是广播的,很耗费资源;
  2. 跨网络的通讯还要依赖于路由器;
  3. 它目前没办法和 L3 HA 共同工作!

为什么它无法和 L3 HA 共同工作呢,因为 L2 Pop 假定了每个 Port 都工作在一个固定的节点上,这样 L2 Pop 才能将 ARP 和 Tunnel 引过去,然而 L3 HA 破坏了这个假设…… Bug 的 report 见 Launchpad 上的 #1365476 ,目前尚未解决……

Read More →

前几个星期,社区通过了一个 Patch 来解决一个遗留很久的 DHCP 相关的问题,这个 Patch 并不复杂(review 地址是 https://review.openstack.org/#/c/185486/),但为什么这么做却有一点故事,拿出和大家聊一聊。

事情从 DHCP HA 说起。我们知道 Neutron 的架构是每个“网络”(Network),都会有一个相应的 namespace 名为 qdhco-XXX(XXX 为网络的 UUID)运行在网络节点上。这个网络命名空间内会有一个  tuntap 设备,名为 tapXXX(XXX 为 port 的 ID),然后有一个 dnsmasq 进程与之绑定。

dnsmasq.png

这样,每当新的虚拟机启动,自动广播 DHCP 请求,namespace 下的 dnsmasq 将收到这个广播包并根据 dhcp-hostfile 里的内容对 VM 给予回应,分配并确认其 IP 地址。这一切都挺好的,先不考虑网络规模很大时 dnsmasq 的承载能力, 不考虑将 dhcp 分布式时,it works。

但如果我们想尝试将 DHCP 做 HA 呢?考虑到如果这个 dnsmasq 进程挂掉了,或者这个网络节点上的 ovs 异常了,甚至网络节点挂掉了…… 嗯,让我们先从 DHCP 的流程说起。

IPv4 版的 DHCP 是按照 RFC 2131 Dynamic Host Configuration Protocol 标准的,先撇开其具体细节,大概的 DHCP 流程是这样的:

[caption id="" align="alignnone" width="640"] dhcp[/caption]

首先在 DHCP 发现阶段,客户端发送目的地址为 255.255.255.255 的 UDP 广播包,然后服务端回复 DHCP OFFER,包含分配的 IP、默认路由、租约有效期等等。为了避免同一个网络下有多个 DHCP 服务端,而客户端只接受一个 DHCP 结果,所以客户端需要再发广播通知所有 DHCP 服务端自己接受了哪个 DHCP 分配结果,这个包里含有它自己给自己确定的 IP 地址,这个 IP 地址来自于哪个 DHCP 服务端(服务端的 IP 地址)。最后服务端广播一条 ACK 作为结束。 Read More →

Port Security 功能

相关链接

bp:[https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity]

code review:[https://review.openstack.org/#/q/topic:bp/ml2-ovs-portsecurity,n,z]

spec:[http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-ovs-portsecurity.html]

main patch:[https://review.openstack.org/#/c/126552/]

问题描述

Neutron 的安全组会向虚拟机默认添加`anti-spoof`的规则,这个规则将保证虚拟机只能发出/接受以它为原地址或目的地址(IP & MAC)的流量,不过注意的是`anti-spoof`并不能屏蔽**arp**包,因为`anti-spoof`是基于 iptables 的,无法识别 arp 包内的信息,社区新实现了一个基于 ovs 的 arp 识别、过滤的功能,见 Commit:`aa7356b729f9672855980429677c969b6bab61a1`,注意这个 Commit 的实现中考虑到了 Port Security 的影响。

上述这些功能确实有助于提高私有网络的安全性,特别是对于公有云而言,用户除非使用`allowed address pair`,将无法以非自己绑定的 IP、MAC 来发送或接收包,方便了云中流量的定位、debug 等。但是,对于一些应用,比如**LVS、基于虚拟机的路由器、基于虚拟机的防火墙等**,它们需要在一个**无防火墙、安全组和 anti-spoof 规则**的私有网络(虚拟网卡)下运行,特别是如果保持着 anti-spoof 规则的话,上述的应用很多都完全无法工作。

改进

Port Security 将提供一个新的属性`port_security_enabled`给`network`和`port`,其默认值为`True`,即与该 Patch 之前的行为相同,可以应用安全组、自动应用`anti-spoof`规则,当`port`的`port_security_enabled`被设置为`False`时,这个`port`将无法设置和应用安全组,`anti-spoof`会被关闭,`allowed address pair`也将无法设置。因为这个属性与安全相关,所以只有网络的`owner`可以设置这个值。

当给一个网络的`port_security_enabled`设置为`False`时,这意味着该网络下建立的`port`都将默认应用`False` 的`port_security_enabled`。

实现概述

Port Security 的 Topic 下有 5 个 Patch,此外在 Spec 中还提到另一个比较 general 的 Patch,但实际上主要的实现都在 [https://review.openstack.org/#/c/126552/] 这个 Patch 中,Commit 号为`554d266f56862d4f15de104e9199e9149124efbe `。 Read More →