【编者按】OpenStack自 2010 年项目成立以来，已经有超过 200 个公司加入了 OpenStack 项目，目前参与 OpenStack 项目的开发人员有 17,000+，而且这些数字还在增加，作为一个开源的IaaS实现，目前在企业的应用越来越普遍，网易公司私有云团队分享了他们在基于OpenStack 开发的一套云计算管理平台的实战经验，期待和广大的OpenStack 使用者进行交流。
以下为原文：
本文为您介绍了网易公司基于 OpenStack 开发的一套云计算管理平台，以及在开发、运营、维护过程中遇到的问题和经验分享。网易作为大型互联网公司，IT 基础架构需要支撑包括生产、开发、测试、管理等多方面的需要，而且需求和请求的变化几乎每天都存在，这就需要内部的 IT 基础架构能够足够灵活和健壮来满足各部门和团队的实际需要。网易私有云平台团队也希望通过本文和广大的 OpenStack 使用者进行一个交流，分享他们在实际项目中收获的成果。
OpenStack 简介
OpenStack 是一个开源的 IaaS 实现，它由一些相互关联的子项目组成，主要包括计算、存储、网络。由于以 Apache 协议发布，自 2010 年项目成立以来，超过 200 个公司加入了 OpenStack 项目，其中包括 AT&T、AMD、Cisco、Dell、IBM、Intel、Red Hat 等。目前参与 OpenStack 项目的开发人员有 17,000+，来自 139 个国家，这一数字还在不断增长中。
OpenStack 兼容一部分 AWS 接口，同时为了提供更强大的功能，也提供 OpenStack 风格的接口（RESTFul API）。和其他开源 IaaS 相比，架构上松耦合、高可扩展、分布式、纯 Python 实现，以及友好活跃的社区使其大受欢迎，每半年一次的开发峰会也吸引了来自全世界的开发者、供应商和客户。
OpenStack 的主要子项目有：
网易私有云使用了 Nova、Glance、Keystone、Neutron 这 4 个组件。
Compute（Nova）提供计算虚拟化服务，是 OpenStack 的核心，负责管理和创建虚拟机。它被设计成方便扩展，支持多种虚拟化技术，并且可以部署在标准硬件上。 Object Storage（Swift）提供对象存储服务，是一个分布式，可扩展，多副本的存储系统。 Block Storage（Cinder），提供块存储服务，为 OpenStack 的虚拟机提供持久的块级存储设备。支持多种存储后端，包括 Ceph，EMC 等。 Networking（Neutron）提供网络虚拟化服务，是一个可拔插，可扩展，API 驱动的服务。 Dashboard 提供了一个图形控制台服务，让用户方便地访问，使用和维护 OpenStack 中的资源。 Image（glance）提供镜像服务，它旨在发现，注册和交付虚拟机磁盘和镜像。支持多种后端。 Telemetry（Ceilometer）提供用量统计服务，通过它可以方便地实现 OpenStack 计费功能。 Orchestration（Heat）整合了 OpenStack 中的众多组件，类似 AWS 的 CloudFormation，让用户能够通过模板来管理资源。 Database（Trove）基于 OpenStack 构建的 database-as-a-service。
网易私有云平台概况 图 1.网易私有云架构
网易私有云平台由网易杭州研究院负责研发，主要提供基础设施资源、数据存储处理、应用开发部署、运维管理等功能以满足公司产品测试/上线的需求。
图 1 展示了网易私有云平台的整体架构。整个私有云平台可分为三大类服务：核心基础设施服务（IaaS）、基础平台服务（PaaS）以及运维管理支撑服务，目前一共包括了：云主机（虚拟机）、云网络、云硬盘、对象存储、对象缓存、关系型数据库、分布式数据库、全文检索、消息队列、视频转码、负载均衡、容器引擎、云计费、云监控、管理平台等 15 个服务。网易私有云平台充分利用云计算开源的最新成果，我们基于 OpenStack 社区的 keystone、glance、nova、neutron 组件研发部署了云主机和云网络服务。
为了与网易私有云平台其他服务（云硬盘、云监控、云计费等）深度整合以及满足公司产品使用和运维管理的特定需求，我们团队在社区 OpenStack 版本的基础上独立研发了包括：云主机资源质量保障（计算、存储、网络 QoS）、镜像分块存储、云主机心跳上报、flat-dhcp 模式下租户内网隔离等 20 多个新功能。同时，我们团队在日常运维 OpenStack 以及升级社区新版本中，也总结了一些部署、运维规范以及升级经验。两年多来，网易私有云平台 OpenStack 团队的研发秉承开源、开放的理念，始终遵循"来源社区，回馈社区"的原则。在免费享受 OpenStack 社区不断研发新功能以及修复 bug 的同时，我们团队也积极向社区做自己的贡献，从而帮助 OpenStack 社区的发展壮大。两年来，我们团队一共向社区提交新功能开发/bug 修复的 commits 近 100 个，修复社区 bug 50 多个，这些社区贡献涉及 OpenStack 的 Essex、Folsom、Havana、Icehouse、Juno 等版本。
得益于 OpenStack 的日益稳定成熟，私有云平台目前已经稳定运行了 2 年多时间，为网易公司多达 30 个互联网和游戏产品提供服务。从应用的效果来看，基于 OpenStack 研发的网易私有云平台已经达到了以下目标：
提高了公司基础设施资源利用率，从而降低了硬件成本。以物理服务器 CPU 利用率为例，私有云平台将 CPU 平均利用率从不到 10% 提升到 50%。 提高了基础设施资源管理与运维自动化水平，从而降低了运维成本。借助于 Web 自助式的资源申请和分配方式以及云平台自动部署服务，系统运维人员减少了 50%。 提高了基础设施资源使用弹性，从而增强了产品业务波动的适应能力。利用虚拟化技术将物理基础设施做成虚拟资源池，通过有效的容量规划以及按需使用，私有云平台可以很好适应产品突发业务。
网易 OpenStack 部署参考方案介绍
在具体的生产环境中，我们为了兼顾性能和可靠性，keystone 后端使用 Mysql 存储用户信息，使用 memcache 存放 token。为了减少对 keystone 的访问压力，所有服务（nova，glance，neutron）的 keystoneclient 均配置使用 memcache 作为 token 的缓存。
由于网易私有云需要部署在多个机房之中，每个机房之间在地理位置上自然隔离，这对上层的应用来说是天然的容灾方法。另外，为了满足私有云的功能和运维需求，网易私有云需要同时支持两种网络模式：nova-network 和 neutron。针对这些需求，我们提出了一个面向企业级的多区域部署方案，如图 2 所示。从整体上看，多个区域之间的部署相对独立，但可通过内网实现互通，每个区域中包括了一个完整的 OpenStack 部署，所以可以使用独立的镜像服务和独立的网络模式，例如区域 A 使用 nova-network，区域 B 使用 neutron，互不影响，另外为了实现用户的单点登录，区域之间共享了 keystone，区域的划分依据主要是网络模式和地理位置。
图 2.多区域部署方法
和典型 OpenStack 部署将硬件划分为计算节点和控制节点不同的是，为了充分利用硬件资源，我们努力把部署设计成对称的，即任意一个节点下线对整体服务不会照成影响。因此我们将硬件分为两类：计算节点，控制计算节点。计算节点部署 nova-network，nova-compute，nova-api-metadata，nova-api-os-compute。控制计算节点除了计算节点的服务外还部署了 nova-scheduler，nova-novncproxy，nova-consoleauth，glance-api，glance-registry 和 keystone，如图 3 所示。
对外提供 API 的服务有 nova-api-os-compute，nova-novncproxy ,glance-api，keystone。这类服务的特点是无状态，可以方便地横向扩展，故此类服务均部署在负载均衡 HAProxy 之后，并且使用 Keepalived 做高可用。为了保证服务质量和便于维护，我们没有使用 nova-api，而是分为 nova-api-os-compute 和 nova-api-metadata 分别管理。外部依赖方面，网易私有云部署了高可用 RabbitMQ 集群和主备 MySQL，以及 memcache 集群。
图 3.计算节点，控制计算节点
网络规划方面，网易私有云主要使用 nova-network 的 FlatDHCPManager+multi-host 网络模式，并划分了多个 Vlan，分别用于虚拟机 fixed-ip 网络、内网浮动 IP 网络、外网网络。
运维上使用网易自主研发的运维平台做监控和报警，功能类似 Nagios，但是更加强大。其中较重要的监控报警包括日志监控和进程监控。日志监控保证服务发生异常时第一时间发现，进程监控保证服务正常运行。另外网易私有云使用 Puppet 做自动部署，以及使用 StackTach 帮助定位 bug。
OpenStack 各组件配置
OpenStack Havana 的配置项成百上千，大部分配置项都是可以使用默认值的，否则光是理解这么多的配置项的含义就足以让运维人员崩溃，尤其是对那些并不熟悉源码的运维人员来说更是如此。下文将列举若干网易私有云中较关键的配置项，并解释它们如何影响到服务的功能，安全性，以及性能等问题。
Nova 关键配置
my_ip = 内网地址
此项是用来生成宿主机上的 nova metadata api 请求转发 iptables 规则，如果配置不当，会导致虚拟机内部无法通过 169.254.169.254 这个 IP 获取 ec2/OpenStack metadata 信息；生成的 iptable 规则形如：
-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT \--to-destination ${my_ip}:8775
它另外的用途是虚拟机在 resize、cold migrate 等操作时，与目的端宿主机进行数据通信。该项的默认值为宿主机的外网 IP 地址，建议改为内网地址以避免潜在的安全风险。
metadata_listen = 内网地址
此项是 nova-api-metadata 服务监听的 IP 地址，可以从上面的 iptables 规则里面看出它与 my_ip 的配置项有一定的关联，保持一致是最明智的选择。
novncproxy_base_url = vncserver_proxyclient_address = ${private_ip_of_compute_host}vncserver_listen = ${private_ip_of_compute_host}novncproxy_host = ${private_ip_of_host}
我们仅在部分节点上部署 novncproxy 进程，并把这些进程加入到 HAProxy 服务中实现 novnc 代理进程的高可用，多个 HAProxy 进程使用 Keepalived 实施 HAProxy 的高可用，对外只需要暴露 Keepalived 管理的虚拟 IP 地址即可：
这种部署方式好处是：
1）实现 novnc 代理服务的高可用
2）不会暴露云平台相关节点的外网地址
3）易于 novnc 代理服务的扩容
但也有不足：
1）虚拟机都监听在其所在的计算节点的内网 IP 地址，一旦虚拟机与宿主机的网络隔离出现问题，会导致所有虚拟机的 VNC 地址接口暴露出去
2）在线迁移时会遇到问题，因为 VNC 监听的内网 IP 在目的端计算节点是不存在的，不过这个问题 nova 社区已经在解决了，相信很快就会合入 J 版本。
resume_guests_state_on_host_boot = true
在 nova-compute 进程启动时，启动应该处于运行状态的虚拟机，应该处于运行状态的意思是 nova 数据库中的虚拟机记录是运行状态，但在 Hypervisor 上该虚拟机没有运行，在计算节点重启时，该配置项具有很大的用处，它可以让节点上所有虚拟机都自动运行起来，节省运维人员手工处理的时间。
api_rate_limit = false
不限制 API 访问频率，打开之后 API 的并发访问数量会受到限制，可以根据云平台的访问量及 API 进程的数量和承受能力来判断是否需要打开，如果关闭该选项，则大并发情况下 API 请求处理时间会比较久。