共用方式為

使用 Azure 可用性區域的 SAP 工作負載設定

  • 發行項

除了在 Azure 可用性設定組中部署各種 SAP 結構層，Azure 可用性區域也可用於 SAP 工作負載部署。 Azure 可用性區域定義為：「區域內的唯一實體位置。 每個區域皆由一或多個配備獨立電力、冷卻系統及網路的資料中心所組成」。 不是所有區域都提供 Azure 可用性區域。 關於哪些 Azure 區域提供可用性區域，請查看 Azure 區域地圖。 此地圖顯示哪些區域提供或宣佈提供可用性區域。

從典型的 SAP NetWeaver 或 S/4HANA 架構開始，您需要保護三個不同的層級：

  • SAP 應用程式層，可以是一到數十部 VM。 您想要將 VM 部署在相同主機伺服器上的機會降到最低。 也建議讓 VM 儘可能靠近 DBMS 層，將網路延遲保持在可接受的程度內
  • SAP ASCS/SCS 層，代表 SAP NetWeaver 和 S/4HANA 架構中的單一失敗點。 您通常會查看您想要涵蓋容錯移轉架構的兩個 VM。 因此，這些 VM 應該配置在不同的基礎結構容錯網域中
  • SAP DBMS 層，其也代表單一失敗點。 通常由容錯移轉架構所涵蓋的兩個 VM 組成。 因此，這些 VM 應該配置在不同的基礎結構容錯網域和更新網域中。 SAP Hana 向外延展部署是例外，其中可使用兩個以上的 VM

透過可用性設定組或可用性區域來部署必要 VM 的主要差異如下：

  • 透過可用性設定組來部署會將設定組內的 VM 排入單一區域或資料中心 (以何者適用於特定區域為準)。 因此，萬一發生電力、冷卻或網路問題而影響到整個區域的資料中心，透過可用性設定組來部署無法幸免於難。 好處是 VM 與該區域或資料中心內的更新網域和容錯網域一致。 特別是針對每個可用性設定組保護兩個 VM 的 SAP ASCS 或 DBMS 層，與容錯網域的一致性可防止這兩部 VM 都位於相同的主機硬體上。
  • 透過 Azure 可用性區域 部署 VM，並選擇不同的區域（最多三個可能），會跨不同的實體位置部署 VM，並新增對影響整個區域數據器之電源、冷卻或網路問題的保護。 不過，隨著您將相同 VM 系列的多個 VM 部署至相同的可用性區域，就難以避免這些 VM 最後落在相同的主機或相同的容錯網域上。 因此，透過可用性區域來部署很適合 SAP ASCS 和 DBMS 層，其中我們通常在各層看到兩個 VM。 至於 SAP 應用程式層，其中遠超過兩個 VM，您可能需要退回到不同的部署模型 (請參閱下文)

您想跨 Azure 可用性區域來部署，理由除了彌補單一必要 VM 的缺失，或在緊要關頭修補軟體時能夠避免停機之外，背後的動機應該是萬一發生更大的基礎結構問題而可能影響一或多個 Azure 資料中心的可用性，還能夠幸免於難。

作為另一個復原部署功能，Azure 引進了 具有 SAP 工作負載彈性協調流程 的虛擬機擴展集。 虛擬機擴展集提供平臺受控虛擬機的邏輯群組。 虛擬機擴展集的彈性協調流程提供選項，可在區域內建立擴展集，或跨越可用性區域。 在建立時，具有 platformFaultDomainCount>1 （FD>1） 的區域中彈性擴展集，擴展集中部署的 VM 會分散到相同區域中的指定容錯網域數目。 另一方面，使用 platformFaultDomainCount=1（FD=1） 跨可用性區域建立彈性擴展集，會將虛擬機分散到不同的區域，而擴展集也會以最佳方式將 VM 分散到每個區域內的不同容錯網域。 僅支援具有 FD=1 的 SAP 工作負載彈性擴展集。 搭配 FD=1 使用彈性擴展集進行跨區域部署的優點，而不是傳統的可用性區域部署，就是使用擴展集部署的 VM 會以最佳方式分散到區域內的不同容錯網域。 如需詳細資訊，請參閱 SAP 工作負載彈性擴展集的部署指南。

在可用性區域上進行部署的考量事項

使用可用性區域時請考量下列事項：

  • Azure 可用性區域之間的網路往返延遲上限會記載於區域和可用性區域文件中。
  • 遇到過網路往返延遲不一定表示形成不同區域之資料中心的實際地理距離。 網路往返延遲也會受到這些不同資料中心之間纜線連接與纜線路由的影響。
  • 可用性區域不是理想的 DR 解決方案。 自然災害可能會造成世界各地區廣泛的破壞，包括電力基礎設施的嚴重破壞。 不同區域之間的距離可能不夠大，無法構成適當的 DR 解決方案。
  • 可用性區域間的網路延遲，並非在所有 Azure 區域中都相同。 在某些情況下，您可以跨不同區域部署及執行 SAP 應用程式層，因為從某個區域到作用中 DBMS VM 的網路延遲，是可接受的。 但在某些 Azure 區域中，使用中 DBMS VM 與 SAP 應用程式執行個體的延遲，在不同的區域中部署時，SAP 商務程序可能無法接受。 在這些情況下，部署架構必須不同於應用程式的主動/主動架構，或不同於跨區域網路延遲太高的主動/被動架構。
  • 決定使用可用性區域的位置時，請根據區域之間的網路延遲做出決定。 網路延遲在以下兩方面扮演重要角色：
    • 需要同步複寫的兩個 DBMS 執行個體之間的延遲。 網路延遲越高，它就越可能影響工作負載的執行個體。
    • 執行 SAP 對話執行個體的 VM 與作用中 DBMS 執行個體與另一個區域中類似 VM 之間的網路延遲差異。 隨著這項差異的增加，商務程序和批次作業執行時間的影響也會增加，取決於它們是否與 DBMS 或在不同的區域中執行。

當您跨可用性區域部署 Azure VM，並在相同的 Azure 區域內建立容錯移轉解決方案時，會套用一些限制：

  • 部署至 Azure 可用性區域時，必須使用 Azure 受控磁碟。
  • 區域列舉與實體區域的對應是以 Azure 訂用帳戶為基礎來修正。 如果您使用不同的訂用帳戶來部署 SAP 系統，則必須為每個訂用帳戶定義理想的區域。 如果您想要比較不同訂用帳戶的邏輯對應，請考慮 Avzone-Mapping 指令碼
  • 除非使用 Azure 鄰近放置群組，否則無法在 Azure 可用性區域內部署 Azure 可用性設定組。 關於如何跨區域部署 SAP DBMS 層和中央服務，同時又使用可用性設定組來部署 SAP 應用程式層，請參閱讓 SAP 應用程式達到最佳網路延遲的 Azure 鄰近放置群組一文。 如果您未使用 Azure 鄰近放置群組，則必須從兩者中選擇其一作為虛擬機器的部署架構。
  • 您無法使用 Azure 基本 Load Balancer 來建立以 Windows Server 容錯移轉叢集或 Linux Pacemaker 為基礎的容錯移轉叢集解決方案。 您必須改為使用 Azure Standard Load Balancer SKU。

理想的可用性區域組合

如果要跨區域部署 SAP NetWeaver 或 S/4HANA 系統，有兩個結構模式可供您部署：

  • 主動/主動：執行 ASCS/SCS 的 VM 配對以及執行 DBMS 層的 VM 配對會分散到兩個區域。 執行 SAP 應用程式層的 VM 數目以雙數部署至同樣的兩個區域。 如果 DBMS 或 ASCS/SCS VM 正在容錯移轉，可能會復原一些已開啟且作用中的交易。 但使用者保持登入。 作用中 DBMS VM 和應用程式執行個體在哪些區域中執行真的無所謂。 這是跨區域部署的首選架構。
  • 主動/被動：執行 ASCS/SCS 的 VM 配對以及執行 DBMS 層的 VM 配對會分散到兩個區域。 執行 SAP 應用程式層的 VM 數目會部署至其中一個可用性區域。 您會在與主動 ASCS/SCS 和 DBMS 執行個體相同的區域中執行應用程式層。 如果不同區域之間的網路延遲太高，而無法執行分散於各區域的應用程式層，請使用此部署架構。 相反地，SAP 應用程式層必須與作用中 ASCS/SCS 和/或 DBMS 執行個體在相同的區域中執行。 如果 ASCS/SCS 或 DBMS VM 容錯移轉至次要區域，網路延遲可能升高，接著降低輸送量。 您必須儘快容錯回復先前容錯移轉的 VM，以恢復先前的輸送量層級。 如果發生區域性中斷，應用程式層必須容錯移轉至次要區域。 這是使用者體驗到系統完全關機的一種活動。 在某些 Azure 區域中，當您想要使用可用性區域時，此架構是唯一可行的架構。 如果無法接受 ASCS/SCS 或 DBMS VMS 容錯移轉至次要區域的潛在影響，最好還是使用可用性設定組部署

在決定如何使用可用性區域之前，您必須查明：

  • Azure 區域三個區域之間的網路延遲。 只要知道地區中各區域之間的網路延遲，您就能選擇跨區域網路流量中網路延遲最低的區域。
  • 您選擇的其中一個區域內的 VM 對 VM 延遲，以及您所選擇的兩個區域之間的網路延遲差異。
  • 確認您需要部署的 VM 類型在您選取的兩個區域中是否適用。 某些 VM SKU 可能會發生部分 SKU 僅適用於其中兩個區域 (共三個) 的情況。

區域之間和區域內的網路延遲

若要判斷不同區域之間的延遲，您需要：

  • 在三個區域中部署您想要用於 DBMS 執行個體的 VM SKU。 在執行此測量時，請確定已啟用 Azure 加速網路。 加速網路是從幾年前開始的預設設定。 不過，請檢查其是否已啟用且可運作
  • 當您找到具有最低網路延遲的兩個區域時，請部署您想要在三個可用性區域中做為應用層 VM 的 VM，再部署三個 VM。 針對您選取的兩個 DBMS 區域中的兩個 DBMS VM 測量網路延遲。
  • 使用 niping 作為測量工具。 此為來自 SAP 的工具，相關說明請見 SAP 支援附註 #500235 和 #1100926。 將焦點放在記錄用於延遲測量的命令上。 由於 ping 無法在 Azure 加速網路程式碼路徑中運作，因此不建議使用。

您不需要手動執行這些測試。 您可以找到可用性區域延遲測試這個 PowerShell 程序，將上述延遲測試自動化。

根據您的測量和可用性區域中 VM SKU 的可用性，您需要做出一些決策：

  • 定義 DBMS 層的理想區域。
  • 根據區域內網路延遲差異，決定是否要將作用中的 SAP 應用層分散到一、二或三個區域。
  • 從應用程式觀點判斷您是否要部署主動/被動組態或主動/主動組態。 (本文稍後將說明這些組態。)

在做出這些決定時，也請考量 SAP 附註 #1100926中所提到的 SAP 網路延遲建議事項。

重要

您所做的度量和決策，對於您在測量時所使用的 Azure 訂用帳戶而言是有效的。 如果您使用另一個 Azure 訂用帳戶，則列舉區域的對應可能不同於另一個 Azure 訂用帳戶。 因此，您必須重複測量，或找出新訂用帳戶的對應，以使用工具 Avzone-Mapping 指令碼，將新訂用帳戶重新對應至舊訂用帳戶。

重要

前述測量在每個支援可用性區域的 Azure 區域中應會產生不同的結果。 即使您的網路延遲需求相同，您可能需要在不同的 Azure 區域中採用不同的部署策略，因為區域之間的網路延遲可能不同。 在某些 Azure 區域中，三個不同的區域之間的網路延遲可能會大不相同。 在其他區域中，三個不同區域之間的網路延遲可能會更統一。 宣稱一定有 1 到 2 毫秒的網路延遲並不正確。 Azure 區域中可用性區域之間的網路延遲無法一般化。

主動/主動部署

此部署架構稱為主動/主動，因為您會在二到三個區域部署作用中的 SAP 應用程式伺服器。 使用加入佇列複寫的 SAP 中央服務執行個體，會部署到兩個區域之間。 DBMS 層也是如此，會部署到和 SAP 中央服務相同的區域中。 在考量此設定時，您必須在您的區域中尋找能針對您的工作負載和同步 DBMS 複寫提供可接受的跨區域網路延遲的兩個可用性區域。 您也應確定，所選區域內的網路延遲，與跨區域網路延遲之間的差異，也不能太大。

SAP 架構天生可以在不同的應用程式執行個體中執行使用者和批次工作 (除非設定得不一樣)。 對於主動/主動部署，這一點帶來的副作用是不論批次工作與作用中 DBMS 是否在相同區域中執行，任何 SAP 應用程式執行個體都可能執行批次工作。 如果不同區域之間與區域內的網路延遲差異很小，則批次作業的執行時間可能相差不大。 不過，在執行批次工作的區域中，如果 DBMS 執行個體不在作用中，則區域內與跨區域網路流量的網路延遲差異越大，越可能影響批次作業的執行時間。 可接受多大的執行時間差異取決於身為客戶的您。 以及您的工作負載可容忍多高的跨區域流量網路延遲。

在如下所示的 Azure 區域中，跨不同可用性區域部署的應用程式層內執行時間和輸送量沒有明顯差異，這種主動/主動部署應該可行：

  • 澳大利亞東部 (三個區域中的兩個)
  • 巴西南部 (全部三個區域)
  • 印度中部 (全部三個區域)
  • 美國中部 (三個區域全部)
  • 東亞 (全部三個區域)
  • 美國東部 (三個區域其中兩個)
  • 美國東部 2 (三個區域全部)
  • 德國中西部 (全部三個區域)
  • 以色列中部（全部三個區域）
  • 義大利北部 （三個區域中的兩個）
  • 南韓中部 (全部三個區域)
  • 波蘭中部 （全部三個區域）
  • 卡達中部 (全部三個區域)
  • 北歐 (三個區域全部)
  • 挪威東部（三個區域中的兩個）
  • 南非北部 （三分之二）
  • 美國中南部 (三個區域全部)
  • 東南亞 (全部三個區域)
  • 瑞典中部 (全部三個區域)
  • 瑞士北部 (全部三個區域)
  • 阿拉伯聯合大公國北部 (全部三個區域)
  • 英國南部 (三個區域其中兩個)
  • 西歐 (三個區域其中兩個)
  • 美國西部 2 (三個區域全部)
  • 美國西部 3 (全部三個區域)

提供的區域清單無法減輕您作為客戶測試工作負載，以判斷主動/主動部署結構是否可行。

可能無法跨區域主動/主動 SAP 部署結構的 Azure 區域，如下所示：

  • 加拿大中部
  • 法國中部
  • 日本東部

雖然對於您的個別工作負載，它可能會運作。 因此，您應該先測試，再決定結構。 Azure 會持續努力改善其網路的品質和延遲。 數年前進行的測量可能不再反映目前的情況。

其他未列出的區域也是一樣，視您願意容忍多大的執行時間差異而定。

跨兩個區域的主動/主動部署的簡化結構描述如下所示：

主動/主動區域部署

下列考量適用於此設定：

重要

在此主動/主動案例中，適用跨區域流量的費用。 請參閱頻寬定價詳細資料文件。 SAP 應用層與 SAP DBMS 層之間的資料傳輸相當繁重。 因此，主動/主動案例可能所費不貲。

主動/被動部署

如果一個區域內的網路延遲與跨區域網路流量的延遲之間出現不可接受的差異，您可以部署從 SAP 應用程式層的觀點來看具有主動/被動特性的架構。 您可以定義作用中區域，在此區域中部署完整應用程式層，並且嘗試執行作用中 DBMS 和 SAP 中央服務執行個體。 使用此類設定時，您必須依據作業是否在作用中 DBMS 執行個體所在的區域中執行，確定商務程序和批次作業不會有太大的執行時間差異。

以下 Azure 區域可能較適合採用這種跨不同區域的部署結構：

  • 加拿大中部
  • 法國中部
  • 日本東部
  • 挪威東部
  • 南非北部

此架構的基本配置如下所示：

主動/被動區域部署

下列考量適用於此設定：

結合高可用性和災害復原的設定

Microsoft 不會共用在 Azure 區域中裝載不同 Azure 可用性區域之設施之間地理距離的任何資訊。 不過，有些客戶會使用區域進行合併「高可用性」和「災害復原」設定，承諾復原點目標 (RPO) 為零。 RPO 為零意味著即使在災害復原的情況下，也不會失去任何已認可的資料庫交易。

注意

建議您在特定情況下才使用此類設定。 例如，當資料因為安全性或合規性原因而無法離開 Azure 區域時，您可能會使用它。

以下是此類設定的範例：

區域中的高可用性DR合併

下列考量適用於此設定：

下一步

以下提供跨 Azure 可用性區域進行部署的後續步驟：