打算開始寫一個Openstack的分析系列，其實接觸Openstack也比較久了，但是一直沒有深入瞭解，而且因爲本人對Python知之甚少，用之甚少，所以想研究Openstack的代碼上手就會比較困難，再加上代碼量也比較大。
不過還是打算下定決心做一個系列的分析，不會全部看，大概只看NOVA和Neutron兩個模塊，而且按照我的認知習慣，還是先要了解全局再去深入細節，所以頭幾篇分析都會集中在What， Why以及How上來看，重點是怎麼用，解決方案是什麼。
What is OpenStack
在Openstack的官方網站上對這一點說的非常簡單，而且非常好，我先把原文附上：
OpenStack is a cloud operating system that controls large pools of compute, storage,
and networking resources throughout a datacenter, all managed through a dashboard
that gives administrators control while empowering their users to provision
resources through a web interface.說Openstack是一個雲操作系統，這裏我們不免要和Linux做對比，同樣作爲操作系統，Linux需要做如下幾件事情：
- 資源管理：這裏的資源包括CPU，網卡，顯卡，內存，硬盤等
- 進程管理：本質上就是任務的調度，在合適的時間分配合適的資源來執行任務
- 存儲管理：包括文件系統，內存管理等
- 網絡通訊：包括主機協議棧的實現以及虛擬設備的支持
- 安全問題 …
其實從以上幾點我們已經看出同爲操作系統，大家都大同小異，都要解決資源的抽象和管理問題，資源的分配和調度問題，和用戶的人機交互問題，應用的生命週期管理問題，以及系統的管理維護問題。 不同點在於，OpenStack需要管理更多的資源，它管理的CPU已經不僅僅侷限於一臺服務器內部的CPU而是整個數據中心的資源；另外作爲雲服務，很重要的一點就是業務上要支持多租戶，雖然Linux是支持多核，多任務的操作系統，可以在一定程度上支持資源隔離。但是在雲操作系統這個層面纔是真正實現多租戶的業務場景。
OpenStack能做什麼
OpenStack當前在私有云的解決方案更多，基於OpenStack做公有云的還比較少，而且近些年用OpenStack做公有云的公司有越來越多的撤出的趨勢，另外是託管雲，像Rackspace等傳統IDC廠商開始提供此類服務，12%的受訪者通過合約委託服務供應商託管專屬的OpenStack部署，藉此幫助客戶省略繁瑣的管理問題。其實還有一個大的市場沒有沒計入，這就是電信雲，隨着近些年NFV的興起，電信運營商也開始大規模投入希望完成網絡業務雲化轉型。這裏面以AT&T, 中國移動爲首。
OpenStack在整個雲解決方案中是一個什麼樣的角色呢？OpenStack在雲平臺這個大的系統裏面也只是一個部件，這個部件的定位就是前面所說的操作系統，以OpenStack爲框架，將計算、存儲、網絡、管理、運營、運維等多個領域的軟硬件產品組件整合在一起，共同組成面向業務場景的整體解決方案。OpenStack優先關注控制面：OpenStack優先考慮如何將計算、存儲、網絡領域的各類資源抽象爲資源池。在此基礎上，對資源池內的各類邏輯對象實施控制操作，並將控制操作包裝成服務。數據面、運維面、管理面目前不是OpenStack的重點關注內容。
鑑於OpenStack的定位，OpenStack社區的核心項目主要都是提供IAAS的服務，也有提供PAAS服務和SAAS服務的項目，但是應用度並不廣。
OpenStack的設計思想
OpenStack在設計初期就是對標AWS，很多項目在AWS上都能找到對應的模塊，但是在設計思想上其秉承着開放，靈活，可擴展的原則。
開放性
- 源代碼開放，設計與開發流程開放
- “不重複發明輪子”，“站在巨人的肩膀上”，大量使用其他開源軟件
- 不使用任何不可替代的商業產品
靈活
- 架構可裁減，可以根據實際需要決定選取的組件範圍
- 大量採用驅動與插件機制
- 通過配置項控制對系統功能特性進行便捷配置
可擴展
- 鬆耦合架構，組件間RESTful API通信，組件內消息總線通信
- 無中心架構，核心組件無中心節點，有效避免單點故障
- 無狀態架構，各組件無本地持久化數據，所有持久化數據保存在數據庫中
OpenStack的部署
雲計算的理念是在可以網絡接入的地方像用水用電一樣隨時獲取計算資源並且按需使用和付費。亞馬遜AWS是公共雲計算的先驅，一些雲計算中重要的產品設計和基礎概念可以說都是亞馬遜引入的。這其中有兩個非常重要的概念：地域（Region）和可用區（AZ：Available Zone）。很多第一次接觸雲計算的同學，光看這兩個名字的字面意義，雖然也能夠猜出大致的意思，但深入的學習瞭解雲計算一段時間之後，才能深刻的體會這兩個概念對於雲計算的重要影響。包括國內的這些雲計算服務商，也是過了很長時間才陸續在產品中引入可用區的設計的。
理想情況下，我們當然希望雲計算能夠徹底消除地域的影響，就像我們用電的時候不用關心發電廠在哪裏一樣。但現實顯然沒有那麼美好，不同地域的機房之間的網絡還做不到像電網一樣透明。所以在雲計算產品的最底層，首先需要考慮不同地域的影響。不同地域之間，一般只能通過公網連通，內部之間網絡是不通的。當然，對於雲計算服務商來說，爲管理需要，一般還是會通過有限的帶寬來連通不同地域的機房，用於雲計算內部資源管理，以及一些特殊的產品場景，比如跨地域的鏡像複製。但因爲內部帶寬有限，一般不會完全開放給用戶使用。
所以，地域就是物理意義上的不同地方的機房，這個不同地方，一般來說距離較遠，機房之間用光纖直連的成本較高。並且相對來說會在用戶需求量較大的地方部署地域機房，比如阿里雲的雲服務器的地域在境內有杭州，上海，北京，深圳，青島，海外已經上線的包括香港、硅谷和新加坡。實際上阿里雲一開始是沒有上海地域的，因爲上海杭州距離較近，部署直連光纖的成本也相對可控，阿里內部之前很多應用都是分別部署在杭州和上海，基本上是當作一個地域來使用的，後來可能因爲需求大而分開了。
所以，地域很好理解，就是物理上相隔較遠的機房，因爲跨地域的機房之間的帶寬無法滿足內網需求，所以不同地域的機器之間內網是不通的。當然，隨着骨幹網絡等物理層基礎設施的發展，未來跨地域內網連通並非完全不可能的事情。在這個過程中，公共雲計算服務商也可能根據用戶的訴求，在某些場景開放一些有限的內部網絡帶寬來做產品，比如，前面說的阿里雲的跨地域鏡像複製，以及最近推出來的OSS跨地域複製等。一般來說，在數據和存儲領域內的產品會先行支持跨地域的功能，畢竟數據容災是更強烈的需求。
那麼，同一個地域之內又分成多個可用區，爲什麼要搞這麼複雜？原因很簡單，IT系統從遠古時代就有同城容災的需求，那使用雲計算以後，怎麼實現同城跨機房容災呢？如果用戶購買的雲服務器無法區分在哪個機房，那麼就無法在業務應用層面來設計同城容災。所以雲計算服務商提出了同地域內不同可用區的概念，簡單點理解，可以認爲就是同城不同機房，雲計算服務商會從底層的機房電力/網絡等層面仔細設計來保障一個可用區出現故障的時候不會影響到另外一個可用區，當然你要說杭州徹底被錢塘江潮淹沒的情況，那可用區也救不了你，要在業務應用層面考慮通過不同的地域來設計異地容災了。
所以，簡單來說，可以將地域理解爲不同城市的機房，將可用區理解爲同一個城市的不同機房。當然，實際上不同可用區也可能是在同一個機房，可用區的概念嚴格來說是按照電力和網絡設備等相互獨立來設計的。同一個地域內的不同可用區之間，內網是連通的，但是網絡的響應時間會有差異。下面是我用阿里雲杭州地域做的一次ping的測試，來觀察同地域不同可用區之間的網絡情況。
OpenStack在AWS的基礎上又引入了Cell 和 Host Aggregates Zone(HAZ) 兩個概念，其中 Cell 是爲了擴充一個 Region 下的集羣的規模而引入的，Host Aggregates 是優化資源調度和利用引入的。
Region的部署
顧名思義，Region 直譯過來就是區域，地域的概念，而事實上，AWS 按地域(國家或者城市)設置一個 Region，每個 Region 下有多個 Availability Zone。Openstack 同樣支持 Region 的概念，支持全球化部署，比如爲了降低網絡延時，用戶可以選擇特定的 Region 來部署服務。各個 Region 之間的計算資源、網絡資源、存儲資源都是獨立的，但所有 Region 共享賬戶用戶信息，因爲 Keystone 是實現 openstack 租戶用戶管理和認證的功能的組件，所以 Keystone 全局唯一，所有 Region 共享一個 Keystone，Keystone endpoint 中存儲了訪問各個 Region 的 URL。
Cell的部署
Cell 概念的引入，是爲了擴充單個 Region 下的集羣規模，主要解決 AMQP 和 Database 的性能瓶頸，每個 Region 下的 openstack 集羣都有自己的消息中間件和數據庫，當計算節點達到一定規模(和IBM，easystack，華爲等交流的數據是300~500)，消息中間件就成爲了擴展計算節點的性能瓶頸。Cell 的引入就是爲了解決單個 Region 的規模問題，每個 Region 下可以有多個 Cell，每個 Cell 維護自己的數據庫和消息中間件，所有 Cell 共享本 Region 下的 nova-api，共享全局唯一的 Keystone。
官網手冊提到 Cell 不成熟（Considered experimental），巴黎峯會也提到 Cell 的痛點，雖然現在已進入 K 版本迭代開發中了，但是本人還未聽說業界成熟使用 Cell 的案例。關於 Cell 更詳細的介紹，請參考以下鏈接
http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html
Availability Zone & Host Aggregates Zone
之所以把 AZ 和 HAZ 放到一同分析，是因爲二者的概念實在類似。
AWS 每個 Region 下有多個 AZ。Openstack 也引入了 AZ 的概念，我個人理解 AZ 的引入是基於可靠性的角度考慮，比如我們定義一個機房爲一個 AZ，把該機房所有計算節點納入到一個 AZ 中，其中一個機房因爲某種原因down 掉，不會影響其它機房的虛擬機和網絡；同時， AZ 對用戶來說是一個可見的概念，用戶創建虛擬機時，可以明確指出在哪個 AZ，用戶可以通過在多個 AZ 創建虛擬機來保證高可靠性。
HAZ 也是把一批具有共同屬性的計算節點劃分到同一個 Zone 中，HAZ 可以對 AZ 進一步細分，一個 AZ 可以有多個 HAZ。 同一個 HAZ 下的機器都具有某種共同的屬性，比如高性能計算，高性能存儲(SSD)，高性能網絡(支持SRIOV等)。HAZ 和 AZ 另一個不同之處在於 HAZ 對用戶不是明確可見的，用戶在創建虛擬機時不能像指定 AZ 一樣直接指定 HAZ，但是可以通過在 Instance Flavor 中設置相關屬性，由 nova-scheduler 調度根據該調度策略調度到滿足該屬性的的 Host Aggregates Zones 中。
那麼，同一個地域之內又分成多個可用區，爲什麼要搞這麼複雜？原因很簡單，IT系統從遠古時代就有同城容災的需求，那使用雲計算以後，怎麼實現同城跨機房容災呢？如果用戶購買的雲服務器無法區分在哪個機房，那麼就無法在業務應用層面來設計同城容災。所以雲計算服務商提出了同地域內不同可用區的概念，簡單點理解，可以認爲就是同城不同機房，雲計算服務商會從底層的機房電力/網絡等層面仔細設計來保障一個可用區出現故障的時候不會影響到另外一個可用區，當然你要說杭州徹底被錢塘江潮淹沒的情況，那可用區也救不了你，要在業務應用層面考慮通過不同的地域來設計異地容災了。
所以，簡單來說，可以將地域理解爲不同城市的機房，將可用區理解爲同一個城市的不同機房。當然，實際上不同可用區也可能是在同一個機房，可用區的概念嚴格來說是按照電力和網絡設備等相互獨立來設計的。同一個地域內的不同可用區之間，內網是連通的，但是網絡的響應時間會有差異。在阿里雲杭州地域做的一次ping的測試，來觀察同地域不同可用區之間的網絡情況，發現同可用區之間的內網是連通的，但響應時間比同一個可用區之內要慢1ms多。所以，在實際應用中，如果需要考慮同城容災或者同城雙活，需要儘量將應用和數據庫分佈部署在不同的可用區。如果對響應時間高度敏感，則建議部署在同一個可用區內。在購買雲服務器和數據庫的時候，要注意選擇了。
參考文獻：
http://blog.csdn.net/u010305706/article/details/54406060
