《VMware vSphere設計（原書第2版）》——1.4 設計流程

本節書摘來自華章出版社《vmware vsphere設計（原書第2版）》一 書中的第1章，第1.4節，作者：[美] 福布斯·格思裡（forbes guthrie）斯科特·羅威（scott lowe）肯德裡克·科爾曼（kendrick coleman），更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

既然已經讨論了設計的三個層面和5個基本原則，那麼是時候介紹設計流程了。本節将介紹如何進行vmware vsphere設計，其中要完成哪些任務，以及要完成這些任務需要使用什麼工具。

我們在前面提到過，vsphere設計最重要的就是功能需求。那麼從功能需求開始介紹設計流程。

功能需求是vsphere設計的基礎和驅動力。大多數設計決策都是基于或者受制于功能需求的，是以在收集和定義功能需求階段，應該盡可能實作功能需求的全面性和完整性。

很多時候，有些功能需求是不需要收集的。例如，組織準備應用vmware vsphere來達到整合的目的，功能需求可能已經描述得很清楚，比如：用虛拟化環境實作整合後，其承載能力應相當于250台實體伺服器。這樣就不需要再定義這個需求了（但是，在設計中實作這個功能需求還是要花些心思的）。

根據我們的經驗，有現成功能需求的情況并不常見。是以，我們不得不自己收集并定義功能需求。收集功能需求主要有兩種方式：

閱讀文檔。

采訪。

　你可以這麼認為：vmware定義的通過采訪來收集資訊的方式是一種咨詢性方法。

閱讀文檔

有時候，實施vmware vsphere的客戶或機關有概述功能需求的文檔。虛拟化的實施是為了實作一個目标（去“做什麼”），這個文檔就記錄了組織大概想要實作什麼。例如，實施虛拟化是其桌面虛拟化目标的一部分，這樣vmware vsphere環境的一些功能需求就可以直接從為桌面虛拟化項目準備的文檔中得到。如果桌面虛拟化文檔中有規定：在host故障的時候，vmware vsphere環境可以自動重新開機桌面虛拟機，那麼這就相當于給你提了個醒：你的vsphere環境需要使用vsphere ha來滿足這個需求。而且，因為使用vsphere ha，就必然會用到叢集，這就意味着還需要備援管理，而備援管理又影響到了網絡設計…如此，牽一發而動全身。

再舉個例子，假設組織要将現有的資料中心遷移到一個新的資料中心，并已經在文檔中列出了需要遷移的應用。你可以通過這個文檔了解各個應用都有什麼要求，然後制定必要的功能需求來實作這些要求。文檔中很可能還指出了i/o profile主要是寫而不是讀，而且應用還需要每秒鐘維持一定數量的事務處理（transactions per second，tps）。将這個資訊轉化為存儲需求就是raid級别，陣列類型，存儲協定和每秒進行讀寫的操作次數（i/o operations per second，iops）。

雖然閱讀文檔對挖掘需求很有幫助，但是不可能在文檔中得到所有資訊。如果這個機關和其他機關一樣，文檔稀少且不完整。那麼，就需要直接通過這個機關的人來收集需求資訊。

采訪

收集資訊以了解功能需求的第二個主要方法就是：采訪要實施vmware vsphere的機關或組織中的人。

一般而言，除非你已經從别人那裡得到了想要的資訊（即使得到了，也有可能需要進行采訪來確定沒有遺漏什麼資訊），你就得采訪組織的以下人群：

桌面支援人員。

伺服器管理者。

網絡管理者。

存儲管理者。

安全經理。

符合性/法務人員。

應用所有人。

業務主管。

項目經理或項目負責人/所有人。

執行/管理負責人。

架構師。

并不是所有情況下，都得采訪上述所有人。有選擇性地采訪，能覆寫到每類人員即可。

這些人可以提供給你很多資訊：目前環境支援什麼應用、這些應用的需求、目前遵循的服務級别協定、資料中心中不同應用或服務間的互相依賴關系、項目計劃或針對未來趨勢的計劃、複合型或法規要求、業務級别的需求、财務目标、運維層面和工作流，以及其他一些可以用來挖掘出功能需求的資訊。

收集完足夠用來挖掘需求的資訊後，就該評估下目前的環境了。評估環境的目的如下：

某些情況下，評估結果可以用來驗證或澄清需求定義階段收集的資訊。人畢竟是人，總會犯錯誤或者遺漏資訊。通過對環境進行評估，你可以驗證别人告訴你目前在使用的應用的确存在。

評估還為技術層面的設計提供了必要的資訊。它能夠發現現有環境中伺服器的類型和配置、目前的網絡配置，以及存儲配置。這些資訊對建立一個能與目前結構緊密結合的新結構是至關重要的。如果現在使用iscsi，要部署光纖，就會産生互操作難題。通過評估來徹底了解目前環境有助于合理裁剪vsphere設計的技術層面。

要評估環境，可供選擇的工具有很多。如果組織内已經具備足夠健壯的管理系統，那麼你可以從中得到需要的目錄、配置和性能資訊。如果沒有相應的管理系統，那麼你就得分析整個環境，從如下資源中挖掘出想要的資訊：

活動目錄。

ldap目錄。

網絡管理工具。

企業範圍的日志解決方案。

ip尋址文檔。

網絡裝置配置。

伺服器性能資料。

伺服器配置資料。

不難想象，隻要是在稍微大一點的環境裡，想通過手動收集資料來評估環境是相當耗時的，而且還容易出錯。幸運的是，為了節省時間避免丢失關鍵資料，vmware以及其他虛拟化産品/解決方案供應商都會提供評估工具用來自動收集資訊。甚至虛拟化社群也會提供腳本或其他工具來收集實體環境和虛拟環境的資訊。

來自虛拟化供應商或社群會員的一些自動化工具如下：

vmware capacity planner。

來自社群會員的各種健康檢查腳本。

netiq platespin recon （也就是以前的 novell platespin powerrecon）。

cirba。

在第10章中介紹一些工具，因為容量規劃會涉及一些虛拟化之前的評估工作。這些自動化工具還可以用來在準備結束vsphere設計時，評估目前虛拟化環境。

現在，已經了解了一些功能需求、用于定義其他功能需求的必要資訊，以及現有環境狀況。但是，在準備開始設計前，最好還是先進行差異性分析。

并不是所有的vsphere設計都是gree field implementation（即在一個從未部署過vsphere的環境中搭建全新的vsphere虛拟化環境）。當已經部署了vmware vsphere組織，想要更新或擴充現有環境，或者要遷移到新環境中時，你就需要執行差異性分析。

差異性分析是一個過程，在這個過程中我們對比環境目前狀态和未來的期望狀态，進而分析得出為了實作期望狀态我們需要做什麼。很可能目前環境并不支援相應的可擴充性。通過差異性分析就可以知道設計中的那些部分制約了其增長，并找到消除這些制約因素（至少改善其可擴充性）的方向。

一旦明确了功能需求、獲得了目前環境的資訊，以及執行了差異性分析（必要時），你就可以開始組合vsphere設計了。

組合vsphere設計是初始過程，如圖1-3所示。組合設計時，你要在每個設計層面做出各種決策。這些決策分别解答什麼/誰/如何的問題，而且都是基于功能需求的（直接擷取或通過設計的5個基本原則amprs定義的）。每個決策都有級聯效應，會影響到一系列決策（稱為下遊決策），如圖1-8所示。

每做一個決策，都要檢查由此決策引出的所有下遊決策的決策結果，以確定滿足所有功能需求。如果滿足則繼續；如果不滿足，就得改變決策或者不得不違背一個或多個功能需求。

違背功能需求也許是必要的

有時候，組織會有些不現實的需求。這樣，偶爾違背一個功能需求也是必要的，隻要有充分的理由并能提供補救措施。是堅持原有的需求，還是接受違背了某個功能需求的設計，這都取決于組織。

組合設計時，還要為vmware vsphere環境定義标準和最佳實踐：

标準　好的設計會為host名稱、網絡配置、存儲布局、資源配置設定和虛拟機配置等定義标準。标準之是以重要是因為它降低了複雜度。複雜度降低了，運維也就簡化了，成本也跟着降低。如果沒有标準，要想高效運維是十分困難的，而低效恰恰是導緻vmware vsphere環境失敗的緻命因素。

最佳實踐　好的設計還會定義并強化執行最佳實踐，這些最佳實踐都是與組織需要和功能需求相吻合的。“最佳時間”并不單單指供應商在如何部署其産品方面給我們的建議，它還可以是組織應該遵守的運維流程。例如，一個最佳實踐指出所有基于windows的虛拟機的檔案系統必須和虛拟硬碟的檔案系統對齊。的确，這是vmware的推薦做法，但同時它也是一個好的設計應該遵循的運維實踐，這樣能確定環境高效且運作穩定。好的設計還會包括一些與實施相關的内容，例如，新虛拟機的機構、新資料存儲的配置等。

不要盲目遵從最佳實踐

談及供應商的最佳實踐時，不要盲目地馬上執行。請首先檢驗這個時間并試圖去了解其背後的原因。如果存儲供應商說最好采用某個多路徑政策，那麼仔細研究下為什麼它會推薦這個多路徑政策呢？如果伺服器供應商把特定的bios設定作為最佳實踐，那麼想想為什麼要這麼設定。這樣你就能夠更加深刻透徹地了解虛拟化環境，同時也為制定實施相關的最佳實踐做了更充分的準備。

組合設計是個很細緻、很耗時的工作。後面的大部分章節都将專注于特定的技術領域以及做vmware vsphere設計時需要做的決策。

設計組合完畢後，也就是說已經做好了每個技術層面的決策，并且将決策結果（以及下遊決策結果）和功能需求進行對照，以確定滿足功能需求。接下來就可以開始文檔化設計了。

設計流程的這個環節可能會群組合設計環節同時進行，而且大部分都是直接記錄。你需要確定文檔闡述了設計的每個層面。很多時候，it專家們會忘記組織和運維層面，但是這兩個層面和技術層面是同樣重要的，在設計資料中應該對三者給予同樣的重視。

特别要注意的是，設計資料中至少要包含如下文檔：

功能需求描述，包括直接提供的和自己定義的。

技術層面決策的完整描述，解決關于“什麼”的問題。

組織層面決策的完整描述，解決關于“誰”的問題。

運維層面決策的完整描述，解決關于“如何”的問題。

構造文檔（也叫藍圖），描述建構設計時涉及的細節。

測試計劃，描述如何驗證該設計是否滿足功能需求。

概述性的架構設計文檔，将衆多元素組織在一起，介紹設計的整個過程。

設計完成且被組織認可後，就可以着手實施了。這樣就有機會根據自己的文檔來建構虛拟化環境。

如果不是親自實施，就需要交給其他人來做。這就是為什麼設計文檔一定要足夠詳細且完整的原因。當别人實施你的設計時，他不可能知道你設計時腦子裡想的是什麼。是以，請確定在設計文檔中提供盡可能多的資訊，讓實施過程能夠簡單順利地進行。