私有云基礎架構設計:儲存、網路、計算、安全和應用的設計最佳實踐及案例

前兩天看到網路某位大牛的一篇文章分析超融合市場，其中提到“超融合是從很大意義上將計算、儲存、網路、安全等企業級IT基礎設施有機融合在了一起，但不只是硬體架構上的融合。到目前為止，能完全有機融合這四大元素的公司似乎還沒有出現，更多的還是如何將計算、儲存、網路還有虛擬資源互相融合。”

在開始討論私有云的架構之前我們首先確定一件事情，即沒有架構是完美的，總是根據實際業務慢慢優化最終滿足或者超越最初需求。

私有云客戶與公有云客戶最大的不同是——客戶對私有的“雲”在管理層面上擁有較大的許可權，他（她）可以很放心地把有涉及到公司或者單位隱私的東西放進“雲”中，出現意外時自己可以要求管理員隨時處理。並且私有云就伺服器規模、SLA、防火牆、計費、安全性等級要求等方面而言，與公有云的側重點不大相同，架構上自然也要區別對待。

本章會從基本原則、架構安全、“雲”化架構三個方面敘述基礎架構的設計實現，涉及到的技術細節筆者儘量在後面的基礎知識章節部分加以敘述。

1、基本架構原則

基礎設施架構的核心即是整合計算、儲存與網路三種資源，而在配置這些時我們需要在擴充套件性、穩定性及冗餘性達到一定要求。

• 穩定性

基礎架構的穩定性對於一個平臺是至關重要的。儲存、網路、計算節點自身的穩定性，以及它們之間通訊的穩定性，都時時刻刻影響著使用者體驗。

即使是穩定性非常好的系統，也應該在平時的運維，即監控以及出現故障時的跟蹤、定位、解決上花一定功夫。現在國內很多雲平臺廠商都沒有提供服務狀態報告，比如可用性、地域延遲、資源統計等，相比國外的主流平臺而言仍有很大差距。

• 擴充套件性

擴充套件性包含兩個方面：橫向擴充套件（scale out/in）和縱向擴充套件(scale up/down)。

叢集橫向擴充套件主要包括計算節點、儲存、網路資源“節點級別”的擴充套件，比如新新增了伺服器、交換機等整機裝置。需要注意的是，節點加入叢集后，其上的所有業務均能在新節點正常執行；同時，新節點的加入對普通使用者來說是透明的，即使用者不會感知到叢集的橫向擴充套件。

縱向擴充套件即是整機中加入例如新的CPU、記憶體、硬碟、網路卡等元件以提高單機效能。

平臺在進行橫向擴充套件時，也可使用其他平臺的資源。比如企業內現有國際品牌的虛擬化產品，如果國內廠商的虛擬化產品能夠直接使用原平臺的虛擬機器、虛擬硬碟甚至是虛擬網路的話，那麼對企業來說，這個過渡將會非常輕鬆。現在能夠提供雲平臺API的廠商比較多，而能夠作為參考標準的只有Amazon、OpenStack、VMWare等國際化平臺。筆者成文時，中國資訊科技標準化組織目前尚未制定出“及時”的標準，但已經成立了很多的工作組，比如伺服器虛擬化、桌面虛擬化、雲端儲存等，相信他們也很快推出統一標準。

• 冗餘性

冗餘性是穩定性和擴充套件性的補充。對於私有云而言，成本往往僅能保證穩定性，而在冗餘性保障上有較少的支出。當成本不足以滿足所有基礎資源的冗餘性的時候，就要根據具體環境來判斷，儘量保持它們不同資源上冗餘能力的平衡，最大程度地減少潛在風險。

1.1 合理的儲存配置

私有云中儲存配置是整個架構的重點，它承擔著整個平臺的資料，所以這裡一般需要進行重點配置。除了傳統儲存架構外，也有廠商Nutanix為首提出的超融合架構，即儲存與網路一樣也可以進行軟體定義。目前對多數國內私有云廠商來說，超融合的一般實現即是在虛擬化平臺中新增分散式儲存的後端與前端管理，可對計算節點資源進行復用，從而降低專案整體成本。

不管何種形式，它們對平臺的提供的功能都是相同的，接下來筆者針對私有云平臺的儲存基礎架構予以介紹，相關的儲存知識讀者可以閱讀本書的第7章。

• 接入方式

私有云中的儲存配置按照接入平臺的方式可分為本地儲存和共享儲存，而它們本身的組合方式又是自由的，除傳統的本地儲存和網路儲存外，也有NFS儲存可以掛載後作為計算節點的本地儲存，或者計算節點上的空閒空間組合為分散式儲存等方法。圖2-1和圖2-2分別是本地儲存與共享儲存的接入方式示例，本地儲存即直接使用本地磁碟或者iSCSI、SAS等裝置作為映象儲存，虛擬機器例項與映象在同一主機中，而共享儲存下虛擬機器例項可在任意主機中開啟映象並執行，從而使得虛擬機器熱遷移成為可能。

圖2-1 本地儲存接入示例

圖2-2共享儲存接入示例

圖2-1中有本地硬碟、共享儲存/FC/SCSI儲存作為本地儲存的兩種用例；圖2-2中節點1直接使用外部儲存作為共享儲存，節點2和3提供本地硬碟作為Ceph/Glusterfs的儲存後端，再使用Ceph/Glusterfs作為共享儲存。儲存的接入方式對平臺效能、穩定性甚至使用體驗上都有直接或間接的影響。

當使用共享儲存時：

• 虛擬機器可以進行線上遷移，合理利用伺服器資源，增加業務連續性；

• 計算節點當機不會造成虛擬機器單點故障，提高穩定性；

• 可以更靈活地應用備份機制，並且擴容相對簡單，提高可維護性；

• 可與其它業務或者平臺共享儲存，提高擴充套件性；

• 儲存與計算節點邏輯、物理都分離時，架構清晰；

• 對網路連線路徑較為依賴，計算節點增加時可能需要增加線路隔離流量；

• 可以利用網路快取機制，減輕啟動風暴影響，但對共享儲存裝置有一定要求；

當使用本地儲存時：

• 虛擬機器更加獨立，某個使用者的過度使用不會造成其它虛擬機器的讀寫效能影響，增強使用者體驗；

• 可以利用更高效的本地快取機制，減輕啟動風暴的影響；

• 儲存成本投入較小；

• 計算節點當機時會造成其上所有機器不可訪問，即單點故障損失較大，影響平臺穩定性；

• 虛擬機器線上遷移有難度，難以平衡叢集負載；

我們選擇接入方式時需要綜合考慮業務型別、成本、使用者體驗、風險控制等等各方面因素，儘量避免對整個平臺的穩定性和效能造成負面影響。

• 儲存後端

儲存後端即平臺儲存資源的核心，組成部件不止於機械硬碟、SSD，也包括其通訊鏈路、韌體等。儲存後端效能與其上的虛擬機器緊密相關，當選擇不當的時候會降低平臺整體效能，而導致使用者體驗不佳。

圖2-3 儲存節點物理示意圖

多數專案方案中既有高速儲存裝置，又有相對低速的儲存裝置，我們要根據“業務”來規劃儲存使用。接下來我們做一次實驗，用資料簡單說明虛擬機器硬碟格式與物理儲存的相互影響，其中我們使用一塊SSD代表效能較高的高速儲存，一塊SAS硬碟代表相對低速儲存，這裡的“業務”是啟動連結克隆方式建立的虛擬機器並進入桌面。

“完整克隆”與“連結克隆”

在KVM虛擬化平臺中，有兩種建立例項的常用方式：完整克隆與連結（增量）克隆，在以後章節中會有詳細介紹。

完整克隆即完全複製模板配置資訊與硬碟檔案，硬碟的複製方式一般為cp或者qemu-img convert。如此建立的例項，其硬碟與模板硬碟相對獨立，在伺服器儲存上擁有各自的扇區位置，所以在讀寫操作時受機械盤磁頭引起的小區域併發問題影響 較小，缺點是建立時需要花費一定時間，不能滿足秒級建立的需求。

連結克隆即新建虛擬機器時只複製模板配置資訊，硬碟檔案則是以原硬碟為模板的增量硬碟。如此建立的硬碟對模板硬碟的依賴程度較高，對於硬碟內已有檔案的讀操作（比如啟動系統時）絕大部分在模板硬碟上進行，所以在傳統機械盤上多個例項的併發啟動風暴更容易在此種格式的硬碟上發生。

本次實驗環境中，筆者使用一臺雙路E5-2630v3、128G記憶體的伺服器，兩塊企業級SSD（其中一塊為伺服器系統，另一塊虛擬機器儲存）和一塊企業級SAS硬碟（虛擬機器儲存），將1G記憶體、單核、全新安裝的XP虛擬機器作為模板。為了防止虛擬機器進入系統後進行檔案索引等佔用空間的操作，模板虛擬機器建立之前開機“靜置”了一段時間直到其資源用度無明顯變化。

• 企業級1T SAS硬碟虛擬機器批量啟動實驗

此時新建的例項所和模板都位於SAS硬碟上。同時啟動20臺虛擬機器後，全部虛擬機器在第300秒左右進入桌面。啟動20臺虛擬機器過程中的伺服器CPU及I/O用度如圖2-4所示。

圖2-4 於SATA硬碟中啟動20臺虛擬機器的CPU及I/O用度

• 企業級480G SSD虛擬機器批量啟動實驗

此時新建的例項和模板都位於SSD上。同時啟動20臺虛擬機器後，全部虛擬機器在第35秒左右進入桌面。啟動20臺虛擬機器過程中的伺服器CPU及I/O用度如圖2-5所示。

圖2-5 於SSD中啟動20臺虛擬機器的CPU及I/O用度

可以看出，高速裝置比低速裝置擁有更高的IOPS以及更高的讀寫速度。目前兩者成本相差很多，所以全部使用高速儲存會增加很多成本。在實際實施中，高速和低速裝置搭配使用，比如將高速裝置用於儲存模板和某些高IOPS虛擬機器，低速裝置用於儲存普通虛擬機器，這樣從成本和使用者體驗綜合考量，方可獲得比較合理的配置。

1.2 穩定的網路基礎

一個優秀的IT架構一定有一個優秀的網路基礎。網路在私有云尤其是桌面雲中的影響有時比儲存更加直接。在搭建私有云的過程中，更多的專案是在已有 IT架構的基礎上進行延展，而不是廠商獨立的架構，所以對整個使用者端網路框架有個清晰認識就顯得很重要。在我們接觸的專案中，有比較多的問題是網路不穩定、框架不合理造成的。雖然我們在專案中極少擁有對使用者網路改造的權力，但是也要在網路上下功夫認真規劃，並在關鍵結點與客戶及時溝通，儘量減少網路因素帶來的諸多“麻煩事”。

圖2-6是以業務為核心的通用私有云架構，圖2-7則是從計算節點出髮網路檢視，它們的共同點都是對網路進行了較為嚴格的區分，但劃分標準不同，讀者在很多雲平臺中都會看到類似架構。其中會涉及到虛擬化網路基礎與軟體定義網路（SDN）等知識點，具體內容讀者可閱讀本書的第6章。

圖2-6 業務為核心的通用架構

圖2-7 計算節點為中心的網路架構

對於構建一個穩定的網路基礎來說，傳統OSI七層模型很有參考價值，而側重協議實現的TCP/IP的四層模型也很實用，在此我們使用它們的混合模型來分層討論。圖2-8是OSI網路模型與TCP/IP模型簡圖。

圖2-8 OSI模型與TCP/IP模型

傳統OSI在服務、介面、協議有所側重，但是它由於歷史原因以及實現等問題，現在僅僅被人奉為“經典”，具有的參考價值大於實用價值。而 TCP/IP的實現由於其模型簡單，很大程度上促進了網際網路時代的來臨，但是使用它來描述比如說藍芽網路，基本上是不可能的了。而混合五層模型即吸收了它們的優點，又一定程度上回避了它們的缺點。下圖即是混合網路模型簡圖。

圖2-9 OSI與TCP/IP混合模型

同儲存資源一樣，我們在構建私有云網路基礎的時候也要關注其穩定、擴充套件、冗餘的能力，同時注意成本，以下筆者將從這5層分別進行介紹。

• 物理層

在物理層，我們需要做出的選擇有傳輸介質和有線/無線傳輸方式。

表2-1 網路線材分類

分類	光纖	萬兆銅纜	千/百兆雙絞線
最大頻寬	100Mb-100Gb	10Gb	100Mb-1Gb
能量衰減	極低	低	中
最大長度	300m-40km	100m	100m
成本估算	中-高	中-高	低

在後端資源鏈路中，一般有計算節點、儲存之間，計算節點、網路之間，儲存、儲存之間以及計算、網路、儲存的內部通訊鏈路。其資料量或高或低，對於私有云而言可以採取後端全萬兆的鏈路以減少後端對整個平臺產生的短板效應。因為對於私有云而言批量啟動是會經常出現的，所以至少計算節點與儲存的鏈路一定要有所保證，從而防止網路頻寬成為儲存能力的制約影響使用者體驗。

伺服器與前端的鏈路資料根據私有云業務的而異，主要是控制檯畫面傳輸、互動（鍵鼠輸入、外設重定向資料、語音等）、檔案傳輸（雲端儲存）等。一般到客戶端匯聚層的鏈路使用千兆雙絞線，到客戶端使用千兆/百兆雙絞線。

• 資料鏈路層與網路層

這兩層中我們要關注的部分主要是不同層次的交換機/路由配置、IP、VLAN的劃分，除非對於完全自主搭建網路的廠商，否則我們只要瞭解其基本拓撲和路由配置即可。

目前比較主流的網路規劃為環網＋星型拓撲，並且按照核心層、匯聚層和接入層區分職責，如下圖所示。

圖2-10 星型＋環形網路拓撲

其中有幾點需要注意：

• 組網的有多種，不同規模可以使用不同的混合拓撲；

• 在私有云的架構中，網路標籤更偏向以功能邏輯而不是以地理位置區分。這點在開源雲實現中體現的很明顯，比如Mirantis OpenStack的網路規劃以及oVirt的邏輯網路；

• 由於後端資源鏈路較多，一般情況下會使用VLAN（tagged/untagged）來進行隔離；

• 非核心資源儘量採用DNS＋主機名的方式進行搭建，防止以後IP變化帶來的維護困難；

• Bonding（鏈路聚合）是比較常用的增加冗餘和頻寬的措施，但要注意交換機關於bonding負載均衡的策略，防止bonding無實際效果，比如IP、MAC、TCP Port的組合方式；

• 交換機儘量採購同一品牌，以免增加運維人員負擔；

• 傳輸層與應用層

我們需要保持網路穩定高效主要是為了這兩層，因為它們對使用者接入、桌面協議、業務網路、資源網路、控制協議等有直接影響。

其中，從使用者端到雲平臺需要保持良好通訊的有http(s)、spice/vnc等，伺服器之間則有ssh、sql、telnet、smtp、pop等之間影響業務等應用層協議。

而在傳輸層中，經常出現的問題有網路擁堵、過載、超時、延遲等問題。比如當一端等交換機或者裝置達不到處理大量報文所需的計算能力時，就會導致丟包或者多次重發的現象；當有錯誤或者惡意報文進行廣播時，區域網所有機器都會返回錯誤包而導致廣播風暴；當有大量機器重啟從DHCP伺服器獲取IP時，也會對伺服器造成很大負載；報文的超時時間對應用的影響也很大，過低會導致在網路繁忙時大量應用超時，過高會引起傳輸效率變低從而影響視訊等實時應用卡頓。

在設計時我們需要注意以下幾點：

• 終端/伺服器的頻寬要儘量保證不低於直接連線的網路頻寬，否則當網路端（有意/無意/惡意）傳送大量報文時，會造成伺服器網路卡處理能力的大幅下降，影響其上的應用效能；

• 適量增加封包大小，減少資料傳送次數，從而降低網路卡負擔；

• 適量調整報文超時時間，減少網路繁忙時產生擁堵；

• 在可以壓縮協傳輸層議頭甚至資料的條件下優先壓縮協議頭，從而減少報文傳輸次數降低流量；

總之，私有云網路設計與傳統網路架構設計相比，需要考慮的變數更多。尤其近些年軟體定義網路的發展，以及OpenStack、VMWare中網路虛擬化的推進，客戶對私有云/公有云對廠商的綜合素質要求更高了。

1.3 可靠的計算資源

提供考量計算資源的標準，不止於物理伺服器的效能、安全、穩定等因素，還有計算節點組成的叢集所具有的能力，比如負載均衡、高可用等。接下來，筆者將根據硬體、軟體配置並結合私有云的特性進行計算資源伺服器的選擇，以其達到最優的計算資源配置。

• 伺服器硬體

圖2-11 PC伺服器一般架構

通常情況下，CPU、記憶體是決定伺服器能夠承擔多少負載的決定性因素，而儲存、NUMA和擴充套件屬性保證著伺服器執行的功能性和穩定性。

多數廠商在部署私有云時，往往按照CPU邏輯核總數和虛擬機器總核數按 1:X 來分配，當虛擬機器有卡頓或者其它情況出現時，再調整比例。而這一點在筆者看來是很不好的習慣，因為它忽略了一些因素，比如CPU最大主頻、非NUMA核間資料拷貝代價、虛擬機器執行程式時的保證峰值負載等。我們在此使用一個經驗公式來計算：

其中，sockets、cores、frequency分別代表伺服器的物理CPU數量、單CPU執行緒數、最大主頻，當超執行緒HT開啟（為真）時獲得20%的提升，否則不提升，cap代表伺服器的能力。讀者可以訪問Intel ARK網站（或手機APP）查詢具體的CPU引數。

假設一個Windows 7桌面普通辦公流暢的最小負載為2.0Ghz，使用雙路Intel E5-2630 v3，則cap為61.44GHz，即我們這臺伺服器可以保障30臺單核Windows 7桌面流暢執行。由於桌面應用程式往往可以利用多核特性，所以我們會考慮分配其雙核甚至四核，同時其單核負載下降，亦可以看做2 * 1 Ghz，加之峰值負載下的機器併發量少，我們可以再適當增加虛擬機器數量。在選配CPU時，我們要根據實際負載、桌面應用、成本等因素綜合考量，儘量減少 CPU效能的瓶頸或者過剩。

NUMA技術和主機板CPU省電選項（C1E等）同樣也會影響伺服器CPU效能。NUMA技術會大幅提高CPU間通訊，換句話說，當有較多程式存在時，利用 NUMA可以減少程式在CPU之間切換的時間，一般建議開啟。對於高I/O、低CPU利用率的應用，主機板使用C1E或者更深度的電源管理選項（C1/C3 /C6）時會較大程度地影響其效能。目前在KVM中，缺少C1E動態開關的選項，所以建議在BIOS設定中關閉此項。

記憶體技術也是影響虛擬機器的重要因素，目前在KVM中可以使用記憶體氣球、巨頁、KSM等技術提高記憶體使用效率。雖然記憶體可以超分（overcommit），但我們仍然要保證實體記憶體不小於所有虛擬機器分配記憶體，因為記憶體不足導致的問題一般比較嚴重，對於伺服器來說甚然。另外，當記憶體充足時建議關閉swap分割槽，因為在資料拷貝期間發生交換將帶來比較嚴重的效能損失。

計算節點的硬碟配置可分為系統盤和資料盤，系統盤即執行虛擬化節點所需作業系統的硬碟，資料盤即用於本地儲存或者共享儲存的硬碟。當採用共享儲存時，可以省去伺服器資料盤配置。

擴充套件插槽中可以新增RAID控制器、JBOD控制器、GPU卡、網路卡等高速裝置。而USB控制器則用於加密狗、U-Key透傳等功能。這兩項外設擴充套件在特定的伺服器中可以進行額外擴充套件。

• 作業系統

計算資源的作業系統首先要做到效率高、穩定性好、相容性好，其次是無狀態、易維護等。

在效率上我們能進行很多比較系統的優化，比較通用的有程式排程、驅動程式優化、I/O優化等。通用的優化做好以後就可能需要對具體硬體進行鍼對性的驅動、排程優化。通用的優化是可移植的，而針對具體硬體的優化難以保證，所以我們在這兩方面應有所取捨。

穩定性是考量系統的重要標準之一，影響它的因素或是系統本身，或是軟體，或是硬體。一般私有云廠商在進行實施之前，如有可能會對伺服器進行連續中低壓測試，確保其穩定性後再進行軟體的部署。而伺服器硬體相容性問題伴隨著硬體廠商和作業系統廠商（尤其RedHat）的緊密合作，它的出現情況已經比較少了。但是一旦出現相容性問題，一般都比較難以排查，往往需要硬體廠商提供協助。

所謂無狀態作業系統，即我們需要這個計算節點異常斷電重啟後無需人工干預繼續提供服務。它提供了一種類似還原模式的作業系統，降低了系統損壞後難以修復的機率同時減少了運維負擔。其實現方式比較多，包括DOM盤、PXE、SQUASHFS等。

至於易維護性的物件，主要針對伺服器的狀態監視、系統軟體修復/升級。

作業系統的選擇

目前主流雲平臺多基於CentOS/RHEL或者Ubuntu系統。其主要原因就是其生命週期與知識庫——CentOS每個大版本是10年左右，Ubuntu/Debian為5年，SUSE為10+3年（期限雖長但對應雲平臺知識庫較少）。當然，影響我們對伺服器選擇的因素中，軟體也佔據大部分，比如下圖就是虛擬化相關軟體的通用架構，其中哪部分使用或高或低配置的伺服器甚至虛擬機器作伺服器還是要調研一番更為妥當。

• 軟體服務

在分散式架構中，不同的軟體服務一般部署在不同的伺服器上，這樣就會使單獨的軟體服務模組更具可維護性和部分效能上的優勢。以IaaS為例，常用的軟體服務模組如圖2-12所示。

圖2-12 開源雲平臺虛擬化相關功能軟體架構

其中，我們重點考慮的軟體模組是模擬器部分（關於開源的x86模擬器QEMU讀者可以參考第4章內容）。

首先，模擬器會對計算節點的CPU特徵有一定要求。以虛擬機器遷移為例，現在的虛擬化實現不能進行異構遷移，即虛擬機器vCPU不能在遷移後改變其CPU特徵，這就要求叢集中的計算節點使用統一的CPU特徵組啟動模擬器，並且所有計算節點的的CPU至少屬於同一架構。其次，模擬器會對計算節點的CPU效能有一定要求。私有云中常常會有重點業務虛擬機器，它們對CPU效能、記憶體等計算資源有較高要求，此時我們就需要賦予較高資源優先順序，保證它們在資源充裕且狀態良好的計算節點上執行。然後，如果虛擬機器需要使用常駐的外部裝置，那麼我們就需要進行裝置透傳或重定向。而現有的模擬器實現不能在裝置已與虛擬機器連線的情況下進行遷移，這就只能將此虛擬機器在固定的計算節點上執行，從而要求此計算節點需要擁有數量合適的外部裝置或介面。最後，某些模擬器的效能會受主機板設定的影響，比如CPU電源管理，這就要求計算節點需要針對具體的模擬器型別作出相應設定，保證模擬器效能最優。

需要注意的是叢集中的網路元件，以Neutron為例，其OVS節點在網路資料包較多的情況下，會對本地CPU造成不小的壓力從而引起網路丟包、延遲現象，而針對這點常用的做法是使用單獨的網路控制節點和SDN交換機以分離控制層與資料層，從而保障網路效能的穩定。

至於容器，它執行在Linux伺服器中時一般不會對CPU有特殊要求，只要保證核數與主頻合適即可。而叢集元件，比如Nova、Glance、vdsm等，它們對計算資源要求也比較少。

2.、架構安全

當人們討論安全時，首先想到的可能就是一個複雜的密碼，還有不同網站使用不同的密碼。作為被各種網站註冊頁面包圍的現代人來說，這是一個好習慣。其實，對一個面向終端使用者的系統而言，密碼只是它複雜又精密的安全機制體現之一。一個系統安全機制實現的複雜度直接關係到使用者資料的安全保障程度，它始終以使用者資料為核心，以保障系統自身安全的條件下保障使用者資料的安全性，圖2-13是私有云環境下的使用者接入檢視。

圖2-13 私有云環境使用者接入簡圖

2.1 認證與授權

認證（authentication）與授權（authorization）歷來是安全系統重點關注的部分，即使在現實生活中也是這樣。認證是發生在使用者進入系統時，而授權是在對系統進行操作的過程中。

在傳統認證授權系統中，普遍使用AD、LDAP等作為網路資訊伺服器（NIS），前者是類Kerberos的實現，後者可直接與Kerberos進行結合。私有云需要這種NIS訪問方式，以便接入現有業務系統或者啟用單點登入（Single Sign On）。Kerberos的認證流程如圖2-14所示，其核心是ticket的獲取與授權。

圖2-14 Kerberos認證過程

可以看到使用者與服務的認證授權過程很清晰，實現時注意需要使用者/服務端/KDC（相當於AD域控）三者時鐘同步。當使用者進行登入以後，他使用任何應用都不再需要再次輸入密碼認證，應用程式通過使用者第一次獲取的key向服務請求對應的許可權，並且所有許可權都可以進行細分管理。

雖然Kerberos效能、安全性方面都很優秀，但與應用結合時仍需考慮它引入的運維複雜度問題，尤其是在擴充套件性方面。

2.2 服務安全

對於使用者來說，將資料儲存在一個放心的環境裡能很大程度上減少他們的擔心。對於管理員來說，一旦被入侵，那麼損失的不止是使用者資料了，更有可能喪失使用者對整個平臺的信任。接下來我們從三個方面來增加我們伺服器安全性。

• 網路安全

網路安全是我們第一個要考慮的事情。從功能上我們將網路劃分為使用者接入端網路、傳輸網路、後端網路。我們很難保證使用者接入端網路的安全性，所以普遍做法是在傳輸網路與後端網路上實施安全防護措施，包括加密傳輸、防DDoS/CC攻擊、流量限制等。在私有云環境中，不僅要對外網入口進行防護，更要對區域網進行監控和防護，我們要採取一定措施進行區分。

• 加密傳輸

在私有云平臺中，所有服務的TCP/IP連線都可以選擇性地使用SSL/TSL進行加密。而在進行SSL/TSL加密傳輸時，有兩點需要注意：確保至少有一個可信的根證書頒發機構頒發的根證書，對於小規模私有云來說，可以使用二級可信證書或者自建可信域；謹慎管理私鑰及其備份，防止外洩。

• 防DDoS/CC/SQL隱碼攻擊

整個平臺給使用者提供的接入方式很可能是一個Web介面，或者REST API的介面，那麼就會與傳統Web伺服器一樣面臨著被攻擊的威脅。和傳統服務一樣，我們可以使用專門的硬體/軟體防火牆以及負載均衡來處理對訪問入口的大量併發請求。SQL隱碼攻擊是目前網際網路企業最為關注的攻擊手段，。技術細節可以市面參考相關書籍與文章，筆者在此不以贅述。

• 流量控制

私有云的流量限制條件比公有云寬鬆一些，但是仍要予以高度重視，否則同樣會帶來體驗乃至安全上的嚴重後果或者事故。平臺入口以外的流量我們可以通過外部防火牆進行處理，虛擬機器內部的流量往往通過虛擬化平臺的流量控制功能進行限制，有些時候也會引入內部防火牆。平臺也要對架構中的異常流量有所感知，以通知相關人員進行維護或者防護。

網路安全方面有很多成熟的方案或者產品，我們應根據它們的效能、管理複雜度、平臺相容性等進行綜合選擇，儘量減少引入私有云時帶來的複雜度和成本。

• 儲存介質加密

在此以常見的智慧手機為例，使用者儲存在手機裡的資料包括聯絡人、音視訊、照片等，給手機螢幕解鎖後，使用者可以訪問它們。當手機損壞或丟失後，某些心懷不軌的人可能會利用裝置複製出手機的快閃記憶體內容進行解讀。為預防這種比較極端的情況發生，現在的智慧手機作業系統中都會有“加密儲存”、“遠端抹除”等安全選項，當使用者選擇進行儲存加密時，對儲存介質的非法直接訪問也將變得異常困難（現在的加密key一般儲存在手機CPU中）。

上述的場景應用到私有云時，使用者的資料即是虛擬機器硬碟以及儲存於“網盤”上的內容。

圖2-15 使用者資料加密主體

伺服器作業系統中儲存有虛擬硬碟，在這一層進行加密就意味著即使這臺伺服器硬碟被取出，也很難讀取其中資料；KVM下的虛擬硬碟本身在建立時也支援 AES加密選項，但由於其穩定性欠佳已經被社群漸漸拋棄，截止成文時沒有任何改進的措施出現；至於虛擬機器OS內，它可以加密虛擬硬碟、資料、目錄等等，但是需要使用者自己進行選擇加密的內容。

資料加密解密的同時一定會帶來效能上的些許影響，全部使用伺服器OS加密硬碟一定不會適用於所有場景，同樣強制使用者虛擬機器OS加密也不會太妥。當面向安全等級特別高的場景時，使用伺服器加密一定是有益的，一般場景下我們提供虛擬機器OS加密的建議即可。

伺服器裝置

我們現在也有很多措施可以專門用來加強伺服器本身的安全性，不妨嘗試從以下兩方面入手：

• 可信平臺模組

可信平臺模組（TPM，Trusted Platform Module）由計算機工業的可信計算組（TCG，Trusted Computing Group）制定，旨在提供電腦保安加密裝置與技術，用來防止密碼、敏感資料被竊取的標準裝置。下圖為某廠商的TPM模組，附加於專用的主機板I/O介面。

圖2-16 某廠家的TPM模組

它是一個硬體模組，本身提供了各種加解密演算法的快速計算，同時可以進行遠端認證、資料加密/解密認證，主要應用場景如下：

• 平臺認證

它可以從硬體裝置、裝置韌體、BIOS到作業系統、軟體都進行雜湊校驗，保證系統中沒有未經許可的硬體或軟體接入。比如接入一個未曾記錄過的USB鍵盤時，它就會記錄並按照預配置操作進行處理。

• 硬碟加密

伺服器作業系統可以在其內部使用TPM協助進行硬碟加密，一般需要特定軟體實現，比如dm-crypt、BitLocker等。

• 密碼保護

使用者的密碼、金鑰、資料、作業系統等都可以使用它來進行保護。傳統軟體實現的認證機制往往不能經受字典攻擊，而TPM內建了防字典攻擊機制，使得所有繞過軟體限制的大量嘗試登入操作被TPM終結。

目前在私有云中，主流虛擬化平臺都提供了對TPM的支援。QEMU中除了TPM透傳外，也可以使用QEMU模擬出TPM裝置進行加解密。

• 地理位置標籤

使用地理位置標籤（Geo-Tag）可以幫助管理人員瞭解伺服器的具體位置，以方便管理維護。它可以配合RFID裝置進行短距離細分標識，並且在統一管理平臺的幫助下，實現所有裝置狀態、位置的實時監控。當然它也可以配合TPM組建基於地理位置的可信資源池。

3、“雲”化架構

由第一章私有云的定義我們可知，虛擬化只是“雲”的實現手段之一，而面對真正的雲我們仍需要很多工作。我們接下來討論的內容就是如何將基礎架構“雲”化。

3.1 池化資源

池化資源是向“雲”邁進的重要一步，這一點我們可以通過社群動態以及商業雲產品中窺探到。在前面的基礎架構中，我們圍繞著計算、儲存、網路三個基本元素組建系統，而接下來就需要使用雲平臺將它們進行“池化”操作，從而提供更具有彈性、更加高效和穩定的的服務。

以伺服器為基本載體的三種資源通過各種方式進行組合，提供IaaS、PaaS、SaaS模式的服務。這些服務模式展現給終端使用者的有諸如虛擬機器、雲端儲存、負載均衡、內容加速、應用框架等具體服務，如圖2-17所示。將資源進行池化的好處即是一方面使用者不必知道所接受服務的具體來源，同時能夠得到穩定、快速的服務響應，另一方面服務提供商對資源也能進行合理的管理與維護。

圖2-17 典型“雲”服務模型

3.2 SLA管理

SLA（Service Level Agreement）即服務等級協議，它通過對資源的限制、配置、排程而保證服務的高可用。

• 高可用

高可用可以按照其作用物件可分為伺服器、虛擬機器以及虛擬機器內應用程式。

在伺服器層面，我們通過評分、隔離、電源管理等機制保證虛擬機器執行在一個穩定的環境中。評分即通過監視伺服器的資源當前及歷史狀態，對其進行綜合評價，分數越高具有執行虛擬機器的權利。隔離操作一般發生在伺服器與叢集管理節點失去聯絡時，為保證服務質量而將其從服務叢集中隔離不再執行虛擬機器，一般配合電源管理進行操作。

虛擬機器層面的高可用往往需要對其新增模擬看門狗。看門狗是一種輔助晶片，在嵌入式系統中常用來監控CPU狀態，當CPU停止工作後看門狗就不會再收到CPU發來的心跳訊號而將CPU強制重啟。對於PC而言，看門狗將系統重啟的條件多是藍屏、當機等。

對於虛擬機器內的應用程式的高可用，可以通過外部監控（比如埠狀態監測）和內部監控（比如虛擬機器代理程式）完成。這方面的監控產品比較多，主流的有 Nagios/Icinga和Zabbix等，它們都需要在虛擬機器內按照代理程式，當某一應用被監測到停止響應時，就可以使用管理員提前設定的策略嘗試重啟此應用。

• 資源限制

資源限制即是對允許使用者使用的最大資源進行限制，包括虛擬機器數目、CPU、記憶體、硬碟、網路等。這裡的限制按照物件可以劃分為兩個方面，一是使用者允許使用的總資源配額，二是虛擬機器在執行時所允許的資源最大利用率。

比如在一個使用者可以自己建立虛擬機器的環境中，管理員往往難以控制其建立刪除行為，如果能對使用者建立的所有虛擬機器數目、vCPU數目、記憶體大小、硬碟大小、網路頻寬進行配額限制的話，那就既能滿足使用者的自主性又可適當減少管理員負擔了。這種限制有些類似作業系統中的配額限制，它主要體現在對“量”的限制上。

但是對“量”的限制還不能滿足私有云的需求，那麼就要從“質”上進行限制了。如果使用者擁有足夠的服務資源配額，那麼當他的虛擬機器長期滿負荷執行時（比如網路發包、硬碟高IOPS直寫、CPU利用率高居不下等），就會對與其處在同一臺伺服器上的虛擬機器造成比較嚴重的影響。為了其他使用者的體驗考慮，我們引入了利用率的限制，包括CPU利用率（CPU數目與其利用率乘積）、硬碟利用率（IOPS、MBPS）、網路利用率（百分比）等。

當使用者的資源將要超過配額或者較長時間內高利用率使用時，平臺同樣需要對其發出警告，防止其系統發生崩潰、惡意入侵等意外情況。

讀者可能會在很多地方讀到關於將PaaS平臺搭建在IaaS平臺上的資料，但是我們需要了解這樣做的原因主要是考慮到了資源的隔離控制，而不是資源用度方面，所以其高可用性較之以物理機直接接駁容器工具方式有一定劣勢。

• 資源配置

資源配置往往是一個動態的過程，它通過一系列策略對虛擬機器的CPU、記憶體、網路、硬碟的使用進行控制，以期最有效地利用伺服器資源。

當一個多核虛擬機器執行時，它會有多個LWP（輕量級程式，可理解為執行緒）協同父程式執行。比如一個雙路32核的伺服器上執行一個單路32核的虛擬機器，往往就會有多於33個LWP在執行（可用ps -eLf檢視）。而這些LWP在未指定的情況下往往會在核之間漂移，然後由於程式同步和上下文切換對虛擬機器效能造成比較大的損失，當使用率提高時也會對其他程式產生比較嚴重的影響。為了解決這一類效能損失，我們引入p-vCPU繫結與NUMA機制。

另外我們還可對每個虛擬機器vCPU進行優先順序安排，較高優先順序的vCPU擁有更多的CPU時間。這一特性由於其收益較小，在私有云中適合於極端優化場景。

對於記憶體的配置，我們同樣可以利用KSM（Kernel SamePage Merging）配合記憶體氣球技術提高記憶體使用效率並達到記憶體“超分”（over committing）的效果。從KSM可以看出其字面意思，即合併虛擬機器所佔用虛擬機器的相同記憶體頁以節約伺服器記憶體佔用，如圖2-18。記憶體氣球即假設虛擬機器的實際佔用記憶體為氣球體積，伺服器總記憶體為裝有許多氣球的盒子，佔用記憶體即為盒子中的空閒體積。當氣球變小時，盒子空閒體積變大，就有更多的空間可以供給其他氣球及伺服器使用，反之亦然，如圖2-19。

圖2-18 KSM原理

圖2-19 記憶體氣球技術

• 資源排程

資源排程的過程按照虛擬機器的生命週期可分為兩部分進行，一是使用者請求服務後服務資源後池中分配合適的資源提供服務，我們稱之為啟動策略；二是當提供的服務達到排程閾值後，為了服務的質量保證而進行的自動排程或者手工排程，我們稱之為執行時策略。資源排程是考慮一個雲平臺質量的重要指標。為了實現私有云的資源排程策略，我們需要的操作通常有對虛擬機器的遷移、開關機、掛起，以及對伺服器的開關機、隔離，再結合定時、分級、排序、統計、反饋機制，套用到不同的場景中去。接下來我們從啟動策略、執行時策略開始，討論它們可能用到的機制和具體操作。

啟動策略的實現或簡單或複雜，目前在私有云中最基本的有兩種：

快速啟動：平臺首先對伺服器按照其所剩資源進行排序，比如第一個列表為所有伺服器剩餘記憶體從高到低的排序，第二個列表為所有伺服器CPU剩餘未分配核數從高到低的排序。當虛擬機器請求資源準備啟動時，它從第一個列表中發現伺服器甲、乙、丙滿足其CPU核數要求，從第二個列表中發現伺服器甲、丁滿足其 記憶體要求，那麼虛擬機器就會在伺服器甲上啟動，原理如圖2-20。類似這種快速啟動策略實現起來比較容易，效果也能滿足大多數場景。

圖2-20 快速啟動示意圖

最優啟動：同樣地，平臺也會對伺服器進行排序，但是這次排序除了考慮剩餘資源，也會考慮已用資源。當虛擬機器請求資源準備啟動時，平臺根據剩餘資源 選擇一組可用的伺服器，然後再計算出這個虛擬機器在這些伺服器上執行的話單個伺服器的資源百分比是否超過預設閾值，然後它會選擇一個資源百分比變化最小的伺服器上啟動虛擬機器，原理如圖2-21。最優啟動在實現時，往往會結合執行時策略進行排程，儘量減少虛擬機器或者伺服器的後期執行時排程。

圖2-21 最優啟動示意圖

啟動排隊

在啟動策略中為減少“啟動風暴”的發生，我們往往會引入排隊機制。每臺伺服器會根據其當時負載狀況選擇一定時間視窗內可 以允許多少臺虛擬機器啟動，待這些虛擬機器啟動完成對硬碟和CPU的負載降低後後，再啟動下一批虛擬機器。在一個監控機制較完善的平臺下，排隊機制中的變數（佇列長度、視窗時間等）可以根據伺服器狀態進行動態調整。

執行時策略可以從很多角度進行設計，比如伺服器利用率、電源能耗、使用者負載等，常用的有如下兩種：

• 平均分佈：平均分佈即要求所有伺服器上的負載（虛擬機器數目、資源用度）儘量相同，對於負載過高的伺服器就會遷移其上的某些虛擬機器至其他負載較低的伺服器。這樣做的目的是降低區域性負載，保持虛擬機器所處環境的平等。

• 低能耗：這種策略有兩種實現，第一種要求所有虛擬機器執行所佔用的伺服器數目儘可能少。它先將虛擬機器從多臺伺服器上集中遷移到某些臺伺服器，然後再 將其他伺服器關機以達到省電的目的。第二種則不要求伺服器關機，但是會讓閒置的虛擬機器釋放CPU、記憶體資源，它通過定期檢測桌面連線或應用連線，掛起較長時間無連線的虛擬機器。在私有云桌面環境中，第二種實現應用比較廣泛。

虛擬機器親和組

虛擬機器親和組即是按虛擬機器應用或者關係將其分組，同一組的虛擬機器儘量在同一臺伺服器中執行或者往同一臺伺服器遷移。應用 環境相似的虛擬機器會有很多相同的記憶體頁，那麼將它們保持在同一臺伺服器上執行就會很大程度上地節約資源消耗。叢集架構的業務虛擬機器有時也需要在同一親和組 中，比如負載均衡的Web伺服器、分散式計算伺服器等。

• 彈性伸縮

彈性伸縮是“雲”化的重點之一，主要功能是在基礎設施資源固定的情況下，平臺可根據使用者應用程式的需求對其在用資源進行自動擴充或回收，其實現包括Amazon簡單/分步擴充套件策略、阿里雲的彈性伸縮服務等，但這不代表它僅適用於公有云。一般來說，三大主要資源都可以進行彈性伸縮，但它們落實到具體物件上時則主要以虛擬機器例項（或者vCPU）數量、容器例項數量、網路質量、儲存讀寫質量等為單位（vCPU、記憶體熱插拔方式的伸縮目前由於作業系統支援受限，所以應用極少），可應用的場景主要有Web服務、分散式計算、儲存服務等依託LB（Load Balance，負載均衡）與HA的叢集服務（關於LB/HA的技術選型可參考第10章相關內容）。

以應用較多的Web服務為例，它的典型實現示意圖如圖2-22所示。

圖2-22 典型Web叢集服務實現示意圖

當Web服務閘道器收到請求以後，它會從LB叢集中選擇一個Web伺服器響應服務，此Web伺服器將與HA的資料庫服務互動以後再返回資訊給使用者。如果使用者請求過多，每個Web伺服器的資源用度超過上限閾值一定時間時，平臺就需要新建一臺Web伺服器並將其註冊到LB叢集中，如此以來新的請求便會被引導至新加入的Web伺服器上，從而使得叢集服務處理能力得以提高；反之，當多數伺服器的資源用度低於下限閾值超過一定時間時，平臺則會從LB叢集中移除一臺Web伺服器以節省資源佔用。

這個過程中的資源用度檢測、閾值設定、Web伺服器數量變化、LB伺服器的註冊與登出，即是由彈性伸縮服務所提供。

完善的彈性伸縮系統對於監測準確度、閾值選擇與設定、閾強度（即高於或低於閾值的持續時間）、響應時間（即伸縮條件被觸發後，Web伺服器建立/移除、註冊/登出過程消耗的總時間）、可伸縮叢集型別（Web服務、資料庫服務等）、防火牆（有效阻擋攻擊流量）等方面都有一定要求。以閾值選擇與設定為例，在實現是多以伺服器即時併發量、資源消耗等綜合考量，如果我們僅僅將指標設定為CPU用度，且閾值設定不合理的話，就可能發生如下現象：已知單位時間內使用者請求數一定，那麼當一個已經擴充套件的LB叢集整體資源用度低於縮減閾值時，則其中一臺Web伺服器會被移除，使用者請求被單臺伺服器全部接收導致其CPU利用率上升，如果此時擴充套件閾值過小系統則會再次向LB叢集中新增一臺伺服器使得CPU利用率再次下降，最後重複前面的步驟導致震盪發生，如圖2-23。

圖2-23 典型Web叢集服務實現示意圖

如果讀者對此部分設計有興趣可適當閱讀自動化相關書籍，比如《線性系統理論》、《現代控制系統》、《自動控制原理》等，雖然是面向電子電氣專業人員，但對IT從業者也頗具參考價值。

4、OpenStack基礎架構設計示例

基礎架構模型是需要根據業務模型設計的，接下來筆者以OpenStack基礎架構為例，首先介紹適用性較廣的通用型設計，然後以其為基礎擴充至計算或儲存密集型的設計。

另外，在部署工具的選擇上，筆者推薦初學者使用Mirantis Fuel或RedHat RDO部署OpenStack，它們都使用了自動化部署工具——Puppet，前者相對後者擁有友好的Web介面，所以使用者相對較多，在國內也有分支合資公司。

• 通用型設計

通用型設計即是指使用者需求不太明顯的情況，我們提供給使用者適用性較廣的架構以滿足其潛在需求。比如使用者在內網執行Web伺服器但不知何時會面向公網，或者使用者是為了某個專案進行實驗等等。這種設計所需要的OpenStack元件中，我們對使用者的潛在需求進行分析，然後選擇安裝儘可能多的元件。

• 儲存考慮

提供的儲存服務主要包括塊儲存與物件儲存兩部分。

塊儲存服務是整個架構的基礎，一般會直接部署Cinder管理塊儲存服務，其後端有很多商業儲存可供選擇，同時OpenStack也提供了針對商業儲存的外掛。如果沒有單獨的儲存裝置則考慮在各個伺服器上部署多副本的CephFS叢集，但伺服器上除系統盤外也要有額外的硬碟組RAID 5或6。如果使用者希望虛擬桌面的操作更流暢，或者他們需要頻繁地建立、刪除虛擬機器，可考慮劃分單獨的SSD儲存池用於虛擬機器映象儲存（Nova、Glance）。如果伺服器僅僅用作提供儲存服務，從筆者經驗來說採用高主頻、少核的CPU時價效比較高。

而使用物件儲存的目的有兩個，一是儲存部分虛擬機器模板映象，二是讓使用者將其作為網盤使用。儲存模板映象時，物件儲存架構比較簡單，Swift控制節點也可放入主控制器中；當作網盤使用時，那麼Swift閘道器伺服器就相當於一個Web伺服器，且使用者會話時間較長，此時如果併發有一定數量但未具備相當規模時，一般只需加強閘道器伺服器硬體與優化系統配置即可，如果要針對較大規模併發，則需要更改其架構，比如新增單獨的負載均衡裝置或者組成高可用叢集。

• 網路考慮

在設計基礎網路時，一般會針對不同的網路功能區域進行單獨設計。

OpenStack目前提供nova-network與neutron兩種網路後端，但前者在最近的版本中已被標記為“deprecated（拋棄）”，所以筆者推薦使用neutron以提高系統向後相容性與擴充套件性。

通用型設計中，網路一般劃分為公共網路、使用者網路、管理網路、儲存網路等。公共網路即是用於對外服務的網路，這些服務主要用於使用者訪問（Web、REST API、Spice），連線到這些網路的節點只有Controller、Swift閘道器、桌面協議代理閘道器等，同時LB叢集節點也會使用此網路。使用者網路即是使用者的虛擬機器或容器例項使用的內部網路，其IP地址位於“虛擬網段”中，或者是與物理交換機相連的“物理網段”中，一些在公共網路中的服務也可在此網路中以提高內部例項訪問服務的速度。管理網路即是管理硬體資源時使用的網路，管理員使用工具新增新節點時會賦予其管理網路所在網段的IP。儲存網路即是儲存節點所使用的網路，它對網路硬體的要求較高，包括頻寬、延遲、冗餘性等方面。

• 計算考慮

通常，計算節點所組成的叢集按照其邏輯功能或位置劃分為多個計算池，且每個池中的資源總量都由管理員定義，比如常駐桌面池、浮動桌面池、研發伺服器池、辦公伺服器池等。考慮到虛擬機器例項的可遷移性，同一池中的伺服器CPU配置（主頻適中、多核）都是相同的，同時伺服器都與需接入對應功能區域的網路。

虛擬化的基本特性之一是資源超分，即分配給虛擬機器的資源可以超過所在計算節點實際資源，CPU資源、記憶體資源在OpenStack中的比例預設為16:1、1.5:1。這些比例並不一定適用於實際環境，比如當CPU超分過多時，會導致部分虛擬機器因QEMU程式上下文切換成本過高而變得卡頓，當記憶體超分過多時，如果虛擬機器例項實際佔用的記憶體超過hypervisor的實體記憶體，則有可能發生交換（swap out）動作同樣導致部分虛擬機器效能下降。

與計算節點緊密相關的控制節點硬體配置一般不需要很高，可參考儲存閘道器節點配置。

• 架構示例

如圖2-23是以提供Web服務虛擬機器為主和物件儲存為輔服務的OpenStack架構。

儲存服務由單獨的儲存伺服器叢集提供，包括用於計算節點的塊儲存服務Cinder以及用於雲端儲存的物件儲存服務Swift。

網路部分的劃分筆者並沒有在圖中標註，但整體可進行如下劃分：外部業務網路包括防火牆、控制器、Swift閘道器、負載均衡閘道器（虛擬機器），伺服器網路包括控制器、Nova計算叢集，儲存網路包括CephFS儲存叢集、Nova計算叢集、Swift儲存閘道器，虛擬機器網路則專門用於虛擬機器。

計算服務池分為研發和業務，前者用於研發人員開發、測試、程式碼/專案管理等，後者則用於執行已經上線的Web服務。由虛擬機器組成的Web服務叢集接收來自負載均衡裝置分發的請求，再選擇Web伺服器予以響應。圖中的負載均衡閘道器是在虛擬機器內以軟體形式提供的，它和Web伺服器叢集的架構與傳統架構相同，因為管理員對後者更為熟悉。而高可用的控制器則保證了所有OpenStack元件控制元件的穩定性。由於使用者需求中物件儲存僅僅作為可選存在，所以此設計並沒有新增單獨的Swift儲存閘道器負載均衡措施。

圖2-23 提供Web服務虛擬機器、物件儲存服務為主的OpenStack架構示例

• 計算密集型設計

如果使用者的應用是在高效能運算（HPC）、網格計算（GRID）、圖文索引等非常依賴CPU效能的環境中時，我們可以對通用型稍作修改以完成應用計算密集型設計，而這其中又可以分別選擇Nova或者Magnum提供虛擬機器例項或容器例項，以隔離計算資源分別進行計算作業，從而構建出多租戶環境的PaaS平臺。

計算密集型的設計中，我們會盡量縮短I/O路徑以減少資料搬遷帶來的時間成本，且由於虛擬機器例項或容器例項很少有高可用需求，所以採用本地儲存將直接用於存放Nova虛擬機器例項映象與應用程式需要的檔案系統，比如HDFS。此時，網路劃分相對來說簡單一些，但是計算節點則需要擁有獨立的資料盤，採用OpenStack 基礎設施的Hadoop叢集架構如圖2-24所示，其中控制節點可選裝OpenStack大資料專案Sahara。

這種架構雖然犧牲了虛擬機器的遷移特性，但同時正因為這點我們便可以在Nova節點新增物理顯示卡並透傳至虛擬機器中，從而提高特定行業領域的分散式計算效能。

圖2-24 以OpenStack虛擬機器作為基礎設施的Hadoop叢集

由於虛擬化的效能較之物理機有輕微損失，所以有人考慮使用效能幾乎等同於物理機的容器執行分散式計算應用。筆者成文時原生Kubernetes、Docker Swarm、Mesos/Marathon組建的Docker叢集並沒有多租戶功能，而出現稍晚的OpenStack容器服務Magnum則可將Swarm與Kubernetes作為容器叢集后端，可同時利用Nova或者Heat提供容器模板，加之其原生的多租戶支援而越來越受人關注。其架構可參考圖2-25，其中使用Kubernetes作為容器叢集服務，兩個計算池分別用Nova和Heat提供的容器例項以適應不同的應用場景，其網路同樣由Kubernetes提供，儲存部分可參考上圖。

圖2-25 OpenStack Magnum參考架構

• 儲存密集型設計

儲存密集型的設計一般可將其理解為用於提供對外儲存服務的基礎架構，相當於一個獨立的儲存裝置，其中的Nova上的虛擬機器僅用作高可用儲存管理服務與負載均衡的Swift儲存閘道器，如圖2-26所示。

圖2-26 儲存密集型OpenStack架構

這個架構主要參考了一些儲存廠商的軟體設計，所有對外暴露的儲存服務都由管理入口進行控制，包括RBD、共享檔案系統、物件儲存以及基於它們二次構建的NFS、iSCSI、CIFS等。其中計算節點效能較弱，僅執行一些功能單一的虛擬機器，廠商的實現中甚至將包括控制器、管理入口在內的服務直接部署至儲存節點。

5、總結

私有云架構的基礎與傳統IT架構一樣，都是根據需求一步一步擴充套件。為了保證物理上難以的虛擬機器維護的虛擬機器穩定執行，我們要求資源的基礎架構具有穩定性、冗餘性和擴充套件性。當資源延伸到虛擬機器中使用以後，整個架構才開始變的靈活但又不易控制。此時需要我們採取安全防護和資源限制措施，以讓它在一個可控的環境中發展。當它發展到一定程度後，我們賦予其“雲”的屬性，比如資源池化、SLA管理等。至此，我們的基礎架構走向正軌，再經歷更多意外、新增更多實用技術，然後才變得更加成熟、穩定。

案例探討：

融合計算、儲存、網路和安全於一身的公司還未出現？看EMC技術大牛如何迴應 https://www.sohu.com/a/192561815_262201