OpenStack之Region、Available Zone、Host Aggregates

OpenStack之Region、Available Zone、Host Aggregates

亚马逊AWS是公共云计算的先驱，一些云计算中重要的产品设计和基础概念可以说都是亚马逊引入的。这其中有两个非常重要的概念：地域（Region）和可用区（AZ：Available Zone）。

Region

很多第一次接触云计算的同学，光看这两个名字的字面意义，虽然也能够猜出大致的意思，但深入的学习了解云计算一段时间之后，才能深刻的体会这两个概念对于云计算的重要影响。包括国内的这些云计算服务商，也是过了很长时间才陆续在产品中引入可用区的设计的。

理想情况下，我们当然希望云计算能够彻底消除地域的影响，就像我们用电的时候不用关心发电厂在哪里一样。但现实显然没有那么美好，不同地域的机房之间的网络还做不到像电网一样透明。所以在云计算产品的最底层，首先需要考虑不同地域的影响。不同地域之间，一般只能通过公网连通，内部之间网络是不通的。当然，对于云计算服务商来说，为管理需要，一般还是会通过有限的带宽来连通不同地域的机房，用于云计算内部资源管理，以及一些特殊的产品场景，比如跨地域的镜像复制。但因为内部带宽有限，一般不会完全开放给用户使用。

所以，地域就是物理意义上的不同地方的机房，这个不同地方，一般来说距离较远，机房之间用光纤直连的成本较高。并且相对来说会在用户需求量较大的地方部署地域机房，比如阿里云的云服务器的地域在境内有杭州，上海，北京，深圳，青岛，海外已经上线的包括香港、硅谷和新加坡。实际上阿里云一开始是没有上海地域的，因为上海杭州距离较近，部署直连光纤的成本也相对可控，阿里内部之前很多应用都是分别部署在杭州和上海，基本上是当作一个地域来使用的，后来可能因为需求大而分开了。

所以，地域很好理解，就是物理上相隔较远的机房，因为跨地域的机房之间的带宽无法满足内网需求，所以不同地域的机器之间内网是不通的。当然，随着骨干网络等物理层基础设施的发展，未来跨地域内网连通并非完全不可能的事情。在这个过程中，公共云计算服务商也可能根据用户的诉求，在某些场景开放一些有限的内部网络带宽来做产品，比如，前面说的阿里云的跨地域镜像复制，以及最近推出来的OSS跨地域复制等。一般来说，在数据和存储领域内的产品会先行支持跨地域的功能，毕竟数据容灾是更强烈的需求。

Available Zone

那么，同一个地域之内又分成多个可用区，为什么要搞这么复杂？原因很简单，IT系统从远古时代就有同城容灾的需求，那使用云计算以后，怎么实现同城跨机房容灾呢？如果用户购买的云服务器无法区分在哪个机房，那么就无法在业务应用层面来设计同城容灾。所以云计算服务商提出了同地域内不同可用区的概念，简单点理解，可以认为就是同城不同机房，云计算服务商会从底层的机房电力/网络等层面仔细设计来保障一个可用区出现故障的时候不会影响到另外一个可用区，当然你要说杭州彻底被钱塘江潮淹没的情况，那可用区也救不了你，要在业务应用层面考虑通过不同的地域来设计异地容灾了。

所以，简单来说，可以将地域理解为不同城市的机房，将可用区理解为同一个城市的不同机房。当然，实际上不同可用区也可能是在同一个机房的不同机柜，可用区的概念严格来说是按照电力和网络设备等相互独立来设计的。同一个地域内的不同可用区之间，内网是连通的，但是网络的响应时间会有差异。

目前 OpenStack 默认的安装是把所有的 computes 节点划分到 nova 的 Availability Zone 上，但我们可以通过对 nova.conf 文件的配置来定义不同的 Availability zones。

Host Aggregates

主机聚合（Host Aggregates）是在 Availability Zones 的基础上更进一步地进行逻辑的分组和隔离。例如我们可以根据不同的 computes 节点的物理硬件配置将具有相同共性的物理资源规划在同一 Host Aggregate 之下，或者根据用户的具体需求将几个 computes 节点规划在具有相同用途的同一 Host Aggregate 之下，通过这样的划分有利于提高 OpenStack 资源的使用效率。

OpenStack中如何应用Host Aggregates来更有效地分配硬件资源：

https://blog.csdn.net/qq_29518275/article/details/103035877