OpenStack在天河二号的大规模部署实践（转）

OpenStack正在成为事实上的IaaS标准，其本身的设计架构赋予了其高度的可扩展性。尽管如此，在千节点量级的大规模部署中，仍然有许多因素决定了实际实施中需要在整体架构和细节优化上进行多方面的尝试与探索。本文分享在天河二号千节点规模上进行大规模部署的实践经验，并介绍团队在基于OpenStack构建企业级解决方案KylinCloud上所取得的进展。

OpenStack大规模部署所遭遇的挑战

随着本身不断的成熟及在多个生产环境中的成功应用，开放、开源的云服务平台OpenStack正在成为事实上的IaaS标准。在其官方的介绍中，易于实施（Simple to Implement）、高可扩展（Massively Scalable）和特性丰富（Feature Rich）是主要的特色，这得益于OpenStack本身松耦合的架构设计、活跃且强有力的社区贡献和不断成熟的生态圈。

然而，需要管理数据中心千以上的物理节点时，如基于OpenStack构建公有云，如何发挥OpenStack的可扩展性优势提供稳定、高效的服务，仍然有许多因素需要考虑，其主要的挑战主要来自以下两个方面：

OpenStack本身的因素：由于定位在松耦合、功能丰富，OpenStack所包含的组件在多个开源平台里面是相对较多的，当前的最新版Juno的组件数为11，即将发布的Kilo会达到12（包含Ironic），而且这个数字可能还在继续增长；同时，各个组件间存在依赖关系，如每个组件都会依赖Keystone，Nova还依赖于Glance、Neutron和Cinder；此外，多个组件，如Neutron、Cinder和Glance还存在多种存储后端实现机制，以实现对各种部署环境的灵活支持；最后，每个组件都有大量的配置文件，而每个配置文件又有大量的配置选项用于对系统进行定制与优化；
部署环境的因素：在数据中心中，物理节点数目达到一定量级之后其本身的运维会面临部署配置复杂、调试困难等因素，仅OS安装及软件包的部署与维护就带来很大的工作量；同时硬件故障率、网络压力、数据库压力甚至日志压力都给OpenStack的部署带来诸多挑战，典型的表现之一是消息超时、响应变慢等问题。

天河二号的云计算需求

在世界超算Top500排名中取得四连冠的天河二号已经于2014年初部署在国家超算广州中心并对外提供服务。与已有超级计算机系统的一个重要区别是，天河二号不仅仅定位在高性能计算，而是通过异构多态的体系结构设计与实现，期望能够为广州市、广东省甚至更大范围的政府部门和企事业单位的信息化建设和大数据处理提供强有力的资源支撑。

图1 天河二号

为了满足信息化和数据处理类应用对按需、弹性计算资源的需求，天河二号的软件体系中融合了当前不断成熟与普及的云计算模式。经过比较与测试，研发团队选取了具有良好扩展性和社区基础的OpenStack作为软件栈的组成部分。本文再现了在天河二号千节点规模上进行OpenStack大规模部署的一次试验。

软硬件配置

在开始之前，简单介绍一下此次部署的软硬件配置。

硬件：天河二号定制刀片，每个节点配有双路12核CPU，64GB内存，两块千兆网卡、一块THNI高速网卡以及一块1TB的SATA本地硬盘；

软件的具体版本信息如下：

OpenStack ─ IceHouse （2014.1）；
OS ─ 内核为3.8.0的Ubuntu Server 12.04；
Ceph ─ 0.67.0，用于提供后端存储，取代Swift；
Puppet ─ 2.7.11，实现自动化的部署与配置；
Rabbitmq ─3.24，缺省的消息队列；
MySQL ─ Ver 15.1 Distrib 5.5.35-MariaDB，OpenStack的后台支撑数据库；
kvm ─ QEMU emulator version 1.7.91，以KVM作为底层的虚拟化机制；
libvirt ─ 1.2.2，虚拟化层接口；
OpenvSwitch ─ 2.0.1，虚拟机网络的管理后端。

部署架构

为了实现OpenStack千级节点的部署，经过调研和尝试，在确定其架构时确定了如下五个重要的选择：

使用Cell进行逻辑划分。OpenStack中使用Cell来解决可扩展性和规模瓶颈，实现对横向扩展和大规模部署的支持。Cell在Grizzly版本引入，并不断成熟。前面提到，OpenStack由多个松耦合的组件构成，当达到一定的规模后，某些模块将成为整个系统的瓶颈。Cell以树型结构为基础，主要包括根Cell（API-Cell）与子Cell（ Child-Cell）两种形式，子Cell可以嵌套。根Cell 运行 nova-api 服务，每个子Cell 运行除 nova-api 外的所有 nova-*服务以及nova-cells服务，并具有自己的数据库和消息队列、数据库。同时，树形结构引入了分级调度的概念，即调度某个虚拟机的时候先要进行Cell的选择，可以有多种调度策略。父Cell会将消息路由到子Cell的消息队列，同时，子Cell定时的将自己的资源信息上报给父Cell，用来给分级调度策略提供决策数据和基于Cell的资源监控，Cell之间的通信通过rpc完成。

采用无盘方式部署系统。由于节点规模庞大，同时存在一定的故障率，为了提高部署效率，减轻系统维护与软件包升级的开销，全系统采用无盘方式部署。将OpenStack相关的包与操作系统定制为一个镜像，节点重启时会自动从无盘服务器拉取镜像。同时，镜像中打入了一些自动化的脚本用于完成基本的环境配置，如初次启动时的硬盘分区、IP地址和hostname的确定与写入、无密码SSH等。

采用Puppet实现节点服务的自动好配置。以无盘的方式部署系统后，各个节点可以看作是同质的。为了实现对OpenStack各个服务的配置，使用Puppet来完成各个配置文件、配置项的设置以及服务的启动。首先定义每个节点的角色，并为每个角色与角色之间的关系定义相应的配置脚本，进行配置时，每个Puppet 客户端会到服务器端去获取自己的角色和相应的脚本，然后加以执行。

使用Ceph RBD卷作为统一的存储后端，实现镜像存储、逻辑卷和虚拟机启动（Boot-from-Volume）。采用分布式存储Ceph主要基于三方面的考虑：一是Ceph架构本身具有的可扩展性、可靠性与高性能，同时其RBD功能已经相对成熟；二是实验环境的每个节点都具有一块1TB的SATA盘，在不考虑使用成本较高的集中式存储的前提下，使用Ceph把这些本地盘利用起来具有相当大的吸引力；三，尤为重要的是，Ceph一直与OpenStack保持良好的合作关系，能够很好的支持OpenStack多个组件对存储后端的支持。另外，统一采用Ceph RBD卷作为存储后端，能够实现低开销的虚拟机迁移并降低对空间的使用率。

管理网、业务网与存储网络分离。即充分使用每个节点的三块网卡，两块以太网卡分别用于管理网络和虚拟机业务网，THNI高速网用于Ceph，实现网络的流量隔离，并提高存储的访问带宽。

基于以上考虑，在实际部署方案中，采用了如下的部署架构：

1. 128个控制节点，包括：

8个nova控制节点：运行nova-api和nova-cells；
8个镜像服务节点：运行glance-*服务；
8个卷服务节点：运行cinder-*服务；
8个网络控制节点：运行neutron-server服务；
16个网络服务节点：运行neutron-*-agent服务；
8个认证服务节点：运行keystone服务；
6个消息队列的节点：，运行Rabbitmq；
6个数据库的节点：运行MySQL；
4个负载均衡节点，采用LVS+Keepalived实现API节点的调度分发与高可用；
2个Horizon节点；
8个ceph 监控节点，运行ceph mon服务；
16个监控节点：为了实现对当前系统状态的监控与报警，还部署了16个节点用作Ganglia和Nagios的服务器端；
其余节点作为备用节点。

2. 8个Cell的计算节点，每个Cell包含128个节点，包含2个Cell Server节点（运行除nova-api之外的nova-*服务、nova-cells、消息队列和数据库）和126个计算节点，每个计算节点同时运行ceph的osd服务。

大致的部署图如下：

图2 千节点规模部署的拓扑图

性能优化措施

在系统部署完毕之后，为了适应管理和调度物理节点和虚拟机的需要，需要针对相关的服务进行参数调优，在此给出主要的一些配置。

1. 在多个物理节点上配置各类*-api服务，并进行负载均衡，主要包括nova-api、cinder-api、glance-api等，用于增加请求的响应能力；

2. 为Neutron配置独立的Keystone服务。经观察发现，Neutron需要频繁的认证，为此，为其配置独立的Keystone，但数据库共用，从而保证Keystone的最大并发响应数；

3. 通过开启服务的多进程模式提高响应能力：主要包括两类，一类是设置相关服务配置中的worker的数目，包括Neutron-server中的api_works、nova-api中的osapi_compute_workers、metadata_workers和ec2_workers、nova-conductor中的workers、glance-api和cinder-api中的workers配置项等；第二类是将服务进行Apache托管，使用Apache的多进程机制增加服务能力，主要包括Keystone和Puppet Master两个服务；

4. 服务的性能参数调整，增强每个服务进程的处理能力。

其中Nova涉及到的参数如下：

api_rate_limit，将其设置为false，取消限制；
使用较大的数据库连接池：主要包括min_pool_size、max_pool_size和max_overflow等参数；

Neutron涉及到的参数如下：

使用较大的数据库连接池：主要包括min_pool_size、max_pool_size和max_overflow等参数；
agent_down_time：但有数目较多的Agent运行时，允许更多Agent出现故障；

消息队列Rabbitmq涉及到的参数如下：

rabbitmqctl set_vm_memory_high_watermark：允许Rabbitmq使用更多内存来响应连接；
ulimit -n：设置较大的socket限制以承载更大的负载；
使用Rabbitmq集群机制实现消息队列压力的分摊；

MySQL涉及到的参数如下：

max_connections：使用更大的最大连接数；
使用Galera Mysql 集群技术提高MySQL的性能和可用性。

另外一些服务适当的放宽其超时时间设置，防止由于规模过大、节点数多引起的超时导致服务无法响应，主要包括两个参数：

neutron_url_timeout：Neutron服务的响应时间限制；
rpc_response_timeout：RPC响应时间显示；

最后，在每个节点KVM的配置进行调整，主要包括KSM（重复页去重）、虚拟内存比例调整、使用virtio_blk提高IO性能以及设置I/O的调度策略为Deadline等。

实际运行情况

在上述的架构和优化下，实现了对共计1152个物理节点的大规模OpenStack的部署。为了验证此部署的能力，使用测试镜像Cirros、以最小配置（1 vCPU、512MB内存）进行启动虚拟机和查询虚拟机的测试。结果显示，能够一次同时启动的虚拟机的数据为5000个左右，且大部分时间耗费在调度上；每秒可以实现1000个虚拟机的查询操作。后续需要根据分析的性能瓶颈进行进一步的探索与优化。

基于OpenStack打造高效安全的企业云服务平台

在以上部署实践的基础上，天河二号的云平台研发团队深入到OpenStack源代码内部，围绕遇到的问题和需求开发了一系列新特性和大量的Bug修复，并积极反馈给社区。2012年以来团队向社区贡献了大量代码，并在最新的Juno核心组件的代码贡献（commit数目）位居国内第二位。

同时，围绕着充分发挥天河二号的性能优势、为中小企业提供安全、高可用、弹性的高品质服务这一目标，团队基于OpenStack进行了一系列深入的产品化定制与改造，形成了独立的云服务解决方案KylinCloud─麒麟云平台。麒麟云平台采用互联网自助服务的模式，面向企事业单位提供IaaS和PaaS层的IT服务，希望成为小微企业的IT服务的承载平台，并基于此构建完善的IT服务生态环境。

图3 麒麟云平台的特色之处

目前，麒麟云平台已经稳定运行在天河二号上，在用户单位的配合与支持下，已经适配了广州市电子政务中心、广州市萝岗区的若干电子政务系统的部署和运行；同时，作为广东省省级教育数据中心的主要资源池，将为各类教育管理系统提供所需的计算和存储资源，已经部署上线了多个信息管理系统；此外，麒麟云平台已经在为几十家中小企业提供服务，如支持企业客户的信息服务托管以及基于互联网的智能销售等行业服务，又如依托天河二号的强大计算能力为动漫产业提供海量的计算资源，目前正在支持华强、红鹏、创意云等多个用户的渲染业务，其中华强高性能渲染虚拟机集群的最大规模达到千个物理节点规模，已经在支撑其生产系统。麒麟云平台在广州市电子政务和华强文化等单位和企业的成功应用已经验证了其基于天河二号提供云服务的可用性、可靠性和可扩展性，为超级计算机系统的应用开拓了一条崭新的途径。

同时，研发团队也在努力构建面向商用硬件的完整解决方案，面向不同用户、不同应用的需求，提供深度定制、安全、可靠的云服务。此外，麒麟云平台正在与国内著名安全系统解决方案提供商合作，对麒麟云平台的系统安全、平台安全和虚拟机安全进行全方位的定制与增强。