|
OpenStack 是當今最具影響力的云計算管理工具——通過命令或者基于 Web 的可視化控制面板來管理 IaaS 云端的資源池（服務器、存儲和網(wǎng)絡）。它最先由美國國家航空航天局（NASA）和 Rackspace 在 2010 年合作研發(fā)，現(xiàn)在參與的人員和組織匯集了來自 100 多個國家的超過 9500 名的個人和 850 多個世界上赫赫有名的企業(yè)，如 NASA、谷歌、惠普、Intel、IBM、微軟等。 OpenStack 系統(tǒng)或其演變版本目前被廣泛應用在各行各業(yè)，包括自建私有云、公共云、租賃私有云及公私混合云，用戶包括思科、貝寶（Paypal）、英特爾、IBM、99Cloud、希捷等，具體名請參考網(wǎng)站 http：//www./user-stories。 OpenStack 支持 KVM、Xen、Lvc、Docker 等虛擬機軟件或容器，默認為 KVM。通過安裝驅(qū)動，也支持 Hyper-V 和 VMware ESXi，不過有些功能暫時不支持，具體的虛擬機管理器支持矩陣參見網(wǎng)站 http：//docs./developer/nova/support-matrix.html。 OpenStack 采用 Python 語言開發(fā)，遵循 Apache 開源協(xié)議，因此相比 CloudStack 來說，更輕量化，效率更高。 OpenStack 每半年發(fā)行一個新版本，截至發(fā)稿前最新版本是第十四版本 Newton，不同于其他軟件的版本號采用數(shù)字編碼，OpenStack 采用一個單詞來描述不同的版本，其中單詞首字母指明版本的新舊。比如目前的版本 Newton 就比之前的 Mitaka 要新，同時“N”在 26 個字母中排行第十四，所以稱第十四版本。各個版本的發(fā)行時間表參考網(wǎng)站 https：//releases./。 圍繞 OpenStack 發(fā)展起來的企業(yè)很多，為客戶提供 OpenStack 實施、培訓、運維、定制等業(yè)務，之前企業(yè)總是或多或少地加入自己的一些封閉技術，從而導致 OpenStack 的互操作性受損。為此，2015 年 OpenStack 基金會在溫哥華峰會上正式推出互操作性認證，通過認證的產(chǎn)品被貼上“OpenStack Powered”標識。 雖然第一批只有 14 家廠商經(jīng)過認證測試，但這卻是一個重要的里程碑事件，基金會已經(jīng)拿出足夠的誠意來解決問題，并且眾多廠商也開始真正跟進。對用戶而言，選擇經(jīng)過認證的云服務提供商，能夠?qū)崿F(xiàn)在不同 OpenStack 云計算之間的自由遷移。 OpenStack 生態(tài)系統(tǒng)已從“孵化/集成”模式轉(zhuǎn)移到“大帳篷”模式，在此模式下，既保持了對規(guī)模較小的核心項目的關注，也積極鼓勵在更廣泛的主流生態(tài)環(huán)境中的自由創(chuàng)新，而以前的“孵化/集成”模式只是把孵化成功的項目集成到主流生態(tài)中。 “大帳篷”模式把 OpenStack 的組件進行分類，目前包括 6 個核心組件（Nova、Neutron、Swift、Cinder、Keystone、Glance）和 14 個可選組件，每個組件包含若干個服務，后續(xù)版本中組件分類及數(shù)量都可能會發(fā)生變化，如圖 1 所示。  圖 1 “大帳篷”模式下的組件 表 1 列出了 Newton 版本中各個組件的功能介紹。
各個組件的關系圖如圖 2 所示。
 圖 2 OpenStack 組件關系圖 OpenStack 的組件眾多，根據(jù)云端的實施過程，再結合圖 2，我們來梳理一下各個組件的作用：云端要運行很多虛擬機，所以需要在很多服務器中安裝并運行虛擬機軟件（如 KVM、Xen 等），有的客戶為了安全起見，愿意出高價直接租賃物理機（裸金屬機器），所以要用 Ironic 組件來池化物理機，以便用戶能遠程使用。 這些運行了虛擬機軟件的服務器和被池化的物理機統(tǒng)稱為計算節(jié)點。為了讓 Horizon 組件以可視化的 Web 頁面來統(tǒng)一操縱計算節(jié)點上的虛擬機，需要在計算節(jié)點上安裝 Nova 組件，Nova 組件還與其他組件打交道。為了讓一臺虛擬機能在集群內(nèi)的任一計算節(jié)點上快速漂移，虛擬機對應的鏡像文件必須存放在共享場所，到底存放在哪里，由 Glance 組件指定。 例如在圖 4 中，由 Glance 指定存放在 Swift 組件內(nèi)，在實際的實施案例中，也可以存放在 Ceph 中。虛擬機之間需要聯(lián)網(wǎng)，由 Neutron 組件負責。虛擬機里面可能還要使用塊設備（如硬盤），這需要 Cinder 組件的配合；虛擬機里可能需要用到共享文件服務，由 Manila 組件提供服務。 云端的計算節(jié)點很多（如 1000 臺），所以虛擬機就更多（如 10 萬臺），如果要給它們統(tǒng)一安裝一個軟件或配置某項參數(shù)，那么是不是需要手工一臺一臺操作呢？顯然，手工操作費時費力，而且容易出錯，有了 Heat 組件，我們就可以輕松完成這個任務。 OpenStack 的各個組件都是對外暴露 REST API 接口，以便于其他程序調(diào)用，調(diào)用時都要進行身份驗證和權限管理，這由 Keystone 組件完成。跟蹤用戶消耗的資源并計費的任務由 Ceilometer 組件完成（需要 Aodh 和 CloudKitty 組件的配合）。 對于 OpenStack 管理的 IaaS 云服務，有人想在上面部署 Hadoop 大數(shù)據(jù)分析系統(tǒng)怎么辦？這時 Sahala 組件可以幫上忙。各組件之間需要通過消息互相聯(lián)絡，所以 Zaqar 和 RabbitMQ 就派上用場了。另外，很多組件需要在數(shù)據(jù)庫中保存配置數(shù)據(jù)，所以需要用到數(shù)據(jù)庫管理系統(tǒng)（如 MySQL）。 OpenStack 組件的主要作用是充當“中間人”，它不履行具體的實際任務，而由各種第三方軟件來完成，比如虛擬機軟件由 KVM 承擔，網(wǎng)站任務由 Apache 承擔，虛擬網(wǎng)絡任務由 iptables、DNSmasq、Linux vSwitch、Linux 網(wǎng)橋承擔或者統(tǒng)一由 OpenContrail 承擔，結構化數(shù)據(jù)存儲任務由 MySQL 或者 PostgreSQL 承擔，中央存儲任務由 Ceph 承擔（也可采用其他產(chǎn)品）。當然，OpenStack 中也有實現(xiàn)具體功能的組件，比如 Swift 做中央存儲，我們也可以選擇相對發(fā)展多年并且被大量使用的第三方產(chǎn)品，如 Ceph。 一個云端往往包含成千上萬臺服務器，而且還可能分布在世界各地，分別服務符合延時半徑范圍內(nèi)的用戶。OpenStack 中的“地區(qū)”（Region）就是對應地理位置不同的分中心，如中國北京、美國紐約、英國等。 在同一個 Region，還可能包含成千上萬臺機器，如果用一套 OpenStack 中的組件來管理，勢必會導致這些組件本身成為瓶頸（隨著集群規(guī)模的不斷增大，消息系統(tǒng)和數(shù)據(jù)庫系統(tǒng)很可能最先成為瓶頸），所以人們又引入了 Cell 功能，以便增強 OpenStack 集群的擴展性，即把一個 Region 劃分成多個 Cell，這些 Cell 組成樹形結構，父 Cell 主要用于服務通信，它不包含計算節(jié)點，子 Cell 具有自己的消息隊列、數(shù)據(jù)庫和 Noval-cell 服務。 Nova cell 在 OpenStack 的 Newton 版本中將成為默認項，之前的版本是可選項。在創(chuàng)建虛擬機時，為了規(guī)定它能在哪些計算節(jié)點集上運行，人們又提出了兩個概念，即“可用域”（Availability Zones，AZ）和“主機集”（Host Aggregates，HA），前者可以看成后者的一個特例。 “主機集”其實就是根據(jù)計算節(jié)點的某些屬性對計算節(jié)點進行邏輯分組的方法，比如可以分成如下幾個“主機集”：萬兆網(wǎng)卡的機器、擁有兩路 CPU 的機器、惠普機器、自組裝的機器、A 機柜里的機器、由 UPS 供電的機器等。然后我們創(chuàng)建一臺虛擬機，指明在上海云端分部的惠普機器上運行，這樣只要全部的惠普機器不同時壞，那么虛擬機就能一直正常運行（但每一時刻只能在一臺機器上運行，只有當運行的那臺機器出故障時，才會“漂移”到其他惠普機器上繼續(xù)運行）。 “可用域”是用戶可見的，用戶把自己的多個虛擬機分散到不同的“可用域”中，是為了降低所有虛擬機同時不可用的概率，而“主機集”是管理員可見的，目的是用來隔離虛擬機，從而降低一些特定虛擬機的運行行為對其他虛擬機產(chǎn)生的影響。Region、Cell（第 2 版本）、AZ、HA 的關系如圖 5 所示。 從圖 3 中可以看出，多個 Region 允許共享 Keystone 和 Horizon 服務，也可以完全獨立。HA 可以跨 Cell，但是不能跨越 Region，一臺機器可以同時屬于多個 HA，因為 AZ 是 HA 的特例，所以一臺機器允許同時屬于 AZ 和 HA。當一個創(chuàng)建虛擬機的請求到達父 Cell 的 Nova-API 時，父 Cell 會通過 Nova-cell 向各個子孫 Nova-cell 廣播請求，并一次性決定在哪個子孫 Cell 中的哪臺計算節(jié)點上創(chuàng)建虛擬機。  圖 3 Region、Cell（第2版本）、AZ、HA 的關系 在具體部署 OpenStack 時應該遵循“逐步擴展部署法”，如圖 7 所示。  圖 7 OpenStack 逐步擴展部署法 最小系統(tǒng)具備基本的 IaaS 功能，能通過命令來進行管理，這一步只需安裝 OpenStack 的 Keystone、Neutron、Nova 和 Glance 四個組件；此后再安裝 Horizon 就成了小系統(tǒng)，這時可通過 Web 圖形化界面來執(zhí)行管理；繼續(xù)安裝 Swift 和 Cinder 就成了準系統(tǒng)，這時能給虛擬機附加磁盤塊設備，并能滿足大規(guī)模的存儲需求；再加上計費組件 Ceilometer，就上升為一般系統(tǒng)，一般系統(tǒng)具備公有 IaaS 的功能。但是由一般系統(tǒng)跨到生產(chǎn)系統(tǒng)，需要完成的工作就特別多，其中性能和安全是兩個不得不面對的棘手問題。 圖 6 中標注的 Iptables（設立門衛(wèi)）、Selinux 或 Apparmor（加固系統(tǒng)）和 Snort（巡邏）都是為了強化安全。性能和安全涉及的知識太多，這里不再展開討論。圖 7 取自網(wǎng)上，主要考量了安全當中的可用性，供大家參考。 |
|
|
來自： 南莊小筑 > 《OpenStack》
