《VMware vSphere設計（原書第2版）》——1.3 設計原則

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

本節介紹設計的基本原則，即為了滿足功能需求，我們在每個層面（技術、組織和運維）進行決策時需要參考的一些指導性觀點。

概括地講，vsphere 設計有5個基本原則：

可用性（availability）。

可管理性（manageability）。

性能（performance）。

可恢複性（recoverability）。

安全性（security）。

随後，我們會用amprs這個縮略語來指代上述5個基本原則。這些原則大體上都可以顧名思義，無需多加解釋，但我們還會逐個詳細介紹。

當在vsphere 設計中進行各種決策時，首先要考慮的一個原則就是可用性。可用性囊括了諸多領域：正常運作時間和故障時間、可靠性、備援以及彈性。需要注意的是，有時候一些性能方面的原則也會關系到可用性，例如，在已簽署服務級别協定（sla）的情況下，可用性還可能包括應用響應時間或應用延遲時間。後面會單獨讨論性能原則。就設計的幾個層面而言，可用性原則對技術層面的決策影響最大。

在某些情況下，功能需求會直接描述可用性，例如，vsphere 設計實施後必須達到99％的可用性。此時，功能需求已經很清楚地提出了可用性要求，是以必須包含到vsphere設計中。但有的時候，功能需求中并不會直接描述可用性需求。此時，架構師就不得不在設計中加入适當的可用性級别，以進行更多的設計決策。功能需求中可能隻要求虛拟環境必須使用10gb的以太網。隻部署一個10gb的以太網交換機就能滿足這個需求，但是這樣這個10gb的以太網交換機就成了單一故障點。當功能需求中沒有清晰地描述可用性需求時，為了簡單地滿足其描述的需求而設計的可用性級别會是合理的嗎？

在上述情況中，架構師需要做一個假設。這個假設會考慮更廣泛的功能需求和設計限制（請參見1.1節中的“注意”），進而讓vsphere設計者所做的決策更加合理。如果沒有直接說明可用性需求，那麼架構師設計時應該使用這樣的假設：vsphere環境的可用性要在項目資金允許的範圍内做得盡可能高。

架構師還必須考慮可管理性。可管理性原則最直接影響到的是運維層面的決策，因為它涉及了環境的持續管理和維護。可管理性主要包括以下内容：

相容性。（相容性可以作為設計的一部分被管理嗎 ？）

适用性。（如何輕松管理适用性呢？）

互操作性。（可操作性和環境中的其他管理結構是內建在一起的嗎？）

可擴充性。（随着環境的不斷增長，如何很好地保證可擴充性呢？）

功能需求中一般都會很清晰地描述性能要求。性能要求會影響到技術和運維層面的決策。從伺服器的類型、網絡交換機的類型到存儲解決方案的選擇，性能要求會影響到技術層面決策的方方面面。在運維層面，通常是在服務級别協定中定義性能要求的，比如響應時間、每秒事物處理次數以及支援的最大使用者數等（如之前所述，請牢記在某些情況下性能需求和可用性是有關系的）。

顯然，即使性能需求描述并不明顯，設計vsphere環境的架構師在決策時也應該充分考慮性能。

可恢複性原則通常會涉及的概念包括：平均恢複時間（mean time to recover，mttr）、可維護性以及災難恢複或業務持續性（dr/bc）。顯然，這樣看起來可恢複性和可用性是相關聯的，但是可用性關注的是防止服務中斷，而可恢複性的目标是環境如何更快地從故障中恢複正常。

各個組織會采用各種不同的名額來度量可恢複性。這些度量名額就是恢複點目标（recovery point objective（rpo），重大故障或災難發生的情況下，可以接受多大程度的資料丢失）和恢複時間目标（recovery time objective（rto），多長時間環境能恢複運作）。通常，功能需求都會包含設計需要滿足的rpo/rto度量名額。

安全性影響到設計的每個層面：技術、組織和運維，是以做每個決策時都要考慮到安全性。

上述5個基本原則是形成設計決策的基礎。可以滿足功能需求的方法有很多，但是作為vsphere機構，你必須用這5個基本原則來衡量決策的每個選項。這個選項對可用性有正面還是反面影響？對可管理性有正面還是反面影響？同樣，對性能、可恢複性和安全性呢？這些原則指引我們沿着正确的方向以最好的方式來滿足功能需求。

在結束本章開始研究vmware esxi（見第2章）前，我們還得重點讨論另一個問題：vmware vsphere的設計流程。