云计算演进与应用

内容简介

云计算发展至今，已经成为广为接受的应用服务提供形式。而微服务架构的诞生，也是云计算技术应用以及持续交付、 DevOPS 深入人心的综合产物，是未来软件架构朝着动态伸缩和分布式架构发展的方向。本期我们聚焦于2017年云计算在具体行业中的实践应用和相关容器技术的最新发展。

本书内容

谈谈 OpenStack 大规模部署

文/付广平

目前社区还没有一个非常完美的 OpenStack 大规模部署方案，现有方案都存在各自的优点和缺点，实际部署时应根据物理资源的分布情况、用户资源需求等因素综合选择。本文将谈谈 OpenStack 大规模部署问题，讨论现有方案的优缺点以及分别适用的场景。

前言

走过了7年的发展岁月，OpenStack 已成为云计算领域中最火热的项目之一，并逐渐成为 IaaS 的事实标准，私有云项目的部署首选。OpenStack 社区可能自己都没有想到其发展会如此之迅速，部署规模如此之大，以至于最开始对大规模 OpenStack 集群的部署支持以及持续可扩展性似乎并没有考虑完备。

众所周知，OpenStack 每一个项目都会有数据库的访问以及消息队列的使用，而数据库和消息队列是整个 OpenStack 扩展的瓶颈。尤其是消息队列，伴随着集群规模的扩展，其性能下降非常明显。通常情况下，当集群规模扩展到200个节点，一个消息可能要在十几秒后才会响应，集群的整体性能大大下降，英国电信主管 Peter Willis 声称一个独立 OpenStack 集群只能最多管理500个计算节点。

当处理大规模问题时，我们自然会想到分而治之，其思想是将一个规模为 N 的问题分解为 K 个规模较小的子问题，这些子问题相互独立且与原问题性质相同，解决了子问题就能解决原问题。社区提出的多 Region、多 Cells 以及 Cascading 等方案都是基于分而治之策略，但它们又有所区别，主要体现在分治的层次不一样，多 Region 和 Cascading 方案思想都是将一个大的集群划分为一个个小集群，每个小集群几乎是一个完整的 OpenStack 环境，然后通过一定的策略把小集群统一管理起来，从而实现使用 OpenStack 来管理大规模的数据中心。在 Grizzly 版本引入的 Nova Cells 概念，其思想是将不同的计算资源划分为一个个的 Cell，每个 Cell 都使用独立的消息队列和数据库服务，从而解决了数据库和消息队列的瓶颈问题，实现了规模的可扩展性。遗憾的是，目前社区还没有一个非常完美的 OpenStack 大规模部署方案，以上提到的方案都存在各自的优点和缺点，实际部署时应根据物理资源的分布情况、用户资源需求等因素综合选择。本文接下来将谈谈 OpenStack 大规模部署问题，讨论前面提到的各个方案的优缺点以及分别适用的场景。

单集群优化策略

使用独立的数据库和消息队列

前面提到限制 OpenStack 规模增长的最主要因素之一就是由于数据库和消息队列的性能瓶颈，因此如果能够有效减轻数据库以及消息队列的负载，理论上就能继续增长节点数量。各个服务使用独立的数据库以及消息队列显然能够有效减小数据库和消息队列的负载。在实践中发现，以下服务建议使用独立的数据库以及消息队列：

1. Keystone：用户以及其它 API 服务的认证都必须经过 Keystone 组件，每次 Token 验证都需要访问数据库，随着服务的增多以及规模的增大，数据库的压力将会越来越大，造成 Keystone 的性能下降，拖垮其它所有服务的 API 响应。因此为 Keystone 组件配置专门的数据库服务，保证服务的高性能。
2. Ceilometer：Ceilometer 是一个资源巨耗型服务，在收集消息和事件时会发送大量的消息到队列中，并频繁写入数据库。为了不影响其它服务的性能，Ceilometer 通常都搭配专有的数据库服务和消息队列。
3. Nova：OpenStack 最活跃的主体就是虚拟机，而虚拟机的管理都是由 Nova 负责的。几乎所有对虚拟机的操作都需要通过消息队列发起 RPC 请求，因此 Nova 是队列的高生产者和高消费者，当集群规模大时，需要使用独立的消息队列来支撑海量消息的快速传递。
4. Neutron：Neutron 管理的资源非常多，包括网络、子网、路由、Port 等，数据库和消息队列访问都十分频繁，并且数据量还较大，使用独立的数据库服务和消息队列既能提高 Neutron 本身的服务性能，又能避免影响其它服务的性能。

使用 Fernet Token

前面提到每当 OpenStack API 收到用户请求时都需要向 Keystone 验证该 Token 是否有效，Token 是直接保存在数据库中的，增长速率非常快，每次验证都需要查询数据库，并且 Token 不会自动清理而越积越多，导致查询的性能越来越慢，Keystone 验证 Token 的响应时间会越来越长。所有的 OpenStack 服务都需要通过 Keystone 服务完成认证，Keystone 的性能下降，将导致其它所有的服务性能下降，因此保证 Keystone 服务的快速响应至关重要。除此之外，如果部署了多 Keystone 节点，还需要所有的节点同步 Token，可能出现同步延迟而导致服务异常。为此社区在 Kilo 版本引入了 Fernet Token，与 UUID Token 以及 PKI Token 不同的是它是基于对称加密技术对 Token 加密，只需要拥有相同加密解密文件，就可以对 Token 进行验证，不需要持久化 Token，也就无需存在数据库中，避免了对数据库的 I/O 访问，创建 Token 的速度相对 UUID Token 要快，不过验证 Token 则相对要慢些。因此在大规模 OpenStack 集群中建议使用F ernet Token 代替传统的 Token 方案。

以上优化策略能够一定程度上减少消息队列和数据库的访问，从而增大节点部署规模，但其实并没有根本解决扩展问题，随着部署规模的增长，总会达到瓶颈，理论上不可能支持无限扩展。

多 Region 方案

OpenStack 支持将集群划分为不同的 Region，所有的 Regino 除了共享 Keystone、Horizon、Swift 服务，每个 Region 都是一个完整的 OpenStack 环境，其架构如图1。

图1 多 Region 方案的架构

部署时只需要部署一套公共的 Keystone 和 Horizon 服务，其它服务按照单 Region 方式部署即可，通过 Endpoint 指定 Region。用户在请求任何资源时必须指定具体的区域。采用这种方式能够把分布在不同的区域的资源统一管理起来，各个区域之间可以采取不同的部署架构甚至不同的版本。其优点如下：

1. 部署简单，每个区域部署几乎不需要额外的配置，并且区域很容易实现横向扩展。
2. 故障域隔离，各个区域之间互不影响。
3. 灵活自由，各个区域可以使用不同的架构、存储、网络。

但该方案也存在明显的不足：

1. 各个区域之间完全隔离，彼此之间不能共享资源。比如在 Region A 创建的 Volume，不能挂载到 Region B 的虚拟机中。在 Region A 的资源，也不能分配到 Region B 中，可能出现 Region 负载不均衡问题。
2. 各个区域之间完全独立，不支持跨区域迁移，其中一个区域集群发生故障，虚拟机不能疏散到另一个区域集群中。
3. Keystone 成为最主要的性能瓶颈，必须保证 Keystone 的可用性，否则将影响所有区域的服务。该问题可以通过部署多 Keystone 节点解决。

OpenStack 多 Region 方案通过把一个大的集群划分为多个小集群统一管理起来，从而实现了大规模物理资源的统一管理，它特别适合跨数据中心并且分布在不同区域的场景，此时根据区域位置划分 Region，比如北京和上海。而对于用户来说，还有以下好处：

1. 用户能根据自己的位置选择离自己最近的区域，从而减少网络延迟，加快访问速度。
2. 用户可以选择在不同的 Region 间实现异地容灾。当其中一个 Region 发生重大故障时，能够快速把业务迁移到另一个 Region 中。

但是需要注意的是，多 Region 本质就是同时部署了多套 OpenStack 环境，确切地说并没有解决单 OpenStack 集群的大规模部署问题。

OpenStack Cascading 方案以及 Trio2o 项目

OpenStack Cascading 方案是由国内华为提出的用于支持场景包括10万主机、百万虚机、跨多 DC 的统一管理的大规模 OpenStack 集群部署。它采取的策略同样是分而治之，即把原来一个大的 OpenStack 集群拆分成多个小集群，并把拆分的小集群级联起来统一管理，其原理图2。

图2 OpenStack Cascading 方案的原理

1. 只有最顶层的 OpenStack 暴露标准 OpenStack API 给用户，其包含若干个子 OpenStack 集群。
2. 底层的 OpenStack 负责实际的资源分配，但不暴露 API 给用户，而必须通过其之上的 OpenStack 调度。

用户请求资源时，首先向顶层 OpenStack API 发起请求，顶层的 OpenStack 会基于一定的调度策略选择底层的其中一个 OpenStack，被选中的底层 OpenStack 负责实际的资源分配。

该方案号称支持跨多达100个 DC，支持10万个计算节点部署规模，能同时运行100万个虚拟机。但该方案目前仍处于开发和测试阶段，尚无公开的实际部署案例。目前该方案已经分离出两个独立的 big-tent 项目，一个是 Tricircle，专门负责网络相关以及对接 Neutron，另一个项目是 Trio2o，为多 Region OpenStack 集群提供统一的 API 网关。

Nova Cells 方案

前面提到的 OpenStack 多 Region 方案是基于 OpenStack 环境切分，它对用户可见而非透明的，并且单集群依然不具备支撑大规模的能力和横向扩展能力。而 Nova Cells 方案是针对服务级别划分的，其最终目标是实现单集群支撑大规模部署能力和具备灵活的扩展能力。Nova Cells 方案是社区支持的方案，因此本文将重点介绍，并且会总结下在实际部署中遇到的问题。

Nova Cells 架构和原理介绍

Nova Cells 模块是 OpenStack 在 G 版本中引入的，其策略是将不同的计算资源划分成一个个 Cell，并以树的形式组织，如图3。

图3 Nova Cell 架构

从图中看出，Cells 的结构是树形的，一个 Cell 可能包含若干子 Cell，以此逐级向下扩展。每个 Cell 都有自己独立的消息队列和数据库，从而解决了消息队列和数据库的性能瓶颈问题，Cell 与 Cell 之间主要通过 Nova-Cells 负责通信，一层一层通过消息队列传递消息，每个 Cell 都需要知道其 Parent Cell 以及所有孩子 Cells 的消息队列地址，这些信息可以保存到该 Cell 的数据库中，也可以通过 json 文件指定：

{    "parent": {        "name": "parent",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": true    },    "cell1": {        "name": "cell1",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit1.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": false    },    "cell2": {        "name": "cell2",        "api_url": "http://api.example.com:8774",        "transport_url": "rabbit://rabbit2.example.com",        "weight_offset": 0.0,        "weight_scale": 1.0,        "is_parent": false    }}

根据节点所在树中位置以及功能，分为两种 Cell 类型：

1. api cell，非叶子节点，该类型的 Cell 不包含计算节点，但包括了一系列子 Cells，子 Cells 会继续调度直到到达叶子节点，即 Compute Vell 中。其中最顶层的根节点通常也叫作 Top Cell。
2. compute cell，叶子节点，包含一系列计算节点。负责转发请求到其所在的 Nova-Conductor 服务。

注意：所有的 Nova 服务都隶属于某个 Cell 中，所有的 Cells 都必须指定 Cell 类型。

每个 Cell 节点都有从根节点到该节点的唯一路径，路径默认通过 ! 分割，比如 root!cell _ 1!cell _ 13 表示从 root 到 cell _ 1 再到 cell _ 13。根节点的 Cell 类型一定是 API 就是说 Cell 对用户是完全透明的，和不使用 Cell 时是完全一样的。其中 Nova-Cells 服务是需要额外部署的新服务，该服务主要负责创建虚拟机时，从所有的孩子 Cell 中选择其中一个子 Cell 作为虚拟机的 Cell，子 Cell 会继续执行调度直到到达底层的 Compute Cell 中，最后转发请求到目标 Compute Cell 所在的 Nova-Conductor 服务中。因此采用 Nova Cells 方案后，Nova 实际采用的是二级调度策略，第一级由 Nova-Cells 服务负责调度 Cell，第二级由 Nova-Scheduler 服务负责调度计算节点。

Compute Cell 节点担任的职责类似于非 Cell 架构的控制节点，需要部署除 Nova-API 服务以外的所有其它 Nova 服务，每个 Cell 相当于一个完整的 Nova 环境，拥有自己的 Nova-Conductor、Nova-Scheduler 等服务以及数据库服务和消息队列服务，并且包含若干计算节点，每个 Cell 的组件只服务于其自身所在的 Cell，而不是整个集群，因此天生具备支撑单集群大规模部署能力。增大规模时，只需要相应增加 Cell 即可，因此具有非常灵活的可扩展能力。

子 Cell 的虚拟机信息会逐层向上同步复制到其父 Cell 中，Top Cell 中包含了所有 Cells 的虚拟机信息，查看虚拟机信息时，只需要从 Top Cell 数据库查询即可，不需要遍历子 Cell 数据库。对虚拟机进行操作时，如果不使用 Cell，则只需要根据其 Host 字段，向宿主机发送 RPC 请求即可。如果使用了 Cell，则需要首先获取虚拟机的 Cell 信息，通过 Cell 信息查询消息队列地址，然后往目标消息队列发送 RPC 请求。

Nova Cell 生产案例

Nova Cells 方案很早就已经存在一些生产案例了，其中 CERN（欧洲原子能研究中心）OpenStack 集群可能是目前公开的规模最大的 OpenStack 部署集群，截至2016年2月部署规模如下：

1. 单R egion，33个Cell。
2. 2个 Ceph 集群。
3. 约5500个计算节点，5300KVM 和 200Hyper-V，总包含140k Cores。
4. 超过17000个虚拟机。
5. 约2800个镜像，占 44TB 存储空间。
6. 约2000个 Volumes，已分配800TB。
7. 约2200个注册用户，超过2500个租户。

其 Nova 部署架构如图4。

图4 CERN OpenStack 集群 Nova 架构

天河二号是国内千级规模的典型案例之一，于2014年初就已经在国家超算广州中心并对外提供服务，其部署规模如下：

1. 单 Region，8个 Cell。
2. 每个 Cell 包含2个控制节点和126个计算节点。
3. 总规模1152个物理节点。
4. 一次能创建大约5000个左右虚拟机。
5. 每秒可查询约1000个虚拟机信息。

除了以上两个经典案例外，Rackspace、NeCTAR、Godaddy、Paypal 等也是采用了 Nova Cells 方案支持千级规模的 OpenStack 集群部署。这些生产案例实践证明了使用 Nova Cells 支持大规模 OpenStack 集群的可能性。

Nova Cells 遇到的坑

刚刚介绍了不少 Nova Cells 的成功生产案例，让人不禁“蠢蠢欲动”，想要小试牛刀。笔者已经架不住诱惑，于是专门申请了23台物理服务器作为 Nova Cells 测试环境使用，实际部署时包含3个 Cells，每个 Cell 包含7台物理服务器，其中1台控制节点，一台 Ceph All-in-one 节点，剩余为5个计算节点。另外多余的两台分别作为 Top Cell 的控制节点和网络节点。部署的 OpenStack 版本为 Mitaka，使用社区原生代码。在部署过程中遇到了大大小小不少坑，有些是配置问题，有些是 Cells 本身的问题。

虚拟机永久堵塞在 scheduling 状态

我们知道，每个 Cell 都使用自己的独立数据库，因此配置 Nova 的数据库时，显然需要配置其所在 Cell 的数据库地址。而从 Mitaka 版本开始已经把一些公共的数据从 nova 数据库单独分离出来一个数据库 nova _ api（原因后面说明）。创建虚拟机时 Nova-API 不会把初始化数据直接保存到 nova 数据库的 instances 表中，而是保存到 nova _ api 数据库的 build _ requests 表，此时虚拟机状态为 scheduling 。Nova API 获取虚拟机信息时会首先查询 nova _ api 的 build _ requests 表，如果存在记录，则直接返回虚拟机信息。正常流程下，当执行完调度后，Nova-Conductor 会自动删除 build _ requests 的虚拟机信息。但是在配置多 Cell 情况下，如果 nova_api 也是配置其所在 Cell 的数据库地址，当调度到 Compute Cell 中时，Compute Cell 数据库的 build _ requests 显然找不到该虚拟机的信息，因为实际上信息都保存在 Top Cell 中，因此 Top Cell 的 build _ requests 中的虚拟机信息将永远不会被删除。此时我们使用 nova list 查看的虚拟机信息是从 build _ requests 拿到的过时数据，因此我们查看虚拟机状态永久堵塞在 scheduling 状态。解决办法是所有 Cell 的 nova _ api 数据库都配置使用同一个数据库，nova _ api 数据库本来就是设计为保存公共数据的，为所有的 Cell 所共享。

分配网络失败导致创建虚拟机失败

解决了上一个问题后，发现仍然创建虚拟机失败，虚拟机一直堵塞在 spawning 状态直到变成 error 状态，在计算节点调用 virsh list 命令发现其实虚拟机已经创建成功，只是状态为 pause。

通过现场日志发现，正常流程下，创建虚拟机时，Neutron 完成虚拟网卡初始化后会通过 Notification 机制发送通知到消息队列中，Libvirt 会默认一直等待 Neutron 虚拟网卡初始化成功的事件通知。在多 Cell 环境下，因为 Cell 只是 Nova 的概念，其它服务并不能感知 Cell 的存在，而 Nova 的 Cell 使用了自己的消息队列，Neutron 服务发往的是公共消息队列，因此Nova-Compute 将永远收不到通知，导致等待事件必然超时，Nova 误认为创建虚拟网卡失败了，因此创建虚拟机失败。Godday 和 CERN 同样遇到了相同的问题，解决办法为设置 vif _ plugging _ is _ fatal 为 false，表示忽略 Neutron 消息等待超时问题，继续执行后续步骤。另外需要设置等待的超时时间 vif _ plugging _ timeout，因为我们已经确定肯定会超时，因此设置一个较短的时间，避免创建虚拟机等待过长，Godday 设置为5秒，可以作为参考。

nova show 查看虚拟机的 instance_name 与计算节点实际名称不一致

这是因为 instance _ name 默认模板为 instance-x % id，其中 id 为虚拟机在数据库中的主键 id（注意不是UUID），它是自增长的。比如 id 为63 ，转化为十六进制为3f ，因此 instance _ name为 instance-0000003f。在多 Cell 情况下，Top Cell 保存了所有的虚拟机信息，而子 Cell 只保存了其管理 Cell 的虚拟机信息，保存的虚拟机数量必然不相等，因此同一虚拟机保存在 Top Cell 和子 Cell 的 ID 必然不相同。而我们使用 Nova API 获取虚拟机信息是从 Top Cell 中获取的，因此和虚拟机所在的 Compute Cell 中的 instance _ name 不一致。解决办法为修改 instance _ name _ template 值，使其不依赖于 id 值，我们设置为虚拟机 UUID。

后端存储问题

当部署小规模 OpenStack 集群时，我们通常都会使用 Ceph 分布式共享存储作为 Openstack 的存储后端，此时 Glance、Nova 和 Cinder 是共享存储系统的，这能充分利用 RBD image 的 COW（Copy On Write）特性，避免了镜像文件的远程拷贝，加快了创建虚拟机和虚拟块设备的速度。但当规模很大时，所有的节点共享一个 Ceph 集群必然导致 Ceph 集群负载巨大，I/O 性能下降。因此考虑每个 Cell 使用独立的 Ceph 集群，Nova 和 Cinder 共享 Ceph 集群，Glance 是所有 Cells 的公共服务，需要单独部署并对接其它存储设备。由于 Glance 和 Nova 不是共享存储了，因此创建虚拟机时就不能直接 Clone了，而必须先从 Glance 下载 Base 镜像导入到 Ceph 集群中。创建虚拟机时，首先看本地 Ceph 集群是否存在 base 镜像，存在的话直接 Clone 即可，否则从远端 Glance 中下载到本地并导入到 Ceph 集群中，下次创建虚拟机时就能直接 Clone 了。存在的问题之一时，目前 RBD Image Backend 并没有实现缓存功能，因此需要自己开发此功能。问题之二，如何管理 Cell 内部的 Ceph 镜像缓存，Glance 镜像已经删除后，如果本地也没有虚拟机依赖，则可以把 Base 镜像删除了，这需要定时任务来清理。问题之三，创建 Volume 时如何保证和虚拟机在同一个 Cell 中，因为不同的 Cell 是不同的 Ceph 集群，挂载就会有问题，其中一个可选方案是通过 Available Zone（AZ）来限制，此时用户在创建虚拟机和 Volume 时都必须指定 AZ，当用户需要挂载 Volume 到其它 Cell 的虚拟机时，必须先执行迁移操作。

很多功能不能用

由于 Nova Cells 采用二级调度策略，在调度 Cells 时并不能拿到所有 Hypervisor 的信息，因此与之相关的功能都不能用或者出错，比如主机集合、Server Group 等，调度功能也大大受限，比如 Compute Capabilities Filter、Numa Topology Filter、Trusted Filter 等，这些 Filters 为什么不能用了？假如只有 Cell1 的主机满足 Compute Capabilities，但是在调度 Cell 时调度到了 Cell2，由于 Cell2 没有符合条件的主机，因此必然会调度失败，但显然我们有合法的宿主机。另外，Nova Cells 虽然对用户是透明的，但其本身还是存在隔离的，目前不同 Cells之 间不支持虚拟机迁移操作，当一个 Cell 出现故障时，也不能疏散到其它 Cell 中。

虚拟机信息不一致

虚拟机信息被保存在多处，所有的子 Cell 都必须同步复制到 Top Cell 中，一旦同步出现问题导致数据不一致性，就可能出现非常棘手的问题。比如在 Compute Cell 中的某一个虚拟机由于某些原因状态变成 ERROR 了，但没有同步到 Top Cell 中，用户看到的还是 Active 状态，但后续的所有操作都会失败，运维人员必须逐一检查该虚拟机经过的所有 Cell 的数据库数据，直到 Compute Cell，发现状态不一致，必须手动修改数据库，这些操作都是十分危险的，必须具有非常熟练的数据库运维能力。

Nova Cells“涅磐重生”

前面踩到的坑，社区也发现了这些问题，但由于这是由于 Nova Cells 的设计缺陷所导致的，要修复这些问题，只通过填填补补是不可能解决的，社区对这些问题的唯一反馈就是不建议在新的环境上部署 Cells 服务，后续 Cells 相关文档也不会再更新。目前社区已经彻底放弃了该方案，如今 Nova Cells 开发已经冻结了，意味着不会再开发任何新特性，也不会修复与之相关的 Bug，后续的开发也不会保证 Cells 的兼容性。

So，Nova Cells 已死？值得庆幸的是，Nova Cells 其实并没有彻底死去，而是涅槃重生了。从L版开始，社区扔掉原设计的同时，吸取之前的教训，开始着手重新设计 Nova Cells 并彻底重构代码。为了区分，之前的 Nova Cells 命名为 Nova Cells v1，而新方案命名为 Nova Cell v2。Nova Cells v2 为了避免 Nova Cells v1 的问题，一开始就提出了几个明确的设计原则和目标。

Nova 全面支持 Nova-Cells

之前 Nova Cells 是可选安装的，开启 Nova Cells 功能，必须额外安装 Nova-Cells 服务以及额外配置，用户对这个功能的了解和关注程度都是比较低的，而参与开发这一功能的开发者也很少，导致 Cells 的开发力度不够，部署率低，成熟度低。而对于 v2 版本，Nova 开始全面支持，废弃原来的 Nova-Cells 服务，不需要额外部署其它任何服务，减少了部署的复杂度，也容易从原来的非 Cells 架构中升级为 Cells 架构。在 N 版之后，Nova Cells 将成为必须部署方式，相当于 Nova 的内置功能，而不再是可选功能，这大大增加了用户和开发者的关注度。

分离公共数据，只存放一处

为了解决之前的数据一致性问题，在 v2 版本中，从 M 版开始把公共数据从原来的 nova 数据库中分离出来，放在单独的 nova_api 数据库中，这些公共数据包括：flavors，quotas；security group、rules，key pairs，tags，migrations，networks。

此方案解决了公共数据的不一致性问题。另外，Top Cell 也不再保存虚拟机信息了，而仅仅保存其 UUID 与 Cell 之间映射表，虚拟机信息只保存在其所在的 Cell 中，Top Cell 与 Compute Cell 之间不再需要复制同步。由于完整数据只存放一处，不存在数据不一致问题，拿到的数据保证是正确的。

支持 Nova 的所有功能

前面提到 v1 版本存在功能限制，除此之外，对 Neutron 的支持也缺乏测试和验证。而在 v2 设计目标中强调将支持所有功能，无任何功能限制，并且全面支持 Neutron 集成，不再考虑 Nova-Network。

最新的 v2 结构已经不是树状的了，而且没有了 Nova-Cells 这个组件，其架构如图5。

图5 v2 结构的最新架构图

从图5可以看出，新版本的 Nova Cells v2 采用单级调度机制替代了原来的二级调度，由 Nova-Scheudler 服务负责调度 Cell，同时负责选择 Cell 中的主机。另外还设计了个额外的 Cell0 模块，如果你在进行虚拟机调度操作时，调度到任何一个 Cell 都出错，或者没有可用 Cell 的话，这是系统会先将请求放置在 Cell0 中，Cell0 中只有一个 Nova DB，没有消息队列和 Nova 服务。

Nova Cell v2 是一个革命性的变化，其设计目标已经非常明确，也是最期待的方案，但离完全实现还有一定的距离，目前还不支持多 Cells 调度，很多功能正在紧急开发中，目前还不能投入生产使用，不过社区后续会推出 v1 升级 v2 或者非 Cell 转化为 Cell 架构的工具。

不过 Nova Cells v2 也存在问题，我认为：

1. 查询虚拟机信息时，需要首先在 Top Cell 中拿到所有虚拟机的索引和 Cell 映射，然后需要往所有的 Cells 请求数据，这可能导致查询性能低下。
2. 当某个 Cell 出现故障时，就拿不到这部分虚拟机信息了，这个问题该如何处理？
3. Cells 之间通过消息队列通信，如果跨 DC 部署，性能就会非常低下。

任何方案都不能是十全十美的，虽然 Nova Cell v2 也存在问题，但仍值得期待并给予厚望，希望 Nova Cells v2 不会让我们失望，彻底解决 OpenStack 大规模部署问题。

总结与展望

本文首先介绍了大规模部署 OpenStack 存在的主要问题，引出数据库和消息队列是限制大规模部署的主要瓶颈，然后针对这个瓶颈问题介绍了一些组件优化策略，最后详细介绍了几种 OpenStack 大规模部署的方案，分析了其特点和不足。针对大规模部署问题，Nova Cell v2 和 Trio2o 都是比较值得期待的，其设计理念和目标也比较明确，但是离实现和发展成熟还有一定的距离。Region 方案只是共享认证和 Dashboard，实现统一管理多 OpenStack 环境，原则上不算是单 OpenStack 的大规模部署。Nova Cell v1 已经有不少大规模部署的案例，但社区已经不再支持，并且不鼓励在新的环境中部署。如果目前需要上线大规模OpenStack生产环境，有以下两种方案：

1. 使用 Nova Cell v2，同时加入 v2 开发，缺点是开发所有功能的周期不确定，也面临很多变数。
2. 使用 Nova Cell v1，部署架构有可供参考的案例，缺点是后续的所有问题都需要自己解决，得不到上游的支持。

当然也可以先部署一套小规模的环境，等 Cell v2 开发完成后，使用升级工具调整架构，增加 Cells 功能。

业务视角下的微服务架构设计实例

Hurricane 实时处理系统架构剖析

实施微服务的关键技术架构

网易云容器服务基于 Kubernetes 的实践探索

Kubernetes、 Microservice 以及 Service Mesh 解析

阅读全文: http://gitbook.cn/gitchat/geekbook/5a5eafebdff55721bc1dcacc