什麼是冗餘、複寫和備份？

我們通常會將雲端視為全球分散式、無處不在的系統。 不過，實際上雲端是由數據中心內執行的硬體所組成。 復原需要您考慮與雲端裝載元件執行所在的實體位置相關聯的一些風險。

本文提供冗餘、複製與備份的一般介紹，這些方法用來建立能抵抗物理風險、服務中斷、中斷或資料遺失的工作負載。

備援 是維護服務元件多個相同複本的能力，並且以防止任何一個元件變成單一失敗點的方式使用這些複本。

複寫或資料冗餘 是指能夠維護多份資料副本的能力，稱為複本。

備份 是維護時間戳數據複本的能力，可用來還原遺失的數據。

從可靠性的角度來看，降低許多風險的重要方法是在您的 業務持續性規劃中加入某種形式的冗餘、複製或備份。

備註

本文不提供設計指引或關於個別 Azure 服務的詳細資訊。 欲了解特定Azure服務在可靠性上的運作方式，請參考請參考各服務的可靠性指南。

Redundancy

冗餘是指部署多個元件實例。 雖然冗餘機制容易理解，但在某些情況下，實施起來可能相當複雜。

在開始理解冗餘時，最簡單的做法是將冗餘與無狀態元件（nonstates）相關聯，也就是不儲存任何資料的元件。 雖然大多數現實解決方案確實需要管理狀態，但在本節中，我們以無狀態應用程式介面（API）為範例來討論冗餘。 範例 API 接受輸入，對該輸入進行工作，然後回傳輸出，且不儲存任何資料。 在下一節「 複製：資料冗餘」中，我們將加入對有狀態冗餘的考量。

情境：無國家冗餘

在此範例中，一個無狀態的 API 元件部署到虛擬機器。 為避免 API 元件在實體主機硬體故障時停機，範例實作了冗餘解決方案：

• 部署多個 API 實例副本。
• 實作 負載平衡器 以在 API 實例間分配請求。

圖示顯示三個元件實例，並有一個負載平衡器在它們之間分配流量。

負載平衡器會監控每個實例的健康狀況，只向健康實例發送請求。

圖示顯示三個元件實例，其中一個故障，剩餘兩個仍在運作。

冗餘考量

在實施冗餘解決方案時，如上述情境，需考慮以下幾點：

• 資源成本。 根據定義，冗餘是指擁有多個副本，這會增加主機化的總成本。

• 性能。 你在更廣泛的地理範圍內分發複製品，能夠幫助降低的風險就越大。 然而，客戶端的請求會因需穿越更多網路基礎設施而花費較長距離，這會增加 網路延遲。

  在大多數現實情況下，網路延遲對於短距離來說無關緊要，例如在資料中心內，甚至跨城市跨越資料中心。 但如果你將副本分發到很遠的距離，網路延遲就會變得更嚴重。

• 實例的一致性。 保持實例間一致性很重要，避免單獨配置實例，因為可能會不小心引入實例間的差異。 如果實例間存在差異，請求的處理方式可能會根據服務的實例而有所不同。 這可能導致難以診斷的錯誤與現象。

• 工作分配。 當你有多個元件實例時，你需要將工作分配給它們。 你可以平均分配工作到所有實例，或者只向單一 主 實例發送請求，當主實例無法使用時才使用次要實例。

  對於接收外來請求的元件，通常會使用負載平衡器將這些請求傳送到實例。 然而，有時元件會獨立運作，不會接收客戶端的請求，因此在這些情況下，實例之間可能需要協調彼此的工作。

• 健康監控。 每個實例的健康狀況決定該實例是否能完成工作，健康監控對於在出現問題時能快速恢復非常重要。

  負載平衡器通常負責健康監控。 對於沒有負載平衡器的元件，你可能會有一個外部元件監控所有實例的健康狀況，或者每個實例都可能監控其他實例的健康狀況。

雲端中的實體位置

當你明白即使在雲端環境中，實例或資料仍儲存在特定的物理位置時，冗餘的需求就顯而易見了。

例如：

• 虛擬機同時在單一實體地點運行。
• 資料儲存在特定的物理位置，例如連接伺服器的固態硬碟（SSD）或硬碟。

即使有多個資料或元件的副本，每個副本都綁定在儲存它的實體硬體上。

雲端環境的整體物理位置可以組織成物理範圍。 在每個實體範圍內，都存在潛在風險，可能危及該範圍內的元件或資料。 以下是一份非詳盡的風險清單，可以依物理範圍來定義：

物理範圍	可能的風險
特定的硬體，比如磁碟或伺服器	硬體失敗
資料中心中的機架	機架頂端網路交換器故障
資料中心	建築冷卻系統的問題
一組資料中心，Azure稱為 可用性區域	全市電暴
資料中心所在的更廣泛地理區域，例如城市，屬於Azure region	廣泛的自然災害

從可靠性角度來看，降低實體範圍相關風險的重要方法是將元件的實例分散到不同的實體範圍。 具備內建冗餘功能的 Azure 服務可能會提供以下三種部署冗餘實例的方式之一或多種：

• Local redundancy將實例置於單一Azure資料中心的多個區域，並防止可能影響單一實例的硬體故障。 本地冗餘通常提供最低的成本與延遲。 然而，資料中心故障可能導致所有實例無法使用。

• Zone redundancy 將實例分散在單一Azure區域的多個可用區域。 區域冗餘除了防止硬體故障外，也能防止資料中心故障。

• 地理冗餘可將實例置於多個Azure區域，並提供防範大規模區域故障的防護。 地理冗餘成本較高，且需要考慮您的更廣泛的解決方案設計，以及如何在不同區域中切換元件實例版本。 你還需要考慮延遲，這在 同步與非同步複製中有描述。

Azure 中的冗餘如何運作：運算服務

Azure 幾乎每個區域都採用了冗餘設計。 以 Azure 如何實作冗餘為例，請考慮執行運算工作負載的服務。

在 Azure 中，單一虛擬機（VM）會運行在 Azure 資料中心的單一實體主機上。 你可以提供指令給 Azure，確保虛擬機在你預期的位置運行，例如區域和可用性區。在某些情況下，你甚至可以將它放置到專屬於你的主機上。

執行多個虛擬機實例是很常見的做法。 在這種情況下，你可以選擇單獨管理它們，或使用 虛擬機尺度集來管理。 使用擴展集時，你仍能看到支撐它的個別虛擬機，但擴展集提供多種功能來協助管理冗餘虛擬機。 這些功能包括根據你指定的規則自動放置虛擬機，例如將虛擬機分散到區域或可用性區域內的 故障域 。

還有許多其他 Azure 運算服務依賴虛擬機器來執行運算任務。 運算服務通常提供各種冗餘設定，以決定虛擬機的分布方式。 例如，某項服務可能提供區域冗餘設定，你可以啟用它來自動分散虛擬機到不同可用區域並配置負載平衡。

複製：資料冗餘

冗餘應用於狀態（資料）時稱為複製。 透過複寫，你可以維護多個即時或近即時的即時資料副本，稱為 複本。 為了提升風險韌性，你可以將副本分散在不同地點。 若其中一個副本無法使用，系統可能會 切換 ，讓另一個副本接手其功能。

複製有不同類型，每種方式在資料一致性、效能與成本上都給予不同優先考量。 每種複製類型影響兩個用於討論業務持續性的關鍵指標： 復原時間目標 （RTO），即在災難情境下可容忍的最大停機時間，以及 復原點目標 （RPO），即災難情境中可容忍的最大資料遺失量。 欲進一步了解這些指標及其與業務持續性的關聯，請參閱 「什麼是業務持續性、高可用性與災難復原？」。

由於複製在滿足功能與效能需求中的重要性，大多數資料庫系統及其他資料儲存產品與服務都包含某種形式的複製，作為緊密整合的功能。 它們所提供的複製類型通常取決於其架構和使用方式。 欲了解Azure服務支援的複製類型，請參閱 Azure 服務可靠性指南。

這很重要

複製和備份是不一樣的。 複製會同步多個副本間的所有變更，且不會維護舊的資料副本。

假設你不小心刪除了一些資料。 刪除操作會複製到每個副本，你的資料也會被刪除。 在這種情況下，你可能需要從備份中還原被刪除的資料。 備援部分將於本文後面說明。

同步與非同步複製

當你複製資料時，任何對資料的變更都必須在副本間同步。 在資料變動時，試圖維持一致性有幾個主要挑戰：

• 延遲。 更新複本需要時間，且複本間距離越遠，跨越複本間傳輸資料並接收確認所需的時間就越長。

• 變革管理。 在副本同步過程中，資料可能會變動，因此管理資料一致性會變得複雜。

為了解決這些挑戰，有兩種主要方法可以複製資料變更並管理資料一致性：

• 同步複製 需要在多個副本上完成更新，更新才被視為完成。 下圖說明同步複製的運作方式：

  顯示兩個複製品間同步複製的圖示。

  在此範例中，以下步驟序列發生：

  1. 客戶端會更改資料，請求會送達副本 1，該副本會處理請求並儲存變更後的資料。
  2. 副本 1 將變更傳送給副本 2，副本 2 處理請求並儲存變更後的資料。
  3. 副本 2 確認變更回副本 1。
  4. 副本 1 會將變更回報給用戶端。

  同步複製能保證一致性，這表示它可以支援為零的 RPO。 然而，這也以效能為代價。 複製品地理距離越遠，需要經過的網路跳數越多，複製過程中產生的延遲就越多。

• 非同步複製 是在背景進行的。 下圖說明非同步複製的運作方式：

  圖示兩個複製體間非同步複製。

  在此範例中，以下步驟序列發生：

  1. 用戶端會更改資料，請求會傳送到副本 1。
  2. 副本 1 處理請求，儲存變更後的資料，並立即向客戶端確認變更。
  3. 之後某個時候，副本 1 會將變更同步到 replica 2。

  由於非同步複製發生在交易流程之外，它消除了複製作為應用程式效能限制的因素。 不過，如果你需要切換到另一個副本，它可能沒有最新的資料，所以你的 RPO 必須大於零。 非同步複製能支援的具體 RPO 取決於複製頻率。

副本角色

在許多複製系統中，副本可以扮演不同角色，有助於協調資料變更並降低衝突機率。 主要有兩種角色類型： 主動 型和 被動型。 有兩種常見的方法來分發具備這些角色的複製品：

• 主動-被動 複製方式意味著你有一個 主動 副本，負責作為真實數據源。 對資料所做的任何變更都必須套用到該複本。 其他副本則是 被動 角色，也就是說它們會從主動副本接收資料更新，但不會直接處理用戶端的變更。 除非發生 故障轉移 且副本的角色改變，否則被動副本不會用於即時流量。 下圖顯示一個具有一個被動副本的主動-被動系統：

  圖示顯示兩個複製品間的主動-被動複製。

  在主動-被動系統中，故障轉移所需的時間長度決定了 RTO。 通常，主動-被動系統的 RTO 以分鐘為單位。

  部分複寫方案也支援 唯讀副本，這讓你可以從被動副本讀取（但無法寫入）資料。 這種方法有助於提升複本的利用率，例如當你需要進行分析或資料報告，且不影響用於應用程式交易工作的主複本時。 多個Azure服務支援唯讀複本，包括Azure 儲存體搭配讀取存取的 GRS（RA-GRS）複本類型，以及Azure SQL Database主動地理複製。

• 主動 複寫允許同時使用多個主動副本進行即時流量，且任一副本都能處理以下請求：

  顯示兩個副本間主動-主動複製的圖示。

  主動-主動複寫能帶來高效能，因為系統可使用所有副本的資源。 主動-主動複製在某些情況下可支援 RTO 為零。 然而，這些優點以資料一致性變得複雜為代價，因為多個副本上的同時發生變更可能需要非同步協調解決。

複雜的資料服務可以結合主動-主動與主動-被動複寫。 例如，他們可能會在一個 Azure 區域部署一組副本，另一個在不同區域部署。 在每個區域內，一個主動副本負責處理請求，而一個或多個被動副本則待命進行故障轉移。 同時，兩個區域都採用主動-主動模式，允許流量分散於彼此之間。

Azure 資料服務中的複寫如何運作

每個儲存資料的 Azure 服務都提供某種形式的複製功能。 然而，每個服務可能採用不同於其架構及預期用途的具體方法。

舉例來說，Azure 儲存體 可以透過一系列功能提供同步與非同步複製：

• 資料的多個副本會在主要區域內同步複製。 你可以選擇將副本放在單一資料中心的不同實體硬體上，採用本地冗餘儲存（LRS），或分散在多個可用區域以實現區域冗餘儲存（ZRS）。
• 如果你的主要區域是配對的，並且你啟用了地理冗餘儲存（GRS），資料也會被複製到配對區域。 由於成對區域地理位置相距甚遠，此複製以非同步方式進行，以降低對應用程式吞吐量的影響。
• 你可以選擇同時使用區域冗餘儲存與地理冗餘儲存，方法是使用地理區域冗餘儲存層（GZRS）。 區域內的資料同步複製，跨區域的資料則非同步複製。

欲了解更多資訊，請參閱 Azure 儲存體 redundancy。

另一個例子是 Azure Cosmos DB，它也提供複製功能。 所有 Azure Cosmos DB 資料庫都有多個副本。 當你全球分發副本時，它支援多區域寫入，讓用戶端可以寫入你使用的任何區域的副本。 這些寫入操作會在區域內同步複製，然後在其他區域間非同步複製。 Azure Cosmos DB 提供衝突解決機制，以防不同副本間發生寫入衝突。 欲了解更多，請參閱全球資料分布與 Azure Cosmos DB - 深入解析。

如果你使用虛擬機，可以使用 Azure Site Recovery 來複製虛擬機及其磁碟，在不同可用性區域或其他Azure區域。

設計 Azure 方案時，請參考每個服務的 可靠度指南 以了解該服務如何提供冗餘和複寫，包括在不同地點之間。

備份

備份會在特定時間點複製你的資料。 如果有問題，你可以之後 還原 備份。 不過，備份後對資料的任何變更都不會在備份中，甚至可能會遺失。

透過備份，你可以提供解決方案，將資料備份並恢復到Microsoft Azure雲端。 備用能保護您免於多種風險，包括：

• 硬體或其他基礎設施的災難性損失。
• 資料損壞與刪除。
• 網路攻擊，例如勒索軟體。

這很重要

定期測試並驗證備份與還原流程，以及其他復原步驟，這點至關重要。 測試確保你的備份完整且無錯誤，且流程能正確還原備份。 測試也很重要，以確保團隊了解應遵循的流程。 欲了解更多，請參閱 測試與演練。

備份如何影響你的需求

作為災難復原策略的一部分，備份通常支持以小時計算的 RTO 與 RPO：

• RTO 會受到您啟動及完成復原流程所需的時間影響，包括還原備份及確認還原是否成功完成。 根據備份的大小以及需要讀取多少備份檔案，完整還原備份通常需要數小時甚至更久。

• RPO 會受到備份流程的頻率影響。 如果你更頻繁地備份，代表你從備份還原時損失的資料會比較少。 然而，備份需要儲存空間，在某些情況下，備份可能會影響服務在備份進行時的效能。 因此，您需要考慮備用頻率，並找到符合組織需求的適當平衡。 備用頻率應是業務持續性規劃中的考量因素。

部分備份系統支援更複雜的備份需求，包括多層備份且保留期限不同，以及差異或增量備份，這些備份能更快儲存並減少儲存空間。

在 Azure 服務中備份

許多 Azure 服務都提供資料備份功能。

Azure 備份 是一套專門用於多個關鍵Azure服務的備份解決方案，包括虛擬機、Azure 儲存體 以及 Kubernetes 服務（Azure Kubernetes Service，AKS）。

此外，許多受管理資料庫也提供自身的備份功能作為服務的一部分，例如：

• Azure SQL Database 提供自動備份。
• Azure Cosmos DB提供持續與定期備份功能。
• Azure Key Vault 讓你能下載資料庫 中的備份資料。
• Azure App 服務 提供網頁應用程式的自動及自訂備份，也能備份其資料庫。

備份與複寫

備份與複製各自保護你免受不同風險，且兩者互為補足。

複製支援日常韌性，並常用於高可用性策略中。 部分複製方式幾乎不需要停機或資料遺失，並支援低 RTO 與 RPO。 然而，複寫並不能保護你免於導致資料遺失或損壞的風險。

相較之下，備份往往是抵禦災難性風險的最後一道防線。 備份通常需要相對較高的 RTO 和 RPO，但你如何配置備份會決定備份的高度。 從備份進行完全還原通常是災難復原計畫的一部分。

準備元件以備冗餘

當你設計一個將冗餘納入架構的系統時，也必須考慮如何：

• 為了一致性，重複資源配置。
• 在實例故障時，透過超額配置來管理容量。

重複資源配置

在雲端環境中，每個資源的配置都至關重要。 舉例來說，當你建立網路負載平衡器時，你會設定各種會影響其運作方式的設定;而當你使用 Azure Functions 部署函式時，則會設定與安全性、效能及應用程式組態設定相關的設定。 Azure 中的每個資源都有某種設定來驅動其行為。

當你在不同地點管理資源的冗餘副本時，控制它們的配置非常重要。 許多設定需要在每個副本中以相同方式設定，以確保資源的行為一致。 但在每個副本之間，有些設定可能會不同，例如特定區域虛擬網路的參考設定。

維持資源一致性的常見方法是使用基礎設施即程式碼（IaC），例如 Bicep 或 Terraform。 這些工具讓你能建立定義資源的檔案，並且你可以在每個資源實例中重複使用這些定義。 透過使用 IaC，您可以減輕建立和管理多個資源實例以提升韌性的負擔，還有許多其他好處。 欲了解更多，請參閱《 什麼是基礎建設即程式碼（IaC）？ 》及 《使用基礎架構即程式碼的建議》。

透過過度配置來管理容量

當實例故障時，整體系統容量可能與正常運作時所需的容量不同。 舉例來說，假設你通常有六台網頁伺服器來處理你的進來網路流量，這些實例平均分布在一個區域內的三個 Azure 可用性區域：

圖示顯示三個可用區域，每個區域有兩個網頁伺服器實例，總共六個實例容量。

如果某個可用區域發生故障，你可能會暫時失去兩個實例，只剩下四個網頁伺服器實例。 如果你的應用程式通常很忙，且需要六個實例才能跟上正常流量，那麼以降低容量執行可能會影響解決方案的效能。

為了預防故障，你可以超額配置服務容量。 過度布建可讓解決方案容許某種程度的容量遺失，但仍會繼續運作，而不會降低效能。

為應對單一可用性區域的故障，對你的網頁伺服器實例進行多餘配置，請依照以下步驟進行：

1. 確定你的尖峰工作負載需要多少實例。
2. 透過將峰值工作負載實例數乘以 [（zones/（zones-1）]} 來取得超額配置實例數。
3. 將結果取整至最接近的整數。

備註

下表假設你使用三個可用區域，並想考慮其中一個區域容量的損失。 如果你的需求不同，請相應調整配方。

峰值工作負載實例數	因子 [（區域/（區域-1））]	Formula	提供實例（四捨五入）
3	3/2 或 1.5	（3 x 1.5 = 4.5）	5 次
4	3/2 或 1.5	（4 x 1.5 = 6）	6 個實例
5	3/2 或 1.5	（5 x 1.5 = 7.5）	8 次實例
6	3/2 或 1.5	（6 x 1.5 = 9）	9 個實例
7	3/2 或 1.5	（7 x 1.5 = 10.5）	11 次
8	3/2 或 1.5	（8 x 1.5 = 12）	12 次
9	3/2 或 1.5	（9 x 1.5 = 13.5）	14次
10	3/2 或 1.5	（10 x 1.5 = 15）	15次

在前述範例中，峰值工作負載需要六個網頁伺服器實例，因此過度配置則需要總共九個實例：

圖示顯示對網頁伺服器過度配置，總共九個容量實例。

後續步驟

了解故障轉移與故障回復。