第2章
企業雲計算涉及的技術選型和管理
在以AWS、Google、阿裡等為代表的公有雲發展的同時，很多大型企業出于資料安全性、系統穩定性、軟硬體自主權、對自主可控以及TCO（Total Cost of Ownership，總體擁有成本）低的考慮，更加傾向于建設企業私有雲來承載内部業務資訊系統的運作。
2.1 企業私有雲建設需求分析
在建設企業私有雲之前，首先需要回答和解決的問題是企業是否真的需要私有雲，以及需要什麼樣的私有雲?企業私有雲的建設是一個長期的系統工程，初始成本的投入也較為高昂。是以企業在建設私有雲之前，應從以下幾方面對需求和現狀進行評估。
1.需求和資源使用特點
例如，某大型企業的IT系統現狀：
□系統使用率低：煙囪式的系統建設部署方式導緻系統資源無法共享，系統負載不均衡，整體資源使用率和能耗效率低。
□建設擴容成本高：IT系統中原有的UNIX伺服器、資料庫和存儲陣列占比較高，标準化程度低，通用性差，導緻建設擴容成本難以控制，給系統統一維護帶來困難。
□擴充能力有限：系統的scale-up和scale-out能力不足，難以應對越來越大的系統處理和存儲壓力。
那麼針對以上現狀，如何通過雲計算來改變呢?首先我們需要的是：
□動态部署架構：建構基于标準化硬體裝置和虛拟化架構之上的雲計算基礎設施資源池，可對上層應用按需提供彈性資源，實作多系統有效共享，有效提高IT系統資源使用率和能耗效率。
□标準硬體單元：雲計算采用标準的運算和存儲處理單元，有效降低系統建設和擴容成本。
□高可擴充性：雲計算硬體叢集技術和軟體并行處理能力能夠提供出色的scale-out能力，幾乎無限擴充IT系統的處理和存儲能力。
通過引入雲計算技術可改變傳統資訊系統豎井式的建設模式，通過底層資源的共享與靈活排程可提升資源使用率，降低整體資訊系統建設成本，縮短資訊系統的建設周期。這些實作都是以資源使用特點為前提的。如果一個資訊系統本身無資源排程需求（如資源使用曲線較為平穩），或計劃由雲計算承載的資訊系統整體資源規模較小，資源共享和排程的空間有限，又或者特定的應用系統不支援分布式部署，無法進行橫向擴充甚至縱向擴充，對于此類資訊系統建設，則無法充分利用雲計算的優勢。是以對本企業的需求和現狀進行合理評估是非常必要的。
2.資訊系統的标準化程度
在雲計算環境中，資訊系統所具有的标準化程度往往是決定私有雲形态的重要因素。對資訊系統的标準化評估存在多個次元，包括基礎架構環境标準化（例如所需支撐的硬體是專用硬體還是通用硬體）、平台環境标準化（例如對于開發環境、中間件環境以及資料庫環境的通用需求和租戶限制），以及應用系統的标準化（例如應用系統的運作環境是否一緻、配置參數是否标準化、分布式環境下資料的一緻性等）。不同次元的标準化實作決定了企業私有雲應該建設為IaaS雲、PaaS雲抑或是SaaS雲。
□雲化建設/遷移的難度
将新的應用系統直接部署在雲計算環境中或将原有系統遷移到雲計算環境中是兩種主要資訊系統的雲化改造路徑，對其實作難度的評估是對應用系統進行雲化改造風險與收益評估的重要手段。整個業務系統的雲化分析過程需要從包括硬體支撐環境改造、作業系統平台變更、平台軟體綁定分析、IP位址依賴性消除、API重構、子產品化改造、标準化改造、外部依賴條件等在内的多個層面和次元進行，準确評估業務資訊系統雲化改造的相關難點與痛點，才能對資訊系統雲化改造有充分的認識和準備。
□關于成本的評估與考慮
大型企業建設私有雲往往會考慮定制化和一些業務特定的需求，其标準化程度往往低于公有雲，由此所帶來的自動化、運維、管理開銷會更高。最後，在傳統企業環境培養大量開發人才的要求也更高，工作技能、職能的轉變同樣需要成本的投入。
2.2 企業私有雲技術路線選擇
在大型企業建設私有雲時，一個重要的問題就是技術路線的選擇和成本價值産出。一般在進行私有雲技術路線選擇時，大型企業往往會把穩定性、成熟度、服務滿意達成度放在首位，那麼成熟穩定的商業解決方案就會被優先考慮，而開源的往往因為技術不夠成熟和穩定，是以不被優先考慮。下面拿VMware和OpenStack來做比較。
1.從産品設計上看
VMware軟體套件是自底向上的架構，下端邊界為虛拟機管理器。VMware的vSphere和vCloud director産品都依賴于ESXi虛拟機管理器。由于VMware産品架構的健壯性，很多高規格使用者在多資料中心規模的環境中都會使用該産品。但是VMware的軟體系統是封閉的，并且軟體的發展路線完全遵循VMware自己的發展目标，使用者或消費者在此方面沒有任何控制權。而OpenStack作為一個開源系統，沒有任何一家單獨的公司控制着OpenStack的發展路線。另外很多大公司都在支援OpenStack的發展，基于如此多公司的資源投入，OpenStack的發展是多元化的。然而這也帶來了問題，即OpenStack部署和架構的實施和維護成本較VMware有了陡然提高，與此同時，相對快速的版本更新速度導緻技術支援文檔無法跟上産品的腳步。
2.從高可用和容錯、資源平衡功能上看
在vSphere中，虛拟機級别的高可用性展現于允許在虛拟機或者ESXi主機出錯時，在不同主控端部署相同的虛拟機。高可用性即在硬體出問題時保證虛拟機的正常工作，當然如果真的出錯了，則隻能在不同的ESXi主機上啟動虛拟機，這也可能造成服務的中斷。FT（容錯）的主要功能就是保證在出現故障時使用者的應用不會出現中斷。其原理就是在兩台主機上建立一模一樣的兩台虛拟機—VM（主）與VM（輔助），VM（輔助）完全同步VM（主）的操作，當VM（主）發生故障時，VM（輔助）自動切換為VM（主）。FT可使應用程式實作零停機、零資料丢失，同時消除了傳統硬體或軟體叢集解決方案的成本和複雜性。另外VMware vSphere的分布式資源排程（DRS）可以聚合叢集中ESXi主機資源，通過監控使用率，自動配置設定這些資源給虛拟機，并能夠跨ESXi主機不斷進行虛拟機資源優化和平衡。
我們再看一下OpenStack的高可用性。目前并沒有官方聲明OpenStack支援虛拟機級别的高可用性，這個特性在Folsom版本被提出，但是後續又被放棄了。目前OpenStack有一個孵化項目Evacuate，其作用是為OpenStack提供虛拟機級别高可用支援。再看OpenStack 的容錯。在OpenStack中沒有針對容錯的功能，并且截至目前也沒有計劃完成這些功能。OpenStack也還沒有良好的資源自動平衡機制，截至目前OpenStack并未提供DRS功能，這屬于OpenStack功能缺失的一部分。我們可以看到，在功能支援和功能細節方面，OpenStack相較VMware還是有差距的，仍然需要不斷進步才能做得更好。
3.從成本和價值上看
VMware是商業軟體，其成熟度和穩定性經受住了大量實際環境的考驗，但使用成本高，展現在其授權費用和服務費用上。相對VMware的昂貴價格，OpenStack免費、開放的優勢還是很明顯的。對于VMware高投入帶來的功能，OpenStack大部分可以免費提供給客戶。那麼是OpenStack還是VMware更有價值？這個問題并沒有很清晰的答案，并且答案也取決于企業實際部署的規模。雖然OpenStack是免費使用的，但是它需要有專業的開發人員和此領域的專家才行，并且需要完成很多架構和搭建方面的工作，因為它支援很多部署場景，并且安裝過程都不盡相同。VMware則需要花費一些經費購買授權和服務，但相對來說更加容易安裝和運作，另外VMware的學習成本更低一些。
總的來說，基于以上分析，大型企業使用VMware則更穩定和可靠。而OpenStack入門門檻較高，如果企業沒有足夠的技術能力儲備則無法解決大面積部署OpenStack所遇到的問題。
2.3 計算資源管理
在企業IT基礎設施雲架構下，計算資源、存儲資源、網絡資源在統一的雲平台管理下被封裝整合成不同的資源池，以雲服務的方式提供給服務使用者。
雲計算在企業的落地涉及多個方面。除了資源池管理，還有監控管理、運維管理和雲服務管理，隻有相關方面關聯起來，才能真正讓雲計算在企業落到實處、發揮價值。
下面我們通過VMware和OpenStack這兩個比較常用的IaaS管理平台來看看它們在計算資源管理方面的具體技術和實作。
2.3.1 VMware
按照技術平台類型，計算資源池的組成可分為x86平台和非x86平台。非x86平台包含AIX小型機和HPUX等。在這裡x86平台則可具體分為VMware虛拟化平台架構和x86實體伺服器組成的資料叢集類架構。
1.資源池的分區
在企業級IT基礎設施環境中，為了保證風險可控以及業務安全性要求，從網絡上劃分了多個不同的安全區域。基礎架構網絡中，部署計算資源池一般有以下幾個分區：
□業務生産區：運作企業各類線上生産系統。
□開發測試區：友善開發測試的各類業務測試系統。
□管理區：部署各類管理用伺服器。
□實體區：部署各類資料庫和不友善虛拟化的實體伺服器。
□DMZ服務區：實作網際網路接入及部分需要連接配接網際網路的應用部署。
2.資源池部署規劃
為了滿足應用系統上線的需求，在相關區域中将選擇不同标準的計算資源池以進行部署，部署區域和資源池類型的對應關系見表2-1。
3.部署單元（主機和叢集）
具體來說，計算資源池（Resource Pool，RP）有兩種，CPU資源池和記憶體資源池。
圖2-1中一台EXSi主機有36GHz CPU資源和96GB可用記憶體資源，并且建立了兩個資源池。其中OA系統獲得1/3的資源，也就是12GHz CPU資源和32GB記憶體資源。HR系統獲得剩下的2/3的資源。
一個叢集（Cluster）的資源池包含叢集中所有主機（Host）的資源總和。比如一個8主機的叢集，每個主機都有32GHz CPU和64GB記憶體，那麼這個叢集的資源總和就是256GHz的CPU和512GB的記憶體。在這個叢集中建立的資源池就從這個總的可用資源中配置設定。
叢集的可用資源總是小于叢集的總資源，這是因為每台主機都會占用一部分CPU和記憶體資源，以留給自己的Hypervisor和OS使用。
雖然叢集資源池是所有主機資源的總和，但是并不意味着某一VM（虛拟機）可以使用超過某一台主機的資源。比如，兩台32GB記憶體的主機組成叢集，叢集中建立了一個64GB記憶體的資源池，但是任何單台VM都不能使用超過32GB的記憶體，因為VM不能跨主機使用資源，即VM的可用資源受到單台主機實體資源上限的影響。
另外一種情況：如果考慮VM的SWAP的話，這台大于32GB記憶體的VM可以被建立，也可以被運作。雖然這台VM不能跨主機使用資源，也就是它最多可以使用32GB的記憶體，但是别忘記它還有SWAP，是以，20GB的SWAP保證了Guest OS的運作。
同VM一樣，資源池也有份額（Shares）、預留（Reservation）和限制（Limit）這3個配置項，見圖2-2與圖2-3。
□限制
資源池的限制與VM的限制類似，不同的就是這個限制是資料池中所有VM可用實體資源的上限值。
雖然“限制”項不會限制VM的建立，但是它限定了可用實體資源，影響了資源池中運作的VM的性能。
□份額
資源池中的資源通常通過份額來配置設定，有3種預設的份額配置設定方式：High、Normal和Low，比重分别為4∶2∶1。反映在數字上則如表2-2所示。
比如說一個叢集有5個資源池：1個High、2個Normal、2個Low。那麼High資源池可以獲得4/ （4+2×2+1×2） = 40%的資源，Normal資源池各可以獲得20%，Low資源池各可以獲得10%資源。
資源池下可以建子資源池。資源按份額的比例配置設定。
□預留
資源池的Reservation（預留）不是決定其中的VM能用多少CPU/記憶體資源，而是配置設定給VM的Reservation使用的。如果資源池的可用預留不夠VM預留需要的量，VM将不能被啟動，或者正在運作中的VM不能被移動到該資源池中。這種檢查叫作準入控制（Admission Control）。
比如資源池中可用記憶體預留是1500MB。位于該資源池中的VM1和VM2的記憶體預留都是1024MB，當我們啟動VM1時可以正常啟動，但是再啟動VM2時，剩下的可用記憶體預留隻有476MB（小于1024MB），于是VM2無法啟動，使用者将收到“Insuff?icient Memory Resource”的報錯。
資源池有兩種類型：Fixed和Expandable。從圖2-2和圖2-3可以看出，CPU和記憶體資源都可以勾選“不受限制”（Expandable Reservation），預設是勾選的。如果手工去掉這個勾選，就可以更改為Fixed。
Fixed類型即其中的VM的Reservation隻能使用自己的預留資源，而Expandable類型就是不僅可以使用自己的預留資源，而且當資源池中的可用預留資源不夠VM使用的時候，可以使用父資源池中的。
VM開機時才會申請預留，關機時就把這部分預留還回資源池了。
RP（資源池）預留中的記憶體/CPU資源并非被這個RP獨占，而其他RP無法使用。如果某一個RP預留中的記憶體沒有被用完，則其他RP的VM還是可以使用這部分記憶體的。
例如，主機有3GB記憶體，在完全競争下RP1獲得1GB，RP2獲得2GB。RP1設定了1GB的預留，但是其中沒有VM。RP2中有且僅有一台VM并配置了2.5GB記憶體，運作一個消耗記憶體的程式，那麼這個VM可以獲得2.5GB的記憶體，其中0.5GB來自RP1，而無視其預留。
但是，增加某個RP的預留就減少了其他RP可以獲得的預留。
開啟一台VM所需要的實體記憶體，不僅與記憶體預留有關，也與記憶體開銷有關。當可用記憶體預留小于開啟一台VM的需求（等于記憶體預留和開銷的總和）時，VM就無法啟動。
2.3.2 OpenStack
OpenStack是一個能夠管理整個資料中心大量資源池（包括計算、存儲和網絡資源等）的雲作業系統。就計算資源來說，OpenStack可以規劃并管理大量虛拟機，進而允許企業或服務提供商按需提供計算資源；開發者可以通過OpenStack API通路計算資源進而建立雲應用，管理者與使用者則可以通過Web通路這些資源。在OpenStack中，計算服務是OpenStack的核心服務，它由Nova項目提供實作。Nova項目不包括任何虛拟化軟體；相反地，它通過各種插件與運作在主機上的底層虛拟化軟體進行對接，然後再向外提供API。
Nova包括以下四個核心子產品：
□Nova-api：向外提供OpenStack Compute API。
□Nova-conductor：資料庫通路。
□Nova-scheduler：将通過API進來的虛拟機建立請求排程到某個主機上。
□Nova-compute：通過調用主機上Hypervisor的API建立和控制虛拟機。
1.主機管理
為了更好地管理雲中的主機，OpenStack Nova引入了多個概念來對這些主機進行邏輯劃分，這些概念包括域（Region）、可用域（Availability Zone，AZ）、主機聚合域（Host Aggregates Zone，HAZ）等。
OpenStack通過引入Region（域）的概念，支援全球化部署，比如為了降低網絡延時，使用者可以選擇在特定的Region中部署服務。各個Region之間的計算資源、網絡資源、存儲資源都是獨立的，但所有Region共享賬戶使用者資訊，因為Keystone是實作OpenStack租戶使用者管理和認證功能的元件，是以Keystone全局唯一，所有Region共享一個Keystone，Keystone端點中存儲了通路各個Region的URL。
OpenStack引入了AZ的概念，其主要目的之一是基于可靠性考慮。AZ可以簡單地了解為一組節點的集合。在實際操作中，我們可以将具有獨立的電力供電裝置的一組節點劃分到一個AZ之中，比如将一個獨立供電的機架劃分為一個AZ。AZ由管理者建立，對使用者可見，比如使用者要運作某個有高可靠性要求的應用，那麼他可以在兩個不同的AZ之中分别建立一個虛拟機，然後在每個虛拟機中部署該應用，并使用負載均衡服務來連接配接這兩個虛拟機中的應用以對外提供可靠的服務。
HAZ也是把一批具有共同屬性的計算節點劃分到同一個Zone中，HAZ可以對AZ進一步細分，一個AZ可以有多個HAZ，一個HAZ也可以跨多個AZ。同一個HAZ下的機器都具有某種共同的屬性，比如高性能計算、高性能存儲（SSD）、高性能網絡（支援SR-IOV等）。HAZ和AZ的另一個不同之處在于HAZ對使用者不是明确可見的，使用者在建立虛拟機時不能像指定AZ一樣直接指定HAZ，但是可以通過在Instance Flavor中設定相關屬性，由Nova-scheduler根據排程政策排程到滿足該屬性的HAZ中。
這些概念組合起來，可以用圖2-4來表示。
比方說，某使用者有兩個機房，分别位于北京和上海，分别有100台和200台實體伺服器作為計算資源池，那麼可以使用表2-3中的方法來對這些伺服器進行劃分。
2.資源池管理
如圖2-5所示，Nova-scheduler服務通過運作在每個主機上的Nova-compute服務擷取主機的資訊并儲存在集中式資料庫中，形成一個虛拟計算資源池，這些資訊會被及時更新。管理者可以在OpenStack Dashboard（Horizon）或者使用Nova API/CLI來檢視資源池的情況。
如圖2-6所示，在彙總（Hypervisor Summary）部分，管理者可以看到整個資源池中的資源總數，包括vCPU、記憶體和本地磁盤等，以及這些資源已經被使用的數目；在清單部分，可以看到每個主機的詳細資訊，包括類型、vCPU數目、記憶體總量和已使用量、本地磁盤空間總量和已使用量、虛拟機數目等。管理者還可以通過Nova CLI擷取每一個Hypervisor在資料庫中儲存的詳細資訊。
3.資源池的使用
開發者、管理者和使用者通過Nova API和CLI或者在OpenStack Horizon上進行操作來建立虛拟機，每個虛拟機都會占用一定的計算資源，而計算資源占用的多少則是通過Nova Flavor來實作的。Nova Flavor是所要建立的虛拟機的規格，其中就包含了該虛拟機所要求的vCPU、記憶體、本地磁盤等計算資源的數目。如圖2-7所示。
4.資源的排程
當Nova-api服務接收到建立虛拟機的請求後，它會通過消息隊列将請求轉交給Nova-scheduler子產品，後者會根據在資料庫中儲存的整個環境中計算資源池的情況，按照請求中所要申請的資源，選擇一個最合适的主機來建立該虛拟機。
如圖2-8所示，Nova-scheduler的排程包括兩個子過程：
□過濾（filtering）：Nova根據管理者在配置檔案中所配置的過濾器（filter），對雲環境的所有主機進行逐一過濾，将滿足所有過濾器要求的主機選出來。
□權重（weighting）：對上一步驟中所有滿足要求的主機計算權重并以此排序進而得出一個最佳主機。計算主機權重的過程需要調用指定的各種Weigher Module以得到每個主機的權重值。
Nova中已經實作了很多過濾器，也支援使用者自定義的過濾器。Nova預設使用如下過濾器：
□RetryFilter：過濾掉之前已經嘗試排程過的主機。
□AvailabilityZoneFilter：過濾出在指定可用域中的主機。
□RamFilter：過濾出有足夠記憶體（RAM）的主機。
□CoreFilter：過濾出有足夠vCPU核的主機。
DiskFilter：過濾出有足夠根磁盤和臨時磁盤空間的主機。
□ComputeFilter：過濾出Nova-compute服務可用的主機。
□ComputeCapabilitiesFilter：過濾出滿足Flavor中指定的特定要求的主機。
□ImagePropertiesFilter：過濾出滿足虛拟機鏡像特定要求的主機。
每個主機隻有在滿足所配置的所有過濾條件後，才能進入權重階段。關于過濾器更詳細的資訊和可選的過濾器等内容，請參考OpenStack有關文檔。
5.虛拟機管理
如圖2-9所示，Nova-compute支援多種Hypervisor，通過使用不同的Hypervisor API來管理這些Hypervisor上的虛拟機。OpenStack通過Nova管理虛拟機，形成在雲範圍内的虛拟機資源池。
根據OpenStack社群2016年最新的一次使用者調查結果，目前，在生産和開發測試環境中使用的Hypervisor情況如圖2-10所示。
2.4 存儲資源管理
下面我們通過VMware和OpenStack這兩個比較常用的IaaS管理平台來看看它們在存儲資源管理方面的具體技術和實作。
2.4.1 VMware
1.存儲資源池設計
存儲資源池通常包含兩個部分：内部存儲和外部存儲。内部存儲指的是伺服器自帶的存儲媒體。外部存儲指的是伺服器之外的儲存設備，比如SAN、NAS等。一般伺服器内部的存儲媒體容量有限，企業私有雲資料中心主要使用的還是外部存儲。
2.存儲資源的選擇
在企業級資料中心，虛拟化和雲計算的大規模應用和深入對存儲系統的一個最大挑戰就是需要解決大規模虛拟機部署和業務上雲所帶來的存儲壓力和瓶頸。随着虛拟機數量的迅速增加，随機讀取的陡增和寫入I/O的爆發壓力不可避免，這就必然提高了整個系統對于儲存設備穩定性和I/O性能的要求。
虛拟化環境存在的典型性能問題包括性能瓶頸、混合負載的優化問題、激增流量性能問題等，下面進行具體描述。
□性能瓶頸
當主機對于存儲通路的需求超過儲存設備所能提供的性能時，就會出現性能瓶頸，這直接影響到主機上的應用性能。當将傳統儲存設備用于高度虛拟化環境、多個虛拟機的多個應用并行運作時，儲存設備将難以提供充足的性能來滿足實際運作要求。例如，一台伺服器上可以部署10個虛拟機，但由于後端存儲性能的限制，在實際業務過程中隻能滿足8個虛拟機的并行運作。
□混合負載的優化問題
虛拟化常常在混合負載環境下運作：有可能某一個虛拟機在傳輸大檔案時，另一個虛拟機卻在通路流媒體，而其他虛拟機則在運作某個業務的資料庫。在這種情況下，存儲陣列就會出現多個大的I/O順序讀寫和線上小I/O交易資料處理的并行運作，進而導緻存儲資源的争用。采用傳統存儲來處理混合負載問題不僅使性能調優變得更加困難，還會因為資源的争用導緻系統整體性能下降。
□激增流量性能問題
虛拟化和雲計算的工作負載常常是不可預測的，是以資料流量激增往往會導緻性能問題。随着虛拟化技術的提高和業務雲化的深入，單個實體機上運作的虛拟機和應用越來越多，我們難以預料在某個時刻某一應用是否會有突發的大流量産生。我們希望存儲能自動擴充，動态配置設定容量和性能，以滿足突發流量的各種需求。
除了需要考慮存儲的各種性能問題，對于存儲資源使用率的提高和優化也是建設存儲資源池時要考量的。在企業資料中心，雲環境下的存儲資源使用率一般從以下幾個方面來考慮。
□SLA（服務水準協定）級别的存儲資源使用率
在企業級資料中心和雲計算環境下，如何根據服務水準需求細粒度地動态配置資源，對SLA級别的存儲資源使用率起着決定性作用。
□配置存儲資源使用率
在傳統存儲中，配置的存儲容量中隻有很少一部分得到實際使用，剩下的大部分被預留用于未來的業務發展，這就導緻存儲資源使用率低下。同時，這些長期處于閑置狀态的存儲資源依然需要消耗存放空間、電力、散熱和維護資源。
□存儲容量使用率
由于我們無法準确預估一個業務的增長和所需求的存儲空間，一般在配置設定存儲資源時采用精簡配置。但是在資料保護和業務連續性過程中，一些自動精簡技術隻能實作配置過程的精簡，不能保證恢複過程的精簡，這就導緻存儲容量在資料恢複過程的浪費。另外，傳統存儲預配置造成的存儲容量浪費，在遠端複制、鏡像和快照等實作資料保護和業務連續性過程中得到進一步放大。
□虛拟機容量使用率
虛拟化可能帶來虛拟機蔓延和已配置的虛拟機空間閑置。此外，在測試和研發業務中，在項目完成且資料遷移後，為虛拟機配置的空間會導緻大量退役後虛拟機閑置資源的積累。如果無法有效回收這些閑置的存儲容量，不僅會造成虛拟化環境存儲成本的快速上升，也會導緻虛拟化環境營運成本的更大浪費。
3.存儲資源的設計方法
在一個企業級資料中心，基于雲計算和虛拟化環境對存儲資源進行設計時，首先要基于業務的需求，根據業務的規模和業務類型，通過采集基礎資料，整理出業務需要的存儲容量、性能和可用性級别要求，并根據預計使用的儲存設備的類型規格，計算出所需要的存儲資源配置。
存儲資源設計從資訊收集到輸出詳細的存儲資源配置方案經過如下幾個過程：
□擷取基礎資料
對于現有的業務應用伺服器，在資料增長量是可預計的情況下使用各種伺服器性能采集工具，通過采集一段時間的伺服器關鍵性能資料（如一個月），收集到對該業務具有關鍵作用的實體伺服器的CPU、記憶體、存儲、網絡、磁盤I/O等資料，以便準确充分地對存儲性能需求進行評估。
對于新添加的業務應用，如果對該業務的存儲資源、業務增長率有比較準确的估計，則可以根據這些資料，結合業務類型并依據業界通行的存儲性能估算方法，計算出該業務對存儲的性能需求。反之，如果對該業務的存儲資源、業務增長率沒有比較準确的估計，但其他企業已有大緻相同規模的同類應用，則可以參考業界對該類型伺服器的存儲需求，或采用對該業務進行開發測試的推薦存儲需求，作為該伺服器的存儲需求。
□方案設計
根據上一步驟擷取的存儲性能和容量資料，推薦使用的存儲類型、接口方式、RAID類型、磁盤類型等，相關資訊包括IP SAN或FC SAN的配置資訊、存儲機櫃的數量、存儲叢集的數量和每個叢集下LUN的數量。
其中IP SAN或FC SAN的配置資訊包括IP SAN或FC SAN的總數量，單台IP SAN或FC SAN的硬碟數量、硬碟類型，SAN的RAID類型、數量、熱備盤數量。
□存儲資源規劃
根據存儲方案設計，即可産生相關的存儲資源規劃。具體的規劃包括：
■SAN控制器的前端口位址
■存儲的RAID和LUN命名、容量大小
■LUN的條帶深度
■SAN主機和主機組的命名
■SAN辨別
■硬碟的劃分
■儲存設備的組網
例如，某資料中心SAN存儲資源池的規劃如下。
SAN的存儲資源池主要為資料庫和虛拟化兩類業務提供存儲空間，生産區采用EMC高端存儲和華為中端存儲來搭建存儲資源池，業務系統優先使用EMC高端存儲，開發測試區以華為中端存儲為主。根據業務需求通過雲管理平台對所有存儲資源進行統一的配置設定和回收，達到存儲資源高效利用的效果。
存儲資源劃分為三個服務層級，高性能層采用RAID1的SSD磁盤，為極端強調性能的資料庫提供存儲空間，并為資料庫的Redo Log提供存儲空間。性能層采用RAID1的SAS磁盤，主要提供給一般性能要求的資料庫應用。容量層采用RAID5的SAS磁盤，主要提供給虛拟機環境使用。存儲資源由存儲管理平台集中管理和排程，并提供API接口供雲管理平台進行資源納管。
2.4.2 OpenStack
除了計算資源以外，OpenStack還管理存儲資源。OpenStack可以為雲服務或雲應用提供所需的對象及塊存儲資源；因對性能及價格有需求，很多組織已經不能滿足于傳統的企業級存儲技術，而OpenStack可以根據使用者需要提供可配置的對象存儲或塊存儲功能。
在OpenStack私有雲環境中可能存在多種不同類型的存儲資源，比如傳統的企業級存儲和新興的軟體定義存儲，按照存儲類型可以分為塊存儲和對象存儲等。作為管理資料中心資源的雲作業系統，OpenStack通過Cinder和Swift項目來管理這兩種存儲資源。
如圖2-11所示，與Cinder相比，Swift有些不同，它是一個開源對象存儲項目，并不提供存儲虛拟化功能，是以，本節我們主要讨論Cinder。與Nova項目類似，Cinder服務本身也不提供存儲功能，而是通過虛拟化各種後端存儲形成虛拟存儲池，以供虛拟機和應用使用。
1.虛拟機對塊存儲的要求
Cinder是一個資源管理系統，負責向虛拟機提供持久塊存儲資源，它把不同的後端存儲進行封裝，向外提供統一的API，對卷進行管理并貫穿虛拟機的整個生命周期。如圖2-12所示。
Cinder的基本功能：
□建立卷
□從已有卷建立卷（克隆）
□擴充卷
□删除卷
□挂載卷到虛拟機
□從虛拟機上分離卷
□建立卷快照
□從已有卷快照建立卷
□删除卷快照
□從鏡像建立卷
□從卷建立鏡像
Cinder通過插件式驅動來支援不同的後端存儲，如圖2-13所示。
圖2-14是Cinder LVMiSCSIDriver的技術架構。
圖2-15是IBM SVC/DS8K/XIV Cinder驅動的技術架構。
圖2-16為預設的LVM驅動和第三方存儲驅動。
2.存儲池管理
Cinder-volume服務運作在存儲節點上，管理着存儲空間。每個存儲節點都有一個Volume Service，若幹個這樣的存儲節點聯合起來可以構成一個虛拟塊存儲資源池，如圖2-17所示。
OpenStack Cinder主要包括如下幾個子子產品（如圖2-18所示）：
□Cinder-api：提供Cinder REST API。
□Cinder-scheduler：将用戶端的卷建立請求排程到某個後端存儲上，其工作原理類似于Nova-scheduler。
□Cinder-volume：調用後端存儲的接口進行卷操作。
3.Volume Type和QoS
運作不同應用的虛拟機對存儲可能有不同要求，比如，對I/O要求高的虛拟機自然要求使用高I/O的後端存儲，對資料加密有要求的虛拟機則要求後端存儲支援卷加密功能，有些虛拟機則有QoS要求。一方面，Cinder-volume周期性地将後端存儲的功能和容量等資訊上報給Cinder-scheduler；另一方面，Cinder通過Volume Type功能來支援這種需求。
Volume Type是定義某個服務級别的标準的集合，它由雲管理者定義，使用者在建立卷的時候根據需要選擇使用某種Volume Type；帶有某種Volume Type的卷在被建立後也可以被修改。
舉個例子：如圖2-19所示，使用者需要建立一個SLA為“Silver”、大小為520GB的卷，他輸入大小和Volume Type；Cinder-scheduler則會根據該Volume Type中定義的存儲能力，找到一個滿足條件的後端存儲（Cinder backend），再将卷建立請求排程到該後端存儲對應的Cinder-volume服務上。
如圖2-20所示，Cinder支援兩種類型的QoS：
□一種是“front-end”類型，通過QEMU實作。
□一種是“back-end”類型，通過後端存儲實作。
使用者使用Cinder QoS的通常步驟是：
□建立一個QoS spec：cinder qos-create high_read_low_write consumer= "front-end" read_iops_sec=1000 write_iops_sec=10
□建立一個Volume Type：cinder type-create type1
□将QoS spec和Volume Type關聯起來：cinder qos-associate 9476d6a5-8903-4383-bb0a-bdc753843329 ca306ba5-fe9e-4b87-84b1-49823057c528
□建立一個使用上述Volume Type的卷：cinder create --display-name high-read-low-write-volume volume-type type1 100
□将卷挂載到某個虛拟機：nova volume-attach vm-1 high-read-low-write-volume/dev/vdb
2.5 網絡資源管理
下面我們通過VMware和OpenStack這兩個比較常用的IaaS管理平台來看看它們在網絡資源管理方面的具體技術和實作。
2.5.1 VMware
在企業級資料中心内，VMware由于管理和應用的不同要求，需要劃分多個不同的網絡區域，并需要考慮實體區域和邏輯區域的隔離。依據應用系統的要求，資料中心網絡邏輯區域劃分需要考慮如下原則：
1）根據安全架構，不同安全等級的網絡區域歸屬不同的邏輯區域。
2）不同功能的網絡區域歸屬不同的邏輯區域。
3）承載不同應用架構的網絡區域歸屬不同的邏輯區域。
4）區域總量不宜過多，各區域之間保持松耦合。
根據以上原則，網絡的邏輯區域可劃分為外網區和内網區。
□外網區：外網區根據功能的不同可劃分為網際網路和外聯網兩個區域。這兩個區域部署對外服務的應用系統，網際網路提供網際網路客戶的通路，部署Web網站、電子商務、學習環境等網際網路業務；外聯網提供第三方機構及大客戶的通路，部署外聯或托管等業務。
□内網區：内網區根據功能的不同又可劃分為網絡功能區、伺服器接入區和帶外管理區。
■網絡功能區：無伺服器部署，根據功能不同劃分為核心區和廣域網區兩個子區域。核心區提供各個子產品間的高速轉發功能，廣域網區負責資料中心與集團各網絡的互聯互通。
■伺服器接入區：負責各類應用伺服器的部署，根據功能的不同可分為主機接入區和開放服務區兩個子區域。主機接入區提供x86或其他小型機的接入環境。開放服務區提供開放伺服器的接入環境。在開放服務區，可根據不同的應用架構進行區域細分，即普通開放服務區、網絡管理安全區、存儲區和語音區。
■帶外管理區：這是一個特殊功能區域，負責伺服器和網絡裝置的帶外組網，也友善對伺服器和網絡裝置進行帶外管理和維護。
2.5.2 OpenStack
除了計算和存儲資源，OpenStack還能管理資料中心内的網絡資源。如今的資料中心存在大量裝置，如伺服器、網絡裝置、儲存設備、安全裝置等，而它們還将被劃分成更多的虛拟裝置或虛拟網絡；這會導緻IP位址的數量、路由配置、安全規則呈爆炸式增長；傳統的網絡管理技術無法真正地高擴充、高自動化地管理下一代網絡；因而OpenStack提供了插件式、可擴充、API驅動型的網絡及IP管理。
如圖2-21所示，一個标準的OpenStack網絡環境至少需要4個不同的資料中心網絡：
□管理網絡（management network）：用于OpenStack各元件之間的内部通信。該網絡内的IP位址必須隻能在資料中心内可通路。
□資料網絡（data network）：用于OpenStack雲内虛拟機之間的資料通信。
□外部網絡（external network）：用于向虛拟機提供網際網路通路。該網絡内的IP位址必須在網際網路上可通路。
□API網絡（API network）：提供OpenStack API通路的網絡。該網絡内的IP位址必須在網際網路上可通路。
對于内部網絡，OpenStack Networking項目Neutron提供了豐富的API來定義雲中的網絡連接配接。它的主要概念包括：
□Network：一段隔離的二層（L2）網段，類似于實體網絡中的VLAN。
□Port：将一個裝置比如虛拟機的一個網卡連接配接到一個虛拟網絡的連接配接點。
□Subnet：一段IPv4或者IPv6位址段，以及它們的配置狀态。
通過建立和配置網絡、端口和子網，開發者、管理者和租戶可以建立出豐富的OpenStack雲中網絡。
除此以外，OpenStack Neutron還提供了基于VR（Virtual Router，虛拟路由器）的VPN as a Service（VPN即服務），可以将兩個實體上分離但是由網際網路連接配接起來的兩個OpenStack子網通過VPN連接配接起來，并使得各自子網内的虛拟機可以互連互通。
2.6 監控管理
2.6.1 監控名額的設定和調整優化
當虛拟化和雲計算技術被企業和資料中心廣泛利用後，其對現有硬體提供更高的資源使用率和降低企業應用成本成為人們談論的焦點，通常實體伺服器的資源使用率隻有10%～20%，是以通過虛拟化整合資源使用率低的伺服器将非常有意義。
伺服器虛拟化技術在近幾年已經發生了根本性改變，現在虛拟化已經被視為資料中心實作靈活和彈性的必需品，虛拟化開銷較低的伺服器已經沒有太大意義，越來越多的組織開始虛拟化整個業務乃至資料中心，這樣組織可以将所有宿主伺服器看作一個計算資源池，實作按需配置設定資源。
為了确儲存儲和伺服器能應付不斷增長的業務需求，對磁盤資源、記憶體和CPU資源、宿主作業系統進行監控和調整是必要的。
1.磁盤資源
伺服器硬碟是磁盤資源中最慢的元件，在企業資料中心，注意仔細設計存儲子系統，不要讓它成為主要性能瓶頸，而最理想的辦法是使用SAN，即使預算不允許，也要想辦法確定磁盤資源争用不會導緻虛拟機（VM）癱瘓。
首先應将宿主作業系統安裝到專用硬碟上，注意不是專用卷，確定宿主作業系統不會與虛拟機搶奪磁盤資源。如果托管伺服器可以連接配接外置存儲，還可以考慮将宿主作業系統的分頁檔案移動到外置存儲的專用驅動器上。
RAID陣列是滿足虛拟伺服器性能所必需的，至少應該選擇使用RAID1，但“RAID1+RAID0”（RAID10）是更好的選擇，因為它能提供容錯，并且性能開銷也比RAID5小。如果可以的話，給每個虛拟伺服器配置設定一個專用磁盤陣列最好。
雖然存儲陣列類型很重要，但陣列使用的硬碟也同樣重要，如果兩個或更多虛拟伺服器共享一個存儲陣列，那麼應該考慮使用10k RPM的硬碟，它比7500 RPM的硬碟要貴一些，但性能表現卻要好很多，當然這需要使用者在性能和成本之間進行平衡。
另外不要忘了使用可熱插拔的SCSI硬碟，不然換一塊硬碟就得關閉系統，尤其是當多個虛拟服務共享一個存儲陣列時，其影響面非常大。
不管使用哪種儲存設備類型，都要確定已安裝了合适的驅動。比如可以讓Windows系統自動識别儲存設備，雖然這樣做本身并沒有問題，儲存設備也可能會工作得很正常，但性能表現就不是很理想了。
使用固定大小的虛拟硬碟來配置虛拟伺服器會獲得額外的性能提升。雖然動态擴充虛拟硬碟很友善，但對伺服器的性能是有影響的。
磁盤I/O性能監控的名額主要包括以下七個。
名額1：每秒I/O數（IOPS或TPS）
對于磁盤來說，一次磁盤的連續讀或者連續寫稱為一次磁盤I/O，磁盤的IOPS就是每秒磁盤連續讀次數和連續寫次數之和。當傳輸小塊不連續資料時，該名額有重要參考意義。
名額2：吞吐量
吞吐量即硬碟傳輸資料流的速度，傳輸資料為讀出資料和寫入資料的和。其機關一般為kbit/s、MB/s等。當傳輸大塊不連續資料時，該名額有重要參考作用。
名額3：平均I/O資料尺寸
平均I/O資料尺寸為吞吐量除以I/O數目，該名額對揭示磁盤使用模式有重要意義。一般來說，如果平均I/O資料尺寸小于32KB，可認為磁盤使用模式以随機存取為主；如果平均每次I/O資料尺寸大于32KB，可認為磁盤使用模式以順序存取為主。
名額4：磁盤活動時間百分比
磁盤處于活動時間的百分比即磁盤使用率，磁盤在資料傳輸和處理指令（如尋道）時處于活動狀态。磁盤使用率與資源争用程度成正比，與性能成反比。也就是說磁盤使用率越高，資源争用就越嚴重，性能就越差，響應時間就越長。一般來說，如果磁盤使用率超過70%，應用程序将花費較長的時間等待I/O完成，因為絕大多數程序在等待過程中被阻塞或休眠。
名額5：服務時間
服務時間即磁盤讀或寫操作執行的時間，包括尋道、旋轉時延和資料傳輸等時間。其大小一般與磁盤性能有關，CPU/記憶體的負荷也會對其有影響，請求過多也會間接導緻服務時間的增加。如果該值持續超過20ms，一般認為會對上層應用産生影響。
名額6：I/O等待隊列長度
I/O等待隊列長度即待處理的I/O請求數目，如果I/O請求壓力持續超出磁盤處理能力，該值将增加。如果單塊磁盤的隊列長度持續超過2，一般認為該磁盤存在I/O性能問題。需要注意的是，如果該磁盤為磁盤陣列虛拟的邏輯驅動器，需要再将該值除以組成這個邏輯驅動器的實際實體磁盤數目，以獲得平均單塊硬碟的I/O等待隊列長度。
名額7：等待時間
等待時間指磁盤讀或寫操作等待執行的時間，即在隊列中排隊的時間。如果I/O請求持續超出磁盤處理能力，意味着來不及處理的I/O請求不得不在隊列中等待較長時間。
通過監控以上名額，并将這些名額數值與曆史資料、經驗資料以及磁盤标稱值對比，必要時結合 CPU、記憶體、交換分區的使用狀況，不難發現磁盤I/O潛在或已經出現的問題。但如何避免和解決這些問題呢？這就需要利用磁盤I/O性能優化方面的知識和技術了。限于篇幅，在這裡僅列出一些常用的優化方法以供讀者參考：
1）調整資料布局，盡量将I/O請求較合理地配置設定到所有實體磁盤中。
2）對于RAID磁盤陣列，盡量使應用程式I/O等于條帶尺寸或者為條帶尺寸的倍數。并選取合适的RAID方式，如RAID10、RAID5。
3）增大磁盤驅動程式的隊列深度，但不要超出磁盤的處理能力，否則部分I/O請求會因為丢失而重新發出，這将會降低性能。
4）應用緩存技術減少應用存取磁盤的次數，緩存技術可應用在檔案系統級别或者應用程式級别。
5）由于大多數資料庫中已包括經優化後的緩存技術，資料庫I/O宜直接存取原始磁盤分區（raw partition）或者利用繞過檔案系統緩存的DIO（Direct I/O）技術。
6）利用記憶體讀寫帶寬遠比直接磁盤I/O操作性能優越的特點，将頻繁通路的檔案或資料置于記憶體中。
2.記憶體和CPU資源
實體記憶體是伺服器虛拟機容納數量的最大影響因素，應盡可能安裝最多的記憶體，最好是主機闆支援的記憶體上限。此外，應給虛拟機配置設定合适的記憶體，給宿主作業系統預留足夠的記憶體，避免記憶體不夠用或過度配置設定。
有些虛拟化産品不限制管理者過度配置設定伺服器的CPU資源，它們允許使用者配置設定比實體CPU核心還多的虛拟CPU給虛拟機。為了獲得最佳性能，宿主作業系統至少要預留兩個CPU核心，以確定配置設定的每個虛拟CPU都有對應的實體CPU核心，否則就會出現“資源赤字”。
請記住，這些建議是基于最佳性能角度考慮的。雖然有時可以配置設定比實體CPU核心還多的虛拟CPU給虛拟機，性能也能維持在一個可接受的水準，但它一定不是最優的狀态。一般建議CPU可以超配，但記憶體最好不要超配。
CPU和記憶體性能監控關鍵名額說明如下。
CPU使用率：指使用者程序與系統程序消耗的CPU時間百分比，長時間情況下一般可接受的上限不超過85%。
判斷CPU是否是瓶頸的方法：一般情況下當CPU滿負荷工作時，有時候并不能判定為CPU出現瓶頸，比如Linux總是試圖要CPU盡可能的繁忙，使得任務的吞吐量最大化，即CPU盡可能最大化使用。是以，一般主要從兩方面來判斷CPU是否為瓶頸：一是CPU空閑持續為0，二是運作隊列大于CPU核數（經驗值為3～4倍），即可判定存在瓶頸。CPU的高消耗主要由什麼引起的？可能是應用程式不合理，也可能是硬體資源不足，需要具體問題具體分析，比如問題由SQL語句引起，則需要跟蹤并優化引起CPU使用過高的SQL語句。
記憶體使用率：記憶體使用率=（1-空閑記憶體/總記憶體大小）×100%。
判斷記憶體是否是瓶頸的方法：一般至少有10%可用記憶體，記憶體使用率可接受上限為85%。當空閑記憶體變小時，系統開始頻繁地調動磁盤頁面檔案，空閑記憶體過小可能由記憶體不足或記憶體洩漏引起，需要根據系統實際情況監控分析和優化。
3.宿主作業系統
伺服器虛拟化優化常常被忽視的一個方向是宿主作業系統本身對硬體資源的需求。不是所有虛拟化産品都依賴于傳統的Windows伺服器作業系統。例如，Hyper-V伺服器是一個專門的、獨立的産品，它比完整的Windows伺服器作業系統的“身材”要小巧得多，是以它對硬體資源的需求就更少。
如果目标是最大化性能，那麼最好使用獨立的虛拟化産品，可以是VMware、Hyper-V或其他VMware類似的産品，但有時系統管理需求可能會要求你在宿主伺服器上運作傳統作業系統，在這種情況下，你可以采取一些措施來減少宿主作業系統的開銷。
首先，确定宿主作業系統中的哪些程序是必需的，哪些是可有可無的，哪些是應該停止的，在任何情況下，宿主作業系統都應該隻運作那些關鍵的應用，如備份代理或防病毒軟體，其他非必需應用應該關閉或解除安裝。
其次，確定宿主作業系統上的防病毒軟體不要掃描虛拟硬碟或與虛拟機相關的任何檔案。掃描這些檔案不但沒有實際意義，而且會對伺服器的性能造成影響，最糟糕的是，防病毒軟體還可能損壞虛拟硬碟檔案。
另一個優化技術是更改宿主作業系統的處理器排程方法，Windows伺服器提供了一個設定，允許你調整處理器排程以優先滿足運作中的程式或背景服務。對于虛拟主機，應該總是優先滿足背景服務的需要。
最後，如果宿主伺服器可以自動執行碎片整理，那麼應該将碎片整理程序安排在空閑時段執行。同樣，對虛拟機執行自動化碎片整理也應該安排在非高峰時段進行，同時要避免多個虛拟機同時執行碎片整理。
随着虛拟主機處理的負載越來越多，優化宿主伺服器的虛拟化性能變得比以往任何時候都重要，通過優化可以確定資源池得到最有效的利用。
2.6.2 統一運維監控平台和告警處理
建構一個統一的運維監控平台，必須以運作監控和故障報警這兩個方面為重點，将所有業務系統中所涉及的網絡資源、硬體資源、軟體資源、資料庫資源、存儲資源等都納入運維監控平台中，并通過消除管理軟體、資料采集手段的差别，對各種不同的資料來源實作統一管理、統一規範、統一處理、統一展現、統一使用者登入、統一權限控制，最終實作規範化、自動化、智能化的大運維管理。
統一運維監控平台的系統建設主要有以下3個要點：
□分層告警
在企業級資料中心中會存在多個檢測組，下層組織隻需要将關鍵告警資訊轉發到上層組織。當發生重大故障時，多級組織可以同時發現、分解、解決故障事件。為了減少層級間資料備援和節省鍊路帶寬，我們可以按級别、類型有針對性地進行資料轉發。
□監控資料同步
為了提高系統的可用性和業務連續性，我們可以在多個資料中心之間進行資料同步，當其中的監控中心發生故障時，其他備選監控中心可以暫時接管監控工作，當系統恢複時再切換到原有監控中心。
□全方位支援模式
企業級資料中心環境下的監控平台可能在不同的地理位置都有服務站點，這些站點可能跨時區、國家或地區。為了有效地監控系統并節省資源，我們可以在多個監控中心之間進行消息轉發。
如圖2-22所示，在每個資料中心都部署了分控中心，總部部署統一監控中心并與各分控中心保持實時聯系，實作告警資訊的統一收集、監控與分發。當資料中心1不在工作時間時，其所負責的資料中心告警将由統一監控平台負責分發到其他正在工作的分控資料中心，實作及時處理并達到最佳經濟效益。
下面具體介紹應用監控項以及告警處理。對于一個企業的私有雲來說，雲監控的應用監控項比較多，但大多數隻是警示性監控項，具體監控項的描述會在監控項輸出的時候歸檔成表，以下針對主要的兩個監控項進行說明。
1.Java程序監控及處理
該監控項在每個雲監控應用中都有設定，目的是實時監測應用的Java程序是否有關閉的情況，如果監控報警收到沒有Java程序，此時應用管理者應該檢視伺服器出現的狀況，通常情況下隻須重新開機應用即可。
2.端口監控及處理
雲監控各應用的運作涉及不同的端口，端口監控的目的就在于確定每一個端口的狀态正常，如果出現端口報警，一般情況下重新開機應用即可。如果出現重新開機應用解決不了的情況，須到伺服器上檢查網絡狀态，系統狀态以定位問題所在。
對于運維人員來說，不可能天天盯着資料報表，是以還需要對監控收集到的資料進行報警和處理。
例如，對每個需要監控的主機或服務設定一個合理的報警門檻值，當收集到的資料超過這個門檻值時，在第一時間自動報警并通知運維人員，反之，運維人員就可以做其他事情，而不用時刻盯着資料報表，這是建構智能監控報警平台必須要實作的一個功能。
對主機或服務的狀态值進行監控并當達到指定門檻值時進行報警，要實作這個功能并不難，寫一個簡單的shell腳本就能實作，但是維護性差，并且當需要監控報警的主機或服務越來越多時，腳本的性能就變得很差，管理起來也非常不友善，是以需要有一個專業的監控報警工具來實作這個功能，那麼擁有自動化的運維監控工具就非常有必要了。
2.7 運維管理
2.7.1 IT運維流程與規範
随着資訊化的飛速發展，IT資訊系統已成為支撐企業運作不可缺少的一部分，企業内部建立了各種資訊系統，如ERP系統、CRM系統、生産執行系統、辦公自動化系統等。目前，雖然資訊技術在企業中的應用得到了前所未有的重視，但是企業中普遍存在“重建設、輕運維”，“重技術、輕流程”等問題，導緻對IT運維工作投入不足，缺乏規範化的運維管理流程。其實從資訊系統的整個生命周期來看，實施建設隻占其生命周期的20%，而其餘80%的時間都是對其進行運作維護，是以運維階段是IT生命周期中的關鍵階段，如果IT的運維管理做得不好，那麼這些花費大筆投資建立起來的系統将無法帶來預期的效益。
由于缺乏規範的運維管理體系，導緻企業普遍存在以下問題：
□運維人員就像救火隊員一樣處于被動的服務狀态，隻有當問題已經發生後才進行緊急處理，不能預防問題的發生。
□缺乏統一的服務台，使用者請求随意性大，他們直接找有經驗的資訊人員，導緻能幹的人員成天處理無價值的瑣碎事情，價值無法有效展現。
□缺乏規範的運維制度和流程。在處理問題時，沒有對問題進行記錄和分類，導緻無法跟蹤和監控問題的處理情況。
□IT運維的相關經驗沒有積累和共享。由于缺乏對運維過程的記錄，使得問題的處理方法隻有當時的維護人員掌握，相關經驗難以積累和共享。
□運維人員績效無法量化。在運維工作中沒有建立量化的考核名額，IT運維品質和運維人員的績效無法量化，使得運維人員的工作積極性得不到提高。
是以實作運維管理從傳統被動式服務轉變為主動預防服務，以流程貫穿整個運維管理過程，實作運維管理的标準化、規範化和流程化是目前企業資訊化建設急需解決的問題。
那麼如何建立規範的IT運維流程與體系呢？從實踐來看，需要做好以下幾方面的工作。
1）标準化。比如說，我們資料中心經常要進行巡檢，不同的人巡檢，其效果是不一樣的，因為不一樣水準的人能夠發現的問題不盡相同。那麼針對硬體、小型機、x86、存儲等，做到這些環節的巡檢标準化，甚至可以用軟體來統一實作是否可行？經過近一年的努力，我們把巡檢标準化這個難題給解決了。現在不管哪個員工到現場，根據這份标準化流程和分析方法做出來的巡檢報告品質能保證水準基本一緻。從這件事情我們可以窺見标準化的重要性。
2）自動化。一旦能夠标準化了，下一步我們就可以考慮運維的自動化了。現在很多企業都在談論運維自動化，但如果企業運維的各種工具、平台、知識體系都不标準化，怎麼能做到自動化？即使做出來了，這種自動化也是虛的。在做運維自動化的過程中，企業采集了大量名額，做了大量的監控告警，但每天成百上千個告警跳出來，根本解決不完—這不是在做自動化，而是給我們的運維添亂、添堵，給運維人員造成巨大的精神壓力。是以說，考慮自動化之前，一定要先考慮運維标準化，當我們能把運維的一系列工作包括采集、分析、監控、操作等全部标準化了，自動化的問題也會迎刃而解。
3）可視化。自動化實作後還需要做可視化，為什麼呢？這是必須完成的一個環節，它可以把采集到的大量資料通過一種可視化方式表現出來，很好地把一些名額向運維人員展示并在一定程度上解放運維人員，降低運維成本。但是在做可視化的過程中，我們不能再走以前的老路。以前我們使用的運維自動化工具都是一些商業軟體，并且這些商業軟體通常是基于網管式方法，這些網管軟體面面俱到，但是不夠專業。舉個例子，比如說現在有一個業務系統，這個系統裡面有12個網絡裝置、90個伺服器，不同的人關注的點是不一樣的，但是專業的網管軟體隻能采集一套資料。是以這裡就涉及在引入可視化時，不單單要把資料展示出來，還要做到場景化運維。對于哪怕同一個拓撲圖，網管人員、安全人員和業務人員會根據自身關注的名額體系，看到不一樣的内容，即不同的人關注不同的場景。
當我們把前面所有步驟都完成了，後續就可以實踐智能化了，也就是引入大資料分析。通過大資料分析，我們能夠發現以前很多關注不到的問題，一些以我們的知識能力達不到的分析層面。至此，我們的運維流程和體系就逐漸完善起來了，同時智能化的大資料分析對我們的IT運維來說也是很好的補充。
2.7.2 自動化運維工具
開源或商業的自動化運維工具有很多，本書并不能一一枚舉。這裡隻對業内著名的開源配置自動化工具進行介紹。
Puppet：Puppet是一種Linux、UNIX、Windows平台的集中配置管理系統，使用自有的Puppet描述語言，可管理配置檔案、使用者、cron任務、軟體包、系統服務等。Puppet把這些系統實體稱為資源，Puppet的設計目标是簡化對這些資源的管理以及妥善處理資源間的依賴關系。Puppet采用C/S星狀結構，所有用戶端和一個或幾個伺服器互動。每個用戶端周期地（預設為半個小時）向伺服器發送請求，獲得其最新配置資訊，以保證與該配置資訊同步。Puppet使用一種模組化方法來配置自動化配置清單，通過推送的方式來更新所有伺服器。
Chef：該工具類似于Puppet，它也是使用程式設計腳本來實作伺服器、作業系統和應用軟體自動化部署和更新的。Chef使用Git程式設計語言，它能夠提供非常詳細和定制化的腳本，受到IT運維團隊的青睐。
Ansible：Ansible是一款基于Python的自動化運維工具，集合了衆多運維工具（Puppet、Chef）的優點，實作了批量系統配置、批量程式部署、批量運作指令等功能。管理節點上的Ansible将指令通過SSH協定（或者Kerberos、LDAP）推送到被管理節點上并執行指令，通過這種方式能夠在管理節點上控制一台或多台被管理節點，以執行安裝軟體、重新開機服務等指令。
Salt：Salt在配置自動化腳本或者部署應用軟體方面的功能類似于Puppet和Chef。你可以通過使用Python或PyDSL程式設計語言建立定制化的腳本或子產品，還可以下載下傳預制子產品。Salt的最大優勢在于其伸縮性和彈性能力。
Git：Git是一個開源的分布式版本控制系統，用于Linux核心開發的版本控制工具，可以有效、高速地處理從很小到非常大的項目版本管理。與常用的版本控制工具CVS、Subversion等不同，它采用了分布式版本庫的方式，不需要伺服器端軟體的支援（注：這需要區分使用的是什麼樣的伺服器端，使用HTTP協定或者Git協定等不太一樣。并且在push和pull時與伺服器端還是有互動的），使源代碼的釋出和交流極其友善。Git的速度很快，這對于諸如Linux Kernel這樣的大項目來說自然很重要。Git最為出色的是它的合并跟蹤（merge tracing）能力。
Foreman：Foreman是一個內建的資料中心生命周期管理工具，提供了服務開通、配置管理以及報告功能，與Puppet一樣，Foreman也是一個Ruby on Rails程式。與Puppet不同的是，Foreman更多地關注服務開通和管理資料中心的能力，如PXE啟動伺服器、DHCP伺服器及伺服器開通工具進行內建。Foreman可以與Puppet內建使用，通常是作為Puppet的前端接入。Foreman能夠通過Facter元件顯示系統目錄資訊，并且可以從Puppet主機報表中提供實時資訊，能夠自動化完成所有手工管理工作。Foreman還能夠管理大規模（當然也包括小規模）的企業級網絡，可能有很多域、子網和很多Puppet Master節點。Foreman也可以實作配置版本的回溯。
2.7.3 雲環境下的新型IT運維體系
在企業私有雲環境下，虛拟化通過資源優化整合，大幅降低了硬體投入、能源、資料中心的實體空間等成本，虛拟伺服器正在承擔着企業基礎甚至核心架構的重任。但虛拟化卻增加了IT運維的複雜性，加之很多企業都是重建設、輕運維，沒有理念的轉變和IT運維管理工具、運維政策的支撐，“後虛拟化時代”帶來的這些新問題将會使得IT部門麻煩重重。
據調查，很多企業中雲化的業務系統運作狀況并不樂觀。比如，IT部門優化了伺服器資源，但網絡資源卻沒有更新，一台實體伺服器向外連接配接的帶寬還與從前一樣，如果被虛拟化承載的多個業務系統是跨越多個實體實體機進行部署的，那麼網絡性能與交換機背闆帶寬将成為虛拟機流量交換的“短闆”，業務系統反而會因為虛拟化變得更加緩慢。是以，如果企業不能将業務系統裡的基礎資料導入IT運維最為關鍵的CMDB（配置管理資料庫）中，而迫不及待地點選“安裝”，等待他們的将是另一個危機陷阱。當然，我們也可以通過建立負載均衡來優化工作負載，或者對多個業務系統進行劃分，把高CPU高I/O、高CPU低
I/O、低CPU高I/O、低CPU低I/O的不同業務應用系統區分開來，并放到不同配置的實體實體機上或納入不同配置的資源池，以避免混亂劃分帶來的風險。随着每台實體伺服器上托管的虛拟機數量增多，資源的整體使用率提高了，但業務系統的潛在風險因大集中反而更高了，此時實體伺服器性能監測的重要性不言而喻。
如何建構雲環境下的IT運維體系呢？基于雲計算的彈性、靈活快速擴充、降低運維成本、自動化資源監控、多租戶環境等特性，雲環境下的運維需要從以下兩個方面來考慮。
1）改變現有的IT運維管理工具。
IT運維工具需要能夠管理IaaS平台。IaaS平台可以看作一個大型資料中心，它具有大型資料中心的異構化、虛拟化和大容量的特點，這要求管理雲計算的IT運維工具必須具有标準化、虛拟化和自動化的特點：
①通過标準的資料采集方式管理異構的雲平台。
②能夠監控和管理虛拟化的雲設施，包括虛拟伺服器、虛拟資料庫等。
③具有高度的自動化能力以完成對大量實體、虛拟裝置的監控管理并能主動發現潛在問題、及時進行告警。
2）為使用者提供SaaS模式的運維服務。
雲的到來無疑給中小企業帶來了利好消息，企業無須投入大量資金、人力進行運維管理平台體系的建設，隻須購買基于SaaS的運維管理服務，即可享受先進的運維管理工具和運維管理體系。基于雲的IT運維管理工具必須提供基于PaaS模式的标準軟體接口，使用者可以在雲上添加針對專業裝置的監控管理工具子產品或開發個性化的運維功能子產品，這樣既可以滿足自身業務的需求，也使雲運維管理工具日漸完善。
建構雲環境下的新型IT運維體系則需要注意以下三點：
1）打破原有各運維資源之間的分割，進行一體化監控和管理。
打破以往的運維分割，對複雜異構的IT資源環境（如網絡裝置、伺服器、存儲、安全裝置、作業系統、中間件、資料庫、業務系統、前端應用等）進行一體化監控和管理，保障IT基礎架構穩定可靠運作、降低系統和業務應用當機風險，實作提高運維效率和優化運維流程、控制運維成本的目标。
2）把安全管理作為體系架構的核心，針對資源池化的特點進行合理的控制與排程，實作資源的統一管理、安全運作。
在企業中，安全管理中心作為運維管理平台與資源池之間的連接配接紐帶，便于資訊安全管理的貫徹與落實；虛拟化資源池的建立可以實作IT系統對資源配置設定進行統一管理，同時，整合虛拟化管理平台則可實作統一運維管理。系統和應用的部署由人工操作變為模闆控制，大大減少了對內建商和運維人員的依賴；原有對基礎設施的維護分解為對實體機和虛拟系統的維護。當實體機或虛拟設施發生故障時，可調用不同的基礎設施來替換，降低了發生單點故障的可能性；事件、流程、人員與安全中心并列，形成對資源池的全面管理，實作了資源的統一管理和安全運作。
3）建立業務導向的一體化管理，實作高效運維。
雲計算體系下的運維目标首先應該以業務為導向，如新業務的快速部署、系統容量的平滑擴容、随需而變的資源配置設定等，根據業務目标形成IT服務的管理目标，保證IT服務達到要求的等級标準。其次通過自動化運維工具完成系統部署、配置管理以及監控報警等功能，降低故障發生率，提升故障發生後的響應處理效率，實作業務的快速恢複。最後通過改進運作維護服務能力管理過程中的不足，持續提升運作維護服務能力。
2.8 雲服務管理
2.8.1 雲服務的分類
雲服務主要分為三大類，從底向上依次為IaaS、PaaS和SaaS，每一類服務解決的問題都不一樣。
1.IaaS
基礎設施即服務（Infrastructure as a Service），是雲服務裡最重也是最基礎的一塊，經常提到的雲計算、雲存儲和CDN加速等都屬于這個領域。由于這個領域有資本密集的特征，相對中小雲服務公司，巨頭在這一塊的優勢是極其明顯的。國際市場上亞馬遜的AWS占據了該領域比較大的份額，國内是阿裡雲。而AWS和阿裡雲之是以能占有這麼高的份額，與它們的母公司都是電商公司有密不可分的關系。由于電子商務在海量資料、實時支付等處理上對速度有極高的要求，且對失敗的容忍度較低，同時還對安全性有嚴格要求，是以，電商公司内的許多部門在處理業務時會在不知不覺間産生各種對雲服務的需求。
現在的IaaS市場上，大的流程化的雲服務廠商會更多地提供基礎子產品化服務，由于巨大的前期投入，該領域不是一般小公司可承受的。但還是有部分創業公司，如七牛雲、Ucloud等，選擇從存儲、金融等一些細分垂直領域切入并做精做深，加上B端（企業）市場先付費的特性，是以仍然有不錯的營業收入。在達到一定量之後，可再探索一個有效的盈利模式。
2.PaaS
平台即服務（Platform as a Service），這個分類下已經誕生了上市公司Twilio，2015年其營收達1.669億美元，2016年一季度營收大增78%，上市首日即大漲92%，市值已經突破了35億美元。
由于不管是國外還是國内市場IaaS的競争大局将定，雲服務市場的變數可能更多地發生在PaaS和後面要提到的SaaS領域。PaaS的價值在于，它可以提供軟體開發（包括APP）所需的基礎功能子產品，特别是非核心但又有普遍需求的子產品，如通信、存儲、推送等。
相對于發展時間較長的IaaS和SaaS來說，國内的PaaS發展程度相對比較低，市場仍需培育，并且它不像AWS這樣的底層雲服務：客戶的資料存儲在亞馬遜的伺服器上，一旦開始用，很少會再進行遷移，這就是所謂的資料忠誠度。但如Uber、WhatsApp等公司，在使用Twilio服務的同時也會使用其他多家公司的服務，一旦一家公司出問題，可以立馬更換。
由于對于雲的需求服務開始像水、電、煤一樣變得常見，即插即用式的接入網絡就可以直接使用的定制化雲子產品依然有很大的市場需求，提供更多技術場景的綜合類PaaS公司将有機會迅速發展。
3.SaaS
軟體即服務（Software as a Service），這一領域可能是大家最熟悉的。雖然它主要還是面向企業的服務，但是仍有許多可以讓企業員工個人直接使用到的産品。國外比較有名的如由CRM起家的Salesforce等，國内比較有名的如做企業通信的釘釘（Ding Talk）和企業銷售管理的紛享銷客等。
與PaaS仍處在初期發展不同，SaaS已經紅火數年，并且關注度持續升溫。之前提到的PaaS領域的Twilio的市值才剛達35億美元，而Salesforce已經突破500億美元了。
除了CRM，SaaS領域還有許多細分領域，相對于OA、ERP和團隊協作軟體，由于CRM涉及銷售，是企業營收的根本，是以無論是國内還是國外，都是最早進入紅海競争的産品門類。
但是，雲服務市場發展到今天，這三個分類的分界線變得越來越模糊。
比如，做SaaS業務的Salesforce會收購一些PaaS公司，這樣一來，除了定制化軟體，它開始涉足定制化接口子產品業務了。而原本做IaaS的AWS，也在原來的業務基礎上疊加了PaaS甚至SaaS業務。國内的阿裡雲也是如此，推出了YunOS，包括旗下的釘釘也開始提供全部的三大類雲服務。
其中，PaaS創業企業的境遇最尴尬，一方面它們面臨着SaaS企業基于優勢業務拓展PaaS服務帶來的壓力，另一方面IaaS巨頭公司持續開放自家産品的功能，形成平台效應并成為PaaS創業企業的挑戰。
雖然PaaS公司做IaaS比較難，但它們可以利用自己在某些方面的技術優勢向SaaS領域發展，這樣更靠近使用者之後，不但豐富了自己的産品線，也提升了自己的盈利能力。
2.8.2 雲服務的建設
雲服務是雲計算環境的核心。在建構私有雲時企業往往會從自身的應用特點和需求出發進行服務的設計和實作，是以很難針對私有雲制定通用的服務模闆。依據雲計算建設的通用方法，對于雲服務的建設，一般來說會關注以下四個方面：
□雲服務的識别：雲服務的識别是雲服務實作的第一步，決定了在雲計算環境中将供給的服務内容。雲服務的識别是以需求調研為基礎的，從必要性、可複用性、實作成本等多個角度出發，分析服務實作的難點和收益，制定服務分階段實作的計劃與路線圖。
□雲服務的設計：在雲計算環境中對雲服務的使用模式決定了雲服務的設計要點，一般來說，對于雲服務的設計内容包括服務的底層架構、服務的運作流程、服務安全與監控、服務的審計與合規性檢查、評價服務能力的關鍵名額（KPI）、服務的高可用、服務的SLA等幾個方面。
□雲服務的實作：雲服務的實作一般有四種方式。一是從業務需求分析出發進行雲服務的定制開發;二是利用第三方軟硬體産品進行服務封裝;三是從其他雲計算營運商購買，合作實作;四是基于已有服務進行服務組合，形成新的服務。
□雲服務的維護：在雲服務上線後，對雲服務的運維是企業私有雲成敗的關鍵。雲服務的維護包括兩個方面。一是針對雲服務自身的維護，包括對服務能力和狀态的監控、對服務性能和規模的趨勢分析、服務的修正與更新、服務底層架構的維護等；二是服務的SLA達成度保障，包括實時監控服務的KPI并與SLA所規定的服務目标進行比較，在不符合SLA時及時幹預使其符合要求，同時確定滿足SLA所規定的安全、隔離等相關條款。
2.8.3 雲服務品質評估
從雲服務品質評估的角度來說，雲服務可以包含一項或多項核心服務和支援服務，如
圖2-23所示。核心服務是重點，它能滿足使用者的關鍵期望和需要。支援服務也是不可或缺的部分，它能推動和增強核心服務的服務。
1）可用性。從服務的角度來說，可用性是最重要的參數，它表示一個服務是否存在或者是否立即可用。服務可用性落實到具體的可以衡量的名額上來說，通常用百分比中的幾個9來表示。比如在雲廠商提供的SLA中會對各種類型的服務可用性進行承諾，如“××服務的可用性至少達到99.9%”。承諾中的99.9%就是我們常說的“3個9”級别，9越多代表可用性越高，計算公式為：
正常服務時間百分比% =（最大可用分鐘數-停機時間）÷最大可用分鐘數
含9越多代表停機時間越短，以年為例，計算清單如圖2-24所示。
服務可用性劃分了5個等級，從“2個9”到“6個9”。為什麼沒有90%，即“1個9”？因為“1個9”不在可用性範圍内。絕大多數企業在上雲之前其可用性均已超過99%，而第5級的“6個9”每年隻停機31秒堪稱完美，可惜要達到這個等級需要投入的代價非常昂貴，目前不具備可實施性，是以多數基于可用性等級考慮選擇均在“3個9”到“5個9”之間。企業可以根據業務特點并結合服務成本效益，來選擇合适的雲平台部署。
2）安全性。雲計算的優勢顯而易見，使用者将其IT應用系統轉移至雲端的同時也增大了風險性。在使用者使用雲計算服務後，雲服務提供者如何確定客戶資料的隐私性和安全性成為一個重要的課題。雲服務的安全性從客戶感覺的角度可以細化為資料的保密性、資料的完整性、業務的連續性、災難恢複這幾個評估角度。雲服務安全性評估還需結合國内相關法律法規和标準要求，對雲服務進行全方位的評測，以幫助企業有效提升雲服務安全水準、管理政策，同時降低安全風險、減少損失，保持企業的雲服務業務持續發展和競争優勢，維護企業的聲譽、品牌和客戶信任。
3）性能。性能是雲服務的重要品質衡量名額，包括提供的服務性能、客戶感覺的虛拟機性能以及雲計算業務提供的裝置性能。
4）易用性。雲服務的易用性需要從客戶使用的角度展開，比如各類資源是否友善申請和使用、配置更改和應用設定是否操作簡單和便捷。
5）可擴充性。可擴充性是雲基礎架構的一項重要特征。雲計算所具備的可擴充性可以讓使用者根據業務和資源需求的變化随意配置相應的裝置和資源等，比如增加計算資源、存儲容量、給帶寬擴容，以及不斷增加、減少不同規格的雲主機等，使得系統、裝置、資源等變得更加靈活可控。
6）可管理性。從客戶角度來看，具備良好可管理性的雲服務可以實作客戶便捷管理雲主機和相關産品的功能。是否具備運轉穩定、操作便捷、覆寫全面的統一管理平台是衡量雲服務可管理性的主要名額。
2.8.4 雲服務安全性和法規遵從
企業不使用公有雲而選擇自建私有雲的主要考慮就在于安全。資料表明，安全已經成為阻礙雲計算發展的最主要原因之一。根據CDA資料分析師協會統計，32%已經使用雲計算的組織和45%尚未使用雲計算的組織将雲安全作為進一步部署雲的最大障礙。
事實上，安全對于ICT而言并非全新課題，傳統的資訊系統架構同樣存在安全問題。隻是在雲計算環境中，由于采用了包括資源共享、打破資源孤島、多租戶等在内的新的營運模式，導緻錯誤容易蔓延，同時，由于涉及大量虛拟化和自動化等新的技術領域，往往會帶來新的技術風險點，是以，在雲計算環境中安全問題顯得尤為突出。
在雲計算體系中，安全涉及很多層面，一般來說，在雲計算環境中應主要考慮網絡安全、存儲安全、實體機安全、虛拟化安全、虛拟化管理安全、傳遞層安全、資料安全、安全服務和運維安全等9個層面和領域。
同樣需要注意的是，并非所有的應用安全問題都應該依賴于雲計算環境的安全架構來解決。雲計算基礎架構環境支援的系統種類衆多，業務要求和安全基線各有不同，在對使用者進行服務供給時應根據服務種類以及SLA對安全服務内容進行嚴格的規範，劃厘清晰的分工和責任界面。
ITIL v3定義的術語—服務水準協定（SLA），主要用以描述提供商和客戶之間的服務、文檔目标以及具體的職責。為了使其變成一個安全的術語，SLA應該為一個環境帶來透明度，能夠疊代變化并通過名額的使用加強自動化協作，以便維護互相之間的信任。
雲服務為客戶提供一個有用的資源，可以在基礎架構層證明其資源合規性，并對客戶确定合規責任提供了一些建議。然而，由于絕大多數合規工作需要由客戶完成，同時由于共同責任的模式，客戶一定要了解雲的服務細則。
考慮到這些，雲安全和法規遵從的關鍵點主要有以下三個：
□資産所有權：包含資料保管、控制、擁有和傳回權。
□服務可用性、監控和響應：旨在衡量與成本相關的領域以及持續性能力。
□服務基線：比如配置管理的法規遵從或者安全評估。
編寫一個雲服務的SLA要覆寫以上三個領域的風險，并且可以基于可用性水準、保密性和完整性來衡量。
2.9 小結
本章從企業雲計算涉及的技術選型和計算、存儲、網絡資源管理以及監控和運維、雲服務管理等方面，闡述了私有雲建設的一些實際問題，以幫助讀者更好地了解企業私有雲建設。