前言
最近自己在搞一个 OpenStack Octavia Amphorae 负载均衡性能的测试，花了几天时间，很遗憾没有达到预期的结果，不过也有收获到一些经验，感触良多。本文不会涉及到任何测试步骤和测试数据，只作为一次性能测试及优化经历的回顾。
遇到的问题
有用的经验大多从解决的问题中获得。
安装操作系统
没有错，从操作系统安装开始，这个测试就注定会在磕磕碰碰中进行。
- 问题：无法进入 DELL R720 服务器 Boot Manager 界面。
很久没碰服务器了，感到很生疏。拿到服务器首先给它配上 RAID，参考文章：《DELL R720 服务器 RAID阵列卡配置介绍》。然后使用 U 盘安装操作系统，参考文章《Dell R720服务器设置光盘引导流程安装 CenOS7》，主要是要搞清楚 DELL R720 的 LIFECYCLE CONTROLLER 的操作流程。可能需要对 Boot Manager 做一些配置，然后进入到 Boot Manager 选择 USB bootable 启动系统。
- 问题：安装 CentOS7 时为了省事选择「自动划分磁盘分区」最终导致了 Nova Placement 磁盘空间紧缺的问题。
切忌安装操作系统的时候一定要手动的进行分区。一是可以检查服务器上还有没有残留的操作系统或者分区，如果有的话，就视乎于实际情况将其清理干净；二是因为 CentOS 自动分区默认只给了跟目录 50G 的 size，这个问题我在安装完 Devstack，启动虚拟机的时候才暴露出来。nova-compute resource tracker 的 Libvirt Driver 会把 nova.conf 配置项 instances_path 指定的文件路径所在的分区容量作为 resource provider 的 DISK_GB，而这个 DISK_GB 就是创建虚拟机时进行资源调度的数值。所以，我就遇见了空有 1500G 磁盘，但却只有 50G 可用的尴尬。当然 workaround 的方式就是修改 instances_path 指向的分区，但这种方式在已经运行了虚拟机的环境中可能会遇到一些麻烦，而且还需要删除原有的 resource provider 之后才能更新新的 DISK_GB 数值，实在是麻烦。那么能不能对原有分区进行扩容呢？当然可以，前提是你还有空余的磁盘空间，如果你想先把别的分区进行缩容的话，很可惜 xfs 文件系统不支持缩容。
可见，再部署 OpenStack 的时候，就应该根据部署方式的不同来规划好操作系统的安装细节，这样能够省去很多不必要的麻烦。
基准的确定
就性能测试而言，怎么确定测试参数及每个参数的基准是非常重要的第一步，我认为这应该作为测试方案的首要部分。性能参数跟测试环境的方方面面都有关联性，为了最求最高的某一项性能很可能会为此放弃其他的性能项目，所以即便你已经掌握了一个业界水准的性能数据，也不能作为当前环境中测试的基准。
以这次测试为例，实际上我要测试的是 Amphorae 虚拟机中 HAProxy 对 TCP 连接的并发请求峰值。所以我应该在同一台物理服务器上直接测试 HAProxy 的性能并根据预期的调优方式获得性能峰值。然后在同一台物理服务器上测试运行在 Amphorae 虚拟机中的 HAProxy 的性能数据。期间逐步添加性能调优的方法，观察性能数据是否正向上升。
可知在相同的条件下，Amphorae HAProxy 的性能数据肯定会低于物理机上直接运行的 HAProxy 性能参数。所以更明智的做法是，不应该将任何外部公开的性能指标作为基准，而是应该以自己的测试环境为准。
杜绝压力机和负载机的瓶颈
我设计的测试模型中具有压力机、负载机和测试机等对象：
- 压力机：负责打压
- 负载机：负责承受业务压力
- 测试机：Amphorae，负责承受访问和转发
显然，测试机才是我们核心关注的对象，是性能优化的关键。前提是压力机和负载机没有成为你的瓶颈，只有在保证这个前提的基础上，测试所得到的数据才是最真实的数据。
解决这个问题的思路是逐步建立经验数据，以一个预估的步进逐渐扩展压力机和测试机的规模。理想的结果可以观察到性能数据会随着压力机和负载机的水平扩展而线性增长。在保持压力机和负载机的常规资源（CPU、内存）不超过 80% 的情况下，水平扩展直到性能数据到达峰值。
在达到峰值之，并不意味着不再扩展压力机和负载机，而是应该继续扩展一个合理的规模。例如在 10 台压力机的情况下到达了峰值，那么还应该再继续扩展至 12-15 台，然后在这样的条件下摸索性能的瓶颈，对 Amphorae 测试机进行调优。
总结
一句话总结一下最重要的三点收获：
- 前期规划：这个跟经验挂钩，经验欠缺的话该走的坑还是要走
- 确定基准：盲目的测试没有意思，确定一个基准目标之后再针对性攻坚才是正确的姿势
- 测试瓶颈：只有核心测试对象才应该成为瓶颈，杜绝压力机和负载机引入的瓶颈，这样的数据才有意义
性能测试及优化涉及到非常底层的操作系统和网络知识，所以实际上是一个不太容易完成的事情，需要非常多的耐心从理论上分析瓶颈的原因然后再通过合理的方式去验证，从而解决瓶颈达到新的高度，这是一个没有边际的行动，但也会带来非常丰厚的知识量收获，如果你愿意踏实的去消化的话。OpenStack 的性能测试尤为之难，难在你必须要对计算、存储、网络、操作系统都得懂，缺少一块都无法独当一面，无法全盘的考虑解决问题的思路。