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

發行項
07/11/2023

本文以 BCDR 的 Azure 登陸區域設計區域中定義的一些考慮和建議為基礎。本文可協助您瞭解支援 SAP 平臺之任何登陸區域的唯一條件約束。由於 SAP 是任務關鍵平臺，因此您也應該參閱本檔的 Azure 登陸區域 設計區域 一節中呈現的其他指引，並將其納入您的設計中。

案例和範圍

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

服務與商務程式可用性。
復原時間目標 (RTO) 失敗或災害案例。
失敗案例的復原點目標 (RPOs) 。
作業和生命週期管理工作，以及在失敗案例期間填入的技術。這些管理工作包括修補客體作業系統和資料庫管理系統、複製和重新整理 SAP 系統。

提示

提早同意 SAP 環境中每個原型的高可用性和災害復原 (HADR) 解決方案。請確定所有 SAP 元件都涵蓋在適當的解決方案中。

在 Azure 上提早設定 HADR，至少在一個環境中，讓它保持執行狀態。這麼做可讓小組有機會取得相關技術的經驗，這可能與現有技術不同。早期設定 HADR 也可協助您開發及發展標準作業程式， (SOP) 。

規劃在系統上線時，為生產工作負載提供完整的高可用性、災害復原和備份保護。

本文涵蓋企業規模 SAP 案例的 BCDR 層面如下：

Azure 區域內的高可用性。
備份和還原考慮。
在跨區域與區域災害復原之間決定的準則。

Azure 區域內的高可用性

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

高可用性的設計考慮

針對高可用性，重點在於提供 SAP 軟體單一失敗點的可用性，例如：

資料庫管理系統。
應用程式中的單一失敗點，例如 SAP ABAP 和 ASCS + SCS。範例包括 SAP NetWeaver 和 SAP S/4HANA 架構。
其他工具，例如 SAP Web Dispatcher。

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

SAP 和 SAP 資料庫支援自動容錯移轉叢集。在 Windows 中，Windows Server 容錯移轉叢集支援容錯移轉。在 Linux 中，Linux Pacemaker 或協力廠商工具，例如 SIOS Protection Suite 和 Veritas InfoScale 支援容錯移轉。使用 Azure，您只能在自己的資料中心部署子集高可用性設定。

若要深入瞭解 Azure 如何支援 SAP，請參閱 Azure VM 上 SAP 工作負載的支援案例，以及 SAP HANA 大型實例的支援案例。

針對 DBMS 層，常見的架構模式是同時複寫資料庫，並使用與主要和次要 VM 所使用的儲存體堆疊不同的儲存體堆疊。 Azure 不支援主要和次要 VM 共用 DBMS 資料儲存體的架構。也不會Azure 支援交易或重做記錄。指導方針是使用兩個獨立儲存體堆疊，即使它們是以網路檔案系統 (NFS) 共用為基礎也一樣。當您比較內部部署可能的內容與 Azure 上可能的內容時，此方法是主要限制。

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

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

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

以下是適用于不同高可用性部署選項的平台層級 SLA。提供受控服務的合作夥伴會提供應用層級 SLA。

層	HA 案例	平臺 SLA
第 1 層	可用性區域	99.99%
第 2 層	可用性設定組	99.95%
第 3 層	單一 VM (自我修復)	99.9%

如需詳細資訊，請參閱下一節。

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

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

VM 不會分散到不同的可用性區域。
您可以透過單一可用性設定組部署的 VM 類型會受到限制，因為主機是由部署在集合中的第一個 VM 所定義。其中一個範例結果是您將 M 系列和 E 系列 VM 結合成一個可用性設定組。

跨不同可用性區域部署高可用性架構的優點是，您的服務等級協定 (VM 的 SLA) 可能更高。如需詳細資訊，請參閱 Azure VM SLA。根據 Azure 區域，您可能會發現 VM 之間的網路流量會有不同的網路延遲狀況。如需詳細資訊，請參閱使用 Azure 可用性區域的 SAP 工作負載設定。

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

如果您使用應用程式伺服器層的主動/被動區域部署 (應用程式伺服器必須連線到相同可用性區域中的資料庫) ，請建置自動化和 SOP，以便在資料庫容錯移轉時快速且自動復原。

如果您在 SAP 解決方案中使用可用性區域，請針對區域備援在 SAP 環境中設計所有其他 Azure 服務和基礎結構元件，以便達成真正的區域備援。要考慮的服務與元件範例包括 Azure ExpressRoute 閘道、Azure 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 和資料庫叢集前面使用Standard Load Balancer SKU。
在進階受控 SSD 上執行所有生產系統，並使用 Azure NetApp Files 或 Ultra 磁片儲存體。至少 OS 磁片應位於進階層，以便達到更佳的效能和最佳 SLA。
在可用性設定組或可用性區域中的高可用性配對中部署這兩部 VM。這些 VM 的大小應該相同，且具有相同的儲存體設定。
使用原生資料庫複寫技術，同步處理高可用性配對中的資料庫。
根據作業系統，使用下列其中一項服務來執行 SAP 中央服務叢集：
- SUSE Linux Enterprise Server Pacemaker 叢集。支援 Azure 柵欄代理程式和三個 STONITH 區塊裝置， (SBD) 。
- Red Hat Enterprise Linux Pacemaker 叢集。目前不支援 SBD。僅支援 Azure 柵欄代理程式。
- Windows 叢集。
- SAP 認證的協力廠商叢集軟體。
如中央服務和資料庫叢集檔中的建議，設定叢集逾時參數。

SAP 工作負載的儲存體

選擇正確的儲存體選項是針對 SAP 工作負載進行復原設計的一部分。 Azure 儲存體上 SAP 工作負載的設計旨在將延遲保持在最低且最大化的輸送量。請考慮您的實作，以及下列指引如何協助您針對 SAP on Azure 實作做出架構決策。如需各種儲存體類型及其與 SAP 工作負載和元件相容性的資訊，請參閱適用于 SAP 工作負載的 Azure 儲存體類型。
您應該只在 SAP 認證的儲存體類型上執行 SAP HANA on Azure。請注意，某些磁片區必須在適用的情況下在特定磁片組態上執行。這些設定包括啟用寫入加速器和使用進階儲存體。您也必須確定在儲存體上執行的檔案系統與電腦上執行的 DBMS 相容。如需詳細資訊，請參閱 SAP HANA 的儲存體組態。

除了連結至 VM 的 Azure 受控資料磁片之外，各種 Azure 原生共用儲存體解決方案也可用來在 Azure 上執行 SAP 應用程式。您的高可用性設定可能會有所不同，因為 Azure Site Recovery不支援 Azure 上提供的某些儲存體服務。下列儲存體類型通常用於 SAP 工作負載。

儲存體類型	高可用性組態支援
Azure 共用磁片 (LRS 或 ZRS)	Windows Server 容錯移轉叢集。如需設定詳細資料，請參閱使用 Windows Server 容錯移轉叢集設計 SAP HA 。
Azure 檔案儲存體 (LRS 或 ZRS) 上的 NFS	以 Pacemaker 為基礎的 Linux 環境叢集。請務必檢查不同區域中 NFS 的可用性。
Azure NetApp Files上的 NFS	以 Pacemaker 為基礎的 Linux 環境叢集。如需詳細資訊，請參閱SAP 虛擬機器Azure NetApp Files。
Azure 檔案儲存體 (LRS 或 ZRS 上的 SMB)	Windows Server 容錯移轉叢集。如需設定詳細資料，請參閱Windows 上 Azure VM 上的 SAP NetWeaver 高可用性，以及適用于 SAP 應用程式的進階 SMB Azure 檔案儲存體。
Azure NetApp Files上的 SMB	Windows Server 容錯移轉叢集。如需設定詳細資料，請參閱Windows 上 Azure VM 上的 SAP NetWeaver 高可用性，以及適用于 SAP 應用程式的 Azure NetApp Files (SMB) 。

您可以使用以 DRBD 複寫) 、GlusterFS 或叢 (集儲存空間直接存取共用磁片區為基礎的傳統 NFS 叢集，而不是使用 Azure 原生共用儲存體服務，作為替代的共用儲存體解決方案，以在 Azure 上執行 SAP 工作負載。當目標 Azure 區域中無法使用 Azure 原生共用儲存體服務或不支援目標架構時，這些選項特別有用。如需儲存體服務可用性的相關資訊，請參閱依區域排序的 Azure 產品。
若要瞭解 Azure 上 SAP 工作負載可用的儲存體選項，請參閱設定災害復原的儲存體建議和指導方針。

備份與還原

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

雖然備份和還原通常不會被視為生產 SAP 工作負載的適當高可用性解決方案，但技術提供其他優點。大部分使用 SAP 應用程式的公司都必須遵循需要備份儲存數年之合規性法規。也必須有備份，而且能夠在其他案例中從中還原備份。假設您已建立並遵循 SAP 應用程式的備份和還原最佳做法，這表示您可以：

在任何符合 RTO 的時間範圍內，為您的生產資料庫執行時間點復原。時間點復原通常會提供保護，防止操作員錯誤，例如刪除 DBMS 層或透過 SAP 的資料。
維護存放區以保留長期備份，以符合合規性法規。
使用資料庫備份來複製 SAP 系統，並將備份還原到另一部伺服器或 VM。
使用資料庫備份的生產資料庫資料來重新整理非生產系統。
備份 SAP 應用程式伺服器和 VM、磁片或 VM 快照集。

當您備份和還原內部部署時，您必須將這些功能帶入 Azure 中的 SAP 系統。

如果您滿意目前的解決方案，請檢查備份廠商是否支援 Azure 部署，或它是否有軟體即服務 (SaaS) 解決方案。

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

備份和還原的設計建議

您可以使用Azure 備份來備份 SAP 應用程式伺服器和中央服務 VM。
您可以針對最多 8 TB 的 HANA 部署使用 SAP HANA 備份。如需詳細資訊，請參閱在 Azure VM 上備份 SAP HANA 資料庫的支援矩陣。
如果您使用 IaaS 備份解決方案，請調整備份基礎結構的大小，以確保它可以同時備份所有生產大小的系統，或在預期的時間範圍內，以及使用生產設定或類似的設定，以網路、安全性等方式備份所有生產大小系統。
測試備份和復原時間，以確認它們是否符合災害後同時還原所有系統的 RTO 需求。
在理想情況下，請避免將備份從 Azure 提取到內部部署備份基礎結構，特別是針對大型資料庫。這樣做會影響 ExpressRoute 線路使用的頻寬量。
將備份和復原工具負載測試為效能測試計劃的一部分。

災害復原

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

災害復原的設計考慮

Azure 區域對應顯示超過 65 個 Azure 區域，並非所有區域都會執行相同的服務。對於較大的 SAP 軟體部署，特別是使用 SAP HANA 的部署，請尋找提供 Azure M 系列或 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 協力廠商軟體的組合。
如果發生災害，Azure 區域中的多個受影響的客戶會想要容錯移轉至對應的配對 DR 區域。這種情況會導致資源競爭，以在 DR 區域中啟動休眠的 VM。因應措施是在 DR 區域中執行非生產系統，並使用相同的資源來裝載生產系統的 DR 複本。在 DR 區域中，這種雙重用途的 Azure 基礎結構可協助您避免資源容量限制。

另一個重要考慮是保護災害區域中所需的作業容量。如果發生災害，您可能需要以最少的 IT 容量執行 SAP 應用程式，而且只有在您工作在主要區域中復原正常作業時，才需要有重要的人力資源來執行 SAP 應用程式。這需要您在 DR 區域中提供最少的 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 連線。
除了使用 ExpressRoute，請考慮設定從內部部署到主要和次要 Azure 災害復原區域的 VPN 連線。
使用Site Recovery將應用程式伺服器複寫至災害復原網站。 Site Recovery也可以協助您將中央服務叢集 VM 複寫至災害復原網站。當您叫用災害復原時，您必須在災害復原網站上重新設定 Linux Pacemaker 叢集。例如，您需要取代 VIP 或 SBD、執行 corosync.conf 等等。
複寫金鑰保存庫內容，例如跨區域憑證、秘密或金鑰，以便您將 DR 區域中的資料解密。
在目前處於公開預覽) (Azure NetApp Files中使用跨區域複寫，同步處理主要區域與災害復原區域之間的檔案磁片區。
使用原生資料庫複寫，而不是Site Recovery，將資料同步處理至災害復原網站。
將主要和災害復原虛擬網路對等互連。例如，針對 HANA 系統複寫，SAP HANA DB 虛擬網路必須對等互連至災害復原網站的 SAP HANA DB 虛擬網路。
如果您針對 SAP 部署使用Azure NetApp Files儲存體，至少請在兩個區域中，在進階層中建立兩個Azure NetApp Files帳戶。
請考慮根據系統的商業重要性和相依性，根據應用程式效能來分組系統。將每個群組部署到配對區域建構中的個別區域，以將區域性中斷的業務影響降到最低。例如，兩個提供兩個不同業務單位的重要 ECC 系統可以在英國南部和英國西部部署，以將區域性中斷的影響降到最低。

下一步

Azure 中的 SAP 部署選項

共用方式為