共用方式為

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

  • 發行項

在 Azure 上部署不同 SAP 架構層 可用性區域 是 Azure 上 SAP 工作負載部署的建議架構。 Azure 可用性區域定義為：「區域內的唯一實體位置。 每個區域皆由一或多個配備獨立電力、冷卻系統及網路的資料中心所組成」。 不是所有區域都提供 Azure 可用性區域。 關於哪些 Azure 區域提供可用性區域，請查看 Azure 區域地圖。 本文列出哪些區域提供 可用性區域。 大部分可裝載較大 SAP 工作負載的 Azure 區域都提供 可用性區域。 新的 Azure 區域會從一開始就提供 可用性區域。 一些較舊的地區或正在通過 可用性區域 進行改造。

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

  • SAP 應用層，可以是十幾 虛擬機器（VM）。 您想要將 VM 部署在相同主機伺服器上的機會降到最低。 您也希望這些 VM 位於資料庫層的可接受鄰近性，以在可接受的視窗中保持網路等待時間
  • 代表 SAP NetWeaver 和 S/4HANA 架構中單一失敗點的 SAP ASCS/SCS 層。 您通常會查看您想要涵蓋容錯移轉架構的兩個 VM。 因此，這些 VM 應該配置在不同的基礎結構容錯網域中
  • SAP 資料庫層，其也代表單一失敗點。 通常由容錯移轉架構所涵蓋的兩個 VM 組成。 因此，這些 VM 應該配置在不同的基礎結構容錯網域和更新網域中。 SAP Hana 向外延展部署是例外，其中可使用兩個以上的 VM

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

  • 透過可用性設定組來部署會將設定組內的 VM 排入單一區域或資料中心 (以何者適用於特定區域為準)。 因此，透過可用性設定組的部署不受影響整個區域資料中心的電源、冷卻或網路問題所保護。 使用可用性設定組時，VM 與其磁碟之間也不會強制對齊。 表示，磁碟可以位於 Azure 區域的任何資料中心，與區域的區域結構無關。 好處是 VM 與該區域或資料中心內的更新網域和容錯網域一致。 特別是針對我們保護每個可用性設定組兩部 VM 的 SAP ASCS 或資料庫層，與容錯網域的一致性可防止這兩部 VM 都位於相同的主機硬體上。
  • 透過 Azure 可用性區域 部署 VM，並選擇不同的區域（最多三個可能），會跨不同的實體位置部署 VM，並新增對整個區域數據中心影響的電源、冷卻或網路問題的保護。 VM 及其相關磁碟也會共置在相同的可用性區域中。 不過，隨著您將相同 VM 系列的多個 VM 部署至相同的可用性區域，就難以避免這些 VM 最後落在相同的主機或相同的容錯網域上。 因此，透過 可用性區域 部署很適合 SAP ASCS 和資料庫層，我們通常會在每個 VM 中查看兩個 VM。 針對 SAP 應用層，這可大幅超過兩個 VM，您可能需要切換回不同的部署模型（請參閱稍後）。

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

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

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

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

  • Azure 可用性區域 的詳細資訊請參閱區域和可用性區域檔。
  • 遇到過網路往返延遲不一定表示形成不同區域之資料中心的實際地理距離。 網路往返延遲也會受到這些不同資料中心之間纜線連接與纜線路由的影響。
  • 如果您使用 可用性區域 作為小距離DR解決方案，請記住，我們經歷了自然災害，造成世界不同地區的廣泛破壞，包括電力基礎設施的嚴重和廣泛破壞。 不同區域之間的距離可能並不總是足夠大，無法彌補這類更大的自然災害。
  • 可用性區域間的網路延遲，並非在所有 Azure 區域中都相同。 即使在 Azure 區域內，不同區域之間的網路等待時間可能會有所不同。 雖然即使在最糟的情況下，根據 HANA 系統複寫或 SQL Server Always On 的資料庫層級同步復寫仍可運作，而不會影響工作負載的延展性。
  • 決定使用可用性區域的位置時，請根據區域之間的網路延遲做出決定。 網路延遲在以下兩方面扮演重要角色：
    • 需要同步復寫的兩個資料庫實例之間的延遲。 基於最大 NetWeaver 和 S/4HANA 系統在網路等待時間較高（少於 1.5 毫秒）的區域之間非常成功的作業，可能會忽略此考慮
    • 執行 SAP 對話實例的 VM 與作用中資料庫實例與另一個區域中類似的 VM 之間的網路等待時間差異。 隨著這項差異增加，商務程式和批次作業運行時間的影響也會增加，取決於它們是否與資料庫或在不同的區域中執行（請參閱本文稍後）。
  • Azure 可用性區域 的網路等待時間，即使是在最大的區域中，也足以執行 SAP 商務程式。 到目前為止，我們只會看到少數特殊案例，客戶需要在單一數據中心網路脊椎下共置 SAP 應用層和資料庫層。

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

  • 部署至 Azure 可用性區域時，必須使用 Azure 受控磁碟。
  • 區域列舉與實體區域的對應是以 Azure 訂用帳戶為基礎來修正。 如果您使用不同的訂用帳戶來部署 SAP 系統，則必須為每個訂用帳戶定義理想的區域。 如果您想要比較不同訂用帳戶的邏輯對應，請考慮 Avzone-Mapping腳本。
  • 除非使用 Azure 鄰近放置群組，否則無法在 Azure 可用性區域內部署 Azure 可用性設定組。 Azure 鄰近放置群組一文中記載了如何使用可用性設定組來部署 SAP 應用層，同時跨區域部署 SAP 應用層和中央服務的方式，以及達到 VM 的鄰近性。 如果您未使用 Azure 鄰近放置群組，則必須從兩者中選擇其一作為虛擬機器的部署架構。
  • 您無法使用 Azure 基本 Load Balancer 來建立以 Windows Server 容錯移轉叢集或 Linux Pacemaker 為基礎的容錯移轉叢集解決方案。 您必須改為使用 Azure Standard Load Balancer SKU。
  • 您必須部署 ExpressRoute 閘道、VPN 閘道 和標準公用 IP 位址的區域性版本，以取得您想要的區域性保護。

理想的可用性區域組合

除非您使用登入群組、RFC 伺服器群組、Batch Server 群組等 SAP 功能來設定商務程式指派，否則商務程式可以在 SAP 應用層的不同應用程式實例中執行。 這個事實的副作用是，批次作業可能會由任何與作用中資料庫實例在相同區域中執行的 SAP 應用程式實例獨立執行。 如果不同區域之間與區域內的網路延遲差異很小，則批次作業的執行時間可能相差不大。 不過，相較於跨區域網路流量，區域內網路等待時間的差異更大，如果作業在資料庫實例不在作用中的區域中執行，批次作業的運行時間可能會受到更多影響。 可接受多大的執行時間差異取決於身為客戶的您。 以及您的工作負載可容忍多高的跨區域流量網路延遲。 純粹從技術觀點來看，Azure 區域內 Azure 可用性區域 之間的網路等待時間適用於 NetWeaver、S/4HANA 或其他 SAP 應用程式的架構。 當您決定本文所介紹的其中一個部署概念時，客戶也有可能使用登入群組、RFC 伺服器群組、Batch 伺服器群組等 SAP 概念來減輕這類差異。

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

  • 主動/主動：執行 ASCS/SCS 的 VM 配對，以及執行資料庫層的 VM 配對會分散到兩個區域。 執行 SAP 應用層的 VM 會部署在相同兩個區域的偶數中。 如果資料庫或 ASCS/SCS VM 正在故障轉移，可能會回復某些開啟和作用中交易。 但使用者保持登入。 作用中資料庫 VM 和應用程式實例執行的區域並不重要。 這是跨區域部署的首選架構。 如果區域之間的網路等待時間在執行商務程式時造成較大差異，您可以使用SAP登入群組、RFC 伺服器群組、Batch 伺服器群組等功能，並將商務程序的執行路由傳送至與作用中資料庫實例位於相同區域中的特定對話實例
  • 主動/被動：執行 ASCS/SCS 的 VM 配對，以及執行資料庫層的 VM 配對會分散到兩個區域。 執行 SAP 應用層的 VM 會部署到其中一個 可用性區域。 您會在與使用中 ASCS/SCS 和資料庫實例相同的區域中執行應用層。 如果您認為不同區域的網路等待時間太高，您可以使用此部署架構。 此外，這會導致商務程式的運行時間發生無法容忍的差異。 或者，如果您想要使用可用性區域部署作為短距離DR部署。 區域。 如果 ASCS/SCS 或資料庫 VM 故障轉移至次要區域，您可能會遇到較高的網路等待時間，並降低輸送量。 您必須儘快容錯回復先前容錯移轉的 VM，以恢復先前的輸送量層級。 如果發生區域性中斷，應用程式層必須容錯移轉至次要區域。 這是使用者體驗到系統完全關機的一種活動。

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

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

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

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

  • 在三個區域中部署您想要用於資料庫實例的 VM SKU。 在執行此測量時，請確定已啟用 Azure 加速網路。 加速網路是從幾年前開始的預設設定。 不過，請檢查其是否已啟用且可運作
  • 當您找到具有最低網路延遲的兩個區域時，請部署您想要在三個可用性區域中做為應用層 VM 的 VM，再部署三個 VM。 針對您選取的兩個區域中的兩個資料庫 VM 測量網路等待時間。
  • 使用 niping 作為測量工具。 此為來自 SAP 的工具，相關說明請見 SAP 支援附註 #500235 和 #1100926。 將 SAP 附注 中的網路等待時間分類 #1100926 視為粗略的指引。 大於 0.7 毫秒的網路等待時間並不表示系統不會在技術上運作，或商務程式不符合個別 SLA。 附注並非說明 SAP 和/或Microsoft所支援或不支持的內容。 將焦點放在記錄用於延遲測量的命令上。 由於 ping 無法在 Azure 加速網路程式碼路徑中運作，因此不建議使用。

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

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

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

重要

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

重要

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

主動/主動部署

此部署架構稱為主動/主動，因為您會在二到三個區域部署作用中的 SAP 應用程式伺服器。 使用加入佇列復寫的 SAP Central Services 實例會在兩個區域之間部署。 資料庫層也是如此，資料庫層會部署在與 SAP Central Service 相同的區域。 考慮此設定時，您必須在區域中尋找兩個 可用性區域，以提供工作負載可接受的跨區域網路等待時間。 您也想要確定所選區域內的網路等待時間與工作負載可接受跨區域網路等待時間之間的差異。

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

主動/主動區域部署

下列考量適用於此設定：

重要

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

主動/被動部署

如果您找不到可減輕 SAP 商務程式運行時間潛在差異的設定，或如果您想要部署短距離災害復原組態，則可以從 SAP 應用層的觀點部署具有主動/被動字元的架構。 您可以定義作用中區域，也就是您部署完整應用層的區域，以及您嘗試執行作用中資料庫實例和 SAP Central Services 實例的位置。 使用這類設定時，您必須確定您沒有極端的運行時間變化，視作業是否在具有作用中資料庫實例的區域內執行，以及商務交易和批次作業而定。

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

主動/被動區域部署

下列考量適用於此設定：

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

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

注意

如果您使用 可用性區域 作為小距離DR解決方案，請記住，我們經歷了自然災害，造成世界不同地區的廣泛破壞，包括電力基礎設施的嚴重和廣泛破壞。 不同區域之間的距離可能並不總是足夠大，無法彌補這類更大的自然災害。

以下是此類設定的範例：

區域中的高可用性DR合併

下列考量適用於此設定：

下一步

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