Openstack并行性能加速(转)

在google时，看到一篇极佳的博客,Boosting OpenStack’s Parallel Performance，内容聚焦于OpenStack并发性能的，在接触OpenStack以来，很少有看到谈论OpenStack性能的文章，而这篇博客作者Peter Feiner对此问题写的极其用心，详尽而全面，故将其转载过来，并翻译一下，帖在这儿。

在开始正式的翻译之前，需要先明确一下简单的背景: Peter Feiner的这篇博客发表在今年6月份，性能改善都是在OpenStack Grizzly版本上进行的，作者贴出的诸多改善OpenStack Grizzly的parallel performance的patches目前大部分已经集成到了OpenStack Havana代码中了，还有部分patches可能会在Icehouse中集成。尽管现在在Havana版中已经享受到大神的成果，但是还是看看这篇博客，知道OpenStack中会涉及哪些性能问题，有什么改进方法，还有大神严谨的工作态度，这些都受益匪浅。

翻译过程中努力理解作者的意思，若翻译错处，敬请谅解。

好，正式开始！

摘要

---

OpenStack Grizzly 在并行性能（原文是：parallel performance）上表现不好。例如，在单台计算节点上，创建虚拟机的过程必须是串行的，这样就导致OpenStack在单台节点上横向扩展虚拟机数量时不是高效的。但是通过重新配置计算节点和对OpenStack Grizzly 打上一些补丁，可以将在同台计算节点上同时创建40台虚拟机并且通过ssh访问它们所需的时间降低74%。

引言

---

在充分利用服务器性能方面，虚拟化技术就是一个好的机制。一般，在服务器上，虚拟机作为应用的基本单元，当应用的负载增加时，就需要创建更多的机器来处理负载了，而虚拟机不能立刻创建出来，所以负载量往往被提前充分的预测了而允许创建新的虚拟机来准备服务用户请求。系统创建虚拟机的时间越长，那么就需要预测更长时期内的负载情况，而这样会导致预测的准确度下降。为了防止不准确的负载预测问题，操作人员往往需要超额配置虚拟机(over-provision virtual machines)。然而，在最理想的情况下，超额配置是低效率的，在最坏的情况，超额配置又可能不足够。因此，能够迅速的创建虚拟机是对于使用虚拟机的应用横向扩展的必须要求。此外，当横向扩展时，多个虚拟机常常会同时被请求提供服务（例如，多租户，虚拟桌面云平台），因此对于扩展来说，迅速的并行创建虚拟机是必须要具备的特征。

在几个月前的OpenStack Summit 上（作者写此文是的前几个月），我做了一个关于Scaling the Boot Barrier: Identifying $ Eliminating Contention in Openstack的演讲，主要关于在Ubuntu 12.04使用libvirt，kvm，然后在上部署OpenStack Grizzly，并行的创建虚拟机较慢的问题。我观察到，创建20台虚拟机实例比创建单台虚拟机实例多20多倍的时间，并且，并行创建虚拟机的数量增加了，创建的时间也线性增加。因为，我做实验的机器有足够的硬件资源去并行的运行20台虚拟机实例，显然的，软件资源的竞争(原文是：software contention)(例如，锁) 序列化了实例的创建。

在我演讲中，我介绍了一些鉴别software contention的技术，并举例说明了虚拟机实例创建过程中导致串行化最为糟糕的原因，还解释了我为解决一些software contention问题而写的patches。不幸的是，最初，我提供的patches并没有如我所期待的大幅提高启动时间。后面，我总结了我的演讲和大家的一些评论。现在，我要开始不负众望的实现我的承诺。

在这篇博文中，我将呈现我提供OpenStack 性能的技术。最初，我从OpenStack中移除了software contention的代码，让创建实例更加并行化。然而，一旦足够的序列化被移除了，硬件又成为了导致并行启动性能瓶颈的因子。所以，下面我将讨论的技术将高效并且消除竞争。

这些技术分为两类： 需要对OpenStack打补丁的和不要的。一般的patches已经被接受了或快完成review了。所以我希望所有的patches都能够包含到OpenStack Havana中。 后者只是OpenStack配置上的改变，你可以应用到OpenStack Grizzely集群中去（在havana版本中，这些配置应该同样很有帮助。）

Techniques that Don’t Reuire Patches

---

在Ubuntu12.04上，OpenStack和libvirt的默认配置导致了虚拟机实例创建的高度串行化。这一节就讨论改变配置来提升并行性能。

Running N nova-api workers

Nova-api直接访问数据库（注意：这是说的Grizzly版）。 Since the database connection driver is typically implemented in a library beyond the purview of eventlet's monkeypatching(ie, a native python extension like _mysql.so)，（这句话我的理解是：数据库连接驱动的实现是基于一个库，而这个库不能用eventletmokeypatch改造。从后文中还提到过，应该是这个意思），阻塞的数据库调用操作会阻塞所有的eventlet协程。因为nova-api的大部分工作就是访问数据库， 一个nova-api进程处理请求是串行的。

你可以简单的运行多个nova-api进程来缓解这个问题。 假如，你需要并行的启动40个虚拟机实例，那么在nova.conf中设置osapi_compute_workers=40。所有的nova-api进程都会在主进程在http socket上调用了listen函数之后创建出来。 现在，当一个client连接到server上来时，那么会存在一个nova-api进程从中竞争获胜出来处理请求。因此，你有N个nova-api进程，至少可以并行处理N个client请求。一个进程不太可能在一个时刻处理1个以上的请求， 因此在一个nova-api进程中串行处理数据库调用没多大实际意义。

需要注意的是，还存在其他方法可以用来阻止数据库调用时导致eventlet thread阻塞。然而，这些方法没有一个比创建多个nova-api更管用。

• 替代原生的数据库驱动，例如_mysql.so。可以使用pure-python driver， 例如通过在nova.conf中设置sql_connection=mysql+pymsql://.... 来使用pymysql，这个驱动eventlet将会通过使用monkeypatch来避免阻塞。这种方式相比使用原生的驱动，更加的消耗更多的CPU。因为pure-python driver是一个CPU密集型的驱动， eventlet thread 将花费更多的时间来于数据库交互，这导致我们前面提到的问题更严重。

• 代替从eventlet thread中发起数据库调用，可以提交数据库调用到eventlet pool的workers，然后等待结果。可以通过所设置 dbapi_use_tpool=True达到上述的目的。我发现的这个方法主要在workers threads之间同步的花销。特别的， worker thread 结束到等待协程恢复的时间开销往往比数据库调用的花费的时间还要多。

Use quantum for Security Groups, not nova-compute

尽管你在使用quantum来代替nova-network，而你可能还在使用nova-compute来处理firewall rules。

security groups的firewall rules可以通过nova，也可以通过quantum实现，二者皆可。使用Nova时，当一个新的虚拟机实例被创建，nova-compute将会序列的处理所有的security group工作和其他的实例创建工作，而对于quantum来说，会并行的处理security group与其他实例创建的工作。

配置nova使用quantum来代理防火墙更新的工作，可以在nova.conf配置：

[DEFAULT]
firewall_driver =