OpenStack中的Nova设计之初要具备大规模水平可扩展的功能，那么我们来看看如何进行云计算资源的可扩展性。
从顶层架构设计先有个认识，Region大于Cell，Cell大于AZ，AZ大于Host Aggregate，我们从小到大来说：
Host Aggregate主机集合
虚机是要部署到计算节点上的，占用计算节点上的资源。计算节点对应一块物理服务器，不同厂商的不同系列的物理服务器有不同的资源和不同的性能抗压能力等等。OpenStack云平台管理员可以根据硬件资源的某一属性，将具有相同硬件属性的服务器归类划分，这就是Host Aggregate。
对Host Aggregate的理解参考很多公有云供应商的云计算资源供给实现，例如供应商的数据中心部署了不同类型的服务器，某些服务器具有强大的计算能力，而另外一些服务器具有强大的I/O能力，其他的一些服务器具有强大的网络吞吐能力，这样供应商为了提供针对特定领域使用的用户，便会将具有强大计算能力的主机放置到一个主机集合中(取名为A)，具有强大I/O能力同时计算能力也不错的主机放置到另一个主机集合中(取名B)。此时，如果有用户想要在该供应商的公有云上部署一个高性能集群，因高性能集群通常有“胖节点”和“瘦节点”之分(“胖节点”既充当计算节点也充当IO节点，而“瘦节点”只做计算节点)，这样用户便可根据需求在主机集合A中创建实例用作“瘦节点”，在主机集合B中创建实例用作“胖节点”。而供应商便可根据用户选择进行差异计费，通常计算能力和I/O能力都不错的主机集合B收费要高于仅提供计算能力的主机集合A(当然收费跟内存CPU磁盘多少也有关系)。
当然供应商还可以根据很多硬件参数来设置Host Aggregate，例如使用固态硬盘的机器，内存超过32G的机器等。根据服务器硬盘所属类型，将AZ中服务器细分为SSD硬盘主机集、SATA硬盘主机集。
用户选择满足某种要求的物理服务器主机集合Host Aggregrate部署虚机即可。我相信在openstack的某个版本中应该是可以安装Host Aggregrate来部署虚机的。不清楚什么原因导致Host Aggregate对用户不可见，因此无法通过指定Host Aggregate来创建虚机。
物理服务器有架式和框式两种，架式服务器直接放置在某个机架中的，框式服务器放在某个机框中然后机框再放到机架中。架式服务器和框式服务器最大区别是后者每个主机的电源，风扇和网口都是内置的，网口是直接连到内置交换机，有一个统一模块来管理这些硬件，相对前者来说比较好管理。一般一个机框有16台物理服务器，一个机架可以容纳2-3个机框，一个机架可以容纳6-10台物理服务器。
想象一下，不同厂商的架式服务器，不同厂商的框式服务器排列组合放到不同机架中，Host Aggeegrate根据硬件资源的某一属性来划分，然而对于某些主机集合Host Aggregrate在某种程度上提供的计算/IO/网络/存储的能力是一样的，且放在同一机架或相邻机架中，这就产生了Availability Zone （AZ）可用域。
AZ(Availability Zone)可用域
为了提高容灾性和提供廉价的故障隔离服务，将处于同一个故障域（Failure Domain, FD）内的服务器划分到一个AZ中，一个故障域在实际的数据中心中通常意味着共享电源系统和网络连接的服务器集合。例如可以把处于相同机架或者相邻机架上的物理服务器划分到同一个AZ中，或者可以把同一个Region中彼此独立供电和制冷的机房划分为独立的AZ。
从功能实现而言，OpenStack中AZ功能主要是基于Nova的调度服务Nova-scheduler来实现的。用户在创建虚拟机时，可以显式告知Nova应该将虚拟机创建在哪个AZ中，当Nova-scheduler接收到AZ参数后，便会将创建虚拟机的请求调度到指定的AZ主机集中，并将虚拟机创建在此AZ中的某台主机上。
随着业务增长，AZ内主机不断增加，根据OpenStack社区的讨论，超过500个计算节点时便会遇到共享消息队列系统的性能问题。为了解决大规模Nova计算节点部署过程中可能带来的集群瓶颈问题，OpenStack的G版本提出Nova的Cell功能。
不管AZ内计算节点个数是否达到500，尤其是公有云，都可能部署到全球的各个区域，用户可以就近选择部署的虚机。此外，为避免人为如恐怖袭击或自然灾害如地震，这就需要Region来解决高可用容灾和部署虚机离用户近的问题。
Cell
根据OpenStack社区的讨论，通常在计算节点数目超过500个时，便会遇到共享消息队列系统的性能问题。Nova的Cell提出的主要需求是解决这个集群瓶颈问题。Nova的Cell功能模块允许用户在保持现有OpenStack云环境不变的前提下，提高OpenStack计算节点水平横向扩展和大规模部署的能力。
在目前发行的OpenStack版本中，Nova Cell功能默认并未启用，而当Nova Cell模块启用后，OpenStack云环境被分成多个子Cell，并且在原有OpenStack云环境中添加子Cell的方式来扩展OpenStack云环境，因此后期Cell功能的启用对原云环境的影响并不是很大。
那么cell是如何解决这个集群瓶颈问题呢？Nova Cell模块以树型结构为基础，树形Cell架构主要由一个API-Cell(父Cell)和多个Child-Cell构成。其中，API-Cell只运行Nova-API服务，而每个Child-Cell运行除Nova-API以外的全部Nova服务，且每个Child-Cell运行自己的消息队列、数据库及Nova-cells服务，即Cell之间的消息队列和数据库都是独立的。Nova Cell通过将共享的消息队列和数据库拆分为以子Cell为单位的独立消息队列和数据库，以分而治之的思想解决大规模计算节点部署时经常出现的消息堵塞和数据库性能问题。
AZ与Cell不同，AZ中没有独立的数据库和消息队列服务器，而是多个AZ共享Cell内部或者Region内部的数据库和消息队列系统。
从Nova Cell的发展历程来看，Nova Cell可以分为Nova Cell V1和Nova Cell V2两个发展阶段。
在Nova Cell V1架构中，不同的计算资源被隔离为多个独立的Cell，而在每个Cell中均有独立的调度、消息队列和数据库服务，不同的Cell之间可以构成树状结构，并逐步向下扩展，因而可以轻松实现OpenStack计算节点的规模扩展。每个Cell中都有独立的数据库服务、独立的消息队列，而不同的Cell之间则通过Nova-Cells服务进行消息传递。在启用Nova Cell V1的OpenStack集群中，用户创建虚拟机的请求首先到达顶层的API Cell(父Cell)，然后通过API Cell的调度算法决定虚拟机应该由哪个Child-Cell负责创建，当某个Compute Child-Cell接收到来自API Cell的请求后，Compute Child-Cell将这个请求通过Nova-Cells服务传递给Cell中的Nova-scheduler服务进行与Cell无关的主机调度，Compute Child-Cell中的Nova-scheduler服务收到请求后，再根据主机资源统计信息决定将虚拟机创建在哪一台物理服务器上。
Nova Cell V1版本在用户实际部署和社区开发过程中都存在诸多问题和限制。Nova的网络模块Nova-network在设计之初并没有主机集合(Host Aggregate)的概念，其对安全组(Security Group)的支持具有一定的局限性，同时对可用域AZ的支持和Cell内部的调度功能都有很大的局限性。在Nova Cell V1中，用户请求需要经历两层调度，即顶层API Cell在多个Compute Cell之间的调度和各个Compute Cell内部的调度，而在Nova Cell V1的内部Cell中，调度所支持的策略和过滤条件都具有一定的局限性。
基于上述原因，Nova Cell V1被认为是实验性质的功能，且Nova Cell的核心团队已经冻结了Cell V1的功能，即不再接受关于Cell V1的新功能建议，也不会再去修复Cell V1中存在的Bug，目前团队的工作优先级和重心是Nova Cell V2的开发设计和Cell V1到Cell V2的迁移。
Cell V2采用了单层调度，用户请求只需通过一层调度即可抵达最终的物理服务器，即API Cell不仅在Compute Cell之间进行调度，还同时对选定的Compute Cell内部的Host进行调度。在每一个Compute Cell中，消息队列系统和数据库是独立的，同时Cell V2将数据库进行了分离实现，即将整个OpenStack的全局信息保存在API Cell的数据库中，而虚拟机等相关信息则保存在各个独立的Cell中。此外，Cell V2在设计上还新增了Cell0模块，一旦API Cell对全部Compute Cell的调度都失败或者没有可用的Compute Cell，则用户请求被暂时存放到Cell0中。
CERN两地三中心的OpenStack部署模式便采用了Nova Cell功能：Nova Cell模式将CERN的OpenStack计算资源进行了隔离，从而使得各个数据中心的OpenStack集群可以实现透明独立的水平扩展。在CERN看来，虽然Nova Cell的部署使得CERN不能使用OpenStack的某些功能，如安全组和实时迁移功能，并且CERN的技术人员也需要在不同数据中心之间手工拷贝类似Flavors这样的某些细节信息，但Nova Cell的部署模式确实解决了CERN的不同数据中心为用户提供统一公共服务Endpoint API的问题和计算节点扩展时的问题。在架构图中，CERN创建了1个API Cell(父Cell)和3个Compute Cell(子Cell)。在每个Compute Cell中，CERN为了进一步划分计算资源又配置了3个可用域，并为每个Compute Cell配置了三个RabbitMQ消息服务器以实现消息队列的高可用性。CERN的API Cell位于瑞士数据中心，并且通过两个负载均衡器配置了API调用的负载均衡。API Cell采用CERN自定义的Cell调度算法来将用户的API请求转发到位于不同数据中心的Compute Cell。
Region
Region是地理位置上隔离的数据中心区域，不同Region之间是彼此独立的，即某个Region范围内的人为或自然灾害并不会影响到其他Region的正常运行。
理想情况下，不同的Region最好是分别位于地球上不同的大洲之间，这种布局使得不同Region几乎不受某个地区大面积自然灾害的影响，当然也可以将不同的Region部署到同一国家的不同省份或州之间，具体如何布局Region更多是受成本预算导向的。
不论是国外的云计算巨头AWS、Azure，还是国内的阿里云、腾讯云等，用户都可以在公有云服务商提供的不同Region中创建自己的服务器并部署业务系统，选择标准通常是以距离用户最近为首选。
Region的设计更多是为公有云服务供应商考虑的，对于私有云部署，如果不进行容灾高可用设计，则通常很少在架构之初考虑Region。此外，Region的多少是衡量一个公有云服务供应商运营成熟度的关键指标。
OpenStack官方推荐的私有云多Region部署架构，Region1和Region2共享Horizon、Keystone和Swift服务，其他OpenStack服务在Region中独立部署。由于不同Region内部服务独立部署，因而不同Region内部相同的OpenStack服务会有不同的Endpints API，对不同Region内部服务的访问就需要指定不同的API，在实际应用中，用户通常是通过负载均衡器实现不同Region中服务API的访问。
对于计算资源的分区，OpenStack仅支持Cell部署、AZ和Host Aggregate划分，并不能实现跨Region的部署；网络服务仅能管理相同广播域或者互联交换机集中的网络资源；块存储服务也只能管理单个Region内相同存储网络内的存储资源。
部署和维护
在OpenStack中，用户可以选择是否启用Nova Cell。如果启用Nova Cell功能，则通常做法是将单个Region部署为Compute Cell然后在Cell中划分AZ；如果用户不启用Nova Cell功能，则直接在Region中划分AZ即可。
主机的增删改，可以在某个region的某个cell的某个AZ的某个Host Aggregate中增加或删除或更改主机。而这个主机可以是计算节点，控制节点，网络节点或者存储节点等。
笔记整理来自山金孝的《OpenStack高可用集群（上册）：原理与架构》8.3章节 Nova分区与区域，如有侵权请通知删除。