次の方法で共有

DAG：除了 “A” 之外

  • [アーティクル]

英文原文已於 2011 年 9 月 16 日星期五發佈

定義

我們都知道，在 Microsoft Exchange 的世界裡，DAG 代表了「資料庫可用性群組」。

資料庫 – 因為在高可用性的 Exchange 2010 信箱伺服器上，「資料庫」(而非伺服器) 是「可用性」的單位，而且在 DAG 內的多部伺服器之間，只有資料庫才能進行容錯移轉或轉換。這個概念稱為資料庫行動性。

群組 – 因為「可用性」的範圍由 DAG 中的信箱伺服器決定，而且結合在容錯移轉叢集中以「群組」為單位一起運作。

可用性 – 這個字似乎是此處最不明顯且最模糊的詞彙 (且其他兩個詞彙也參考它)。諷刺的是，它有直接的數學定義，並且在了解整體 Exchange 設計原則時扮演了重要的角色。

Wikipedia 將「可用性」定義為意指下列其中一項：

  • 在任務開始時，若以不明的時間 (也就是隨機的時間) 呼叫任務，系統、子系統或設備處於指定的可執行且可供運用狀態的程度。簡單地說，可用性是指系統處於可運作狀況的時間比例。這經常以任務支援率表示。在數學上，這表示 1 減掉不可用的時間 (可能為英文網頁)。
  • (a) 在某個時段中，能夠使用功能單元 (可能為英文網頁)的總時間，與 (b) 間隔長度的比例。

使用機率理論的詞彙來說，這兩種定義的意義是相同的：在任何隨機的時間點 (進行測試時)，某個系統或元件「可執行」或「能夠使用」(亦即，「可用」) 的機率。

就數學上來說，這種測量方式可以藉由計算某個長期統計代表期間 (通常是一年) 系統可用的時間總量 (「執行時間」)，除以期間的總長度。使用廣為採用的平均無故障時間 (MTBF) 和平均修復時間 (可能為英文網頁) (MTTR) 等詞彙 – 前者代表故障之間的系統可用性 / 執行時間，而後者代表任何故障之間的系統停機時間 –「可用性」可利用分數表示：

方程式1

相反的數學特性為「故障機率」 (請想成「不可用性」)：

方程式2

可用性經常以「由 9 構成的數字」表示，如下表：

可用性等級

可用性值

故障機率

每年可接受的停機時間

兩個 9

99%

1%

5256 分鐘 = 3.65 天

三個 9

99.9%

0.1%

525.6 分鐘 = 8.76 小時

四個 9

99.99%

0.01%

52.56 分鐘

五個 9

99.999%

0.001%

5.26 分鐘

當然，可用性值會依我們是否同時考慮「已排程」 (計畫) 及「未排程」 (未計畫) 停機時間，或是只有未排程停機時間而有所不同。代表企業可用性需求的服務等級協定必須對此非常明確。但是在所有情況下，任何系統或元件的可用性其實取決於許多因素，而且很重要的一點是，要能找出並了解這些相依性，以及這些相依性對於可用性的影響。

服務相依性對可用性的影響

Exchange 信箱資料庫的可用性，取決於許多其他服務和元件的可用性 – 例如，裝載資料庫的儲存子系統、操作此資料庫的伺服器、與此伺服器的網路連線功能等等。這些全都是重要的元件，而且即使資料庫本身運作完全正常，只要任何這些元件之一故障，都無法提供服務。這表示，為了要讓資料庫能夠作以服務的方式提供，資料庫的每一項相依元件也都必須要能夠使用。如果我們正確地找出並隔離相依元件，我們便能以數學的方式計算它們如何判定 Exchange 信箱資料庫本身所得出的可用性。

針對某個 Exchange 信箱資料庫，可能會視下列元件為重要的相依元件：

  • 資料庫磁碟/存放子系統 – 假設它的可用性為 A1；
  • 信箱伺服器 (硬體及軟體元件) – 假設它的可用性為 A2；
  • Client Access Server (硬體及軟體元件) – 請記住，在 Exchange 2010 中，所有用戶端都只透過 Client Access Server 連接信箱資料庫，而且讓我們假設在此情況下，CAS 與信箱伺服器並非安裝在一起 – 假設它的可用性為 A3；
  • 用戶端與 Client Access Server 之間的網路連線功能，以及 Client Access Server 與信箱伺服器之間的網路連線功能 – 假設它的可用性為 A4；
  • 伺服器和儲存裝置所在的資料中心電力 – 假設它的可用性為 A5；

這份清單可以繼續列下去；例如，Active Directory 和 DNS 同樣也都是 Exchange 的重要相依元件。此外，除了純粹的科技相依性之外，可用性也會受到相依程序的影響，例如操作成熟度等：人為失誤、定義的作業錯誤、缺乏團隊協調等全都可能導致服務中斷。我們不會嘗試在此處詳列所有相依性，而是將重點放在它們對於整體服務可用性的影響。

由於這些元件本身彼此獨立，它們每一者的可用性都代表一個獨立事件，而 Exchange 信箱資料庫最後所得出的可用性，則代表所有這些事件的組合 (換句話說，信箱資料庫要能夠供用戶端使用，這些元件「全部」都必須可用)。從機率理論來說，獨立事件組合的機率，是每個事件個別機率相乘：

圖像

例如，如果您丟三枚銅板，全部得到正面的機率是 (1/2)*(1/2)*(1/2) = 1/8。

很重要的是您要了解，由於每個個別的可用性值都不可能大於 1 (或 100%)，最後所得出的服務可用性只是個別元件可用性相乘的結果，所以最後得出的可用性值不可能大於相依元件可用性最低的值。

這點可用下表呈現的範例加以說明 (此處的數字只是範例，但相當接近實際的值)：

重要的相依元件

故障機率

可用性值

信箱伺服器與儲存裝置

5%

95%

Client Access Server

1%

99%

網路

0.5%

99.5%

電力

0.1%

99.9%

整體服務 (取決於上述所有元件)

6.51383%

95% x 99% x 99.5% x 99.9% = 93.48617%

從此範例中您可看到服務相依性有多重要。即使是從未故障的信箱資料庫 (從未損毀、從未感染病毒等等)，可用性仍然低於 93.5%！

結論：服務相依項目一旦數量過多，就會降低可用性。

為了降低服務相依性數目或影響所能做的一切努力，都可正面影響整體服務可用性。例如，您可以藉由簡化與保護伺服器管理，還有將操作程序最佳化，而改善操作成熟度。在技術方面，您可以嘗試讓設計變簡單而減少服務相依性的數目 – 例如，避免使用複雜的 SAN 儲存設計，包括 HBA 卡、光纖網路交換器、陣列控制器，以及甚至 RAID 控制器，以及更換成簡單的 DAS 設計，使用最少的運轉零件。

光是減少服務相依性，可能不足以讓可用性達到希望的等級。關於提高所得出之可用性並將重要服務相依性的影響降至最低，有另一個很有效率的方式，就是運各種備援方法，例如使用雙電源供應、一組網路卡、將伺服器連接至多部網路交換器、為作業系統使用 RAID 保護、為 Client Access Server 部署負載平衡器，以及多份信箱資料庫複本，以提升所得出的可用性以及將重要服務相依性降至最低。但備援究竟會提高多少可用性呢？讓我們以負載平衡和多份資料庫副複本這兩者做為重要範例，進一步地仔細觀察。

備援對可用性的影響

從概念上來說，所有備援方法都指的是同一件事：元件存在多個可用的執行個體，而且可以與其他執行個體同時使用 (如在負載平衡期間) 或是作為替換之用 (如在多份資料庫複本的情況下)。讓我們假設我們有 n 個某元件的執行個體 (CAS 陣列中的 n 部伺服器，或 DAG 中的 n 份資料庫複本)。即使它們其中之一故障，其他的執行個體仍然可以使用，因此能夠維護可用性。唯一會面臨實際停機的情況就是當「所有」執行個體都故障的時候。

如同先前所定義，任何特定執行個體的故障機率為 P = 1 – A。所有執行個體在統計方面都是彼此獨立的，這表示它們任何一者的可用性或故障，並不會影響其他執行個體的可用性。例如，某個資料庫複本的故障，並不會影響該資料庫另一份複本的故障機率 (此處可能要注意的是從第一個受損資料庫複本傳播到所有其他複本的邏輯資料庫損毀，但目前讓我們先忽略這個可能性不高的因素。畢竟，您隨時都能夠施行遲延資料庫複本，或是運用傳統的時間點備份來解決此問題)。

再次使用相同的機率理論定理，一組 n 個獨立元件的故障機率，是每個元件機率相乘的結果。由於此處所有的元件都相同 (相同物件的不同執行個體)，所以乘積變成了次方：

圖像

很明顯地，當 P < 1 時，Pn 小於 P，這表示故障機率下降，因此可用性提高：

圖像

為了釐清想法起見，讓我們舉一些現實生活中會出現的例子。假設，我們正在部署多個信箱資料庫複本；每個複本都裝載在單一 SATA 磁碟機上。就統計而言，SATA 磁碟機的故障率是一年 ~5%[1]，如此得到 5% 的故障機率：P = 0.05 (這表示可用性為 95%：A = 0.95)。當我們增加其他資料庫複本時，可用性產生何種變化？請見下表，它應該能夠說明清楚：

資料庫複本數

故障機率

可用性值

1

P1 = P = 5%

A1 = 1 – P1 = 95%

2

P2 = P2 = 0.25%

A2 = 1 – P2 = 99.75%

3

P3 = P3 = 0.0125%

A3 = 1 – P3 = 99.9875%

4

P4 = P4 = 0.000625%

A4 = 1 – P4 = 99.9994%

十分令人印象深刻，不是嗎？基本上，SATA 磁碟機上每額外增加一個資料庫複本，都會造成 5% 的乘數，也就是 1/20，因此故障機率變成比每個單一複本低 20 倍 (相對應的可用性就提高)。您可以看到，即使是最不可靠的 SATA 磁碟機，只部署 4 個資料庫複本，都能讓資料庫可用性達到五個 9。

這樣已經很好了，但是還能更好嗎？在不進行架構變更的情況下 (例如，如果不可能再增加資料庫複本時)，還能進一步提高可用性嗎？

事實上是可以的。如果您改善任何相依元件的個別可用性，就會提高整體服務可用性，得到比新增備援元件更強的效果。例如，這麼做而不會造成大量花費的可能方式之一，是使用 Nearline SAS 磁碟機取代 SATA 磁碟機。Nearline SAS 磁碟機的年故障率為 ~2.75%，不像 SATA 是 ~5%。如此可降低上述計算式中儲存元件的故障機率，因而提高整體服務的可用性。以下讓我們比較一下新增多個資料庫複本的影響：

  • 5% AFR = 1/20 乘數 = 每份新複本讓資料庫的故障能降低 20 倍。
  • 2.75% AFR = 1/36 乘數 = 每份新複本讓資料庫的故障能降低 36 倍。

額外的資料庫複本對於資料庫可用性的這項重大影響，同時也解釋了我們對於使用 Exchange 原生資料保護的指引方向，這種保護表示如果部署足夠數目 (三個或更多) 的資料庫複本，則多份資料庫複本可以取代傳統備份。

相同的邏輯也適用於在 CAS 陣列中部署多部 Client Access Server、多部網路交換器等等。現在假設已部署了 4 份資料庫複本與 4 部 Client Access Server，然後再回頭看先前分析的元件可用性表格：

重要相依元件

故障機率

可用性值

信箱伺服器與儲存裝置 (4 份複本)

5% ^ 4 = 0.000625%

99.999375%

Client Access Server (4 部伺服器，分開安裝)

1% ^ 4 = 0.000001%

99.999999%

網路

0.5%

99.5%

電力

0.1%

99.9%

整體服務 (取決於所有上述元件)

0.6%

99.399878%

您可以看到，我們光是部署 4 部 Client Access Server 和 4 個資料庫複本，整體服務的故障機率就降低超過 10 倍 (從 6.5% 降到 0.6%)，而服務可用性也跟著從 93.5% 提高到更好的 99.4%！

結論：增加服務相依性的備援會提高可用性。

一併思考

從先前的結論，產生了一個有趣的問題。我們分析兩個以不同方式影響整體服務可用性的不同因素，發現兩項清楚的結論：

  • 引入較多的系統相依性會降低可用性
  • 增加系統相依元件的備援可提高可用性

若兩者都是某個解決方案的因素時，會發生什麼事？哪個可能性較高？

請思考下列情況：

我們在 DAG 部署兩部信箱伺服器，以及兩個信箱資料庫複本 (每部伺服器上一個複本)，且在負載平衡的陣列中部署兩部 Client Access Server。(為簡單起見，我們將只會考慮用戶端連線的信箱資料庫可用性，目前暫時不考慮集線傳輸及整合通訊)。假設每部伺服器有其獨立的故障機率 P，那麼這樣的系統，可用性會比單一獨立 Exchange 伺服器同時部署 Mailbox 伺服器角色及 Client Access Server 角色的可用性好還是差呢？

圖像

在第一個案例中，信箱伺服器是獨立的，且唯有在兩部伺服器都故障時才無法使用。這組兩部信箱伺服器的故障機率將是 P × P = P2。相對應地，它的可用性將是 AMBX = 1 – P2。遵循相同的邏輯，CAS 服務唯有在兩部 Client Access Server 都故障時才無法使用，因此這組兩部 Client Access Server 的故障機率同樣也是 P × P = P2，相對應地，它的可用性將是 ACAS = 1 – P2。

如同您所經瞭解的，在此案例中兩部信箱伺服器或兩部 Client Access Server 都是備援系統元件的例子。

繼續此案例… 為了要讓整個系統都能使用，兩組的伺服器 (一組信箱伺服器和一組 Client Access Server) 必須同時可用。不是同時「故障」，而是要同時「可用」，因為現在它們代表系統相依性，而不是備援元件。這表示整體服務可用性是每一組的可用性相乘：

圖像

當然，第二個案例簡單許多，因為只有一部伺服器要考慮，而它的可用性就是 A = 1 – P。

因此，既然我們已計算出兩個案例的可用性，哪個值比較高，(1-P2)2 還是 1-P？

如果我們繪製兩個函數的圖形，將會看到下列行為：

圖像

(我使用 Wolfram Alpha Mathematica Online (可能為英文網頁) 這個免費的計算引擎，輕鬆快速地進行繪圖。)

我們可以看到，P 值較小時，複雜的 4 部伺服器系統的可用性比單一伺服器的可用性高。沒有意外；這是我們預期的，對吧？但是，當 P ~ 0.618 時 (更精確地說，圖像) 兩條繪圖交叉，P 值較大時，單一伺服器系統實際上具有較高的可用性。當然，您會預期在現實中，P 的值相當接近於零；但是，如果您計畫從「非常」不可靠的元件建置解決方案，單一伺服器可能比較適合您。

故障範圍的影響

現實生活中的部署案例很不幸地極少像上述討論的情況那麼簡單。例如，如果您部署多角色的伺服器，服務可用性會有什麼樣的變化？我們注意到在上述情況中，結合伺服器角色能有效地減少服務相依性的數目，因此這可能是件好事？如果您將相同資料庫的兩份資料庫複本放到相同的 SAN 陣列或 DAS 設備會怎麼樣？如果您所有的信箱伺服器都連接到相同的網路交換器會怎麼樣？如果除了上述情況之外還有其他的狀況，又會怎麼樣？

這些情況全都圍繞在故障範圍的概念上。在上述範例中，伺服器硬體、SAN 陣列或是網路交換器，都代表了一個故障範圍。故障範圍打破了它所結合的獨立性或備援。例如，多重角色伺服器中的伺服器硬體故障，表示這部伺服器上所有的 Exchange 角色都會變成無法使用；相對應地，磁碟設備或 SAN 陣列故障，表示此設備或陣列上所裝載的所有資料庫複本都會變成無法使用。

故障範圍不一定是件壞事。重要的差別在於何種類型的元件構成故障範圍，是不同的系統相依性或是備援系統元件呢。讓我們思考上面兩個範例，以了解這項差別。

多重角色伺服器案例

讓我們比較兩個不同系統的可用性：

  1. Mailbox 伺服器角色及 Client Access Server 角色都裝載在相同的伺服器上，而伺服器硬體故障機率為 P；
  2. 相同的角色裝載在兩部不同的伺服器上，每部伺服器都有相同的硬體故障機率；

在第一個案例中，單一伺服器的硬體代表一個故障範圍。這表示所有裝載的角色都全部可用或全部無法使用。這很簡單；此類系統的整體可用性為 A = 1 – P。

在第二個案例中，整體服務唯有在「兩部」伺服器都獨立可用時才能使用 (因為每個角色代表一項重要相依性)。因此，根據機率理論，它的可用性為 A × A = A2。

同樣地，當 A < 1 時，表示 A2 < A，因此第二個案例的可用性較低。

我們很明顯地可以將其他 Exchange 伺服器角色 (Hub Transport 及 Unified Messaging，如果需要的話) 新增到相同的案例，都不會打破此邏輯。

結論：在多重角色伺服器上組合 Exchange 伺服器角色，可提高整體服務可用性。

共用儲存裝置案例

現在，讓我們思考另一個故障範圍的案例 (兩個資料庫複本共用相同的儲存陣列)，並比較下列兩種情況的資料庫可用性：

  1. 兩個資料庫複本裝載在相同的共用儲存裝置上 (SAN 陣列或 DAS 設備)，故障機率為 P；
  2. 相同資料庫複本裝載在兩個不同的儲存系統上，每個儲存系統有相同的故障機率；

在第一個案例中，共用儲存裝置代表一個故障範圍。如先前案例一般，這表示兩個資料庫複本會同時可用或無法使用，因此整體可用性同樣為 A = 1 – P。

在第二個案例中，整體服務會在「至少一個」系統可用時即為可用，且唯有在「兩個」系統都故障時才會無法使用。我們所討論的儲存系統是獨立的；因此，整體服務的故障機率為 P × P = P2，且相對應地，整體服務可用性為 A = 1 – P2。

同樣地，當 P < 1，表示 P2 < P，因此 1 – P2 > 1 – P。這表示第二個案例的可用性「比較高」。

結論：將資料庫複本組合在相同的儲存系統，可降低整體服務可用性。

那麼，這兩個案例之間有什麼差別？為什麼故障範圍變多在第一個案例中會提高可用性，而在第二個案例中則會降低可用性？

這是因為第一個案例中的故障範圍結合服務相依性，實際上降低了服務相依性的數目，因此改善可用性；而第二個案例中的故障範圍則結合備援元件，有效降低了備援，因而損害了可用性。

這些概念與結論可能全都可以視覺化，如下所示：

圖像

(我們這張圖沒有使用 Wolfram Alpha！)

結語

Exchange 2010 架構在像是於 Exchange 等級增加備援 (例如在 CAS 陣列中部署多重資料庫複本或多部 Client Access Server)，以及在減少系統相依性的數目 (藉由在多重角色伺服器中結合 Exchange 伺服器角色，或是使用較簡單的儲存架構，而不要有太大量的重要元件) 方面，提供了非常大的可能性。您可利用本文所提出的簡單規則與公式，計算部署額外資料庫複本或結合 Exchange 伺服器角色對可用性值的影響；您也可以計算故障範圍的影響。請務必要注意的是，我們嘗試使用這些簡單的數學模型來說明概念，而不是假裝取得精確的可用性值。現實生活中的情況向來就不簡單，您需要進行的計算會複雜許多，才能得到合理的實際系統可用性估計；光是以統計方式測量可用性，然後確認它是否符合 SLA 需求，可能會比較容易。但是，了解影響可用性的因素以及它們在複雜的工程解決方案中所發生的影響力，應該能協助您適當地設計解決方案，並在整體服務可用性方面達到顯著的提升，而能符合即使最嚴峻的商業需求。

Boris Lokhvitsky
架構設計師

[1] Carnegie Mellon University、Google 及 Microsoft Research 的下列研究顯示 SATA 磁碟機為 5% AFR：

https://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf (可能為英文網頁)

https://labs.google.com/papers/disk_failures.pdf (可能為英文網頁)

https://research.microsoft.com/apps/pubs/default.aspx?id=64599 (可能為英文網頁)

這是翻譯後的部落格文章。英文原文請參閱 DAG: Beyond the “A”。