本節書摘來自異步社群《openstack實戰》一書中的第1章，第1.3節，作者： 【美】v. k. cody bumgardner（v. k. 科迪•布姆加德納）著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
前面介紹了openstack能帶來的好處，但它是如何工作的呢？也許，了解openstack是怎樣工作的最簡單的方式是把這個架構與企業環境内的常見技術關聯起來。
在本節中，讀者将會了解openstack是如何與它控制的基礎資源（計算、存儲、網絡等）關聯起來的。如你所見，openstack通常不提供實際意義上的資源，它隻是簡單控制這些低層次的資源。圖1-4展示了openstack是如何管理資源的提供者的，它們輪流被虛拟機使用。
圖1-4 openstack資源管理模型
在接下來的小節裡，讀者将會看到關聯特定資源元件的詳情：伺服器虛拟化，通過對hypervisor（虛拟機管理器）的控制；網絡，通過對廠商提供的硬體和openstack服務的控制；塊和對象存儲，通過對廠商和openstack服務的控制。最後，我們會看到openstack各個服務和常見的雲術語的關聯。如你所見，openstack是一個協調資源和服務的架構，而不關心有哪家底層技術廠商。
1.3.1 openstack和hypervisor
hypervisor或者虛拟機監控器（virtual machine monitor，vmm）是一種為虛拟機進行實體硬體仿真的管理軟體。openstack不是一個hypervisor，但它确實控制着hypervisor的操作。openstack架構支援多種hypervisor，包括xenserver/xcp、kvm、qemu、lxc、esxi、hyper-v、baremetal和其他（可通過下列網址檢視hypervisor的支援清單：<code>https://wiki.openstack.org/wiki/hypervisorsupportmatrix</code>）。讀者可能對vmware esx、vmware esxi和microsoft hyper-v比較熟悉，因為這些是目前企業虛拟化市場主流的hypervisor。因為許可限制、成本和其他因素，openstack社群對這些商業hypervisor的支援要少于開源的hypervisor。
圖1-5展示了openstack如何管理實體硬體上被hypervisor虛拟化的資源。在一個openstack叢集内，openstack協調多個hypervisor資源和虛拟機的管理。
圖1-5 openstack管理着hypervisor
無論部署規模多大，大多數的個人群組織采用的hypervisor是xenserver或者kvm，它們也是支援最多功能的hypervisor。xenserver是思傑（citrix）公司的産品，從嚴格意義上來說，它是開源的hypervisor，但商業支援通過思傑公司提供。kvm已經是linux核心的一部分，是以，很多linux發行版的維護者提供kvm的商業支援，包括紅帽（red hat）、ubuntu、suse等。
你通過認證了嗎 随着大量提供商開始設計基于openstack架構的公有iaas服務，他們很快意識到自己的客戶可能需要微軟對運作在windows主機上的hypervisor進行認證。當時，思傑公司的xenserver已經滿足了認證條件，并通過了微軟的認證過程。但是，盡管思傑公司有一個以cloudstack形式競争的平台，很多組織還是使用了xenserver作為他們的openstack hypervisor。自從很多linux發行廠商通過了微軟的認證以後，現在可以完全支援windows運作在kvm hypervisor上，包括那些被openstack控制的hypervisor上。
本書将采用基于核心的虛拟機（kernel-based virtual machine，kvm）作為hypervisor。自2007年釋出的linux 2.6.20開始，kvm被并進linux核心，完全被openstack支援。kvm還提供了半虛拟化，但需要作業系統原生支援，或者通過在虛拟作業系統鏡像添加hypervisor特定驅動來進行支援。使用開源的hypervisor的傳統問題是部署和維護它的學習曲線陡峭，經常需要擁有系統、網絡和應用管理經驗。幸運的是，在組織内部提供集中化支援的虛拟化資源，資源申請必須通過組織的網絡、系統、安全和财務供給流程。通常使用者有以下3種選擇。
使用社群代碼，自給自足——社群維護的軟體使用社群的支援，自己負責部署的設計、開發和運維。
使用社群代碼，商業支援——社群維護軟體使用廠商支援，你和廠商或者隻是廠商負責部署。
使用社群項目的廠商分支，商業支援——使用廠商提供的軟體和支援，你通常隻需要負責部署關聯的運維和廠商管理。
雖然很多廠商提供openstack和kvm的商業支援，但很多為工作負載建構的内部雲不需要商業支援或者認證，是以，用openstack支援沒有購買商業支援的kvm也是很流行的做法。無論你如何部署和采用哪種支援方式，本書提供的材料都一樣有用。
linux容器 最近，一些人對作業系統級别的虛拟化應用産生了濃厚的興趣，而不是openstack執行個體提供的基礎設施級别的虛拟化。作業系統級别的虛拟化可以在單一伺服器上運作多個互相隔離的作業系統執行個體（容器）。但它不是hypervisor技術——它運作在系統級别，所有容器共享相同的核心。你可以把容器想象成在需要的地方提供虛拟的隔離，而沒有全虛拟化的模拟開銷。 目前最流行的兩個作業系統級别的虛拟化項目是docker（<code>https://www.docker.com/</code>）和rocket（<code>https://github.com/coreos/rkt</code>）。 雖然容器是否比基礎設施級别執行個體更适用于應用程式運作時傳遞還存在争議，但毫無疑問的是，基于容器的技術将會在建構雲時廣泛采用。
1.3.2 openstack和網絡服務
openstack不是一個虛拟交換機，但它确實管理多個實體、虛拟的網絡裝置和虛拟覆寫網絡（overlay network）。不像openstack控制虛拟機控制器那樣受限于hypervisor提供的服務，openstack直接提供網絡服務，如dhcp、路由等。但與hypervisor管理類似，openstack對底層廠商技術透明，可以是商業或者開源的技術。
更重要的是，後端技術的改變，如從一種網絡/廠商切換到另一種網絡/廠商，并不需要用戶端配置進行改動。對于涉及網絡的大量專有的硬體、軟體和使用者接口，經常從一個廠商或者技術轉換到另一個并非易事。通過openstack，這些接口都被openstack api抽象化了，如圖1-6所示。
圖1-6 openstack管理網絡
openstack可以管理多種類型的網絡技術（實作機制），包括由arista networks、cisco nexus、linux bridging和open vswitch（ovs）等提供的技術。在本書中，我們将使用openstack和ovs提供的網絡服務。ovs是openstack部署中常被選擇的一種，使用者可以簡單地在自己的環境裡獲得和複制，不需要特定硬體環境。除了網絡實作機制，還有很多被openstack支援的網絡類型（vlan和各種隧道技術等），這些内容将會在第6章中詳細介紹。
1.3.3 openstack和存儲
openstack不是一個存儲陣列，至少應該不是你通常認為的存儲那種形式。openstack沒有從實體上提供被虛拟機使用的存儲。
如果你曾經使用過檔案共享（nfs和cifs等），就會用過“基于檔案”的存儲。這種存儲的類型很容易被人使用和被計算機通路，但它通常是另外一種存儲類型的抽象：塊存儲。你可以認為作業系統或者檔案系統是塊存儲的主要使用者。
還有另外一種系統管理者可能不熟悉的存儲類型：基于對象的存儲。這種類型的存儲通常是通過軟體api（如get /obj=xxx）接口進行通路。基于對象的存儲是檔案或塊存儲的更高層面的抽象，但沒有後兩者的限制。基于對象的存儲可以很容易地在多個參與節點之間進行分布和複制。不像塊存儲那樣需要被虛拟機快速通路，分布式的對象存儲允許更大的延遲，将不能用作虛拟機的卷（volume，挂載到一個執行個體上的塊裝置）。通常做法是在建立時就指明使用對象存儲來存放卷和鏡像（包含作業系統）的備份。
下面首先介紹openstack是如何管理塊存儲的，然後介紹對象存儲的相關内容。
1．塊存儲
openstack現在沒有為最終使用者管理基于檔案的存儲。由圖1-7可以看出，openstack管理塊（虛拟機）存儲與管理hypervisor和網絡類似。
圖1-7 openstack管理塊（虛拟機）存儲
圖1-7從基礎虛拟機資源管理展望的角度展示了其全貌。openstack可以管理很多廠商提供的存儲解決方案，包括來自ceph、戴爾（dell）、emc、惠普（hp）、ibm和netapp等廠商的方案。與hypervisor和網絡元件一樣，openstack提供靈活切換存儲廠商和技術的能力，并且不需要改變用戶端的配置。
2．對象存儲
雖然openstack不是一個用于塊存儲（用來啟動虛拟機）的存儲陣列，但它天生擁有提供對象存儲的能力。與在實體硬體上運作linux的支援版本不同，openstack提供分布式對象存儲叢集時并不需要其他軟體。這種存儲類型可以用來存放卷備份，也通常用來存放大量可以被分割成二進制對象的資料。圖1-8展示了一個基本的對象伺服器部署，當然這些都包含在openstack環境中。
圖1-8 openstack提供基于對象的（api）存儲
對象存儲不是必須在同一地點。事實上，節點（代理節點和存儲節點）可以在多個不同的地點，互為備援。
對象存儲傳統的用法是存儲那些被應用通路的資料，如被使用者的應用程式使用的一個文檔或檔案。在openstack環境中，對象存儲有幾種用法。例如，使用對象存儲作為虛拟機鏡像的倉庫。這樣并不是說虛拟機直接使用了這些存儲，它們隻是通過這個存儲系統維護的資料被提供出來。這樣做是合理的，因為這個提供過程不需要對随機資料的低延時通路。對象存儲還會用來備份一個現有的虛拟機的快照，用于長期儲存備份。
1.3.4 openstack和雲專業術語
openstack是一個用來建構雲的架構，可以建構公有雲和私有雲。除了公有雲和私有雲的定義，還有“即服務”的雲定義。openstack是什麼即服務呢？openstack是多個即服務雲的基礎。
假如你對為自己的企業提供一個類似于aws供應虛拟機和存儲資源感興趣，那麼openstack可以認為是基礎設施即服務（infrastructure as a service，iaas）。在這種場景下，使用者具有提供給個人的直接通路的虛拟機，并由使用者直接管理。雖然構成雲的實體元件對使用者是隐藏的，但是可以直接通路它們。openstack的職責是控制為最終使用者提供基礎設施的資源。
現在假設你的雲使用者不能對基礎設施直接通路，使用者隻能通路由openstack提供和支援的應用編排功能。在這種場景下，openstack可以認為是平台即服務（platform as a service，paas）的後端提供者。底層的實體和虛拟基礎設施元件對使用者是隐藏的。想象一下這樣的場景，一個開發團隊需要一個獨立的應用環境（應用層部署在iaas上）來進行軟體測試。通過雲編排，openstack可以用來作為部署測試平台的後端提供者。
現在假設你的公司通過使用openstack提供的基礎設施即服務（iaas）或平台即服務（paas）為客戶提供一種服務。在這種場景下，openstack服務作為軟體即服務（software as a service，saas）的後端元件。你可以看到，openstack可以用作雲計算多個層面的基礎元件。
現在你對openstack可以做什麼和如何做有了更深的了解，是時候介紹openstack各個元件是如何工作的了。1.4節将會介紹openstack各個獨立元件和它們在整個架構中的作用。