干货分享:网易OpenStack部署运维实战

配置优化

　　在网易私有云的稳定性得到了保障之后，我们开始了性能方面的调优工作。这一方面，我们参考了 IBM 公司的一些 优秀实践，在 CPU、内存、I/O 等方面做了一些配置方面的优化。整体而言，网易私有云在注重稳定性的基础上，也会积极借鉴业界优秀实践来优化私有云平台的整体性能。

CPU 配置优化

　　为了保障云主机的计算能力，网易私有云开发了 CPU QoS 技术，具体来说就是采用 cfs 的时间片均匀调度，外加 process pinning 的绑定技术。

　　参考 IBM 的分析，我们了解到了 process pinning 技术的优缺点，并且经过测试也验证了不同绑定方式的云主机间的性能存在较大的差异。比如，2 个 VCPU 分别绑定到不同 numa 节点的非超线程核上和分配到一对相邻的超线程核上的性能相差有 30%~40%(通过 SPEC CPU2006 工具测试)。另一方面，CPU0 由于处理中断请求，本身负荷就较重，不宜再用于云主机。因此，综合上面的因素考虑以及多轮的测试验证，我们最终决定将 0-3 号 CPU 预留出来，然后让云主机在剩余的 CPU 资源中由宿主机内核去调度。最终的 CPU 配置如下所示（libvirt xml 配置）：

<vcpu placement='static' cpuset='4-23'>1</vcpu><cputune>    <shares>1024</shares>    <period>100000</period>    <quota>57499</quota></cputune>

内存配置方面，网易私有云的实践是关闭 KVM 内存共享，打开透明大页：

echo 0 > /sys/kernel/mm/ksm/pages_shared    echo 0 > /sys/kernel/mm/ksm/pages_sharing    echo always > /sys/kernel/mm/transparent_hugepage/enabled    echo never > /sys/kernel/mm/transparent_hugepage/defrag    echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

经过 SPEC CPU2006 测试，这些配置对云主机 CPU 性能大概有 7%左右的提升。

I/O 配置优化

1）磁盘 I/O 的配置优化主要包含如下方面：

KVM 的 disk cache 方式：借鉴 IBM 的分析，网易私有云采用 none 这种 cache 方式。

disk io scheduler：目前网易私有云的宿主机磁盘调度策略选用的是 cfq。在实际使用过程中，我们发现 cfq 的调度策略，对那些地低配置磁盘很容易出现 I/O 调度队列过长，utils 100% 的问题。后续网易私有云也会借鉴 IBM 的实践，对 cfq 进行参数调优，以及测试 deadline 调度策略。

磁盘 I/O QoS：面对日渐突出的磁盘 I/O 资源紧缺问题，网易私有云开发了磁盘 I/O QoS，主要是基于 blkio cgroup 来设置其 throttle 参数来实现。由于 libvirt-0.9.12 版本是在 QEMU 中限制磁盘 I/O，并且存在波动问题，所以我们的实现是通过 Nova 执行命令方式写入到 cgroup 中。同时我们也开发并向 libvirt 社区提交了 blkiotune 的 throttle 接口设置 patch（已在 libvirt-1.2.2 版本中合入）来彻底解决这个问题。

2）网络 I/O 的配置优化

我们主要是开启了 vhost_net 模式，来减少网络延时和增加吞吐量。

运维经验

使用经验

• 开源软件 bug 在所难免，但是新版本比旧版本会好用很多，尤其是对于 OpenStack 这种正在迅速成长壮大的开源软件来说更是如此，这一点在我们使用过 Essex、Folsom 和 Havana 版本后深有体会，所以建议各种 OpenStack 用户能及时的跟进社区版本，与社区保持同步。
• 不要轻易的对社区版本进行各类所谓的功能性能方面的"优化"，尤其是在没有与社区专家交换意见之前，千万不要轻易下手，否则此类"优化"极有可能演变成故障点或者性能瓶颈点，最终可能导致无法与社区同步，毕竟一个公司或团队（尤其是小公司、小团队）的能力和知识储备，是很难与社区成百上千的各类专家相提并论的。
• 多参考各类大型公司分享的部署架构方案，尽量不要自己闭门造车，尤其是对于开源软件来说，各类公司、团队的使用场景千差万别，各种周边组件也是应有尽有，多参考业界实践是最好的方式。
• 一些细节实现可能有很多途径，但每种方式都有优缺点，需要经过充分的论证、分析、测试验证后，才能考虑部署到生产环境使用。
• 所有的部署方案、功能设计都要考虑到平滑升级问题，即使你得到的信息是升级时可以停服，仍然要尽量避免这种情况，因为停服的影响范围很难界定。

运维准则

OpenStack 也是一个后端系统服务，所有系统运维相关的基本准则都适用，这里简单的提几点实际运维过程中根据遇到的问题总结的一些经验：

• 配置项默认值与实际环境不匹配可能导致各种问题，尤其是网络相关配置与硬件有很强的关联性，生产环境和开发环境硬件异构，导致部分默认值在生产环境不适用。应对准则：每个版本都必须在与线上硬件相同的环境测试过才能上线。
• 做好容量规划，已分配的配额量要小于云平台总容量，否则会出现各种问题，导致运维开发耗费很多不必要的精力去定位分析问题。
• 配置项过多容易出错，需要与开发人员一起仔细核对，上线时首先要通过 puppet 的 noop 功能验证改动是否正确后，才能真正上线。
• 网络规划要提前做好，如固定 IP、浮动 IP、VLAN 数量等，网络扩容难度和风险都比较大，所以提前规划好是最保险的，一个原则是大比小好，多比少好。
• 网络隔离要做好，否则用户网络安全没办法保证。
• 信息安全问题要重视，这个是老生常谈的问题了，每个平台都有相同问题，但还是要重视再重视，一旦出现安全漏洞，所有虚拟机都面临严重威胁。