OpenStack大规模部署详解( 三 ) _虚拟

每个Cell节点都有从根节点到该节点的唯一路径，路径默认通过!分割，比如root!!，表示从root到再到。根节点的Cell类型一定是API就是说Cell对用户是完全透明的，和不使用Cell时是完全一样的。其中Nova-Cells服务是需要额外部署的新服务，该服务主要负责创建虚拟机时，从所有的孩子Cell中选择其中一个子Cell作为虚拟机的Cell，子Cell会继续执行调度直到到达底层的 Cell中，最后转发请求到目标 Cell所在的Nova-服务中。因此采用Nova Cells方案后，Nova实际采用的是二级调度策略，第一级由Nova-Cells服务负责调度Cell，第二级由Nova-服务负责调度计算节点。
Cell节点担任的职责类似于非Cell架构的控制节点，需要部署除Nova-API服务以外的所有其它Nova服务，每个Cell相当于一个完整的Nova环境，拥有自己的Nova-、Nova-等服务以及数据库服务和消息队列服务，并且包含若干计算节点，每个Cell的组件只服务于其自身所在的Cell，而不是整个集群，因此天生具备支撑单集群大规模部署能力。增大规模时，只需要相应增加Cell即可，因此具有非常灵活的可扩展能力。
子Cell的虚拟机信息会逐层向上同步复制到其父Cell中，Top Cell中包含了所有Cells的虚拟机信息，查看虚拟机信息时，只需要从Top Cell数据库查询即可，不需要遍历子Cell数据库。对虚拟机进行操作时，如果不使用Cell，则只需要根据其Host字段，向宿主机发送RPC请求即可。如果使用了Cell，则需要首先获取虚拟机的Cell信息，通过Cell信息查询消息队列地址，然后往目标消息队列发送RPC请求。
4.2 Nova Cell生产案例
Nova Cells方案很早就已经存在一些生产案例了，其中CERN(欧洲原子能研究中心)集群可能是目前公开的规模最大的部署集群，截至2016年2月部署规模如下[7]：
其Nova部署架构如下图:

文章插图
图3 CERN 集群Nova架构
天河二号是国内千级规模的典型案例之一，于2014年初就已经在国家超算广州中心并对外提供服务,其部署规模如下[5]:
除了以上两个经典案例外，、、[6]、等也是采用了Nova Cells方案支持千级规模的集群部署。这些生产案例实践证明了使用Nova Cells支持大规模集群的可能性。
4.3 Nova Cells遇到的坑
刚刚介绍了不少Nova Cells的成功生产案例，让人不禁“蠢蠢欲动”，想要小试牛刀。小编已经架不住诱惑，于是专门申请了23台物理服务器作为Nova Cells测试环境使用，实际部署时包含3个Cells，每个Cell包含7台物理服务器，其中1台控制节点，一台Ceph All-in-one节点，剩余为5个计算节点。另外多余的两台分别作为Top Cell的控制节点和网络节点。部署的版本为，使用社区原生代码。在部署过程中遇到了大大小小不少坑，有些是配置问题，有些是Cells本身的问题。
1. 虚拟机永久堵塞在状态
我们知道，每个Cell都使用自己的独立数据库，因此配置Nova的数据库时，显然需要配置其所在Cell的数据库地址。而从版本开始已经把一些公共的数据从nova数据库单独分离出来一个数据库（原因后面说明）。创建虚拟机时Nova-API不会把初始化数据直接保存到nova数据库的表中，而是保存到数据库的表，此时虚拟机状态为。Nova API获取虚拟机信息时会首先查询的表，如果存在记录，则直接返回虚拟机信息。正常流程下，当执行完调度后，Nova-会自动删除的虚拟机信息。但是在配置多Cell情况下，如果也是配置其所在Cell的数据库地址，当调度到 Cell中时，Cell数据库的显然找不到该虚拟机的信息，因为实际上信息都保存在Top Cell中，因此Top Cell的中的虚拟机信息将永远不会被删除。此时我们使用nova list查看的虚拟机信息是从拿到的过时数据，因此我们查看虚拟机状态永久堵塞在状态。解决办法是所有Cell的数据库都配置使用同一个数据库，数据库本来就是设计为保存公共数据的，为所有的Cell所共享。