經常有朋友讓我介紹Openstack，我就乾脆寫一篇Openstack的元件介紹，也算是總結一下。馬上2012年就要結束了，也是到該總結的時候。去年現在的Openstack，其實官方的Keystone和Horizon還沒法很好的一起工作。

我個人的理解：下面的元件全部工作良好，那麼基本的一個IAAS就算比較完整，這些功能都是目前Rackspace和linode都有的。

Nova

這個是最核心的，Nova最開始的時候，可以說是一套虛擬化管理程式，還可以管理網路和儲存。不過從Essex版本後，Nova開始做減法，和網路相關的內容，包括安全組，交給Quantum負責，儲存相關的交給Cinder負責。排程有關的內容，會交給新的專案

以前還有一個nova common，這其實是各個元件都使用相同的東西，現在也專門成立一個專案：oslo，已經是核心專案。

未來Nova對各種Hyperv的支援是有差異的，KVM和XEN，基本是最好的。微軟的Hyper-V算是很不錯，微軟投入再研發。剛才朋友還專門提到一點：就是未來計算節點，不直接查詢資料庫，而是通過rpc的方式，據說這是一大進步。

Nova的穩定性，其實取決於libvirt，qemu，希望未來可以能更加穩定。功能現在其實已經不是大問題。

keystone

這是提供身份認證和授權的元件。任何系統，身份認證和授權，其實都比較複雜。尤其Openstack 那麼龐大的專案，每個元件都需要使用統一認證和授權。

目前keystone 要做的東西其實還是很多。沒法基於角色的授權，web管理使用者等。當然你如果希望實現使用動態令牌認證，多因素認證，LDAP整合，這都是未來版本需要實現的功能，這些功能都已經在計劃中。

目前好像要實現keystone的高可用，還是比較困難，這個就讓社群慢慢解決吧。大規模部署，這也會是瓶頸。

Glance

這是映象管理。功能其實相對比較簡單。不過Glance後端的儲存的支援，其實一直到Folsom的版本，Glance對swift的支援，才算是比較完善。

目前Glance的映象儲存，支援本地儲存，NFS，swift，sheepdog和Ceph，基本是夠用了。

目前Glance的最大需求就是多個數據中心的映象管理，如何複製，不過這個功能已經基本實現。還有就是租戶私有的image管理，這些目前功能都已經實現。

個人感覺：Glance後續基本就是一個bug修復，穩定的階段。

Quantum

這是網路管理的元件，也是重頭戲，Openstack的未來，基本都要靠quantum。上面介紹nova的時候，說過網路相關的內容，都會交給Quantum。不過Quantum的開發進度不是太如人意。Flosom規劃實現功能，到Grizzly才實現。未來nova network的程式碼清理，估計到H版本都不見得可以實現。

Quantum 後端可以是商業產品或者開源。開源產品支援Openvswitch，和linux bridge。網路裝置廠商都在積極參與，讓他們的產品支援Quantum，目前思科，銳捷已經實現支援。

比較悲觀的估計：quantum要完全滿足生產的需求，例如頻寬限制，mutilhost等功能，很可能需要等到2014年的I版本，真的考驗耐心。

如果你關注Quantum的話，就會發現目前還是在起步階段，無論是bug還是功能，都是非常多。

Cinder

這是儲存管理的元件。一直以來，很多人都很糾結AWS的EBS的實現。Openstack也終於推出了自己的儲存管理元件。

Cinder儲存管理主要是指虛擬機器的儲存管理。目前支援開源和商業化產品。開源的sheepdog，Ceph等。商業儲存的支援，目前ＩＢＭ是最積極的。未來如果商業儲存廠商都支援Cinder，對Openstack的商業化還是非常有利的。

對於企業來說，使用分散式作為虛擬機器的儲存，並不能真正節省成本，維護一套分散式儲存，成本還是很高的。目前虛擬機器的各種高可用，備份的問題，其實都可以把問題交給商業儲存廠商來解決。

Lbaas

這是實現負載均衡的專案。現在linode，Rackspace，都提供了負載均衡的服務，有了這個服務，你才有可能實現所謂的彈性擴充套件。這個元件是Mirantis公司和思科合作開發的。目前這個專案整合在Quantum裡，不過基本算是一個獨立的元件。

Lbaas後端可以是各種商業產品和開源產品。F5，Ngnix，Haproxy，LVS

為了釋出的Grizzly，你應該有機會在Dashboard裡設定虛擬機器的負載均衡。

Horizon

嚴格意義來說，Horizon不會為Openstack 增加一個功能，他更多的是一個演示，demo。不過對於很多使用者來說，瞭解Openstack基本都是從Horizon，dashboard開始。從這個角度來看，他在Openstack各個專案裡，顯得非常重要。

Horizon的開發者，應該是最累的。需要和各個專案打角度。每個專案的功能很多都是需要通過Dashboard來展現。

大家需要注意的是：Horizon只是使用了Openstack部分API功能，很多功能，你可以根據你的需求去實現。

Swift

這是物件儲存的元件。對於大部分使用者來說，swift不是必須的。你只有儲存數量到一定級別，而且是非結構化資料才有這樣的需求。很多人都問一個相同的問題：是否可以把虛擬機器的儲存放在swift上。簡單回答：不行。你需要搞明白物件儲存是幹啥，擅長那些地方，那些是不行的。

swift是Openstack所有元件了最成熟的,可以線上升級版本,各種版本可以混合在一起,也就是說,1.75版本的swift可以和1.48的在一個群集裡.這個是很難得的.

oslo

這個專案其實就是把所有元件需要用到相同的東西，集中起來，以前叫nova common，估計感覺不貼切，現在單獨成立一個專案。日後大家開發新的元件，估計都需要用到oslo。

Ceilometer

這是實現監控和計量的元件。這應該算是Grizzly的孵化專案。對他的瞭解其實很少。在Grizzly版本里，你應該可以在Dashboard裡看到這個元件。

監控和計費一直是一個難題，尤其使用者希望知道cpu和記憶體的使用情況。看看他如何解決這個問題。到時候看看同事如何呼叫api來解決監控和計量的問題。解決計量，計費就簡單的。

Heat

這個專案是要解決虛擬機器的軟體部署的問題。你的虛擬機器建立好，os準備好，你還需要做很多配置才能使用，如何能實現把所有繁瑣的操作簡化呢？亞馬遜上有一個專門的工具：AWS cloudformation。目前Openstack上，希望通過Heat來實現類似的功能。

關於這個專案，還是有很多爭議。不過這個專案是Redhat發起。他們的功力是不容置疑，等Openstack成熟後，這個專案的重要性就會體現出來。

真的要實現彈性擴充套件，自動部署，都是需要指望這個。目前Heat已經成為孵化專案

下面的專案，基本都還是在討論階段，不過成為孵化專案的可能性很大。

Moniker

這是實現dns功能的元件。其實如果你用過AWS，你就知道這個功能是必不可少。新浪目前的已經加上了這個功能，每個虛擬機器，都會自動有一個dns記錄。

估計整合到Dashboard裡，還是需要等待一段時間啊。目前該專案開發還是非常積極。

marconi

此專案用於解決openstack 訊息佇列的擴充套件問題。據說這是Rackspce推出的專案，就是為了解決他們生產中遇到訊息佇列的問題。

Marconi – Message Bus for OpenStack

http://www.chenshake.com/openstack-component-introduction-2/