flexibility of openstack(1)

作为一个云平台，最看重的几个因素，在我看来是扩展性，安全性，容错性，不是说其他的不重要，而是这三点是称之为“云”的关键而已，

说到扩展性，openstack很多概念就是为其而生的，基本上都能在AWS找到对应，毕竟在AWS面前，openstack还是学生，不过我相信，很快它会变成老师。

我想这些概念肯定会看起来很熟悉：

region, available zone, aggregates,cells

region

region可以理解成地理位置，大的云计算厂商会在全世界各地设置云计算中心，香港，北京，上海等地的数据中心，对openstack来说，region就是区分这些数据中心，

现在的openstack在region层面没有多少东西，在J版以前（我看的是J版和K版），网上说horizon是不支持多region的，同时即使配置了多个region，也是贡献同一套

keystone，且horizon上默认显示regionOne，只有多个horizon才能管理多个region，但是我看K版的horizon中：

在local_settings.py中：

# For multiple regions uncomment this configuration, and add (endpoint, title).
#AVAILABLE_REGIONS = [
#    ('http://cluster1.example.com:5000/v2.0', 'cluster1'),
#    ('http://cluster2.example.com:5000/v2.0', 'cluster2'),
#]

是支持多region的，从horizon代码中看出是可以在不同region间切换的，同时不同的region配置不同的keystone，没有仔细trace进去，切换region时，要是不同region

使用不同的验证，应该需要重新输入用户名密码验证的吧（没有多region环境验证过，只是个人理解）。

配置文件中对region的配置不多，nova中：

region_list=   #AWS ec2配置

os_region_name=  #cinder client配置

region_name=RegionOne  #nova服务所在region，默认是RegionOne

而neutron.conf中：

nova_region_name =RegionOne

在keystone的/etc/keystone/default_catalog.template中

catalog.RegionOne.identity.publicURL = http://localhost:$(public_port)s/v2.0
catalog.RegionOne.identity.adminURL = http://localhost:$(admin_port)s/v2.0
catalog.RegionOne.identity.internalURL = http://localhost:$(public_port)s/v2.0
catalog.RegionOne.identity.name = Identity Service

# fake compute service for now to help novaclient tests work
catalog.RegionOne.compute.publicURL = http://localhost:8774/v1.1/$(tenant_id)s
catalog.RegionOne.compute.adminURL = http://localhost:8774/v1.1/$(tenant_id)s
catalog.RegionOne.compute.internalURL = http://localhost:8774/v1.1/$(tenant_id)s
catalog.RegionOne.compute.name = Compute Service

要是多个region，也需要修改这里的RegionOne，让keystone work起来。

available zone

如果我们看nova/db/sqlalchemy/models.py，发现”Instance“ 其实没有region属性，但是有availability_zone和cell_name,

available zone是对物理硬件的逻辑划分，就其目的而言，划分available zone时，一般是电源隔离的或者网络隔离的，一组硬件，

比如一个机架的所有机器称之为一个zone，或者一个供电线路的机器成为一个zone，zone在备份和容错上有好处，（联想到hadoop中

hdfs的容错备份机制），在不同的available zone中备份一个instance，可以使得一个机架down时，另一个切换发挥作用。

在horizon上创建instance时，要制定available zone，执行：zones = api.nova.availability_zone_list(request)， detail默认为False

调用nova client的 rest call：

            return self._list("/os-availability-zone",
                              self.return_parameter_name)
在nova/api/openstack/compute/contrib/availability_zone.py中，调用AvailabilityZoneController的index方法，trace一下，

 def _describe_availability_zones：

     available_zones, not_available_zones = availability_zones.get_availability_zones(ctxt)

trace这个函数，同时进去数据库，跟着看数据库中services和aggregates两个表的内容，available zone list得到过程为：

1.查询services表，得到所有service（什么算service，nova-conductor，nova-compute，nova-scheduler，nova-cert，nova-consoleauth）

2.根据service的host得到host的set，比如此处我得到了controller，compute1，compute2，compute3

3. 根据key=‘availability_zone’得到aggregates，并由hosts filter结果集，每个service都有其“availability_zone”

4. 对每个service，如果运行的是nova-compute service，如果有aggregates指定在该host上，其对应的available zone也为此service的available zone的一员，

5. 反之则为默认的available zone（nova）

6.对其他service，available_zone为internal default available zone(internal)

可以trace的更细，为什么available zone非要和aggregate搅合在一起呢，虽然这两个概念有重叠，侧重点不同，不过我认为把他们摘清楚不是更好?

host aggregates

aggregates也是对节点的逻辑划分，我认为available zone重在冗余和容错，而aggregates重在创建instance时的filter，也为了更直观的了解物理硬件的分布，

比如逻辑上，我们将所有CPU更强悍的分成一个aggregate，将硬盘转速更快的机器分成一个aggregate，再或者将网卡是10GB的分成一个aggregate等等，

所以aggregate和az是有重叠的，因为你可以将一个机架的机器分为一个aggregate，从概念上说这并没有问题。

查看aggregate的创建过程，你会发现 avail_zone = host_aggregate.get("availability_zone")，创建aggregate时要指定az的，这也是上面说az时和aggregate搅合

在一起的原因。

明白了二者的区别和联系，合理的使用az和aggregate才重要，mark的link中用图的形式直观的展现了region，az，aggregate的区别和联系。

还有一个就是cell，cell的概念大概是G版之后引进的，相比这三个要复杂些，待续。。。

mark link

http://blog.csdn.net/quqi99/article/details/8687511

http://blog.chinaunix.net/uid-20940095-id-4064233.html

http://www.tuicool.com/articles/qay673