OpenStack調研：OpenStack是什麼、版本演變、組件關係（Havana）、同類產品及個人感想

一點調研資料，比較淺，只是覺得部分內容比較有用，記在這裏；

首先，關於雲計算，要理解什麼是SAAS、PAAS、IAAS，這裏不述；關於虛擬化，需要知道什麼是Hypervisor，這裏也不述；

OpenStack是什麼

OpenStack是一個由美國宇航局NASA與Rackspace公司共同開發的雲計算平臺項目，且通過Apache許可證授權開放源碼。它可以幫助服務商和企業實現類似於Amazon EC2和S3的雲基礎架構服務。下面是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是一個可以管理整個數據中心裏大量資源池的雲操作系統，包括計算、存儲及網絡資源。管理員可以通過管理臺管理整個系統，並可以通過web接口爲用戶劃定資源。

由以上可以知道OpenStack的主要目標是管理數據中心的資源，簡化資源分派。它管理三部分資源，分別是：
   計算資源：OpenStack可以規劃並管理大量虛機，從而允許企業或服務提供商按需提供計算資源；開發者可以通過API訪問計算資源從而創建雲應用，管理員與用戶則可以通過web訪問這些資源；
   存儲資源：OpenStack可以爲雲服務或雲應用提供所需的對象及塊存儲資源；因對性能及價格有需求，很多組織已經不能滿足於傳統的企業級存儲技術，因此OpenStack可以根據用戶需要提供可配置的對象存儲或塊存儲功能；
   網絡資源：如今的數據中心存在大量的設置，如服務器、網絡設備、存儲設備、安全設備，而它們還將被劃分成更多的虛擬設備或虛擬網絡；這會導致IP地址的數量、路由配置、安全規則將爆炸式增長；傳統的網絡管理技術無法真正的可高擴展、高自動化地管理下一代網絡；因而OpenStack提供了插件式、可擴展、API驅動型的網絡及IP管理；

OpenStack的版本演變

OpenStack的每個主版本系列以字母表順序（A~Z）命名，以年份及當年內的排序做版本號，從第一版的Austin（2010.1）到目前最新的穩定版Havana（2013.2），共經歷了8個主版本，第9版的Icehouse仍在開發中。以下是各個版本的簡單描述（注：描述摘取自官方文檔https://wiki.openstack.org/wiki/Releases，當版本描述較多時，僅選取個人認爲比較重要（且能看懂）的部分）：

Series	Status	Releases	Date
Icehouse	Under development	Due	tbd
Havana	Current stable release, security-supported	2013.2	Oct 17, 2013
Grizzly	Security-supported	2013.1	Apr 4, 2013
		2013.1.1	May 9, 2013
		2013.1.2	Jun 6, 2013
		2013.1.3	Aug 8, 2013
		2013.1.4	Oct 17, 2013
Folsom	EOL	2012.2	Sep 27, 2012
		2012.2.1	Nov 29, 2012
		2012.2.2	Dec 13, 2012
		2012.2.3	Jan 31, 2013
		2012.2.4	Apr 11, 2013
Essex	EOL	2012.1	Apr 5, 2012
		2012.1.1	Jun 22, 2012
		2012.1.2	Aug 10, 2012
		2012.1.3	Oct 12, 2012
Diablo	EOL	2011.3	Sep 22, 2011
		2011.3.1	Jan 19, 2012
Cactus	Deprecated	2011.2	Apr 15, 2011
Bexar	Deprecated	2011.1	Feb 3, 2011
Austin	Deprecated	2010.1	Oct 21, 2010

• Austin

   作爲第一正式版本的OpenStack，主要包含兩子項目，Swift是對象存儲模塊，Nova是計算模塊；
   帶有一個簡單的控制檯，允許用戶通過web管理計算和存儲；
   帶有一個部分實現的Image文件管理模塊，未正式發佈；

• Bexar

   正式發佈Glance項目，負責Image的註冊和分發；
   Swift增加了對大文件（大於5G）的支持；增加了支持S3接口的中間件；增加了一個認證服務中間件Swauth；等；
   Nova增加對raw磁盤鏡像的支持，增加對微軟Hyper-V的支持；等；
   開始了Dashboard控制檯的開發；

• Cactus

   Nova增加新的虛擬化技術支持，如LXC容器、VMWare/vSphere、ESX/ESXi 4.1；支持動態遷移運行中的虛機；增加支持Lefthand/HP SAN做爲卷存儲的後端；
   Glance提供新的CLI工具以支持直接訪問；支持多種不同的Image格式；

• Diablo

   Nova整合Keystone認證；支持KVN的暫停恢復；KVM的塊遷移；全局防火牆規則；
   Glance整合Keystone認證；增加事件通知機制；

• Essex

   正式發佈Horizon項目，支持開發第三方插件擴展web控制檯；正式發佈Keystone項目，提供認證服務；
   Swift支持對象過期；在swift CLI接口上支持Auth 2.0 API；支持URL以允許通過控制檯向要求認證的swift集羣上傳對象；
   Nova完全依賴Keystone管理用戶、項目、角色等；支持根據角色設定訪問控制；計算與網絡解耦，使得網絡可以通過獨立的服務進行管理；卷管理使用了獨立api；爲消息隊列增加額外的後端模塊；元數據分離；支持浮動ip池；

• Folsom

   正式發佈Quantum項目，提供網絡管理服務；正式發佈Cinder項目，提供塊存儲服務；
   Nova中libvirt驅動增加支持以LVM爲後端的虛機實例；Xen API增加支持動態遷移、塊遷移等功能；增加可信計算池功能；卷管理服務抽離成Cinder；

• Grizzly

   Nova支持將分佈於不同地理位置的機器組織成的集羣劃分爲一個cell；支持通過libguestfs直接向guest文件系統中添加文件；通過Glance提供的Image位置URL直接獲取Image內容以加速啓動；支持無image條件下啓動帶塊設備的實例；支持爲虛機實例設置（CPU、磁盤IO、網絡帶寬）配額；
   Keystone中使用PKI簽名令牌代替傳統的UUID令牌；
   Quantum中可以根據安全策略對3層和4層的包進行過濾；引入仍在開發中的load balancer服務；
   Cinder中支持光纖通道連接設備；支持LIO做ISCSI的後端；

• Havana

   正式發佈Ceilometer項目，進行（內部）數據統計，可用於監控報警；正式發佈Heat項目，讓應用開發者通過模板定義基礎架構並自動部署；網絡服務Quantum變更爲Neutron；
   Nove中支持在使用cell時同一cell中虛機的動態遷移；支持Docker管理的容器；使用Cinder卷時支持加密；增加自然支持GlusterFS（If qemu_allowed_storage_drivers is set to gluster in nova.conf then QEMU is configured to access the volume directly using libgfapi instead of via fuse）；
   Glance中按組限制對Image的元屬性的訪問修改；增加使用RPC-over-HTTP的註冊 API；增加支持Sheepdog、Cinder、GridFS做後端存儲；
   Neutron中引入一種新的邊界網絡防火牆服務；可通過***服務插件支持IPSec ***；
   Cinder中支持直接使用裸盤做存儲設備無需再創建LVM；新支持的廠商中包含IBM的GPFS；

注：紅字部分指出系統添加了新的服務組件，或是新組件出現前的鋪墊工作；

OpenStack的架構及組件（Havana）

服務	項目名	描述
控制檯	Horizon	用戶通過該服務與OpenStack的各服務進行交互，如啓動虛機實例、分配IP地址、設置訪問控制等；
計算	Nova	按需分派並管理虛機；
網絡	Neutron	通常是計算服務通過該服務管理網絡設置之間的連接，也可以允許終端用戶創建並添加網絡接口；通過一個插件式架構支持大量網絡廣商設備及網絡技術；
存儲類
對象存儲	Swift	存取文件，但並不提供傳統掛載式的文件服務；
塊存儲	Cinder	向虛機提供可用於持久存儲的塊存儲服務；
共用服務
身份服務	Keystone	爲OpenStack提供認證及授權服務。
鏡像服務	Glance	提供虛機鏡像的註冊服務；同時計算服務也使用該服務分派實例；
計量/監控服務	Ceilometer	用於計費、基準測試及數據統計等功能
更高層服務
編排組織服務	Heat	使用自帶的HOT模板或AWS的CloudFormation模板，通過OpenStack中各服務的REST API，將各組件的資源組織形成雲應用；

邏輯架構圖如下（注：原圖在這裏，Ceilometer與Heat與服務邏輯無關，因而不在這張圖中體現）

Nova

計算服務是OpenStack的核心服務，它由nova-compute模塊通過libvirt、XenAPI等管理hypervisor，從而管理虛機，此外它還通過nova-api服務向外提供如EC2兼容、管控功能等的接口，通過nova-scheduler模塊提供虛機調研邏輯等；這些模塊間的通信全部通過消息隊列完成；

Swift

對象存儲服務是OpenStack最早期的兩個服務之一（另一個是計算服務），在OpenStack平臺中，任何的數據都是一個對象；swift-proxy模塊對外提供如HTTP(S)、OpenStack Object API及與S3兼容的存取接口。對象的存取經swift-proxy接入後，還需要經三個模塊進行定位，即account、container、object；這是因爲在OpenStack中一個對象被描述爲：某個帳戶下某個容器中的某個對象；

Glance

Glance的出現是解決虛機鏡像的管理問題；在生成一個鏡像後，需要將鏡像註冊到系統的數據庫中；當要實例化一個虛機時，需要將鏡像分派到一臺具體的實機上用來以啓動虛機；因而Glance最重要的接口是鏡像的註冊和分派；

Cinder

Essex將nove的卷管理api獨立化後，Folsom終於將卷管理服務抽離成了Cinder；Cinder管理所有的塊存儲設備，塊設備可以掛接在虛機的實例中，然後虛機裏的guest系統可以像操作本地卷一樣操作塊存儲設備；
Cinder需要處理的主要問題應該是接入各種塊設備，如本地磁盤、LVM或各大廣商提供的設備如EMC、NetApp、HP、HuaWei，還有如Vmware提供的虛擬塊設備等。
值得一提的是發現在Cinder的驅動列表中出現了NFS，按理說NFS提供的不是塊訪問接口，而是文件訪問接口，走到文檔中看到說明爲：NFS based cinder driver. Creates file on NFS share for using it as block device on hypervisor.竟然是用NFS上的文件模擬塊設備。爲什麼不直接寫一個將本地文件模擬爲塊設備的驅動呢？應該是寫成NFS驅動，可以將NFS的掛載動作封裝在驅動中。

Neutron

經過一定時間的演變，網絡管理也抽離成一個獨立的服務；在OpenStack的網絡管理流程中，通常需要經過以下幾個步驟：
1.    創建一個網絡；
2.    創建一個子網；
3.    啓動一個虛機，將一塊網卡對接到指定的網絡上；
4.    刪除虛機；
5.    刪除網絡端口；
6.    刪除網絡；

Keystone

身份服務需要進行認證憑證的驗證及關於用戶、角色等的信息，及所有相關的元數據；這些數據全都由Keystone服務管理，並提供CRUD的操作方法；另外這些信息可以從另一個認證服務中獲取，例如使用LDAP做Keystone的後端。

OpenStack與VM

以上這些服務與服務、服務與虛機的關係如下圖所示：

• 真正服務於VM的服務只有Nova、Glance、Neutron、Cinder：

  • Nova調派資源實例化虛機；

  • Glance提供虛機實例化時需要的鏡像；

  • Neutron提供網絡連接；

  • Cinder提供外接的塊存儲服務；

  
  

• Ceilometer從上面與虛機相關的幾個服務中收集數據，用於統計、監控、計費、報警等；

• Swift可以爲Glance提供鏡像的存儲服務，可以爲Cinder提供卷的備份服務；

• Keystone爲所有服務提供認證、授權等服務；

• Horizon爲所有服務提供基於Web的操作接口；

• 通過Heat可以方便地將各組件組織起來；

同類產品

   來自加拿大CANARIE機構的DAIR：http://www.canarie.ca/en/dair-program/about
   微軟的Azure：http://www.windowsazure.com/zh-cn/
   亞馬遜AWS（EC2及配套的S3等）：http://aws.amazon.com/
   來自UCSB的Eucalyptus：http://www.eucalyptus.com/，中文入門資料：http://www.oschina.net/p/eucalyptus
   Google GCE：https://cloud.google.com/products/compute-engine

至於Google的App Engine？應該是PAAS了，不算同類；

---------以上是正文---------

---

---------以下是個人的一點看(fei)法(hua)---------

OpenStack無疑是當前最火的開源IAAS方案，而且已經得到大量廠商的支持，如HP、IBM、Intel、EMC、Huawei，當然還不能忘記Ubuntu系統等，看一下Cinder的api中那一堆的驅動，再看一下Nova不斷支持的各類虛擬化技術，不由會去想當年Linux是否也是這樣蓬勃發展起來的。個人感覺，廠商積極參與的最終目標肯定還是想撈金，試想如果突然冒出大批公司做OpenStack平臺，這必然有大量存儲和計算設備可以賣啊$$

2011年我在Intel實習，有幸參與了OpenStack的開發工作，當初使用的D版只有三大模塊，因爲自己研究方向偏Storage，所以碰過Swift和Glance，又因爲有Security背景，所以也在Nova中爲Intel TXT打通了上下層接口。研究版本演變時，看到可信計算池功能被F版支持，感覺一點點小成就感，雖然我的代碼可能早被refactor了。

兩年後再來看H版的OpenStack，子項目已經暴增到9個，對一個新人而言也許難以下手，但如果可以從發展的角度看，會清楚很多，我是這樣理解：最初的A版應該是學習AWS的EC2+S3，只抽象出計算與存儲兩個服務；存儲一直是一個比較容易理解的層次，接口明晰，而計算/VM則變數很多，一開始也只能將Image的管理剝離出來，成爲Glance；後來，爲了產品化，出於安全性及簡化使用的需求，洐生了Keystone和Horizon；再後來，E版對Nova進行了大的調整，儘量解耦，從而允許網絡和卷管理獨立，爲後來Neutron和Cinder的出現做了鋪墊；再後應該是出於監控和統計的需求，出現了Ceilometer；然後發現過度解耦，提供的選擇太多，組織起來比較麻煩，所以做了Heat（我相信，如果OpenStack繼續像Linux那樣發展下去，將來Heat會變成今天Linux Kernel的menuconfig:）。從這個過程可以看出，大部分的功能，都是慢慢從最核心的計算需求中抽離出來的。

OpenStack的演變過程，也正是一家公司的基礎平臺發展過程的縮影。區別在於，在公司，基礎平臺的目標不是產品化，所以很難出現一個Horizon和Heat，而以SLA或PKI爲目標時，Ceilometer會變得過分重要，會重要到影響其它組件的發展，比如Nova永遠得不到調整，因爲調整前，上頭就可能要問你：爲什麼要這樣做，能帶來什麼收益，拿出點數據看看；而這個後果就是，各組件越來越難用越來越難以維護，成爲惡性循環。算了，吐槽有點過。廢話到此吧，以後有時間我會繼續關注OpenStack的發展，看能否得到新的感悟。