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