共用方式為

Azure 上 Oracle 的商務持續性和災害復原 虛擬機器 登陸區域加速器

  • 發行項

本文以商務持續性和災害復原 （BCDR） 的 Azure 登陸區域設計區域中定義的考慮和建議為基礎。 本文遵循該指引，並說明 Azure 基礎結構虛擬機上 Oracle 工作負載部署 BCDR 選項的設計考慮和最佳做法。

Azure 提供可用來設計高可用性和復原架構的服務。 本指南概述各種選項和最佳做法，以協助您為 Azure 上的 Oracle 資料庫設計高可用性和災害復原，虛擬機器 登陸區域加速器。 它也會說明如何設定隨附的 Azure 服務，以協助您達成解決方案的高端對端可用性。

開始使用

若要為工作負載環境建置復原架構，請根據不同失敗層級的復原時間目標（RTO）和恢復點目標（RPO）來判斷解決方案的可用性需求。 RTO 是應用程式在事件發生後仍無法使用的最大時間。 RPO 是災害期間數據遺失量上限。 在您判斷解決方案的需求之後，請設計您的架構，以提供已建立的復原和可用性層級。

Azure 上的 Oracle 工作負載主要使用 Oracle Data Guard，這是使用復寫技術的內建 Oracle Database Enterprise Edition 功能。 您可以使用 Data Guard 來滿足高可用性和災害復原需求。 Data Guard 提供三種保護模式：最大效能、最大可用性和最大保護。 根據您的架構設計和特定的 RPO 和 RTO 需求，選擇您的保護模式。

設定工作負載以達到高可用性

執行 Oracle 工作負載的 Azure 虛擬機器 實例受益於 Azure 虛擬機器擴展集 架構，特別是彈性的協調流程模式。 高可用性組態提供近乎實時的數據復寫，並具有潛在的快速故障轉移功能。 高可用性設定不會為 Azure 資料中心層級或區域層級失敗提供保護。

選擇正確的高可用性選項

使用下列流程圖，為您的 Oracle 資料庫選擇最佳的高可用性選項。

此圖顯示 虛擬機器 登陸區域加速器上 Oracle 的服務設計保護程序對應。

在高可用性模式中使用 Data Guard 以達到高可用性

處於最大可用性模式的 Data Guard 為正常作業提供零數據遺失承諾 （RPO=0） 的最高可用性。 針對在 虛擬機器擴展集 彈性協調流程內建立的兩部 Oracle 資料庫伺服器高可用性組態，Azure 會針對分散於容錯網域的實例，為服務等級協定 （SLA） 提供 99.95% 的服務可用性。 Azure 針對分散於 可用性區域的實例，提供 99.99% 的服務可用性。 如需詳細資訊，請參閱 虛擬機器擴展集 高可用性。

此圖顯示 虛擬機器 登陸區域加速器上 Oracle 的 Data Guard 高可用性設定。

如需 Azure 上的 Data Guard 逐步設定，請參閱 在以 Linux 為基礎的 Azure VM 上實作 Oracle Data Guard。

在最大保護模式中使用 Data Guard 以達到高可用性

如果您需要資料庫的交易一致複本，請考慮在最大保護模式中使用 Data Guard。 不過，當待命資料庫無法使用時，最大保護模式不允許交易繼續。 因此，即使您使用 虛擬機器 擴展集彈性協調流程，當您使用最大保護模式時，SLA 會縮減為 99.9% x 99.9% = 99.8%。 此設定可確保一致的數據複本，但不一定會增加可用性。

此架構的其他屬性與最大可用性模式相同。 例如，RPO 為零，而 RTO 小於或等於兩分鐘。

請考慮實作高可用性的其他方式

下列各節說明高可用性的特殊考慮。

使用可用性區域改善高可用性

Azure 可用性區域 是位於相同 Azure 區域內的 Azure 資料中心。 可用性區域的往返延遲少於兩毫秒。 您通常會使用可用性區域進行災害復原，但您可以使用它們來改善高可用性。 如果您這麼做，您必須確定您的解決方案可以使用可用性區域所提供的延遲和輸送量來執行。

具有 虛擬機器擴展集 彈性協調流程的可用性區域優點是您的 VM 可用性 SLA 增加到 99.99%。

使用共用記憶體叢集來取得高可用性

共用記憶體叢集技術提供獨特的屬性，可協助您達成業務目標。 例如，您可以使用共用記憶體來實作 Pacemaker 和 Corosync （PCS） 叢集。 您可以使用受控磁碟或 Azure NetApp Files 作為 PCS 叢集實例的共享記憶體。 PCS 叢集不會重複數據。 它提供虛擬IP服務，其具有靜態IP位址或不會在故障轉移之間變更的IP網路名稱。

注意

PCS 叢集不是 Oracle 認證的解決方案。 當您選擇高可用性架構時，請記住此因素。

此圖顯示適用於 Oracle 的 Pacemaker 在登陸區域加速器上 虛擬機器 高可用性設定。

使用鄰近放置群組

若要提供最低的延遲，請將 VM 盡可能接近。 您可以在鄰近放置群組內部署它們。 鄰近放置群組是邏輯群組，可確保 Azure 計算資源實際位於彼此附近。 鄰近放置群組適用於需要低延遲的工作負載。

設定您的工作負載以進行災害復原

災害復原架構可針對影響 Azure 數據中心或區域的失敗，或針對阻礙整個區域應用程式功能的失敗，提供復原能力。 在這種情況下，您應該將整個工作負載移至不同的數據中心或區域。

根據您的解決方案需求選擇災害復原架構。 您可以根據 RTO 和 RPO 來判斷需求。 災害復原架構適用於例外失敗案例，因此故障轉移程式是手動的。 在高可用性設計中，故障轉移程式是自動的。 在災害復原架構中，您應該對 RTO 和 RPO 有更寬鬆的需求，以節省成本。

本文著重於主伺服器和輔助伺服器都位於 Azure 上的案例。 您也可以在內部部署和 Azure 上擁有主伺服器，以便進行災害復原。 如需詳細資訊，請參閱 Azure 上的主要月台內部部署和災害復原網站。

選擇正確的災害復原選項

使用下列流程圖，為您的 Oracle 資料庫選擇最佳的災害復原選項。

顯示 Oracle 在登陸區域加速器上 虛擬機器 數據保護設計流程圖的圖表。

使用 Data Guard 進行災害復原

您可以使用 Data Guard 將資料復寫至災害復原網站。 根據數據保護的需求，使用該月臺作為相同區域或不同區域中的另一個可用性區域。 您的設定也取決於生產站臺上的可用性區域結構。 災害復原案例中的 Data Guard 實作類似於先前討論的高可用性案例，但有一些重要的差異。 例如：

  • 當您在高可用性案例中故障轉移至次要複本時，您會設定 Azure Load Balancer 將要求重新導向至新的主資料庫實例。

  • 當您故障轉移至災害復原網站時，會將整個解決方案故障轉移至新月臺。 若要避免延遲挑戰，您通常需要設定應用程式服務的故障轉移。

如果災害復原網站位於另一個區域，您必須根據需求來設計故障轉移的月臺。

單一數據中心內的延遲小於彼此隔開的數據中心之間的延遲，遠小於不同區域之間的延遲。 因此，最不複雜且成本最低的選項是針對災害復原目的，在最大效能模式中使用 Data Guard。 如果最大效能模式中的潛在數據遺失太高，您可以搭配 Oracle Data Guard Far Sync 機制使用最大可用性模式。 但 Far Sync 實例會在主要環境和待命環境中觸發 Active Data Guard 授權。 如需詳細資訊，請參閱 Oracle 授權詳細數據。

此外，當您在 Azure 區域或資料中心之間傳送數據時，會針對傳送至災害復原網站的重做記錄等數據支付輸出成本。 如果您不需要復寫資料庫中的所有數據，您可以使用 Oracle Golden Gate 型復寫，視需要只復寫部分數據，進而降低輸出成本。

此圖顯示 虛擬機器 登陸區域加速器上 Oracle 的 Data Guard 災害復原組態。

如需 Azure 上的 Data Guard 逐步設定，請參閱 在以 Linux 為基礎的 Azure Linux VM 上實作 Data Guard。

使用 Golden Gate 進行災害復原

Golden Gate 是一種邏輯複寫軟體，可用於從源資料庫到目標資料庫或多個主資料庫之間的即時復寫、篩選和轉換數據。 這項功能可確保源資料庫中的變更會以近乎即時的方式複寫，讓目標資料庫與最新數據一起為最新狀態。

您可以使用 Golden Gate，將數據從主資料庫複寫到災害復原組態中的輔助資料庫。 如果您只需要保護部分數據，Golden Gate 會特別實用。 若要避免復寫不必要的數據，請使用 Golden Gate 選擇性地復寫數據表，並在復寫期間篩選掉數據表數據列。

如需如何在 Azure 上實作 Golden Gate 的逐步指南，請參閱 在以 Linux 為基礎的 Azure VM 上實作 Golden Gate。

使用備份進行災害復原

備份和還原是災害復原架構的傳統方法。 Azure 上 Oracle 資料庫的災害復原方法有兩個主要元件可供備份：

  • 從資料庫擷取和移動數據的備份，以確保災害復原網站具有最新的數據。

  • 請確定災害復原月臺的最新部署。 若要更新月臺，請將所有網路元件、應用程式伺服器和組態的相同部署複寫至災害復原月臺。

您可以使用數個備份選項來復寫資料。 如需詳細資訊，請參閱 Azure 上 Oracle 資料庫的備份策略。

請考慮使用下列其中一種方法來維護災害復原網站：

方法 1： 若要避免額外的維護工作和成本，請勿在災害復原月臺維護任何實體部署。 您可以使用基礎結構作為程式代碼和網站可靠性工程實務來開發和維護存放庫。 此存放庫可以在故障轉移時，將部署複寫為設定至災害復原月臺。 此方法會優化成本，因為它在故障轉移發生之前不會使用任何實體資源。

重要

如果您在故障轉移期間從頭開始建立整個部署，您必須確定您的部署可以符合解決方案的 RTO 需求。 若要確保部署程式代碼未中斷，您必須定期模擬及測試災害復原案例。

方法 2： 部署和維護生產環境的調整版本。 有一個版本可以針對小型工作負載正常運作，而且您可以在故障轉移期間視需要相應增加，以用於生產負載。 這個方法通常用於您不想要建立整個環境或想要快速故障轉移以提供低 RTO 的複雜部署。

方法 3： 在災害復原網站中部署和維護整個解決方案，以取得最快的 RTO 和故障轉移時間。 由於執行完整備援基礎結構，此方法會增加成本。

請考慮實作災害復原的其他方式

下列各節說明災害復原的特殊考慮。

使用遠距同步處理

Far Sync 不會改善高可用性功能，但您可以使用它來達到 Oracle 資料庫零數據遺失保護功能。 如果您的主資料庫失敗，您的工作負載可能需要零數據遺失。 如需詳細資訊，請參閱 Azure 上的 Oracle 參考架構。

選擇正確的數據復寫技術

除了本文中的技術之外，您還可以使用任何可協助跨兩個 Oracle 資料庫進行數據復寫的技術，為 Azure 上的 Oracle 資料庫維護高可用性複本和災害復原複本。 您選擇的技術必須滿足這些類別的解決方案需求。

延遲： 將更新從主資料庫複寫至輔助資料庫以達到高可用性和災害復原所需的時間，應符合您的解決方案需求。

帶寬： 您需要將數據復寫至輔助資料庫以取得高可用性和災害復原所需的頻寬數量和成本。 Azure 提供可用性區域之間的高速網路基礎結構。 當您考慮復寫至其他 Azure 區域以進行災害復原時，請考慮離開 Azure 資料中心的數據頻寬和輸出成本。

影響： 復寫對主資料庫事務處理的影響層級應符合您解決方案的需求。

數據遺失： 主資料庫突然失敗時所預期的數據遺失量應符合您的解決方案需求。

總擁有成本： 請考慮非Microsoft複寫解決方案的取得成本，以及設定和維護復寫解決方案所需的投入量。 確認這些因素符合您的解決方案需求。

優化故障轉移實例

當您在高可用性模式或高保護模式中使用 Data Guard 時，您可以設定自動故障轉移，以便在主伺服器失敗時自動啟動輔助伺服器。 當您正確設定應用程式伺服器時，可以確保您在故障轉移期間幾乎沒有應用程式停機。

在此實作中，資料庫必須在故障轉移之後執行相同。 因此，您必須將具有相同CPU、記憶體和輸入/輸出 （I/O） 容量的輔助伺服器設定為主伺服器。 您需要使用輔助伺服器來維護高容量，這會增加您的 Azure 成本和 Oracle 資料庫授權成本。 輔助伺服器通常不會處理使用者要求。

Azure 為可用性區域中的 VM 提供 99.9% 的可用性。 如需詳細資訊，請參閱 VM 運行時間 SLA。 當您使用資料復寫技術來維護相同可用性區域中資料庫次要複本、不同可用性區域或不同區域時，您可以將次要容量優化。

使用此方法時，輔助資料庫會設定為需要維持最新狀態的容量。 發生失敗時，輔助資料庫的大小會調整為與主資料庫相同的容量。 只有在發生失敗時，才會發生此作業。 因此，在正常作業期間，您只需支付主伺服器成本的一小部分。 主資料庫在失敗期間無法運作，因此您不需要其他 Oracle 資料庫授權。

作為複寫目的地操作輔助資料庫所需的容量取決於您所使用的複寫技術。 基本上，交易式在線事務處理 （OLTP） 系統上的工作負載主要有讀取要求。 例如，90% 讀取和 10% 寫入作業或 95% 讀取和 5% 寫入作業在 OLTP 應用程式中很常見。 數據復寫基本上會復寫在源資料庫中寫入要求的結果。 透過此設定，您可以預期輔助資料庫會以 1/10 的容量運作（如果您有 90% 的讀取率和 10% 寫入比例）的主資料庫容量。

自動化故障轉移程式，以確保您在故障轉移程式期間符合企業標準。 您可以設定故障轉移程式，以包含伺服器重設大小作業，以簡化端對端程式。

設定服務保護和數據保護的網路拓撲

若要達到高可用性和災害復原，您必須制定財務和商務決策，以平衡復原時間或 RTO，以及潛在的數據遺失或 RPO，以符合其他 Oracle 授權、VM 服務及數據傳輸成本。 當您在單一 Azure VM 上裝載工作負載時，您會以低成本獲得常見硬體失敗的基本保護。 但是單一 VM 上的失敗可能會導致停機時間和數據遺失。 因此，在您的生產環境中，至少有一個次要 Oracle 資料庫裝載於具有 Data Guard 的個別 VM 上。 根據您的需求，使用下列一或多個 Data Guard 組態進行資料複寫：

  • 最佳 RTO 和 RPO。 若要將延遲降到最低，請在相同 虛擬機器擴展集 彈性協調流程和與主資料庫相同的可用性區域中，將次要 Oracle 資料庫併入不同的 VM 上。 此組態提供高可用性和保護，以防止單一實例失敗。

  • 數據中心失敗的數據保護。 將次要 Oracle 資料庫放在第二個可用性區域中，以提供高可用性設定，並在整個可用性區域失敗時提供保護。 此設定在主資料庫和輔助資料庫之間最多可以有兩毫秒的延遲時間，這可能會影響效能、RTO 和 RPO。

  • 防止區域性失敗的數據保護。 為了協助防止因 Azure 區域失敗而導致的潛在資料遺失，您可以將輔助資料庫放在不同的區域中。 此設定在區域之間可以有 30 毫秒到 300 毫秒的延遲，因此您可能不符合 RTO 和 RPO 目標。 此解決方案最適合區域災害復原，而不是高可用性。

商務持續性需要整合式方法，其中包含工作負載的所有元件。 網路基礎結構是 Azure 上任何工作負載的主要元件。 您的網路基礎結構必須符合高可用性或災害復原架構。 請考慮下列網路基礎結構因素：

  • Data Guard 提供高可用性，而且在大部分情況下，都提供足夠的常見失敗支援。 您可以將 VM 放在 虛擬機器擴展集 彈性協調流程中。 為了降低網路等待時間，單一解決方案中的所有服務都應該位於相同的可用性區域內，而服務應該共用相同的虛擬網路。

    為了進一步保護，您可以策略性地將 VM 放在不同的可用性區域中，而不是單一可用性區域。 這種方法可以防止數據中心失敗期間的停機時間。

  • 若要獲得最大保護，您可以將輔助資料庫放在與主資料庫區域不同的 Azure 區域中。 若要套用持續更新，您可以使用 Data Guard 來實作全域虛擬網路對等互連。 使用此方法，透過Microsoft骨幹私下將數據更新套用至次要區域。 資源會直接在沒有閘道、額外躍點或透過公用因特網傳輸的情況下進行通訊。

    此網路選項可在不同區域中的對等互連虛擬網路之間提供高頻寬、低延遲的連線。 您可以使用全域虛擬網路對等互連，透過高速網路，將主要月台聯機到不同區域中的災害復原月臺。

針對各種失敗類型的復原摘要

失敗案例 Azure 上的 Oracle 高可用性或災害復原案例 RPO/RTO
單一元件失敗，例如主機、機架、冷卻、網路或電源故障 Data Guard 中具有相同 虛擬機器擴展集 相同數據中心的彈性協調流程中有兩個節點：

- 防止單一實例失敗。
- 如果整個數據中心失敗，就會造成停機時間。		 如果您使用 Observer 進行快速啟動故障轉移，並針對 Data Guard 使用MAX_AVAILABILITY或MAX_PROTECTION模式：
- RPO 為零。
- RTO 小於或等於 2 分鐘。
數據中心失敗 在個別可用性區域中有兩個節點的 Data Guard：

- 防止數據中心失敗。
- 如果整個區域失敗，就會造成停機時間。
- 需要更多應用程式伺服器的故障轉移設定來管理網路等待時間。		 - RPO 小於或等於 5 分鐘。
- RTO 小於或等於 5 分鐘。

如果您使用 Data Guard 的MAX_PERFORMANCE模式和MAX_AVAILABILITY模式：
- RPO 為零。
- RTO 小於或等於 5 分鐘。
區域失敗 在個別 Azure 區域中有兩個節點的 Data Guard：

- 防止區域性失敗。
- 需要更多應用程式伺服器的故障轉移設定來管理網路等待時間。		 如果您使用 data Guard 的MAX_PERFORMANCE模式：
- RPO 大於或等於 10 分鐘。
- RTO 大於或等於 15 分鐘。
所有案例：單一元件、數據中心和區域失敗 寄送至不同 Azure 區域的備份：

- 防範區域失敗。
- 在故障轉移期間，必須在目標區域中設定整個 Azure 環境。		 - RPO 大於或等於 24 小時。
- RTO 大於或等於 4 小時。

後續步驟

瞭解 Oracle 在企業級案例中 虛擬機器 登陸區域加速器安全性的設計考慮。

虛擬機器 登陸區域加速器上 Oracle 的安全性指導方針