【文章內(nèi)容簡介】 份認證 系統(tǒng)可使用的總?cè)萘繛?340G，現(xiàn)已使用了 170G，使用率為 50%。 ? IBM DS5020 陣列上， 視頻服務器 可使用的總?cè)萘繛?1540G，現(xiàn)已使用了1530G，使用率為 97%； 防病毒系統(tǒng) 可使用的總?cè)萘繛?270G，現(xiàn)已使用了206G，使用率為 76%。 ? EMC CX340 陣列 上， 財務 系統(tǒng)可用總?cè)萘繛?941G，現(xiàn)已使用了 325G，使用率為 32%； 移動站業(yè)務管理系統(tǒng) 可用總?cè)萘繛?800G，現(xiàn)已使用了270G，使用率為 34%； 安全評估 系統(tǒng)可用總?cè)萘繛?600G，現(xiàn)已使用了305G，使用率為 51%。 ? EMC CX500 陣列上， 任務管理系統(tǒng) 可用總?cè)萘繛?120G，現(xiàn)已使用了 95G，使用率為 79%； 固定資產(chǎn)管理系統(tǒng) 可用總?cè)萘繛?300G，現(xiàn)已使用了 280G，使用率為 94%。 ? EMC CX4480 陣列上， 下載服務器 可用總?cè)萘繛?2020G，現(xiàn)已使用 了2020G，使用率為 100%； 生產(chǎn)經(jīng)營管理系統(tǒng) 可用總?cè)萘繛?980G，現(xiàn)已使用了 800G，使用率為 82%。 上述 存儲設備及其相應系統(tǒng)的容量與使用率情況如下 表 所示。 陣列名稱 使用系統(tǒng) 可用空間 已用空間 使用率 IBM DS4700 網(wǎng)管系統(tǒng) 1400G 800G 57% 郵件系統(tǒng) 1950G 900G 67% 人力資源系統(tǒng) 400G 400G 100% IBM FastT600 庫存管理系統(tǒng) 1340G 1340G 100% 身份認證系統(tǒng) 340G 170G 50% IBM DS5020 視頻服務器 1540G 1530G 97% 防病毒系統(tǒng) 270G 206G 76% EMC CX340 財務系統(tǒng) 941G 325% 32% 移動站業(yè)務管理系統(tǒng) 800G 270G 34% 安全評估 系統(tǒng) 600G 305G 51% EMC CX500 任務管理系統(tǒng) 120G 95G 79% 固定資產(chǎn)管理系統(tǒng) 300G 280G 94% EMC CX4480 下載 服務器 2020G 2020G 100% 8 生產(chǎn)經(jīng)營管理系統(tǒng) 980G 800G 82% 表： XXX 客戶 數(shù)據(jù)中心 存儲陣列 可見，目前 XXX 客戶的磁盤陣列劃分孤立、分散，造成了磁盤陣列的浪費以及數(shù)據(jù)的高風險性，而且十分不易于維護。隨著之后系統(tǒng)和數(shù)據(jù)量的不斷增加，這一現(xiàn)象將會持續(xù)加劇。 ? 現(xiàn)狀分析 通過對 XXX 客戶 服務器 和 存儲 現(xiàn)狀的分析，目前 IT 基礎架構(gòu)有以下幾個問題亟待解決： ? 資源孤立且利用率低下 ?，F(xiàn)有 數(shù)據(jù)中心中，計算、存儲以及網(wǎng)絡資源都是緊耦合的，也就是說數(shù)據(jù)中心內(nèi)的 IT 建設是煙囪式的，根據(jù)客戶需求一個項目建設一套系統(tǒng)，這樣便形成了一個個的 ―項目孤島 ‖ 。這種系統(tǒng)牽一發(fā)而動全身，很難作任何改變，擴展起來要對系統(tǒng)進行重新設計。在這種環(huán)境下，系統(tǒng)之間無法相互通信，資源不能在整個數(shù)據(jù)中心里實時、動態(tài)調(diào)度與共享，這樣便使服務器與存儲以及網(wǎng)絡資源得不到充分利用，各種資源的利用效率全面低下。 ? 服務器和存儲購置成本高，維護成本遞增。隨著 應用的不斷增加， 服務器數(shù)量 也跟著 增加，每年要支出高額購置費用不說，還有 部分 服務器已經(jīng)過保修期，部件逐漸進入老化期，維護、維修預算費用也逐年增加 。 ? 能源消耗巨大。當前數(shù)據(jù)中心存在 海量的能源消耗和惱人的散熱問題，這也成為數(shù)據(jù)中心發(fā)展的一大瓶 頸。目前電力和數(shù)據(jù)中心輔助設施的成本已經(jīng)超過了購買 IT 設備的費用，電力能耗占到數(shù)據(jù)中心整體成本中的 50%以上。 ? 可 用 性 低下 。 首先 ，幾乎每個應用服務器都是單機，如果 某 臺服務器出現(xiàn)故障，相對應的業(yè)務也將中斷。其次是 當硬件需要維護、升級或出現(xiàn)硬件故障時，上層業(yè)務系統(tǒng)均會出現(xiàn)較長時間的中斷，影響業(yè)務的連續(xù)性， 其中包括一些重要業(yè)務系統(tǒng)，一旦中斷服務影響很大 ，未來數(shù)據(jù)中心搬遷時會更加麻煩。 ? 兼容性差。系統(tǒng)和應用遷移到其他服務器，需要和舊系統(tǒng)兼容的系統(tǒng)。新的軟件包括操作系統(tǒng)和應用軟件無法運行在老的硬件平臺，而老的代碼有時候也很難移植到新的硬件平臺上。例如： 由于各種資源數(shù)據(jù)庫不同 公司分別開發(fā) ，需要的運行的軟硬平臺很多時候不能保證兼容。 為節(jié)省時間、物力和保持 系統(tǒng)部署的順利 ，只能用增加服務器 單獨部署的 方法來解決。 ? 資源配置與 運維管理 的 成本 非常 高昂且 效率低下。 現(xiàn)有數(shù)據(jù)中心的資源配置與部署大多采用人工方式，沒有對應平臺的支撐，沒有自動化的部署。這種管理方式首先會增加人力成本，耗費大量人力在繁重的工作上，這 使得管理費用成為機構(gòu)的沉重負擔。其次，這種管理方式會導致出錯率高，效率底下，靈活性低等后果 ，同時，在性能調(diào)優(yōu)，容量管理方面，這種管理方式的效率也是非常低下的 。 ? 對業(yè)務需求無法做到及時響應，靈活性差。當有新的應用需要部署時，需要重新部署服務器，存儲系統(tǒng)，并需要對網(wǎng)絡系統(tǒng)進行調(diào)整以適應新的 IT 應用的需求，因此， 運維管理人員無法快速高效地響應業(yè)務部門提出的各種要 9 求。同時，部署實施新應用的周期比較長、成本也很高，這往往會延誤新應用和新產(chǎn)品上市的時間，進而使企業(yè)失去了許多寶貴的商機 。 虛擬化 技術 在一定程度上緩解了上述問題帶來的影響，例如，服務器虛擬化可以幫助數(shù)據(jù)中心減少物理服務器的數(shù)量，進而使企業(yè)在電源、散熱以及機房面積上節(jié)省巨大的成本。此外，它還可以減少數(shù)據(jù)中心 UPS 和網(wǎng)絡設備的費用以及所占用的空間，同時還可以大幅減少管理物理服務器的寶貴時間，提高部署服務器的效率。 但是， 僅僅 依靠 服務器虛擬化還是遠遠不能 充分 解決上述這些難題的， 這主要體現(xiàn)在如下四 個方面。 1) 現(xiàn)有 網(wǎng)絡與安全 體系結(jié)構(gòu)對虛擬化環(huán)境產(chǎn)生束縛 雖然服務器虛擬化的普及徹底改變了應用的調(diào)配和管理，但是，這些動態(tài)工作負載所連接的網(wǎng)絡 和存儲等周邊資 源 卻未能跟上它的發(fā)展步伐。 這些資源的 調(diào)配仍然極其緩慢，甚至一個簡單的拓撲結(jié)構(gòu)的創(chuàng)建也需要數(shù)天或數(shù)周時間。下圖給出了一個典型的示例。 圖：服務器虛擬化后部署一臺服務器所需的時間 從上面這張圖可以看出，在服務器虛擬化之前，管理員部署一臺服務器需要大概數(shù)周時間并花費上萬美金。有了服務器虛擬化后，雖然部署一臺虛擬機只需要幾分鐘且僅花費幾百美金，但是，在該虛擬機 ―周邊 ‖部署所需的各種網(wǎng)絡安全以及存儲等設備仍需數(shù)天的時間，同時耗費數(shù)千美金。可見， 雖然服務器虛擬化可以加快虛擬機的部署，但是與之相連接的網(wǎng)絡 安全以及存儲等組件并沒有跟上服務器虛擬化的步伐 ， 它們嚴重影響了虛擬數(shù)據(jù)中心的部署效率。 傳統(tǒng)的網(wǎng)絡與安全體系結(jié)構(gòu)除了會降低虛擬數(shù) 據(jù)中心的部署效率，在虛擬化環(huán)境下，它們還存在很多其他方面的不足 ， 下圖給出了現(xiàn)有的網(wǎng)絡架構(gòu)在虛擬化環(huán)境下存在的一些缺陷。 10 圖 ： 現(xiàn)有的網(wǎng)絡架構(gòu)對虛擬 化環(huán)境產(chǎn)生 束縛 現(xiàn)有的網(wǎng)絡體系結(jié)構(gòu)對底層物理硬件有很大的依賴，他們依賴于專用物理設備，因此靈活性很差。另外，由于各種網(wǎng)絡服務的管理界面雜亂無章，非常分散，無法進行統(tǒng)一的集中管理，因此，相應的運維管理工作非常復雜且容易出錯。 除此之外，這種不靈活的體系結(jié)構(gòu)對工作負載和應用的擴展與遷移都產(chǎn)生了很大的限制。在安全方面，傳統(tǒng)的安全防護手段價格昂貴，對虛擬化平臺不具感知能力，使用不夠靈活，管理難度大，不能很好地滿足新架構(gòu)的需要 。 由此可以看出，現(xiàn)有網(wǎng)絡與安全體系結(jié)構(gòu)的限制將日益池化的動態(tài)虛擬世界重新束縛到缺乏靈活性的專用硬件上，人為地阻礙了虛擬數(shù)據(jù)中心的發(fā)展。 2) 傳統(tǒng) 可用性與災難恢復 解決方案在虛擬化環(huán)境下難以應用 雖然業(yè)務可用性與災難 恢復技術已經(jīng)有了很多年的發(fā)展，但是傳統(tǒng)的解決方案還是存在很多的問題 ，這使得現(xiàn)有的可用性與災難恢復技術在虛擬化環(huán)境下更是難以得到很好地應用 ，這些問題具體如下 。 首先，傳統(tǒng)的可用性解決方案是利用特定于應用的解決方案（如： Oracle RAC、MS SQL 集群、 Exchange Database Access Groups (DAG)等）在應用級別實施業(yè)務可用性。雖然這種方法通常可以提供不錯的可用性，但是由于每一組應用都有自己的解決方案，因此這種方法有如下弊端： ? 復雜且昂貴 ? 對管理員的技術要求較高 ? 出錯的風險大 ? 許可證較貴 (如 RAC) ? 專用的備份架構(gòu) 其次，雖然有一些基礎架構(gòu)層 的解決方案可以比應用級解決方案更加經(jīng)濟高效，但是這些解決方案往往在正常運行時間和 RTO（恢復時間目標）方面表現(xiàn)得比較差。 11 除此之外，傳統(tǒng)的 災難恢復 解決方案很 難在 現(xiàn)有 的物理 X86 環(huán)境中實現(xiàn) ，這是因為 傳統(tǒng)的災難恢復計劃依賴于一套非常復雜的流程和基礎架構(gòu) ，操作起來非常復雜繁瑣且容易出錯。 可見，傳統(tǒng)的可用性與災難恢復解決方案存在的諸多弊端使其很難在真正的生產(chǎn)環(huán)境中達到業(yè)務高可用與災難恢復的功能， 在虛擬化環(huán)境下就更是如此， 因此，一套專門針對虛擬化環(huán)境的切實可行的可用性與災難恢復技術成為必須。 3) 傳統(tǒng) 運維管理 方式 無法適應全新的動態(tài)虛擬化環(huán)境 在運維管理方面， 雖然服務器虛擬化可以解決 XXX 客戶現(xiàn)有數(shù)據(jù)中心的某些 問題，但隨著虛擬化的引入，現(xiàn)有的傳統(tǒng)運維管理方式已經(jīng)不能滿足虛擬化環(huán)境對運維管理的需求，現(xiàn)有的這些運維方法在新環(huán)境下存在諸多的 挑戰(zhàn)，使用起來也將顯得捉襟見肘，這是因為 現(xiàn)有的 傳統(tǒng)管理工具和方法是為了支持孤立的計算環(huán)境而設計的， 因此IT 團隊面臨著如何利用傳統(tǒng)管理工具和方法有效地支持新的動態(tài) IT 基礎設施 （虛擬化環(huán)境） 的挑戰(zhàn)， 這些挑戰(zhàn)主要包括 如下四個方面。 第一 ， 虛擬化 環(huán)境中有大量 的 數(shù)據(jù)需要管理，相對于物理環(huán)境而言， 管理員可管理的虛擬機數(shù)量要多出達 5~10 倍，服務器和變更的數(shù)量也明顯增多。這些都使得 IT專業(yè)人員在嘗試部署新的虛擬化管理計劃時要面對重重困難。 同時，環(huán)境中的偽警報數(shù)量大幅度增加，使得客戶非常難以應對其環(huán)境所面臨的挑戰(zhàn)和性能問題。 現(xiàn)有的運維管理方法已經(jīng)無法保證管理員可以高效地管理如此大量的數(shù)據(jù)并對問題做出快速地響應。因此，新的運維管理方法需要提供整個 基礎架構(gòu)和應用 的 運行狀況、風險和效率的全面 可見性，并可以提高管理員對問題的響應速度。 圖： 當前的傳統(tǒng) 運維 管理方式 第二， 對于虛擬化平臺的管理員而言，工作中遇 到的問題大多是性能方面的問題，處理性能問題所花費的精力大約占到全部管理任務的 80%，要迅速定位并解決性能問題，需要 高效 的工具來輔助，單純地使用 ―紅黃綠 ‖三色交通燈的性能指示 是無法迅速地解決這些性能問題的。因此，這就需要一種 主動管理基礎架構(gòu)和應用性能 而不是被動監(jiān)控的解決方案 。 12 第三 ，管理員在使用虛擬化平臺時會面對兩個對立的目標：一方面，要盡可能地增加虛擬機的密度以充分利用硬件平臺的處理能力，增加投資回報。另一方面，虛擬化的主要特征就是資源池化，資源整合以后，調(diào)配資源的靈活性大大提高，但同時也對性能和容量的管理帶來了更大的挑戰(zhàn)，如果不能有效地管理資源分配，則可能出現(xiàn)資源濫用，資源匱乏等情況 。實際的生產(chǎn)環(huán)境中一個比較常見的問題 就是 容量 “ 過度調(diào)配 ”和硬件利用率低下 ，它會損害組織最初在節(jié)約成本方面尋求的核心價值， 同時它 還會使組織無法實現(xiàn)最初部署虛擬化和云計算時所尋求的敏捷性。 因此，這就需要推 動更高的整合率， 管理員需要隨時保證業(yè)務增長對性能和容量的要求。 第四 ，現(xiàn)有的運維模式容易導致大家相互指責，同時無法迅速查明問題的源頭、在哪方面需要立即采取措施，以及如何盡快恢復服務。 為了解決這個問題，新的運維管理方法應該能夠幫助管理員高效地定位問題的根源，它應該可以快速地縮小問題的范圍，迅速定位問題所屬的范疇，例如：計算，存儲，網(wǎng)絡等。 4) 云計算數(shù)據(jù)中心需要全新的 服務調(diào)配 方法 在服務調(diào)配方面， 目前沒有 一種自動化的方法來為業(yè)務提供所需資源 ， 進而 導致調(diào)配延遲 ， 同時無法 提供自助服務 給終端用戶 來滿足常規(guī)需求。 圖：傳統(tǒng)服務調(diào)配 當前企業(yè)環(huán)境中， IT 的運營有許多帶來浪費、低效率和客戶不滿意的通病 ， 傳統(tǒng)的管理模式無法滿足動態(tài)變化的虛擬化和云環(huán)境。傳統(tǒng)的垂直豎井式管理把特定應用和基礎架構(gòu)捆綁在一起，這種方式脆弱且不便管理。 為了增加業(yè)務敏捷性，許多企業(yè)希望縮短由豎井式的手動操作導致的冗長的服務響應時間，由于操作的不靈活， IT 專家經(jīng)常需要數(shù)天甚至數(shù)周來交付急需的資源和應用。 此外，應用開發(fā)較以往任何時期都要發(fā)展迅速，功能每日都會更新，規(guī)模每小時都在改變，因此，用戶需求帶來的持續(xù)壓力使得應用所有者面臨著始終如一的快速變更率。云計算使應用所有者可以即時訪問基礎架構(gòu)，然而構(gòu)建應用程序仍需管理員在各個虛擬機上分別安裝和配置應用程序組件，以便插入到應用體系結(jié)構(gòu)中。在當下的云計算時代中，企業(yè)和組織需要更行之有效的跨云加快應用部署速度的方法。 同時， 隨著業(yè)務的快速增長，企業(yè) 需要 一個更快部署系統(tǒng)來創(chuàng)造商業(yè)機會，快速響應市場需求和提高生產(chǎn)力的方法。 此外， 以提高 IT 效率和優(yōu)化資源使用率的方式削 13 減成 本也是越來越多的 IT 部門開始尋求云基礎設施的重要原因。最后， IT 的消費者希望像獲得他們生活中的自助服務和應用一樣方便地獲得企業(yè)的 IT 基礎資源服務。 可見，