五一期间写的,供大家观影 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 完成网络功能,目前功能的完善程度还是比较高的。

OpenDay Light – Collaborating with OpenDaylight for a Network-Enabled Cloud

评分:3/5
简介:这是一个在 MarketPlace 的短片演讲,主要介绍了 ODL 本身和其与 OpenStack 集成的好处,以及一些 UseCase。
评论:对 ODL 不了解的同学可以看一看,看过 OpenStack and Opendaylight The Current Status and Future Direction 的同学就不用看了。

Dragonflow – Neutron Done the SDN Way

评分:5/5
简介:开头科普了 DragonFlow 的架构和意义,然后介绍了最新的进展,其中重点是 Plugable DB (你将可以愉快的使用 ETCD、RamCloud、Redis 等作为分布式的数据库后端)、Plugable 消息后端(你可以愉快的使用 0MQ)、分布式的 DNAT、DHCP 和 OVS 实现的安全组均已完成!

QQ20160501-5.png-265.6kB

AWcloud 介绍了它们一个 500 Scale 的基于 DragonFlow 的集群,主要的考虑在消息和数据库上。本 Session 有架构、有问题、有解决、有案例、有数据,是一场很值得一看的 Presentation。
评论
在去年的 Vancouver Summit 会后总结上,笔者就向国内同僚介绍过 DragonFlow 这个生机勃勃架构的项目,主要 Contributor 中 Gal 和 Eran 都是很有创造力的人,最近随着国内的马力的加入让这个“小社区”更加充满活力,从他们的 Feature 介绍中也能看出里其发展之强。演讲着重介绍了关于数据库一致性的问题解决,和 ODL 重点讨论的那个事情是一样的,区别是二者的方法,DragonFlow 目前采用的是基于锁实现,类似于两步提交,但计划修改成基于版本的对象控制,这个计划其实和 ODL 的实现也是有类似的,但是这里不用状态这个字段,而是用版本,确实看起来更优雅但实现难度还是比较高的。

QQ20160501-7.png-339.9kB

OpenStack 与 SDN 集成的两大痛点,一个消息问题,一个数据库问题,不同的社区给出了不同的解决方案(弃用 MQ 还是采用分布式 MQ?基于 CAS 的比较还是基于状态的异步处理?),很让人拭目以待。此外 DragonFlow 还公布了他们在 Scale 上的路线图,随着 0MQ 的引入,他们把理论的 Scale 已经提高到 4000 节点,但这还是不是终点,目前的目标是 10000 台节点!

DargonFlow 在更新速度上、架构上(他们在架构上在不断进化)都绝对不输目前 Neutron 几个其他 SDN 方案,唯一遗憾的是社区和声音都小了些,希望未来能有更多的慧眼识珠之人参与进来。

QQ20160501-8.png-269.3kB

Deploying Neutron Provider Networking on Top of a L3 Provider Network Using BGP-EVPN

评分:4/5
简介:这是一个 Walmart 出品的其网络结构设计 Case Study,主要技术是 MPBGP EVPN,对大型的 OpenStack 网络设计(VxLAN 网络设计)还是很有价值的,演讲附有珍贵的实际性能数据。
评论
Walmart 首先谈了他们的痛点:
一、目前数据中心建设过程太过漫长,需要6-12个月
二、流程长、重复工作多、缺乏进度可视、相互依赖
三、传统网络架构需要很多网络工程师维护,应用喜欢二层而网络工程师喜欢三层,网络和安全由不同的人负责
据此,Walmart 希望一个支持裸机和虚机、支持大二层、安全、可靠、无厂商锁定的网络方案。最终他们选择MPBGP EVPN VxLan组网。
MPBGP EVPN 在网络界已经不是新技术了,但和 OpenStack 结合其实不多,一来设备支持不那么丰富,二来社区有L2 POP+ARP Responder的解决方案(当然也有 MPBGP EVPN 的软件实现方案,BaGPipe!),此外 OpenContrail 作为开源软件 SDN 界的技术担当也一直支持,所以这个话题在 OpenStack 社区圈内讨论的不多,但是如果你想真的解决 VxLan 的广播问题,或者想扩展 VxLan 到 DCI,那 MPBGP EVPN 确实值得考虑。此外通过设备解决分布式路由?Ancast Gateway(简单的说就是分布式的 VRF)。网络架构整体是和 Spain-leaf 没什么区别,但重要的是 VxLan de/encap 是在 ToR 上做的。

QQ20160501-9.png-295.7kB

最后 Walmart 给出了其性能测试数据,基于 Dell 和 Cisco 的硬件。有意思的是他们还有一个测试项叫 AppMix,混合了各种应用来模拟真实情况。另外还有 Walmart 给出的小包性能一般,瓶颈应该在软件或虚拟机上,不应该是 ToR 的问题。

对了,笔者在会上问了 Walmart 使用的控制器或自动换软件是什么,答案是目前在用 VTS,将来计划迁移到 Ansible 上,网络资源全部是预配置的。

Overstock.com’s OpenStack Networking Strategy

评分:2.5/5
简介:用一句话介绍就是 Overstock.com 是如何使用 Midonet 然后过上了幸福的生活的。
评论
演讲者之前网络设计和规划比较一般般,故障恢复需要数小时,用了 Midonet 和改善了架构后之后做到了零丢包,End。广告太硬了,差评。
QQ20160501-12.png-249.6kB

功能与工具

Tap-As-A-Service What You Need to Know Now

评分:3.5/5
简介:Tap-As-A-Service 目前的主要用途在监控上,这个 Presentation 介绍了 Tap-As-A-Service 的架构、作用、使用方法,做了一个 Demo 演示。
评论
TAAS 目前已经有了 OVS 的实现和 CLI,基本设计是两个概念,Tap Service、Tap Flow,前者代表要监控的 Port,后者代表具体的 Flow。Overlay 网络的监控确实是刚需,但是目前基于 OVS Port Mirror 的设计是否可靠,是否能适应大规模的 Scale,还没有相关测试,猜测还有一段路要走。监控虚拟机流量对系统管理员还是太过简单,毕竟自己用命令也可以做,关键是将来能否能在其上实现一套流量监控、分析之类的系统,这样才能比较完整的满足系统管理员、运维的需求。

Skydive, Real-Time Network Topology and Protocol Analyzer

评分:4/5
简介:如上所述,我们缺乏一个好用的开源 Overlay 网络监控、运维工具,于是 RedHat 的开发者开发了 Skydive 这个工具,功能简洁、WebUI酷炫,做了一个 Demo,大概就是这样。
评论
如果能真的解决 Overlay 网络的监控运维那真是所有 OpenStack Overlay 网络使用者的大福音,目前 OVS 组网运维基本靠手,很麻烦,传统的监控工具如 Zabbix 完全不适用,靠谱的只有额外购买工具(例如 BigSwitch 的解决方案、Gigamon 的解决方案),Skydive 就是来填补这一空白的,自动扫描 Linux 网络和 OVS,自动展现拓扑还可以抓包,通过整合 ElasticSearch,你还可以比较清楚的看到报文在哪里丢掉了:

QQ20160501-13.png-395.2kB

这个项目笔者很久以前就关注过,最重要的的问题是,目前没有做过 Performance 和 Scale 的测试,要知道大型的 OpenStack 云目前已经有成百上千个 Namespace 和 Port,包量可能有上兆的 PPS,节点数量可能也是成百上千,如果性能和 Scale 达不到的话,那就成为小实验室的玩具了。

Neutron DSCP Policing your Network

评分:4/5
简介:Neutron QoS 的最新进展、实现、和实现上遇到的挑战与解决方案。
评论
Neutron QoS 进展不快是事实,但是令人欣慰的是毕竟一直还有进展。这场 Session 介绍了一些人比较关心的 QoS 中 DSCP 的功能。先介绍了 DSCP 是什么,然后介绍了在 OpenStack 中如何使用,如何在 OVS 中被实现。遇到的挑战主要有几个,一个是下面介绍的为了解决 L2 Agent 重启的问题,每个 Flow 增加了 cookie,QoS 需要保证其规则在重启时不被刷掉,解决方案时 Agent Extension 获得自己的 cookie 值,自己维护。另一个是 Feature 的隔离。目前我们在 L2 Agent 上可能实现了很多功能,例如安全组、Vlan、QoS,都通过 OVS Flow 实现,那么如何保障这些 Flow 可以正常同时工作,或者其中一些功能关闭时保证开启的功能正常工作?解决方案是 table 0 会给 packet 的 metadata field 打 0,然后送到 feature table 上,feature table 处理完把相关的 metadata field 打非 0,然后送回,有点像一个小 SFC 似的。

QQ20160502-21.png-252.1kB

最后一个问题是 Server、Agent 的 RPC 版本不同步的问题,解决方案是后面会提到的 OVO。
下一步的 Roadmap 是实现 ECN、最小带宽保障、进流量限制等等。

Troubleshoot Cloud Networking Like a Pro

评分:3.5/5
简介:几个印度哥们讲的如何给 OpenStack 网络做 Troubleshoot。
评论
关键词是 ip, brctl, ovs-*, netstat, iptables, arping, ping, tcpdump,然后掌握好架构图和 IO 路径。如果你确实需要的话,可以参考他们写的 pdf:http://www.slideshare.net/SohailArham/troubleshoot-cloud-networking-like-a-pro
文末提到了一个 check.sh 的神秘脚本,遗憾的是笔者并没有找到这个脚本,当然其实你也可以自己参考其输出写一个,然后贡献到 OpenStack/Steth 项目里。

Load Balancing as a Service, Mitaka and Beyond

评分:3.5/5
简介:介绍 LBaaS 项目的进展和未来。
评论
前面先花了很长时间介绍 Dashboard 的改进,然后 LBaaS 的改进总结起来就是支持了 7 层!然后 Octiva 支持了 A/S HA,支持了一些安全的改进、镜像更新更加容易、证书自动获取等等。

Octiva 的路线图:

QQ20160502-34.png-174.2kB

整个介绍中规中矩,算是一个例行对外发布会吧。

Tired of Iptables Based Security Groups? Here s How to Gain Trem

评分:4/5
简介:介绍了新的 OVS 实现的安全组。
评论
安全组其实是个比较简单的基本功能,之前基于 iptables 实现,问题是虚拟网络拓扑比较复杂,性能一般。另外就是功能也有限,这个演讲提出 Firewall 发展的三级,第一级是实现基本的 ACL、第二级是实现状态防火墙、第三级是实现完整的 OSI 防火墙,可以做 DPI。那么防火墙能否用 OVS 实现呢?第一级很好做,第二级的关键问题是实现状态。如何实现状态?一种思路是用 openflow 中的 learn 动作,记录送出去的流量,效果不错,但流表不好看:

QQ20160502-38.png-180.2kB

另一个思路是通过 conntrack 记录状态,在 OVS 流表中增加 cs_state 字段,性能有提升,但远不如 learn 的实现:

QQ20160502-39.png-150.4kB

大家都比较郁闷 conntrack 实现的性能提升有限,所以下一步会将 conntrack 移到用户态提升性能,以及提升测试和易用性等等工作。

Integration of Neutron, Nova and Designate: How to Use It and How to Configure It

评分:3.5/5
简介:如何使用 Nova、Neutron、Designate 来完成虚拟机的 DNS name 的自动设置、DNS 记录自动添加以及集成外部 DNS(Designate)。
评论
上手实践的大课堂,基本内容和 http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html 一致。根据 User Survey 的资料,DNS 是很多用户关心的一个问题,根据我们的客户经验也确实如此,简单的来说,内部 DNS 使用网络(net)资源里的 dns_domain 属性设置 domain name,然后根据 nova 里虚拟机的名字(host name)来设置 dns name,这个 DNS 由 Neutron 里子网的 DHCP 服务器,dnsmasq 实现,所以要确保 Neutron 子网的dns_nameservers 属性正确,使虚拟机能用正确的 DNS nameserver。

QQ20160502-41.png-324kB

另一件事情就是与外部系统集成,这个就需要 Designate 项目的支持,目前 Designate 支持 Bind、Power DNS 这些开源 DNS 软件,也支持 Akamai、DynECT、Infoblox 这些外部 DNS 系统,也是蛮强大的,当然对于国内用户来说,可能 DNSPod 来的更实在一些。目前外部 DNS 有几种 Use case,包括创建 Port 时把 Port 的 DNS 信息推送到外部 DNS 系统、创建 Flaoting IP 时把 Port 的 DNS 信息推送出去、创建 Floating IP 时把 Floating IP 的 DNS 信息推送出去。

详细过程看文档或者视频吧。

SNAT High Availability Service in Neutron for Distributed Virtual Routers

评分:3/5
简介:介绍了 DVR 场景下 SNAT Router 的高可用功能。
评论
简单的说就是把过去 L3 HA 的功能移到 DVR SNAT Router 上了,过去 DVR 与 L3 HA 不能共存的问题终于得到了解决。

QQ20160502-42.png-215.9kB

未来有一些计划,例如更高效的控制平面、支持 BGP 等等。

Virtual Routers on Compute Nodes: A (Not So) Irrational Decision?

评分:3/5
简介:介绍了 TWC 公司在没有 DVR 时是怎么设计 OpenStack 架构的。
评论
简单的说就是把 L3 Agent 混布在所有计算节点上,他们管这个架构叫 VR-D,醉了……

QQ20160502-43.png-336.3kB

F5 Networks – Technically Speaking..Are You in or Are You Out?

评分:4/5
简介:很短的赞助演讲,但是内容不少,包括 F5 与 OpenStack 的 Roadmap、目前的实现、Demo 等等。
评论
最有价值的可能是这个 Roadmap 吧,但愿 F5 能按时完成:

QQ20160502-61.png-400.8kB

开发

Understanding ML2 Port Binding

评分:4/5
简介:这是一个 Cisco 的开发人员介绍 ML2 Port Binding 的专业演讲,简单介绍了 ML2 的架构以及 Port Binding 的作用,开发原理,需要考虑的因素和 case 等,对开发者来说是一个不错学习材料。
评论
有人说拿 Neutron 做一个 API Server,网络实现走外边的控制器或其他方案那么 Neutron 的任务是不是就很轻,就简单了呢,实际不是这样的。如果只是适配 OVS 一个实现,那自然很简单,但随着大家的需求增多,要能支持 SR-IOV、要支持 DVR、要支持 Hierarchical Port Binding 等,对 Neutron 提出了很高的资源抽象要求,所以现在你能看到 port 上如今有vif_typevnic_typevif_details等等属性:

QQ20160501-10.png-339.7kB

如果你想安全的完成 Neutron 与其他系统的对接,或者 Neutron 的一个 L2 Agent 的实现,你必须很清楚的了解 Nova 的 VIF 如何产生,如何通知到 Neutron,Neutron 如何为其配置流表、修改属性等等过程。很多人对 Hierarchical Port Binding 这一功能不大了解,我在这里简单介绍一下,Kilo 版刚出来时,很多人说这个功能带来了 Neutron 对 ToR 交换机的支持,这个说法是欠妥的,Neutron 所能带来的其实是一个逻辑的抽象和代码的可能性。我们知道过去的 Port Binding 里,关键是 L2 Agent 会随机分配一个“本地 Vlan”来解决同一宿主机下虚拟机间网络的隔离问题,然后在统一转成 VxLan 送出去。那么如果 VxLan 在 ToR 上实现怎么办呢?过去我们在 Server 测是看不到本地 Vlan 这个数据的,现在随着 Hierarchical Port Binding,多了一个ml2_port_binding_levels的表,配合ml2_network_segments,我们可以保存 Port 在一个 Host 上多级的绑定关系,从而配置 ToR 的 Mechanism Driver 就可以获得这些信息,正确的配置 ToR。

Deep Dive into Neutron Upgrade Story

评分:4.5/5
简介:介绍了 Neutron 升级中控制平面和转发平面目前的挑战和应对。
评论
Neutron 升级是一个挺揪心的问题,因为目前 Neutron 的参考实现导致 Neutron 和转发平面紧紧关联,特别对于一个私有云,控制平面的短暂不可用是还可以接受的,但是如果转发平面发生问题,那简直是 horrible。
这个演讲先介绍了整体的一个升级过程:代码升级、数据库升级、Neutron Server 升级、网络节点的 L2、L3、DHCP 升级、计算节点的 L2、L3(DVR)升级。

QQ20160502-9.png-202.7kB

具体的来说,Neutron Server 是无状态高可用的,但因为数据库升级的问题,所以必须得有一段时间关掉 Neutron Server,目前第一个解决措施是将 expand 和 conract 两类数据库操作分开,前者不会影响 Neutron Server 在旧的模式下运行,后者会,所以前者可以提前运行而不干扰 Neutron Server。那么后者呢,是否无解了呢?不是的,关键是引入 oslo.versionedobject,演讲者没有说太多 OVO 如何实现把数据 lazy migrate 到数据库,但是 it works,不需要太担心…… 另外一个 OVO 解决的问题是 RPC 的版本问题,这样你在写代码的时候就不需要额外担心 RPC 的版本问题了(以往 Neutron Server 中有一些比较丑陋的探测 RPC 版本的代码,比如尝试一个调用看看会不会由 exception,或者后来尝试 hardcode 一个版本号之类的)。OVO 目前还有很的路要走,而且需要所有开发者都按新的开发守则撰写代码,路漫漫啊。

QQ20160502-10.png-135.6kB

如果涉及到数据库 Schema 的 Drop 的话,简单的说如果要保证 API 的可用的话需要两次升级过程才能将 Schema drop 掉。具体见 Presentation 的演示。
关于数据平面,目前在 L2 Agent 上做了很多,例如对每个 flow 做一个带 UUID 的 cookie,那么重启时,我就可以先生成一把,再把旧的根据 cookie 删除了。如果你对 cookie 没印象的话,我来帮你一把:

QQ20160502-11.png-121.4kB

然而这个只涉及 br-tun,vlan 网络呢?很遗憾,目前还没解决……
此外社区为了保障之后的重启问题,还增加了 Grenade CI、Partial CI、DVR Testing 等等。
总结下来,我们做了很多工作,你说做完了吗?其实没有,Vlan 网络、L3 等等还没解决完,而且即使是 L2 Agent,也时常有 Patch 提出来(见 Neutron 社区每周记),敌人虎视眈眈,不能掉以轻心啊!

Service Function Chaining Technology Analysis and Perspective

评分:5/5
简介:对 SFC 的实现方法、现状和未来做了详细的阐述,做了一个 Demo 演示了目前通过 Tacker 可以做到的程度。
评论
对 SFC 还一知半解的同学有福了,这个 Presentation 详细介绍了 SFC 的实现方法,考虑到 Demo 演示的是 NSH 的方法,这里放一下 NSH 的实现原理以及与 Tacker、ODL 的集成原理:

QQ20160502-24.png-464.4kB

QQ20160502-25.png-401.5kB

可以看到现在的设计还有些混杂,所以最终还会有所变化,详见视频。最后简单描述了所有相关项目,为科普再一次做出巨大贡献。
介绍高屋建瓴、Demo 具体实际,好评。

Case Study Neutron IPAM APIs and External IPAM Integration

评分:3.5/5
简介:IPAM 算是 L 版的新功能,但是怎么用很多人都没概念,这个 Presentation 介绍了 IPAM 的意义、工作原理和 Use case。
评论
实际上只有前 10 分钟介绍的是 IPAM 本身,有了 IPAM 之后,分配 IP 将可以由外部系统控制:

QQ20160502-32.png-166.6kB

后面介绍的其实如何与 Romana,一个纯三层网络实现相集成,以及如何在上面再搞一个 Kubernets。

Neutron Address Scopes

评分:3.5/5
简介:介绍了 Address Scopes 的功能、作用和实现原理。
评论
Address Scopes 主要作用会在 IPv6(IPv6 没有 NAT 这个东西)、L2/L3 VPN 中,目前的应用场景其实很有限,大概也就划分“路由域”之类的。

QQ20160502-35.png-293.5kB

实现原理主要是基于 IPTables,之后如果不在一个路由域,即使在同一个路由器下流量与会被 Block:

QQ20160502-36.png-221.3kB

中规中矩,看头不大。

Evolving Virtual Networking with IO Visor

评分:4/5
简介:一个 BoF 会议,所以没有视频资料。介绍了 IO Visor 能起到的作用、Linux 网络目前遇到的挑战等等。
评论
IO Visor 是一个笔者也比较关心的项目,Linux 网络最近收到很大的挑战,一方面是高速网络的兴起,如今万兆网络在数据中心已是标配,20G、40G 也在不断发展,更甚至有 100G 的以太网;另一方面是 NFV、Overlay 的发展,服务器上再跑大量的网络基础设施,这对性能、监控等等都提出了巨大的挑战。

解决方法之一是放弃传统 Linux 网络协议栈,另起炉灶,例如 DPDK。Linux 内核的网络实现不够高效?基于中断的数据包收取不够迅速?那就另在用户态实现一套吧。然而所带来的问题就是 Linux Kernel 自带相当丰富、良好的技术生态圈,上面有 socket 这么好用的接口,上面有 netfilter、tc 这么好用的框架,上面有 systemtap、perf 这么好用的工具,你真的要重来一遍吗?

如果不放弃内核的话,如何改造?Linux 3.15 开始引入 eBPF,其特点是 JIT、指令集丰富。你可以在用户态愉快的写代码到内核执行,既完成了高效(无需用户态、内核态拷贝)又做到内核安全(你可以理解为在虚拟机执行,不会轻易造成 Kernel panic)。

QQ20160502-40.png-778.6kB

目前大家拿来主要做的事情在 monitor 和 trace 上,IOVisor 的一个项目叫 bcc,主要作用是帮助开发者减少 eBPF 本身的一些 dirty work 和复杂性,提供了现成的工具链和脚本,甚至提供了 Python SDK!你可以用 Python 去获取内核 softirq、TCP 连接、连接延时等等内核数据。将一些工具组合在一起,你可做出来一个很好看的 Overlay 网络展现工具(bcc 的一个 example):

bcc-vxlan-monitor.png-96.9kB

目前 eBPF 只被 PLUMgrid 的商业产品使用,PLUMgrid 用其实现了完整的 PLUMgrid 网络功能。

LinuxKernal-plumgrid.png-200.3kB

eBPF 前景如何呢?我是比较看好的,因为目前确实内核缺乏高性能而安全的网络工具链,eBPF 带来这一可能性,特别是现在严重缺乏 Overlay 层面的监控、trace 工具,前面介绍过 skydive 确实不错,但是为了发现拓扑需要用那么多工具,做 flow 分析的话 libpcap 性能低下而 sflow 不准确?或许 eBPF 将拯救世界。

MidoNet Scalability Testing with Neutron and Open Source Tools

评分:3/5
简介:介绍了 Midonet 如何做测试和发布,特别是 Scale 测试。
评论
MidoNet 的测试过程大概是这样的,主要工具是 ovs-sandbox、tempest、rally 这些:

QQ20160502-59.png-582kB

比较重要的是 Rally 只测试了 API 层面,怎么保证做 Scale 测试时 Agent 正常处理了呢?主要靠日志和其他监控。

QQ20160502-60.png-623.6kB

Mapping Real Networks to Physical Networks, Segments, and Routed Networks

评分:3.5/5
简介:介绍了 Neutron 里一些网路概念,比如 Segments、Network、Phynets、Routed Work。
评论
基本可以用这个图解释所有内容:

QQ20160502-58.png-261.1kB

有很大篇幅介绍 Routed Networks,有兴趣的话可以看下。

其他

Performance Measuring Tools for the Cloud

评分:4/5
简介:由包括海云的几位演讲者带来的 OpenStack 上用的各类 Performance 度量工具的介绍,关键词是 Rally, Cloud Bench, Ceph Benchmark Tool, SPECcloud。
评论
Rally 基本不用介绍了,OpenStack 上最常用的性能测试工具,有意思的事最近提交了这一 Patch:https://review.openstack.org/#/c/115439,可以为 Rally 带来在 VM 里跑 linpack 和 dd (已有)来衡量虚拟机 CPU 和磁盘性能的数据,将 Rally 的测试从 API 层扩展到了虚拟机性能。缺点是只支持 OpenStack,无法衡量不同云的性能情况。
CloudBench 支持很多平台,可以在 libvirt、OpenStack、SoftLayer、EC2、CloudStack、VMWare、GCE 上跑,执行的测试也是 SPEC、Hadoop、linpack、netperf 等等这些标准化测试,便于比较云平台。
SPECcloud 类似于 CloudBench,但是其标准化的考虑很多,有几篇很详细的报告说明其为何跑哪些测试,能反映出什么指标等等。可以对控制平面和数据平面做测试,metric 有弹性、扩展性、供给时间等。Workload 有 YSCB(Cassandra)和 Kmeans(Hadoop),前者考察 IO,后者考察 CPU 和 MEM。
CBT 全称 Ceph Benchmark Tool,可以用来测试 Ceph 的性能。

QQ20160502-1.png-321.7kB

Perfkit 本是 Google 的云性能检测工具,最近支持了 OpenStack,还可以支持 GCE、Azure、AWS、阿里云、DigitalOcean、Rackspace、Kubernetes、Mesos 等等,测试工具很全,详见其 Github。
演讲里还有一个是如何用 HAproxy 做性能的分析,主要是分析 HAproxy 的日志,也挺有意思的。
可惜的是没有人提 browbeat,这个项目其实也很有意思,也被 RedHat OpenStack 所使用。

Project Vitrage How to Organize, Analyze and Visualize your OpeenStack Cloud

评分:4/5
简介:Vitrage 是一个 Nokia 开发的运维辅助项目,主要作用是集成 OpenStack 的监控工具做可视化和报警压缩。
评论
开场是长达 4 分钟的酷炫动画,我差点以为这个演讲要全程动画了,还好后边及时换成了 PPT。运维有一个痛点是这样的,当你的云很大、监控项很多时,很可能发生一个故障引起一连串报警,你得在一连串报警中分析问题所在,很浪费时间而且撰写故障报告又得重新把所有报警理一遍确定却是所有故障已经处理完,还有发报警一般是要花钱的(比如短信和语音报警),一堆报警一起想起来很花钱……
举个例子,一个交换机 Down 导致几个宿主机网络连接挂掉,进而导致其上运行的虚拟机、分布式服务(例如Ceph)之类的服务都挂掉,这时你可收到很多很多报警例如交换机 Down 的报警,服务器网络 Down 的报警,VM 网络 Down 的报警、Ceph 的 osd down 的报警等等,然而真正有用的其实是第一个!能否压缩报警呢?再比如一个 Region 的 ISP 网关挂了,那我们各种报警是不是得收到手残?(所有交换机、服务器、虚拟机无法连接到公网,想象一下得多少报警)

Vitrage 通过一个 Yaml 格式的配置文件定义各种 Alram 的依赖关系,可以通过简单的逻辑运算符组合各种情况,最终达到如果符合我们预期的某些场景,那么只需要将根本原因的报警发出来就可以的目的。

QQ20160502-2.png-301.9kB

项目不错,而且开源还有 Demo,4 分的原因是 Demo 只有展示,没有现场定义个模版然后触发个报警这样的演示。

Intelligent Workload HA in Openstack

评分:4/5
简介:一般来说,我们在 OpenStack 上做 HA 都是 Reactive 的,什么意思呢,就是出了事情去迁移 Workload,TATA 介绍了他们的基于 Proactive 算法的自己整合的一个 Workload 监控和迁移系统。
评论
演讲先简单说明了现有系统的不足,例如 Ceilometer 没有网络冗余,pacemaker 只能使用管理网(笔者注:这是使用架构问题,pacemaker 可不背这个锅),Zookeeper 无法在很大的 Scale 下使用,Consul 需要很多的消息,nagios、sensu、zenoss 则是没有自动恢复的实现(笔者注:想立项要经费直说,为何立这么多敌……)。基本架构是这样的:

QQ20160502-4.png-295.9kB

有意思的地方是继承了 IPMI 工具和 Intel Node Manager 等等。然后有了监测指标,我们就可以定义动作了:

QQ20160502-5.png-433.8kB

例如如果因为某些虚拟机的 Workload 造成整个宿主机的负载问题做主动迁移、根据宿主机负载做 VM 的负载均衡等等,确实对一些用户有需求。
最后的 Demo 展示了因为虚拟机多而导致宿主机的 CPU 温度升高然后被自动调度到其他宿主机的例子,挺有意思的。智能化的 Workload 平衡、主动化的 HA 是否重要呢?见仁见智,4 分。

Senlin Clustering Service Deep Dive

评分:3.5/5
简介:由 IBM 三名中国同事出品的 Senlin 的介绍,重点介绍了 Senlin 项目的意义和架构,其次是本 Cycle 的一些 Feature、计划的 Feature 等。
评论
很多时间依然在科普上,说明还是任重道远啊。替启明做一些普及工作吧,首先为什么要有 Senlin 这个项目?主要是 Heat 的设计是基于 AWS 的,不够通用,目前我们认为 Heat 的作用更多的在于基于模版的资源管理,它的重点不在与 AutoScaling、HA,而是作为一个引擎来帮其他服务或者开发者做资源管理的工作。

QQ20160502-6.png-391.2kB

而 Senlin 的架构完全是为 HA 和 AutoScaling 设计的,甚至可以不用在 OpenStack 上,和其他 CMS 整合。例如有 receiver 模块可以直接集成各种 webhook、message,而不只是 Ceilometer 的消息;比如 policy 可以有替换、删除、扩展、负载均衡、健康、亲和性等,而不只是 low-level 的 CRUD 这些语义;比如 profiles 模块可以是 Heat 的 stack,也可以是 Nova 的 server,后面可以再接 openstacksdk,这样你可以为不同的云后面接 API(比如都是 OpenStack 版本也可能不同呢)或者做跨云的资源管理,因为这个架构的灵活性都是可能的。

QQ20160502-7.png-481.7kB

大概就是这样,祝这个第一个由国人发起、拼音命名的 OpenStack TC 项目健康发展!

Deploy an Elastic, Resilient, Load-Balanced Cluster in 5 Minutes

评分:4.5/5
简介:通过 Senlin 项目在 OpenStack 上搭建一个弹性、自动伸缩的集群。
评论
同样是介绍 Senlin,但是这个介绍更加实战,首先对 Senlin 能做 Heat 不能做的 Case 作了具体的说明:

QQ20160502-14.png-273.2kB

然后启明的介绍和上一篇是类似的,最后做了一个 Demo 可以看到模版如何撰写,Profile 是什么样的等等。
如果关于 Senlin 的 presentation 中你只能看一个,而且你对 Senlin 没什么直接印象,那一定是看下面这个。

OpenStack Stable

评分:4/5
简介:稳定版是一个 OpenStack Provider 们很关心的问题,这个 Presentation 介绍了什么是稳定版,如何制作,如何保持稳定版的新鲜,目前的困难和下一步计划,对提供 OpenStack 的供应商来说还是值得一看的。
评论
不对外提供 OpenStack 的人很难理解其中的苦衷,但是每个为企业提供服务的 OpenStack 厂商都深受其苦,原因不乏 OpenStack 官方更新过快、OpenStack 目前 Bug 修复没有很严格的评定标准和 backport 标准,这对维护包的 maintainer 来说简直是一个灾难。

QQ20160502-8.png-241.9kB

演讲最后介绍了目前开发的一些脚本和工具等来更加自动化未来的稳定版维护,hope it works.

Automated Security Hardening with OpenStack-Ansible

评分:4/5
简介:如何提供一个安全的 OpenStack 云?目前一些 OpenStack 供应商可能需要雇佣专业的安全公司来保障其部署架构和部署结果是安全的,Rackspace 的架构师介绍了 Openstack Ansible Security 这个项目。
评论
其实这个世界上安全工具和守则已经挺多了,关键是你的意识是否到位。例如有现成的 Security Technical Implementation Guide(STIG)项目,那么你是否按照要求做了配置和打了补丁?相信很多公司都没做到。

QQ20160502-12.png-243.7kB

那怎么办?专门雇一个人每天看 STIG 文档检查所有机器的配置吗?显然不现实,我们可以用 Ansible 来做这件事情。那就是 openstack-ansible-security,它会帮你自动检查和配置 STIG 上的安全建议,帮助你达到 PIC-DSS 的标准。

QQ20160502-13.png-207.4kB

值得一说的是 OpenStack 还有 syntribos(Web 安全测试)、bandit(代码安全检查)、OSSA(安全建议)等等项目,一直在提升 OpenStack 的安全性。4 分的原因是明明 10 分钟能说清楚的事情硬说了 32 分钟,而且目前不支持 CentOS7,否则应该是 4.5 分。

Open Stack at Carrier Scale

评分:3/5
简介:介绍了 AT&T 总结的运营商云和传统私有云的架构、设计等等上面的区别。
评论
前面介绍了 AT&T 的规模很大:

QQ20160502-16.png-446.3kB

然后介绍了运营商区别的种种特别之处:

QQ20160502-17.png-321.7kB

着重说明了网络层面的不同需求:

QQ20160502-18.png-375.4kB

可惜如何解决这些 challenge 说的比较简单,也可能是笔者不做运营商 get 不到其中的 point。总之对了解运营商云还是有一定帮助的。

Ceilometer, Nova and Neutron – Working Together to Provide a Healthy Network for Your Cloud

评分:3/5
简介:如何用 Ceilometer 辅助打造一个更健康的云网络。
评论
笔者看完表示被老印的奇思妙想深深的伤害了…… 他们为什么这么喜欢在调度上做文章,类似于前边的 Intelligent Workload HA in Openstack,你可以通过监控工具把交换机上端口状态、带宽等等数据取出来,发到 Network Health Monitor 里边,计算出一个 Health Score 放到 Nova 的 Schedular 里,实现调度层面的网络负载均衡。

QQ20160502-44.png-250.8kB

Distributed NFV & OpenStack Challenges and Potential Solutions

评分:3.5/5
简介:使用 OpenStack 搭建 NFV 网络所遇到的挑战与一些解决方案。
评论
主要的挑战是这些:

一、启动虚拟机时需要保证虚拟网卡的名字和顺序的一致性;
短期解决措施是 Nova 启动时用 metadata 将设备与 MAC 的对应关系注入进去。这个方法显然很麻烦,所以另一种长期方案是与 Glance 一起在镜像中定义好 pci 设备的地址和 tag。另外虚拟网卡拔插后命名行为同样不一致也很坑,比如一个 VM 存在 eth0, eth1, eth2 三个网卡,那么把 eth1 拔下来再插上有可能还是 eth0,还有可能变成 eth3,甚至有可能没法用了……这个需要和 VNF Vendor 社区一起想办法。

二、Service Chain 的修改;
这个需要 networking-sfc v2 对 nsh 的支持

三、数据安全性
目前主要靠 VPN 解决,希望将来能有设计上更加安全的架构来解决。

四、OpenStack Controller 的 Scalability
主要是运营商的 Scalability 往往比较大而且分布很广,那么控制面怎么设计就会很麻烦,短期的解决方案是边缘(Edge)区域不设置控制平面,或者直接用 libvirt 来控制,远期思路是有一个轻量级的控制平面。类似于华为之前提的 TriCircle 之类的。

五、启动风暴
很好理解,主要是大量虚拟机启动时会对控制平面和网络形成一个冲击,解决思路主要是网络上尽量本地响应,控制平面也尽量能扩展到边缘,就像上面说的那个问题。

六、OpenStack 的向下兼容
OpenStack 的更新很快,可能导致出现很多版本不一致的 OpenStack,而且由于 VNF 的兼容性问题还不能轻易升级,解决方案是 back-port,社区提供长期支持版本等等。

QQ20160502-45.png-533.3kB

讲的也挺好的,可惜笔者确实没什么运营商经验,所以难以评判。

Nova Cells V2 What s Going On?

评分:4/5
简介:Nova Cell 是 Nova 社区提供的一种增强 Nova 的 Scalability 的手段,从 Nova Cell v1 开始已经被成功应用到一些部署环境中,本场 Presenatation 将介绍 Cell v2 的设计初衷、架构和目前的实现。
评论
Nova Cell v1 其实不错,可以有效解决数据库和消息队列的扩展性问题,但是两级调度的设计里,上一级调度往往缺乏细粒度的信息,而且消息队列的使用是基于 Relay 的,代码存在 Race Condition,缺乏一些 Feature 等等。这导致目前实际上 Nova Cell 的部署案例很少、熟悉的开发者也很少、从无 Cell 架构升级也很困难。

社区从老版的 Cell 的设计也学到很多,包括不要重复数据、应该尽量进入默认选项还有 Parent Cell 这个设计导致 Parent Cell 的 Scale 并不好。

下面就要说 Nova Cell v2 的设计了,新的 nova_api 数据库将全局性的数据保存在一个地方、Nova cell 将成为默认的部署方式、全局信息尽量得少。

QQ20160502-49.png-173.2kB

其中 API Cell 运行 API 服务和 API DB,一个 cell0 用来保存 Fail 的主机,其他的 Cell 运行自己的 DB、MQ、Conductor 和 Compute 服务。与 v1 的重要区别是没有了 nova-cell 这个服务,树型架构被舍弃了,cell 内不在保留 scheduler。不过现在还在开发,所以这个架构设计也不是最终结果。

讲的很平淡,但是 Nova Cell v2 是个对大规模部署很重要的事情,所以建议一看。

Troubleshooting oslo.messaging RabbitMQ issues

评分:4/5
简介:RabbitMQ 是 OpenStack 里最受诟病的组件之一,在找到更好的解决方案之前,你先要能 Debug 问题所在。
评论
先介绍了 oslo.messaging 和 OpenStack 中 RPC 的使用场景。演讲者先提到了最有意思的报错是 MessagingTimeout: time out waiting for a reply to message ID xxxx 这个,却是,这是我们最常见的报错之一…… 这个报错是怎么怎么来的呢,首先三个 RPC 场景——Cast、Notify、Call 三个场景只有 Call 会出这个问题,因为 Call 需要返回值(客户端),那么 MQ 没有成功把消息发给服务端、或者服务端没有正确处理、或者服务端没有将返回发给 MQ、或者 MQ 没有正确把消息发给 Client,都可能会报这个错!

第一个 tip 是打开 oslo.messageing 的 debug 日志,第二个是看服务的日志。还有在 MQ 上看 Queue 的消费者情况,是不是消费者挂了?或者集群分区了?一般来说,重启相关服务或者强制关闭连接是比较靠谱的……

有一些建议是不要打开 amqp_auto_delete,最好不要打开 Queue mirroring,如果你实在需要消息高可用(比如涉及支付系统),那么可以考虑只对 notification 开,RPC 是不需要的。

此外还有跟 RabbitMQ 本身的一些 debug 建议,比如内存使用、DB 状态、文件描述符、TCP 连接 backlog 大小等等。

说一些笔者想说的重点,https://review.openstack.org/#/c/249508 这个 Patch 还是很重要的,可以把 Notification 和 RPC 用的 MQ 分开,如果你看过 Performance Analysis in Large-scale Deployment – A Single Thousand nodes Cluster 或者 Tuning RabbitMQ at Large Scale Cloud 这两个 Presentation,你会看到他们的设计也没有特别标新立异的地方,关键还是把热点分离。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

你可以管理本篇文章的订阅。

Post Navigation