SAP 移轉的商務持續性和災害復原

本文以 BCDR 的 Azure 登陸區域設計區域中的考慮和建議為基礎。 本文說明支援 SAP 平臺之登陸區域的唯一條件約束。 SAP 是任務關鍵性平臺，因此您也應該將其他 任務關鍵性指引 納入您的設計。

案例和範圍

將原則併入您的架構，以解決內部部署商務持續性和災害復原 （BCDR） 案例。 這些原則也適用於 Azure。 但 Azure 的硬體容量可能比內部部署環境多，以補償主機失敗。 若要自動復原甚至最大的 Azure 虛擬機（VM），您可以將它們設定為在另一部伺服器上重新啟動。 設定您的 Azure 部署，以使用與內部部署部署相同的條件。 如果您使用自動故障轉移叢集組態來部署內部部署系統或裸機硬體，請在 Azure 上以相同方式部署它們。 執行組織最重要商務程式的 SAP 應用程式需要：

• 服務和商務程式可用性。

• 失敗案例或災害案例的復原時間目標（RTO）。

• 失敗案例的恢復點目標（RPO）。

• 在失敗案例期間執行的作業和生命週期管理工作和技術。 這些管理工作包括修補客體作業系統和資料庫管理系統、複製和重新整理 SAP 系統。

提示

儘早判斷 SAP 環境中每個原型的高可用性和災害復原 （HADR） 解決方案。 請確定解決方案涵蓋所有 SAP 元件。

在 Azure 上早期、至少在一個環境中設定 HADR 解決方案，並讓它保持作用中。 然後，您的小組可以取得解決方案技術的經驗，這可能與現有的技術不同。 儘早設定HADR，以協助開發和發展標準作業程式（SOP）。

規劃在系統上線後立即完成生產工作負載的高可用性、災害復原和備份保護。

本文涵蓋適用於企業級 SAP 案例的 BCDR 下列層面：

• Azure 區域內的高可用性

• 備份和還原考量

• 在跨區域和區域災害復原之間決定的準則

Azure 區域內的高可用性

下列各節提供 SAP 企業案例 Azure 區域內高可用性的設計考慮和建議。

高可用性的設計考慮

當您實作高可用性時，目標是提供 SAP 軟體單一失敗點的可用性，例如：

• 資料庫管理系統。

• 應用程式中的單一失敗點，例如 SAP 進階商務應用程式程式設計（ABAP）、ABAP SAP 中央服務（ASCS）和 SAP 中央服務（SCS）。 高可用性範例包括SAP NetWeaver和SAP S/4HANA架構。

• 其他工具，例如 SAP Web Dispatcher。

在其他案例中，請勿限制基礎結構失敗或軟體失敗的可用性。 將可用性套用至所有必要的生命週期管理工作。 例如，您可以修補 VM 中的 OS、資料庫管理系統 （DBMS） 和 SAP 軟體。 若要將計劃性停機和生命週期管理作業期間可能發生的中斷降到最低，請使用一般工具來協助保護您的系統免於發生非計劃性服務中斷。

SAP 和 SAP 資料庫支援自動故障轉移叢集。 在 Windows 中，Windows Server 2022 故障轉移叢集功能支援故障轉移。 在Linux中，Linux Pacemaker或SIOS Protection Suite 和 Veritas InfoScale 等合作夥伴工具支援故障轉移。 在 Azure 中，您只能在自己的資料中心部署子集高可用性設定。

如需詳細資訊，請參閱 Azure VM 上 SAP 工作負載的支援案例和 SAP HANA 大型實例的支援案例。

針對 DBMS 層，常見的架構模式是同時復寫資料庫，且記憶體堆疊與主要 VM 和次要 VM 所使用的記憶體堆疊不同。 Azure 不支援主要 VM 和次要 VM 共用 DBMS 資料記憶體的架構。 Azure 也不支援事務歷史記錄或重做記錄。 指導原則是使用兩個獨立的儲存堆疊，即使它們是以網路文件系統 （NFS） 共用為基礎也一樣。 這些限制專屬於 Azure 解決方案，而不是內部部署解決方案。

Azure 提供其他選項，因為它支援 NFS 和伺服器消息塊共用。 您可以在 Windows 中使用 Azure 共用磁碟 ，以使用 ASCS 和 SCS 元件和特定的高可用性案例。 針對 SAP 應用層元件和 DBMS 層，分別設定故障轉移叢集。 Azure 不支援將 SAP 應用層元件和 DBMS 層結合成一個故障轉移叢集的高可用性架構。

SAP 應用層元件和 DBMS 層的大部分故障轉移叢集都需要故障轉移叢集的虛擬IP位址。 常見的例外狀況是當您使用不需要虛擬IP位址的Oracle Data Guard 時。 Azure Load Balancer 應該處理所有其他案例的虛擬IP位址。 您可以針對每個叢集組態使用一個負載平衡器。 建議您使用標準版本的負載平衡器。 如需詳細資訊，請參閱 SAP 高可用性案例中使用標準 Azure Load Balancer 的 VM 公用端點連線。

如需詳細資訊，請參閱 SAP NetWeaver 的高可用性架構和案例。

下表顯示各種高可用性部署選項的平臺層級服務等級協定 （SLA）。 提供受控服務的合作夥伴也會提供應用層級 SLA。

層	高可用性案例	平臺 SLA
1	可用性區域	99.99%
2	可用性設定組	99.95%
3	單一 VM （自我修復）	99.90%

Azure 可用性設定組與可用性區域

在您部署高可用性基礎結構之前，請根據您選擇的區域，判斷要使用 Azure 可用性設定組或可用性區域進行部署。 您使用可用性設定組部署的 VM 主要差異如下：

• VM 不會分散到不同的可用性區域。

• 您可以透過單一可用性設定組部署的 VM 類型會受到限制，因為您在集合中部署的第一個 VM 會定義主機。 例如，您無法將 M 系列 VM 和 E 系列 VM 合併成一個可用性設定組。

當您跨不同可用性區域部署高可用性架構時，您可以擁有較高的 VM SLA。 如需詳細資訊，請參閱 Azure VM SLA。 根據 Azure 區域，您可能會在 VM 之間的網路流量中探索不同的網路等待時間條件。 如需詳細資訊，請參閱 使用 Azure 可用性區域的 SAP 工作負載設定。

如果您選擇區域性部署方法，請考慮所選 Azure 區域的跨區域延遲如何影響效能和架構設計選擇。 請考慮應用程式伺服器與資料庫之間的延遲，以及兩個資料庫節點之間的延遲。

如果您針對應用程式伺服器層使用主動/被動區域部署，其中應用程式伺服器必須連線到相同可用性區域中的資料庫，請設定自動化，並建立 SOP，以便在資料庫故障轉移發生時快速且自動復原。

如果您在 SAP 解決方案中使用可用性區域，請在 SAP 環境中設計所有其他 Azure 服務和基礎結構元件，以獲得區域備援，以便達成真正的區域備援。 要考慮的服務與元件範例包括 Azure ExpressRoute 閘道、Load Balancer、Azure 檔案儲存體、Azure NetApp Files、反向 Proxy、防火牆、防病毒軟體服務和備份基礎結構。

高可用性的設計建議

• Azure 提供數個選項來協助您符合應用程式的基礎結構 SLA。 您應該為這三個 SAP 元件選擇相同的選項：中央服務、應用程式伺服器和資料庫。 如需 VM、可用性設定組和可用性區域 SLA 的詳細資訊，請參閱適用於 線上服務 的 SLA。

• 當您在可用性設定組中部署 VM 時，與容錯和更新網域的一致性可防止 VM 位於相同的主機硬體上，進而防止硬體故障。 當您透過可用性區域部署 VM 並使用不同的區域時，您會在不同的實體位置建立 VM。 此設定可針對影響整個區域數據中心的電源、冷卻或網路問題提供額外的保護。 但是，除非您使用 鄰近放置群組，否則您無法在 Azure 可用性區域內部署 Azure 可用性設定組。

  如果您選擇區域性部署方法，SAP DBMS、中央服務和應用層會在不同的可用性區域中執行。 但每個可用性區域最有可能有多個應用程式伺服器。 在此案例中，每個區域中的應用程式伺服器不會自動受益於容錯網域和更新網域。 您可以使用可用性設定組來取得這些優點。 如需詳細資訊，請參閱 Azure 鄰近放置群組，以取得 SAP 的最佳網路等待時間。

• 當您建立可用性設定組時，請使用可用的容錯網域數目上限和更新網域。 例如，如果您在一個可用性設定組中部署兩個以上的 VM，請使用容錯網域數目上限 （三個）。 此外，使用足夠的更新網域來限制潛在的實體硬體故障、網路中斷或電源中斷的影響，以及 Azure 計劃性維護。 容錯網域的預設數目為兩個，且您無法稍後在在線進行變更。

• 在可用性設定組部署中，SAP 系統的每個元件都必須位於自己的可用性設定組中。 SAP 中央服務、資料庫和應用程式 VM 應該位於自己的可用性設定組中。

• 當您在可用性設定組部署中使用 Azure 鄰近放置群組時，請確定這三個 SAP 元件（中央服務、應用程式伺服器和資料庫）都位於相同的鄰近放置群組中。

• 如果您使用鄰近放置群組，請針對每個 SAP 系統識別 （SID） 使用一個。 群組不會跨越可用性區域或 Azure 區域。

• 當您在可用性區域部署中使用 Azure 鄰近放置群組時，請確定兩個 SAP 元件（中央服務和應用程式伺服器）都位於相同的鄰近放置群組中。 這兩個區域中的資料庫 VM 不再是鄰近放置群組的一部分。 每個區域的鄰近放置群組的範圍是執行 SAP ASCS 和 SCS 實例的 VM 部署。 此組態的優點是您可以彈性地調整 VM 的大小。 您也可以輕鬆地切換至 DBMS 層或 SAP 系統應用層中的新 VM 類型。

• Azure 不支援在單一 Linux Pacemaker 叢集中結合 ASCS 和資料庫高可用性。 將它們分成個別叢集。 您可以在一對 VM 中結合多達五 個多個中央服務叢集 。

• 在 ASCS 和資料庫叢集前面使用標準 Load Balancer。

• 在 Azure 進階 SSD 上執行所有生產系統，並使用 Azure NetApp Files 或 Azure Ultra 磁碟記憶體。 請至少確定 OS 磁碟位於進階層，以便改善效能並取得最佳 SLA。

• 在可用性設定組或可用性區域中的高可用性配對中部署這兩部 VM。 請確定這些 VM 的大小相同，且具有相同的記憶體組態。

• 使用原生資料庫復寫技術來同步處理高可用性配對中的資料庫。

• 視作業系統而定，使用下列其中一項服務來執行 SAP 中央服務叢集：

  • SUSE Linux Enterprise Server Pacemaker 叢集支援 Azure 柵欄代理程式，以及多達三個節點隔離裝置。

  • Red Hat Enterprise Linux Pacemaker 叢集支援 Azure 隔離代理程式，且不支持節點隔離裝置。

  • Windows 叢集。

  • SAP 認證的非Microsoft叢集軟體。

• 如中央服務和資料庫叢集檔中的建議，設定叢集逾時參數。

SAP 工作負載的記憶體

• 當您在 SAP 工作負載中設計復原功能時，請選擇正確的記憶體選項。 SAP 工作負載的適當 Azure 記憶體設計可將延遲降到最低，並將輸送量最大化。 請考慮您的實作，以及下列指引如何協助您為 SAP on Azure 實作做出架構決策。 如需詳細資訊，請參閱 SAP 工作負載的 Azure 記憶體類型。

• 您應該只在 SAP 認證的記憶體類型上，在 Azure 上執行 SAP HANA。 您必須在特定磁碟組態上執行特定磁碟區。 例如，組態可能會啟用寫入加速器或使用進階 SSD 記憶體。 您也必須確定在記憶體上執行的檔案系統與電腦上執行的 DBMS 相容。 如需詳細資訊，請參閱 SAP HANA 的記憶體組態。

• 除了連結至 VM 的 Azure 受控數據磁碟之外，各種 Azure 原生共用記憶體解決方案也會在 Azure 上執行 SAP 應用程式。 您的高可用性設定可能會有所不同，因為 Azure Site Recovery 不支援 Azure 上提供的一些記憶體服務。 針對 SAP 工作負載使用下列記憶體類型。

  儲存體類型	高可用性組態支援
  Azure 共用磁碟（本地備援記憶體 （LRS） 或區域備援記憶體 （ZRS））	Windows Server 2022 故障轉移叢集。 如需設定詳細數據，請參閱 使用 Windows Server 2022 故障轉移叢集設計 SAP 高可用性。
  Azure 檔案儲存體 上的 NFS （LRS 或 ZRS）	以 Pacemaker 為基礎的 Linux 環境叢集。 請務必檢查 各種區域中 NFS 的可用性。
  Azure NetApp Files 上的 NFS	以 Pacemaker 為基礎的 Linux 環境叢集。 如需詳細資訊，請參閱 適用於 SAP VM 的 Azure NetApp Files。
  Azure 檔案儲存體 上的 SMB （LRS 或 ZRS）	Windows Server 2022 故障轉移叢集。 如需設定詳細數據，請參閱使用 Azure 檔案儲存體 SMB 安裝高可用性 SAP NetWeaver。
  Azure NetApp Files 上的 SMB	Windows Server 2022 故障轉移叢集。 如需組態詳細數據，請參閱 SAP NetWeaver 與適用於 SAP 應用程式的 Azure NetApp Files （SMB） 高可用性。

• 您可以使用傳統NFS 叢集（根據分散式複寫區塊裝置複寫）、GlusterFS 或叢集共用磁碟區，搭配 儲存空間直接存取 作為替代的共用記憶體解決方案，在 Azure 上執行 SAP 工作負載，而不是 Azure 原生共用記憶體服務。 當目標 Azure 區域無法使用 Azure 原生共用記憶體服務或不支援目標架構時，這些選擇特別有用。 如需記憶體服務可用性的詳細資訊，請參閱 依區域排序的 Azure 產品。

• 如需 Azure 上 SAP 工作負載可用之記憶體選項的相關信息，請參閱 設定災害復原的記憶體建議和指導方針。

備份和還原

下列各節說明 SAP 案例中備份和還原的設計考慮和建議。

雖然備份和還原通常不是生產 SAP 工作負載的適當高可用性解決方案，但這項技術提供其他優點。 大部分使用 SAP 應用程式的公司都需要遵循需要長期儲存備份的合規性法規。 在其他案例中，您也需要有可從中還原的備份。 本指南假設您已建立備份和還原，並遵循 SAP 應用程式的最佳做法，這表示您可以：

• 在任何符合 RTO 的時間範圍內，為您的生產資料庫執行時間點復原。 時間點復原通常提供保護，防止操作員錯誤，例如刪除 DBMS 層或透過 SAP 的數據。

• 維護存放區以保留您的長期備份，以符合合規性法規。

• 使用資料庫備份來複製 SAP 系統，並將備份還原到另一部伺服器或 VM。

• 使用來自資料庫備份的生產資料庫數據來重新整理非生產系統。

• 備份 SAP 應用程式伺服器和 VM、磁碟或 VM 快照集。

• 備份已啟用複寫的 SAP HANA 系統。

• 備份 SAP HANA 資料庫實例快照集。

如果您備份和還原內部部署，您必須將這些功能帶入 Azure 中的 SAP 系統。 如果您想要目前的解決方案，請檢查備份廠商是否支援 Azure 部署，或是否有適用於 Azure 的軟體即服務解決方案。。

Azure 提供名為 Azure 備份 的備份 SaaS 服務，它會擷取 VM 快照集及管理串流 SQL Server 和 SAP HANA 備份。 如果您使用 Azure NetApp Files 來儲存 SAP HANA 資料庫，您可以根據 HANA 一致的記憶體快照集來執行備份。

您也可以使用 Azure 備份 來備份已啟用 SAP HANA 系統複寫 （HSR） 的資料庫。 Azure 備份 在發生故障轉移時自動管理備份，並不需要手動介入。 備份也提供：

• 立即保護，而不需要補救完整備份，因此您可以保護 HANA 實例或 HSR 設定節點做為單一 HSR 容器。

• 立即備份和立即還原的優點。

• 與適用於 SAP HANA 的 Backint 整合的 HANA 一致快照式方法。 您可以針對整個 HANA 環境以及任何資料庫大小，使用備份作為單一產品。

如需詳細資訊，請參閱 已啟用複寫的 SAP HANA 資料庫系統，以及 SAP HANA 實例快照集備份。

備份和還原的設計建議

• 您可以使用 Azure 備份 來備份 SAP 應用程式伺服器和中央服務 VM。

• 您可以針對最多 8 TB 的 HANA 部署使用 SAP HANA 備份。 如需詳細資訊，請參閱 Azure VM 上 SAP HANA 資料庫的備份支援矩陣。

• 如果您使用基礎結構即服務備份解決方案，請調整備份基礎結構的大小，以確保它可以同時備份所有生產大小的系統，或在預期的時間範圍內，例如在實際案例中。 針對網路和安全性等區域，請使用生產設定或類似的設定。

• 測試備份和復原時間，以確認它們符合 RTO 需求，以便在災害發生後同時還原所有系統。

• 在理想情況下，請避免將備份從 Azure 提取到內部部署備份基礎結構，特別是針對大型資料庫。 此方法可能會影響 ExpressRoute 線路所使用的頻寬。

• 負載測試備份和復原工具，作為效能測試計劃的一部分。

災害復原

下列各節說明 SAP 案例中災害復原的設計考慮和建議。

災害復原的設計考慮

Azure 區域對應包含超過 65 個 Azure 區域，並非所有區域都執行相同的服務。 針對較大的 SAP 軟體部署，特別是使用 SAP HANA 的部署，尋找提供 Azure M 系列 VM 或 Mv2 系列 VM 的 Azure 區域。 Azure 儲存體 也會配對不同的區域，將較小的記憶體類型子集復寫到另一個區域。 如需詳細資訊，請參閱 Azure 配對區域概觀。

為 SAP 工作負載配對 Azure 區域的主要挑戰包括：

• 配對不一定與 M 系列或Mv2系列 VM 服務一致。 部署 SAP 系統的許多組織不會使用 Azure 配對區域。 相反地，他們會根據所需的 VM 類型可用性來選擇區域。

• 您可以在配對區域之間復寫標準記憶體，但無法使用標準記憶體來儲存資料庫或虛擬硬碟。 您只能在您使用的配對區域之間復寫備份。 針對所有其他數據，請使用 SQL Server Always On 或 SAP HANA 系統複寫等原生 DBMS 功能來執行複寫。 針對 SAP 應用層使用 Site Recovery、工具，例如 rsync 或 robocopy和其他非Microsoft軟體的組合。

• 如果發生災害，Azure 區域中多個受影響的客戶會故障轉移至對應的配對災害復原區域。 這種情況會導致資源競爭，使災害復原區域中的休眠 VM 處於休眠狀態。 因應措施是在災害復原區域中執行非生產系統，並使用相同的資源來裝載生產系統的災害復原複本。 此災害復原區域中 Azure 基礎結構的雙重用途使用可協助您避免資源容量限制。

另一個重要考慮是保護災害區域中所需的作業容量。 如果發生災害，您可能需要以最少的 IT 容量執行 SAP 應用程式，而且只有在您工作以復原主要區域中的正常作業時，才需要執行 SAP 應用程式。 此策略需要您在災害復原區域中提供最少的IT基礎結構。

定義 Azure 區域之後，您必須選擇部署模式：

• 您要將生產系統部署到主要區域嗎？

• 您是否會將非生產 SAP 系統部署到災害復原區域？

• 您是否會使用將所有 SAP 系統分組到主要區域的架構？ 此設定可確保災害復原區域僅用於災害復原。

大部分的組織都會針對操作系統使用這兩個區域。 以企業回歸測試系統的形式執行完整生產系統複本的組織通常會計劃使用SAP產品線的商業回歸測試系統作為災害復原目標。

當您選擇災害復原區域時，請務必具有該區域的 ExpressRoute 連線能力。 如果您有多個 ExpressRoute 線路連線到 Azure，則至少有一個線路必須連線到主要 Azure 區域。 其他人應該連線到災害復原區域。 這種類型的架構會將您連線到不同地理或地緣政治區域中的 Azure 網路，並在災害影響其中一個 Azure 區域時協助保護您的連線。

某些組織會使用高可用性和災害復原架構的組合，其會將高可用性與相同 Azure 區域中的災害復原分組。 但是，將高可用性與災害復原分組並不理想。 Azure 可用性區域 支援此架構。 一個 Azure 區域內可用性區域之間的距離不如兩個 Azure 區域之間的距離，因此自然災害可能會危及其發生所在區域中的應用程式服務。 您也需要考慮 SAP 應用程式伺服器與資料庫伺服器之間的延遲。 根據 SAP 附注1100926，往返時間小於或等於 0.3 毫秒是不錯的值，且小於或等於 0.7 毫秒的時間是中等值。 因此，對於高延遲的區域，請具備作業程式，以確保 SAP 應用程式伺服器和資料庫伺服器一律在相同的區域中執行。 組織會基於下列原因選擇此架構：

• 合規性足以支持生產部署與災害復原目標之間的較小距離的設定。

• 數據主權是一個因素。

• 涉及地緣政治因素。

• 這是支援區域性失敗的低成本選項，有時會結合備份傳輸至次要區域，以取得影響大半徑的自然災難。

當您選擇災害復原區域時要考慮的另一個因素是 RPO 和 RTO，可用來故障轉移至災害復原網站。 生產區域與災害復原區域之間的距離愈高，網路等待時間就越高。 您可以在 Azure 區域之間以異步方式複寫，但網路等待時間可能會影響您可以復寫的輸送量和 RPO 目標。 若要將 RPO 降到最低，您可以使用合併的高可用性和災害復原架構。 但是，這種設定可能會對大規模自然災害造成更高的風險。

災害復原的設計建議

• 請確定主要虛擬網路的無類別網路域間路由 （CIDR） 不會與災害復原月台虛擬網路的 CIDR 衝突或重疊。

• 設定從內部部署到主要和次要 Azure 災害復原區域的 ExpressRoute 連線。

• 請考慮設定從內部部署到主要和次要 Azure 災害復原區域的 VPN 連線。 使用此方法作為使用 ExpressRoute 的替代方法。

• 使用 Site Recovery 將應用程式伺服器複寫至災害復原網站。 Site Recovery 也可以協助您將中央服務叢集 VM 複寫至災害復原網站。 當您叫用災害復原時，您必須在災害復原網站上重新設定Linux Pacemaker 叢集。 例如，您可能需要取代虛擬IP位址或SBD，或執行 corosync.conf。

• 跨區域復寫憑證、秘密或密鑰等金鑰保存庫內容，以便解密災害復原區域中的數據。

• 在 Azure NetApp Files 中使用跨區域複寫，同步處理主要區域與災害復原區域之間的檔案磁碟區。

• 使用原生資料庫複寫，而不是 Site Recovery，將數據同步處理至災害復原網站。

• 將主要和災害復原虛擬網路對等互連。 例如，針對 HANA 系統複寫，您必須將 SAP HANA DB 虛擬網路對等互連至災害復原網站的 SAP HANA DB 虛擬網路。

• 如果您使用 Azure NetApp Files 記憶體進行 SAP 部署，請至少在進階層的兩個區域中建立兩個 Azure NetApp Files 帳戶。

• 請考慮根據系統的商業重要性和相依性，根據應用程式效能來分組系統。 若要將區域中斷的業務影響降至最低，請將每個群組部署到配對區域建構中的個別區域。 例如，若要將區域中斷的影響降到最低，您可以在英國南部和英國西部部署兩個服務兩個不同業務單位的重要 ERP 中央元件系統。

後續步驟

Azure 中 SAP 的部署選項