openstack中region、az、host aggregate、cell 概念

1. region

　　更像是一個地理上的概念，每一個region有本身獨立的endpoint，regions之間徹底隔離，可是多個regions之間共享同一個keystone和dashboard。（注：目前openstack的dashboard還不支持多region）

　　因此除了提供隔離的功能，region的設計更多側重地理位置的概念，用戶能夠選擇離本身更近的region來部署本身的服務。

2. cell

　　cell是openstack一個很是重要的概念，主要用來解決openstack的擴展性和規模瓶頸。衆所周知，openstack是由不少的組件經過鬆耦合構成，那麼當達到必定的規模後，某些模塊必然成爲整個系統的瓶頸。比較典型的組件就是database和AMQP了，因此，每一個cell有本身獨立的DB和AMQP。

　　另外，因爲cell被實現爲樹形結構，天然而然引入了分級調度的概念。經過在每級cell引入nova-cell服務，實現瞭如下功能：

• Messages的路由，即父cell經過nova-cell將Messages路由到子cell的AMQP模塊
• 分級調度功能，即調度某個instances的時候先要進行cell的選擇，目前只支持隨機調度，後續會增長基於filter和weighing策略的調度
• 資源統計，子cell定時的將本身的資源信息上報給父cell，用來給分級調度策略提供決策數據和基於cell的資源監控
• cell之間的通訊(經過rpc完成)

　　最後，全部的子cell公用底層cell的nova-api，子cell包含除了nova-api以外的其餘nova服務，固然全部的cell都共用keystone服務。

　　（注：nova-*是指除了nova-api以外的其餘nova服務，子cell + 父cell才構成了完整的nova服務）

　　

　　每個 Cell 包含獨立的 Message Broker 以及 Database，其中 API Cell 主要包含 nova-api 服務，用於接收用戶請求，並將用戶請求經過 message 的形式發送至指定的 Cell；Child Cell 包含除 nova-api 以外的全部 nova-*服務，實現具體的 Nova Compute 節點服務;API Cell 與 Child Cell 共享 Glance 服務，且各 Cells 之間的通訊均經過 nova cells 服務進行。Cell 調度獨立於與 host 調度，在建立新的實例時，首先由 nova-cells 選擇一個 Cell。當 Cell 肯定後，實例建立請求會被送達目標 Cell 的 nova-cells 服務，隨後該請求會被交給本 Cell 的主機調度機制處理，此時主機調度機制會像未配置 Cell 的環境同樣處理該請求。

　　 http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html

3. Availability Zone

　　AZ能夠簡單理解爲一組節點的集合，這組節點具備獨立的電力供應設備，好比一個個獨立供電的機房，一個個獨立供電的機架均可以被劃分紅AZ。因此，AZ主要是經過冗餘來解決可用性問題。　　

　　AZ是用戶可見的一個概念，用戶在建立instance的時候能夠選擇建立到哪些AZ中，以保證instance的可用性。

4. Host Aggregate （http://docs.openstack.org/havana/config-reference/content/host-aggregates.html）

　　AZ是一個面向用戶的概念和能力，而host aggregate是管理員用來根據硬件資源的某一屬性來對硬件進行劃分的功能，只對管理員可見，主要用來給nova-scheduler經過某一屬性來進行instance的調度。其主要功能就是實現根據某一屬性來劃分物理機，好比按照地理位置，使用固態硬盤的機器，內存超過32G的機器，根據這些指標來構成一個host group。

　　Example: Specify compute hosts with SSDs

/etc/nova/nova.conf:
scheduler_default_filters=AggregateInstanceExtraSpecsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter

$ nova aggregate-create fast-io nova
+----+---------+-------------------+-------+----------+
| Id | Name    | Availability Zone | Hosts | Metadata |
+----+---------+-------------------+-------+----------+
| 1  | fast-io | nova              |       |          |
+----+---------+-------------------+-------+----------+

$ nova aggregate-set-metadata 1 ssd=true
+----+---------+-------------------+-------+-------------------+
| Id | Name    | Availability Zone | Hosts | Metadata          |
+----+---------+-------------------+-------+-------------------+
| 1  | fast-io | nova              | []    | {u'ssd': u'true'} |
+----+---------+-------------------+-------+-------------------+

$ nova aggregate-add-host 1 node1
+----+---------+-------------------+-----------+-------------------+
| Id | Name    | Availability Zone | Hosts      | Metadata          |
+----+---------+-------------------+------------+-------------------+
| 1  | fast-io | nova              | [u'node1'] | {u'ssd': u'true'} |
+----+---------+-------------------+------------+-------------------+

$ nova aggregate-add-host 1 node2
+----+---------+-------------------+---------------------+-------------------+
| Id | Name    | Availability Zone | Hosts                | Metadata          |
+----+---------+-------------------+----------------------+-------------------+
| 1  | fast-io | nova              | [u'node1', u'node2'] | {u'ssd': u'true'} |
+----+---------+-------------------+----------------------+-------------------+
$ nova flavor-create ssd.large 6 8192 80 4
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 6  | ssd.large | 8192      | 80   | 0         |      | 4     | 1           | True      | {}          |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
# nova flavor-key set_key --name=ssd.large  --key=ssd --value=true
$ nova flavor-show ssd.large
+----------------------------+-------------------+
| Property                   | Value             |
+----------------------------+-------------------+
| OS-FLV-DISABLED:disabled   | False             |
| OS-FLV-EXT-DATA:ephemeral  | 0                 |
| disk                       | 80                |
| extra_specs                | {u'ssd': u'true'} |
| id                         | 6                 |
| name                       | ssd.large         |
| os-flavor-access:is_public | True              |
| ram                        | 8192              |
| rxtx_factor                | 1.0               |
| swap                       |                   |
| vcpus                      | 4                 |
+----------------------------+-------------------+
Now, when a user requests an instance with the ssd.large flavor, the scheduler only considers hosts with the ssd=true key-value pair. In this example, these are node1 and node2.

　　另外，G版中，默認狀況下，對Nova服務分爲兩類，一類是controller節點的服務進程，如nova-api, nova-scheduler, nova-conductor等；另外一類是計算節點進程，nova-compute。對於第一類服務，默認的zone是配置項internal_service_availability_zone，而nova-compute所屬的zone由配置項default_availability_zone決定。（這兩個配置項僅在nova-api的節點起做用，horizon界面纔會刷新）。

　　多是社區的開發人員意識到，讓管理員經過配置的方式管理zone不太合適，不夠靈活，因此在G版中將這一方式修改。就改用nova  aggregate-create 命令，在建立一個aggregate的同時，指定一個AZ。

root@controller:~# nova help aggregate-create  
usage: nova aggregate-create <name> [<availability-zone>]  
  
Create a new aggregate with the specified details.  
  
Positional arguments:  
  <name>               Name of aggregate.  
  <availability-zone>  The availability zone of the aggregate (optional).  

　　所以建立一個aggregate後，同時把它做爲一個zone，此時aggregate=zone。由於你們知道，aggregate是管理員可見，普通用戶不可見的對象，那麼這個改變，就可使普通用戶可以經過使用zone的方式來使用aggregate。

　　建立完aggregate以後，向aggregate里加主機時，該主機就自動屬於aggregate表示的zone。

　　在G版以後，能夠認爲aggregate在操做層面與AZ融合在一塊兒了，但同時又不影響aggregate與flavor的配合使用，由於這是兩個調度層面。同時又要注意，一個主機能夠加入多個aggregate中，因此G版中一個主機能夠同時屬於多個Availability Zone，這一點也與以前的版本不一樣。