超千个节点OpenStack私有云案例1：CERN 5000+ 计算节点私有云

发表日期：2016-04-06 03:36PM 阅览次数：

本文根据以下几篇文章整理而来：

https://www.openstack.org/summit/tokyo-2015/videos/presentation/unveiling-cern-cloud-architecture

https://www.mybookworld.info/view/lcl9u/cern-cloud-architecture-february-2016.html

http://openstack-in-production.blogspot.com/

1. 系统

（1）系统规模

2015 年是 5000个计算节点，16000 个在运行的虚机

2016年2月是 5500 个计算节点，半年期间计算节点增加了 500 个，虚机增加了1000个

左边是当前正在运行的虚机的数量 16000 个，右边是被创建过的虚机的累计数量，超过 25 M.

（2）CERN 使用的 OpenStack 版本保持持续更新，基本上是延迟一个社区版本

（3）2015 年的总体结构：一个 region,2 个数据中心，26 个 Cell,全部使用 nova-network

在 2016 年2月，已经增长到了 33 个 Cell,而且在其中一个 Cell 中使用了 Neutron.

（4）Nova 系统架构

使用 nova-cell

每个 Child Cell 有不同的 Use cases

为什么要使用 Cell?因为不同的用户有不同的需求，因此，在每个 Child Cell 内部，可以使用不同的配置，包括 nova scheduler 等；Cell 还有助于缩小故障发生时候的影响域。

Cell V1 的局限性

Nova-cell 系统架构：两级 Cell 结构。只在 Nova Top Cell Controller 上使用 HA,在 Child Cell controller 上不使用HA.

每个 Child Cell 大概 200 个计算节点

CERN 自己开发了 Cell 调度器

如果将特定 project 的虚机调度到特定的 Child cell 上

如何结合 Cell 使用 AZ

在 2013 年的时候，只使用了一个 Cell,考虑到：（1）Nova Cell 的调度机制非常弱，只能随机调度，（2）想使用 host aggregate功能（3）不能跨Cell 做 live migration.但是最后发现非常难于管理。

随后他们就将其拆分为 9 个 Child cell

Nova 做 block live migration 遇到的问题

Nova kilo 版本与 Python 2.6 不兼容

（5）网络架构

CERN 使用基于 nova-network 的网络分段技术

CERN 自己开发了一个 Network driver

他们已经对 Neutron 做了大量的测试，已经在计划迁移（到2016年2月他们已经在一个Child cell 中使用 Neutron）

（6）Keystone

使用两个不同的 Keystone.Ceilometer 需要调用大量的 API,因此给它们一个专有的Keystone,免得影响用户使用 Keystone.

（7）Glance

Glance 服务运行在虚机中。之前，Glance registry 可以被别的 Glance API 使用，但是，这导致难于定位问题，因此，现在的 Glance registry 只和本地的 Glance API 通信。但是，Glance 不支持分 Project 设置 Quota,这对他们很重要。

（8）Cinder

使用了 3个 backend,两个 Ceph,一个 NetApp.目前没有 Ceph Cinder driver for hyper-v,所以他们使用了 NetApp,被 Hyper-V 虚机使用。

（9）Ceilometer

两套Ceilometer 基础设施。一个保存 sample,meters 等，用于统计，数据保存在 Hbase 中，数据保存3个月。之前用 MogoDB,但是难于扩展。

另一个用于 alarming,它将 CPU sample 保存在 MongoDB 中，只保存几个小时。如果不分开的话，查询 alarming 非常慢。

（10）Rally

不仅用于 benchmarking 测试，还用于 FVT.

（11）新的挑战

2. 简单分析

2.1 CERN 对 Nova Cell 的看法

对大规模的部署，Nova Cell 有几个优势：

能够保持对用户只有单端点可见（single endpoint to users）

能够增加基础架构的可用性和弹性（increase the availability and resilience of the Infrastructure）

能够避免超出 Nova 和其它外部模块（比如 DB,MQ 等）的上限（avoid that Nova and external components （DBs, message brokers） reach their limits）

能够隔离不同用户（isolate different user cases）

但是，Cell 目前还是有不少的局限，如下的功能不能和 Nova Cell 一起使用：

Security Groups;

Manage aggregates on Top Cell;

Availability Zone support;

Server groups;

Cell scheduler limited functionality;

2.2 本人的一点看法

使用现有的 OpenStack 来支持 5000 个计算节点，那是非常牛的事情！这可能是目前最大的 OpenStack 生产系统私有云部署规模。

计算扩展性方面，使用 Nova cell 是一个解决方案，但是目前它的 V1 版本已经被冻结，V2 还在开发中，因此，要使用的话，需要做大量的开发和问题定位；而且，它还存在大量的局限性。

网络扩展性方面，Neutron 的扩展性和稳定性依然问题很大，CERN 也在一步步尝试，期待他们使用 Neutron 的心得

存储扩展性方面，Ceph 居然能做到支撑 30PB 的数据量，这也是非常非常牛的事情！

Ceilometer 扩展性方面，以及性能和开销等方面，默认情况下依然问题很大，CERN 做出了改进的非常好的示范

谢谢 CERN 团队的超强工作和无私分享

欢迎加入本站公开兴趣群

软件开发技术群

兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流

QQ群：26931708

Hadoop源代码研究群

兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop

QQ群：288410967

;