OpenStack G版之後的Availability Zone與Aggregate Hosts

時間 2019-12-09

標籤 openstack 之後 availability zone aggregate hosts 简体版

原文原文鏈接

關於Availability Zone與Aggregate Hosts的概念解析，能夠參考這篇文章：http://blog.chinaunix.net/uid-20940095-id-3875022.htmlhtml

1. availability zone

az是在region範圍內的再次切分，只是工程上的獨立，例如能夠把一個機架上的機器劃分在一個az中，劃分az是爲了提升容災性和提供廉價的隔離服務。選擇不一樣的region主要考慮哪一個region靠近你的用戶羣體，好比用戶在美國，天然會選擇離美國近的region；選擇不一樣的az是爲了防止全部的instance一塊兒掛掉，下圖描述了兩者之間的關係。node

catalog實際上是分級的 <catalog>.<region>.<service>.<endpoint>，第二級的region就是上文提到的region。在這裏咱們能夠設置不一樣的region和不一樣的service的endpoint。horizon只提取keystone中catalog的regionOne中的endpoint，因此，即便設置了多個region，horizon也體現不出來。數據庫

az在openstack中實際上是nova-scheduler來實現的，當新建虛擬機，調度器將會根據nova-compute設置的az來調度，例如在新建虛擬機的時候，用戶設置了但願將虛擬機放在az-1中，那麼調度器將會選擇屬於這個az的nova-compute來調度，以下圖所示。api

2. Aggregate Hosts

　　Availability zones are a customer-facing capability, host aggregates are meant to be used by administrators to separate hardware by particular properties, and are not seen by customers.memcached

　　az是一個面向終端客戶的概念和能力，而host aggregate是管理員用來根據硬件資源的某一屬性來對硬件進行劃分的功能，只對管理員可見。測試

其主要功能就是實現根據某一屬性來劃分物理機，好比按照地理位置，使用固態硬盤的機器，內存超過32G的機器，根據這些指標來構成一個host group。ui

nova aggregate-create joesservers chicagospa

Host aggregate能夠用來進一步細分availability zone。.net

經過以上分析，問題就來了：availability zone和host aggregate都能對host machine進行劃分，那麼兩者的區別是啥？unix

　az是用戶可見的，用戶手動的來指定vm運行在哪些host上，即用戶可見；Host aggregate是一種更智能的方式，是調度器可見的，影響調度策略的一個表達式

3.Openstack 中如何指定那些computer節點屬於同一availability zone？

　　　在G版之前，當咱們用nova-manage service list 查看nova服務啓動的狀態的時候，即看status是笑臉仍是XX，實際上是經過一個循環任務report_state，循環地向數據庫service表中寫入信息，好比一個計數report_count以及更新該記錄的時間。而判斷該服務狀態時，就會讀取Service表，看當前時刻與該服務上次更新的時間的差值是否在容許的範圍內（配置項service_down_time），若是超出了service_down_time，就認爲該服務狀態異常。因此，總結一下，一個服務狀態是XXX的緣由，要麼是該服務出現了異常，要麼是時間不一樣步致使。

　　須要注意的是，在report_state中，除了report_count，還有一個更新的字段：availability_zone。該字段來源於配置項node_availability_zone。舉個例子，一個nova-compute服務，它的Availability Zone就依賴於配置文件中的node_availability_zone配置項。同時，一個nova-compute僅屬於一個AZ。還有一點要注意，咱們建立aggregate時也能夠指定Availability Zone，而後向aggregate中添加主機時，要求主機的zone與aggregate的zone一致。

　　所以，總結以下：每個computer node的屬於哪個AZ，是經過nova.conf中的node_availability_zone配置項來指定，一個nova-compute僅屬於一個AZ，而且建立Aggregate指定的AZ，在向其添加host的時候，應與host原屬的AZ與其一致。

　　可是從G版開始之後的版本，好比我如今所用的H版裏頭，nova.conf裏面就沒有node_availability_zone的配置字段，雖然還留有一個default_availability_zone的配置項，但僅在nova-api節點起做用。所以在這個時候，若是想用戶起虛擬機的時候能指定AZ，或將某一個compute node指定成一個AZ，該如何操做了？

　　G版中對服務的管理增長了不少方式，能夠是老的更新數據的方式（若是節點很少，可使用這種，不會對數據庫形成大的壓力），但若是節點較多，使用數據庫的方式就不太明智了，此時能夠選擇效率較高的memcached或者zookeeper。因而，Service表中也再也不保存availability_zone字段，配置項node_availability_zone也再也不使用。

　　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，這一點也與以前的版本不一樣。