510
技術社區[雲棲]
《OpenStack實戰》——第1章 介紹OpenStack 1.1OpenStack是什麼
本節書摘來自異步社區《OpenStack實戰》一書中的第1章,第1.1節,作者: 【美】V. K. Cody Bumgardner(V. K. 科迪•布姆加德納)著,更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
第一部分 入門指南
本書的第一部分是對OpenStack框架的介紹:為什麼要使用它和如何使用它。剖析OpenStack各個組件,解釋它們與底層資源(計算、存儲、網絡等)的關係。這一部分將會帶領你在單個節點上通過DevStack部署工具來部署OpenStack。同時這一部分內容還會幫你思考如何能將OpenStack用在你的環境中,並激發你對這個框架的興趣,繼續探索本書後麵的部分,更深入地了解它是如何運作的。
第1章 介紹OpenStack
本章主要內容
OpenStack和雲生態係統
選擇OpenStack的理由
OpenStack可以為你和你的組織做些什麼
OpenStack的核心組件
一二十年前,很多大型的計算機硬件公司都通過自己生產製造專門的處理器來保持競爭優勢。但隨著成本的上升,能製造出足夠數量的芯片來保持盈利的公司越來越少。於是,專門生產芯片的廠商出現了,它們可以大規模生產通用處理器,並且大大降低了成本。從一開始的隻有少數計算機芯片廠商“鼓吹”的基於英特爾x86指令集的標準化台式機和服務器平台,到最後形成了采用通用硬件的客戶-服務器的市場格局。
在21世紀初的互聯網風潮下,互聯網快速發展,從而出現了大量大規模使用通用硬件的數據中心。雖然通用硬件設備強大且便宜,但它的架構就跟我們看到的台式機一樣,不是按中心化管理的思想來設計的。沒有現成的工具可以用來像管理資源池一樣管理這些通用硬件設備。更糟糕的是,在那時,這些服務器缺少硬件管理的能力(輔助管理卡),看起來跟台式機一樣。不像大型機和大型對稱多處理結構(symmetric multiprocessing,SMP)的機器,這些通用服務器跟台式機一樣,需要通過軟件管理層來協調其他獨立的資源。
在這個階段,公共或者私有的組織在自己內部開發出很多管理框架來管理公共資源。圖1-1展示了跨越多個數據中心的相互連接的資源池。通過管理框架,這些公共資源可以基於其可用性或者用戶需求來靈活使用。不知道誰創造了這個術語,這種通過管理框架來靈活使用通用硬件設備的計算方式,可以說是擁有了資源“雲”。
圖1-1 彼此互聯的通用資源的雲
在這個階段,在很多商用或者開源的雲管理軟件之中,OpenStack是最為流行的一個。OpenStack提供了一個通用的平台來控製雲計算裏麵的服務器(計算)、存儲、網絡,甚至應用資源。OpenStack可以通過基於Web的界麵、命令行工具(CLI)和應用程序接口(API)來進行管理。這個管理平台不僅能管理這些資源,更妙的是它不需要你去選擇特定硬件或者軟件廠商。廠商特定組件可以輕鬆地被替換成通用組件,OpenStack為IT業界各類從業人員創造了價值。
一種更好理解OpenStack的方式是了解在亞馬遜網站上購物的過程。用戶登錄亞馬遜網站,然後購物,商品將會通過快遞派送。在這種場景之下,一個高度優化的編排步驟是盡可能快並且以盡可能低的價格把商品買回家裏。亞馬遜成立12年後推出AWS(Amazon Web Services)。AWS把用戶在亞馬遜網站購買商品這種做法應用到了計算資源的交付上。一個服務器請求可能要花費本地IT部門幾周的時間去準備,但在AWS上隻需要準備好信用卡,然後點擊幾下鼠標即可完成。OpenStack的目標就是提供像AWS或者其他服務提供商一樣水準的高效資源編排服務。
OpenStack是什麼?
對於雲計算平台/係統/存儲/網絡管理員來說,OpenStack可以控製多種類型的商業或者開源的軟硬件,提供了位於各種廠商特定資源之上的雲計算資源管理層。磁盤和網絡配置這些重複性手動操作任務現在可以通過OpenStack框架來進行自動化管理。事實上,提供虛擬機甚至上層應用的整個流程都可以通過使用OpenStack框架進行自動化管理。
對於開發者來說,OpenStack是一個在開發環境中可以像AWS一樣獲得資源(虛擬機、存儲等)的平台,還是一個可以基於應用模板來部署可擴展應用的雲編排平台。可以想象一下,通過OpenStack框架,可以為應用提供基礎設施(X虛擬服務器有Y容量內存)和相應的軟件依賴(MySQL、Apache2等)資源。
對於最終用戶來說,OpenStack是一個提供自助服務的基礎設施和應用管理係統。用戶可以做各種事情,從簡單的像AWS一樣提供虛擬機(VM),到構建高級虛擬網絡和應用,這些都可以在一個獨立的租戶(項目)內完成。租戶,也就是我們所說的項目,是OpenStack用來對資源分配進行隔離的方式。租戶隔離了存儲、網絡和虛擬機這些資源,因此,最終用戶可以擁有比傳統虛擬服務環境更大的自由度。可以想象一下,最終用戶被分配了一定額度的資源,他們可以隨時獲得他們想要的資源。
虛擬機和租戶
在本書中,虛擬機指的是模擬物理服務器的一個實例。與物理機一樣,虛擬機執行相同的功能,從操作係統的角度來看,無法區分是運行在虛擬機還是物理機上。導致虛擬機被使用的原因多種多樣,但大多數的虛擬化推動力可以歸結為:以犧牲性能來獲得通過軟件對資源的靈活控製。從一個更高的角度來說,你可以認為OpenStack之於數據中心,就像操作係統之於服務器,都帶來了相同水平的運行效率。
讀者將在本書多處看到租戶這個詞,在OpenStack裏麵這個詞有特定含義。我們可以認為租戶就是資源的配額限製集合,被虛擬機用來在邏輯上與不同租戶互相隔離。例如,一個用戶在租戶A配錯了網絡,但租戶B並不會受到影響。
OpenStack基金會擁有數以百計的官方企業讚助商,以及數以萬計的覆蓋130多個國家或地區的開發者組成的社區。像Linux一樣,很多人將會被OpenStack吸引,作為其他商業產品的一個開源的替代品。但他們將會逐漸認識到,對於雲框架來說,沒有哪個雲框架擁有OpenStack這樣的服務深度和廣度。也許更為重要的是,沒有其他產品,包括商業或者非商業的,能被大多數的係統管理員、開發者或者架構師使用並為他們組織創造這麼大的價值。
1.1 OpenStack是什麼
讓我們來詳述OpenStack作為管理、規定和利用雲資源的框架的定義。OpenStack官方網站(www.openstack.org)這樣描述這個框架:“創建私有雲和公有雲的開源軟件。”接著是:“OpenStack軟件是一個大規模雲操作係統。”如果讀者有服務器虛擬化的經驗,也許讀者會很快地得出這樣不正確的結論:OpenStack隻是提供虛擬機的另外一種方式。雖然虛擬機是OpenStack框架可以提供的一種服務,但這並不意味著虛擬機是OpenStack的全部。
圖1-2展示了OpenStack通過其幾個資源組件協調來提供公有雲服務和私有雲服務。如圖所示,OpenStack沒有取代資源提供者,它隻是通過框架內部的控製點來簡單地管理這些資源。
圖1-2 OpenStack是一個雲操作係統
一個有經驗的係統管理員也許會非常懷疑OpenStack是一個“雲操作係統”的描述。OpenStack不像管理員通過啟動盤引導啟動幾百台傳統操作係統服務器那樣,直接在裸設備上引導啟動。相反,它通過對資源的管理,在雲計算環境裏共享操作係統的特性。
在OpenStack雲平台上用戶可以:
充分利用物理服務器、虛擬服務器、網絡和存儲係統資源;
通過租戶、配額和用戶角色高效管理雲資源;
提供一個對底層實現透明的通用的資源控製接口。
乍看之下,OpenStack確實不像是一個傳統操作係統,但“雲”同樣不像傳統計算機。我們必須回過頭來重新考慮一個操作係統的根本作用。
最初,操作係統乃至硬件層麵抽象語言(匯編語言)、程序都是用二進製機器碼來編寫的。然後傳統操作係統出現了,允許用戶不僅可以編寫應用程序代碼,還可以管理硬件功能。現在管理員可以使用通用的接口管理硬件實例,開發者可以為通用操作係統寫代碼,用戶隻需要學習一個用戶交互接口即可。這樣可有效地對底層硬件透明化,隻需要操作係統是一樣的。在計算機進化演變過程中,操作係統的發展和新操作係統的出現,給係統工程和管理領域帶來了風險。
圖1-3展示了現代計算係統的各個抽象的層次。
圖1-3 計算抽象的層次
毫無疑問,過去的一些開發者不想因為使用操作係統而失去了對硬件的直接控製,正如有些管理員不想因為服務器虛擬化而失去對底層硬件和操作係統的控製。在每次轉變過程中,從機器碼到匯編,再到虛擬層,我們一直沒有失去對底層的控製;每次都是通過抽象手段簡單標準化而已。我們仍然擁有高度優化的硬件,我們仍然擁有操作係統,隻不過更常見的是我們擁有這些層麵之間的硬件虛擬化層。
新的抽象層被廣泛接受,通常是因為對標準實現優化的好處大於在這些層麵上做(虛擬化)轉換。也就是說,當整體計算資源的使用率能通過犧牲原生性能來得到很好的提升,那這一個層麵的抽象就會被接受。這個現象可以通過中央處理器(CPU)的例子來清晰展現,這幾十年,中央處理器都遵守相同的指令集,但它們內部的架構卻發生了翻天覆地的變化。
大多數人想到中央處理器時,都沒想到硬件層麵的虛擬化和執行形式的變化,但事實就是這樣。很多在x86處理器上執行的指令可以被處理器內部虛擬化,一些複雜的指令可以通過一係列更簡單、更快速的指令來執行。指令層麵優化的複雜度不在本書的討論範圍內,但很有必要去了解,即使是使用裸設備,即使是在處理器層麵,也是應用到了某種形式的虛擬化。現在,與其關注失去了控製,不如想象一下,通過使用一個共同的框架來管理、監控和部署基礎設施和應用的私有和公有雲。隻有向前邁出轉變的步伐,才會真正領會OpenStack。
數十年間CPU的抽象和虛擬化
英特爾的x86指令集首次出現在1978年推出的英特爾8086處理器上,作為英特爾8080處理器的向後兼容替代品。x86指令集定義了一係列對處理器變化透明的匯編指令。從那以後,新的“處理器擴展特性”不斷被添加進來,處理器時鍾周期也不斷提升,但已存在的指令依舊保留下來。
隨著更快的處理器需求的增長,因此產生了軟件能在不同代處理器之間互操作的需求。CPU設計者需要對低級別抽象進行彈性優化,同時還要保留指令級別的兼容性(標準化)。設計者不用擔心關於如何保持底層硬件一致的問題,這樣他們可以在不同代處理器間極大地提升處理器的時鍾速度。1995年,英特爾的奔騰Pro(Pentium Pro)處理器引入了微操作解碼(micro-op decoding)這個概念。之前一個特定指令就是一個指令時鍾周期,通過翻譯這個指令為多個簡單微指令,每個微指令就是一個指令時鍾周期。
除了微操作,奔騰Pro處理器還引入了指令的無序執行和內存的虛擬化(通過32位總線對36位內存進行尋址)來對處理器進行優化。但這些對開發者來說是完全抽象化的,允許相同的應用運行在不同廠商出品的不同代的處理器上。這種保持指令級別兼容性的方式依然使用在當前的x86_64處理器中。
最後更新:2017-05-31 17:31:30
上一篇:
《OpenStack實戰》——1.2 理解雲計算和OpenStack
下一篇:
《Docker容器:利用Kubernetes、Flannel、Cockpit和Atomic構建和部署》——導讀
用戶體驗是個什麼東西?用戶體驗如何評價好壞?怎樣用一句話描述用戶體驗評價方法的核心?
Column \'表名.某列名\' is invalid in the select list because it is not contained in either an aggregate f
SVN版本管理係統的安裝 CentOS + Subversion + Apache + Jsvnadmin
Linux 走向真正的 CPU 熱插拔支持
Android 應用程序獲得版本號
nfs無法卸載
C/C++產生隨機數
Spring的事務管理對何種異常進行回滾
大數據破局 京津冀一體化再出發
內存數據庫H2使用