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，实现网络的流量隔离，并提高存储的访问带宽。