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

文章插图
5.很多功能不能用
由于Nova Cells采用二级调度策略，在调度Cells时并不能拿到所有的信息，因此与之相关的功能都不能用或者出错，比如主机集合、 Group等，调度功能也大大受限，比如、Numa、等，这些为什么不能用了？假如只有Cell1的主机满足，但是在调度Cell时调度到了Cell2，由于Cell2没有符合条件的主机，因此必然会调度失败，但显然我们有合法的宿主机。另外，Nova Cells虽然对用户是透明的，但其本身还是存在隔离的，目前不同Cells之间不支持虚拟机迁移操作，当一个Cell出现故障时，也不能疏散到其它Cell中。
6.虚拟机信息不一致
虚拟机信息被保存在多处，所有的子Cell都必须同步复制到Top Cell中，一旦同步出现问题导致数据不一致性，就可能出现非常棘手的问题。比如在 Cell中的某一个虚拟机由于某些原因状态变成ERROR了，但没有同步到Top Cell中，用户看到的还是状态，但后续的所有操作都会失败，运维人员必须逐一检查该虚拟机经过的所有Cell的数据库数据，直到 Cell，发现状态不一致，必须手动修改数据库，这些操作都是十分危险的，必须具有非常熟练的数据库运维能力。
4.4 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的问题，一开始就提出了几个明确的设计原则和目标:
1.Nova全面支持Nova-Cells
之前Nova Cells是可选安装的，开启Nova Cells功能，必须额外安装Nova-Cells服务以及额外配置，用户对这个功能的了解和关注程度都是比较低的，而参与开发这一功能的开发者也很少[1]，导致Cells的开发力度不够，部署率低，成熟度低。而对于v2版本，Nova开始全面支持，废弃原来的Nova-Cells服务，不需要额外部署其它任何服务，减少了部署的复杂度，也容易从原来的非Cells架构中升级为Cells架构。在N版之后，Nova Cells将成为必须部署方式，相当于Nova的内置功能，而不再是可选功能，这大大增加了用户和开发者的关注度。
2.分离公共数据，只存放一处
为了解决之前的数据一致性问题，在v2版本中，从M版开始把公共数据从原来的nova数据库中分离出来，放在单独的数据库中，这些公共数据包括:
此方案解决了公共数据的不一致性问题。另外，Top Cell也不再保存虚拟机信息了，而仅仅保存其UUID与Cell之间映射表，虚拟机信息只保存在其所在的Cell中，Top Cell与 Cell之间不再需要复制同步。由于完整数据只存放一处，不存在数据不一致问题，拿到的数据保证是正确的。
3.支持Nova的所有功能
前面提到v1版本存在功能限制，除此之外，对的支持也缺乏测试和验证。而在v2设计目标中强调将支持所有功能，无任何功能限制，并且全面支持集成，不再考虑Nova- 。
最新的v2结构已经不是树状的了，而且没有了Nova-Cells这个组件，其架构如图：