Azure 虛擬機器支援案例上的 SAP 工作負載 \(部分機器翻譯\)

  • 發行項

在 Azure 中設計 SAP NetWeaver、Business one Hybris 或 S/4HANA 系統架構，為各種架構和工具提供了許多不同的機會，可用來進行可調整、有效率且高可用性的部署。 雖然相依于使用的作業系統或 DBMS，但有限制。 此外，並非所有內部部署支援的案例都以相同方式在 Azure 中受到支援。 本檔將引導您使用 Azure VM 獨佔方式支援的非高可用性設定和高可用性組態和架構。

注意

HANA 大型實例服務處於日落模式，不再接受新客戶。 仍可能為現有的 HANA 大型實例客戶提供單位。 如需替代方案，請檢查 HANA 硬體目錄中 HANA 認證 Azure VM 的供應專案 。 針對具有 HANA 大型實例的現有 HANA 大型實例客戶 仍可支援的案例，請參閱 HANA 大型實例的支援案例 一文 。

一般平臺限制

除了所謂的原生 Azure VM 之外，Azure 還有各種平臺，這些 VM 會作為第一方服務提供。 HANA 大型實例 處於日落模式，是其中一個平臺。 Azure VMware 服務 是上述第一方服務的另一項。 一般而言，SAP 不支援 Azure VMware 服務來裝載 SAP 工作負載。 如需 不同平臺上 VMware 支援的詳細資料，請參閱 SAP 支援附注 #2138865 - VMware 雲端上的 SAP 應用程式：支援的產品和 VM 設定。

除了內部部署的 Active Directory，Azure 還提供受控 Active Directory SaaS 服務與 Microsoft Entra Domain Services （由 Microsoft 管理的傳統 AD），以及 Microsoft Entra ID 。 裝載在 Windows OS 上的 SAP 元件通常依賴 Windows Active Directory 的使用方式。 在此情況下，傳統 Active Directory 是您裝載于內部部署，或 Microsoft Entra Domain Services （仍在測試中）。 但這些 SAP 元件無法搭配原生 Microsoft Entra 識別碼運作。 原因是 Active Directory 在其內部部署表單或其 SaaS 表單 （Microsoft Entra Domain Services） 和原生 Microsoft Entra ID 之間仍有較大的功能差距。 此相依性是 Windows OS 上以 SAP NetWeaver 和 S/4 HANA 為基礎的應用程式不支援 Microsoft Entra 帳戶的原因。 傳統 Active Directory 帳戶必須用於這類案例。

AD 服務 以 Windows OS 上的 SAP NetWeaver 和 S/4 HANA 為基礎的支援應用程式
內部部署 Windows Active Directory 支援
Microsoft Entra 網域服務 支援
Microsoft Entra ID 不支援

上述專案不會影響使用 Microsoft Entra 帳戶搭配 SAP 應用程式進行單一登入 （SSO） 案例。

2 層組態

SAP 2 層組態會被視為建置在相同伺服器或 VM 單位上執行之 SAP DBMS 和應用層的結合層。 第二層會被視為使用者介面層。 針對 2 層組態，DBMS 和 SAP 應用層會共用 Azure VM 的資源。 因此，您必須以這些元件不競爭資源的方式設定不同的元件。 您也需要小心，不要過度訂閱 VM 的資源。 這類設定不會提供任何高可用性，除了 涉及不同 Azure 元件的 Azure 服務等級協定 之外。

這類組態的圖形表示如下所示：

Simple 2-Tier configuration

針對 SQL Server、Oracle、Db2、maxDB 和非生產案例的 DBMS 系統，Windows、Red Hat、SUSE 和 Oracle Linux 支援這類設定。 針對 SAP HANA 作為 DBMS，SAP 支援 SAP 附注 #1953429 中所述 的案例。 到目前為止，Linux 散發版本都未提供足夠的 HA 檔，以在這類設定中設定及操作 Pacemaker 叢集。 因此，Azure 僅針對不需要高可用性容錯移轉叢集的非生產案例，才支援這類組態類型。

針對 Azure 上支援的所有 OS/DBMS 組合，支援這種類型的設定。 不過，您必須設定 DBMS 和 SAP 元件的組態，讓 DBMS 和 SAP 元件不會競爭記憶體和 CPU 資源，且超過實體可用資源。 這需要藉由限制允許 DBMS 配置的記憶體來完成。 您也需要限制應用程式實例上的 SAP 延伸記憶體。 您也需要監視整體 VM 的 CPU 耗用量，以確保元件不會最大化 CPU 資源。

注意

針對生產 SAP 系統，我們建議額外的高可用性和最終的災害復原設定，如本檔稍後所述

3 層組態

在這類設定中，您會將 SAP 應用層和 DBMS 層分成不同的 VM。 您通常會因為較大的系統而這麼做，而且因為 SAP 應用層的資源更有彈性。 在最簡單的設定中，除了涉及不同 Azure 元件的 Azure 服務等級協定 之外，沒有高可用性 。

圖形表示如下所示：

Diagram that shows a simple 3-Tier configuration.

Windows、Red Hat、SUSE 和 Oracle Linux 支援這種類型的設定，適用于生產和非生產案例的 DBMS 系統、Oracle、Db2、SAP HANA、maxDB 和 SAP ASE。 為了簡化，我們沒有區分 SAP 中央服務和 SAP 應用層中的 SAP 對話實例。 在這個簡單的 3 層設定中，SAP Central Services 不會有高可用性保護。

注意

針對生產 SAP 系統，我們建議額外的高可用性和最終的災害復原設定，如本檔稍後所述

每個 VM 有多個 DBMS 實例

在此組態類型中，您會為每個 Azure VM 裝載多個 DBMS 實例。 其動機可能是擁有較少的作業系統來維護和降低成本。 其他動機是藉由在多個 DBMS 實例之間共用較大 VM 或 HANA 大型實例單位的資源，以更有彈性和更有效率。 到目前為止，這些組態主要針對非生產系統顯示。

如下所示的組態：

Multiple DBMS instances in one unit

支援這種類型的 DBMS 部署：

在一部主機上執行多個資料庫實例，您必須確定不同的實例不會競爭資源，因而超過 VM 的實體資源限制。 對於需要限制共用 VM 的實例可以配置的記憶體，尤其如此。 對於不同資料庫實例可以取用的 CPU 資源而言，這也可能成立。 提及的所有資料庫系統都有設定，允許限制實例層級上的記憶體配置和 CPU 資源。 為了支援 Azure VM 的這類設定，預期磁片或磁片區會用於不同實例所管理之資料庫的資料和記錄/重做記錄檔。 換句話說，由不同 DBMS 實例管理的資料庫資料或記錄/重做記錄檔不應該共用相同的磁片或磁片區。

注意

針對生產 SAP 系統，我們建議使用額外的高可用性和最終災害復原設定，如本檔稍後所述。 本檔稍後所述的高可用性設定不支援具有多個 DBMS 實例的 VM。

一個 VM 中的多個 SAP 對話方塊實例

在許多情況下，多個對話實例會部署在裸機伺服器上，甚至是在私人雲端執行的 VM 中。 這類設定的理由是針對特定工作負載、商務功能或工作負載類型量身打造特定 SAP 對話實例。 不將這些實例隔離到個別 VM 的原因，是作業系統維護和作業的努力。 或者在許多情況下，如果 VM 的主機管理員或操作員要求每個 VM 運作和管理每月費用，則成本會降低。 在 Azure 中，在單一 VM 內裝載多個 SAP 對話實例的案例，我們針對 Windows、Red Hat、SUSE 和 Oracle Linux 的作業系統支援生產和非生產用途。 如果在單一 VM 上執行多個 SAP 應用程式伺服器實例，SAP 核心PHYS_MEMSIZE，則應該設定 Windows 和新式 Linux 核心上可用的 SAP 核心參數。也建議您限制作業系統上的 SAP 延伸記憶體擴充，例如實作 SAP 延伸記憶體的 Windows。 這可以使用 SAP 設定檔參數 em/max_size_MB 來完成。

在 Azure VM 內執行多個 SAP 對話方塊實例的 3 層組態看起來如下：

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

為了簡化，我們沒有區分 SAP 中央服務和 SAP 應用層中的 SAP 對話實例。 在這個簡單的 3 層設定中，SAP Central Services 不會有高可用性保護。 針對生產系統，不建議讓 SAP Central Services 保持未受保護。 如需 SAP 中央實例的所謂多重 SID 組態和這類多重 SID 組態高可用性的詳細資料，請參閱本檔稍後的章節。

SAP DBMS 層的高可用性保護

當您想要部署 SAP 生產系統時，您必須考慮高可用性組態的熱待命類型。 特別是對於 SAP HANA，資料必須先載入記憶體，才能取得完整的效能和延展性，Azure 服務修復並不是高可用性的理想量值。

一般而言，Microsoft 僅支援 SAP 工作負載案例 中所述的 高可用性組態和軟體套件。 您可以在 SAP 附注 #1928533 中讀取相同的語句。 Microsoft 不會支援 Microsoft 未記載于 SAP 工作負載的其他高可用性協力廠商軟體架構。 在這種情況下，高可用性架構的協力廠商供應商是高可用性設定的支援方，您必須以客戶身分參與支援程式。 本文將提及例外狀況。

一般而言，Microsoft 在 Azure VM 或 HANA 大型實例單位上支援一組有限的高可用性設定。

針對 Azure VM，DBMS 層級支援下列高可用性設定：

重要

針對上述案例，我們不支援一部 VM 中多個 DBMS 實例的設定。 表示在每種情況下，每個 VM 只能部署一個資料庫實例，並使用所述的高可用性方法加以保護。 目前不支援保護相同 Windows 或 Pacemaker 容錯移轉叢集 下的多個 DBMS 實例。 此外，每個 VM 部署案例都支援單一實例的 Oracle Data Guard。

各種資料庫系統允許在一個 DBMS 實例下裝載多個資料庫。 如同 SAP HANA，多個資料庫可以裝載于多個資料庫容器 （MDC）。 如果這些多資料庫組態在一個容錯移轉叢集資源內運作，則支援這些設定。 不支援的組態是需要多個叢集資源的情況。 至於您會在一個 SQL Server 實例下定義多個 SQL Server 可用性群組的組態。

DBMS HA configuration

根據 DBMS 或作業系統而定，Azure 負載平衡器等元件可能或可能不是解決方案架構的一部分。

特別是 maxDB，儲存體組態必須不同。 使用 maxDB 時，資料和記錄檔必須位於共用儲存體上，才能進行高可用性設定。 只有 maxDB，共用儲存體才支援高可用性。 針對所有其他 DBMS，每個節點的個別儲存體堆疊是唯一支援的磁片組態。

其他高可用性架構已知存在，而且已知也會在 Microsoft Azure 上執行。 不過，Microsoft 並未測試這些架構。 如果您想要使用這些架構建置高可用性組態，您必須使用該軟體的提供者來執行下列動作：

  • 開發部署架構
  • 架構的部署
  • 架構的支援

重要

Microsoft Azure Marketplace 提供各種軟設備，可在 Azure 原生儲存體上提供儲存體解決方案。 這些軟設備可以用來建立 NFS 共用，理論上可以在需要待命節點的 SAP HANA 向外延展部署中使用。 由於各種原因，Microsoft 和 SAP on Azure 的任何 DBMS 部署都不支援這些儲存體軟設備。 目前不支援在 SMB 共用上部署 DBMS。 NFS 共用上的 DBMS 部署僅限於 Azure NetApp Files 上的 NFS 4.1 共用。

SAP Central 服務的高可用性

SAP 中央服務是 SAP 設定的第二個單一失敗點。 因此，您也必須保護這些中央服務進程。 SAP 工作負載支援的供應專案和記載如下：

在列出的解決方案中，您需要與 SIOS 的支援 Datakeeper 關係來支援產品，並在遇到問題時直接與 SIOS 互動。 視您授權 Windows、Red Hat 和/或 SUSE OS 的方式而定，您可能也需要與 OS 提供者簽訂支援合約，才能完全支援列出的高可用性設定。

組態也可以顯示如下：

DBMS and ASCS HA configuration

圖形右側會顯示高可用性的 SAP 中央服務。 除了具有可容錯移轉失敗案例中容錯移轉的容錯移轉叢集架構所保護的 SAP Central 服務之外。 高可用性 NFS 或 SMB 共用或 Windows 共用磁片必須確定 sapmnt 和全域傳輸目錄與單一 VM 的存在無關。 其他一些解決方案，例如 Windows 容錯移轉叢集伺服器和 Pacemaker，都需要 Azure 負載平衡器將流量導向或重新導向至狀況良好的節點。

在顯示的清單中，沒有提及 Oracle Linux 作業系統。 Oracle Linux 不支援 Pacemaker 作為叢集架構。 如果您想要在 Oracle Linux 上部署 SAP 系統，而且需要 Oracle Linux 的高可用性架構，則必須與協力廠商供應商合作。 其中一個供應商是 SIOS，其 Protection Suite for Linux 由 SAP on Azure 支援。 如需詳細資訊，請參閱 SAP 附注 #1662610 - SIOS Protection Suite for Linux 的支援詳細資料以取得詳細資訊。

具有上述 SAP 中央服務案例支援的儲存體

由於只有 Azure 儲存體類型的子集提供高可用性 NFS 或 SMB 共用，因此 SAP 中央服務叢集中服務叢集中的使用量品質是支援的儲存體類型清單

  • Windows 容錯移轉叢集伺服器與 Windows 向外延展檔案伺服器可以部署在所有原生 Azure 儲存體類型上，但 Azure NetApp Files 除外。 不過，建議使用進階儲存體，因為輸送量和 IOPS 中的服務等級協定較佳。
  • Azure NetApp Files 支援在 Azure NetApp Files 上使用 SMB 的 Windows 容錯移轉叢集伺服器。 此案例也支援裝載在 Azure 進階版 檔案服務的 SMB 共用。 不支援 Azure 標準檔案
  • 除了 Azure NetApp Files 以外，所有原生 Azure 儲存體類型都可以部署以 SIOS Datakeeper 為基礎的 Windows 容錯移轉叢集伺服器與 Windows 共用磁片。 不過，建議使用進階儲存體，因為輸送量和 IOPS 中的服務等級協定較佳。
  • 支援在 Azure NetApp Files 上使用 NFS 共用的 SUSE 或 Red Hat Pacemaker。
  • 在支援 LRS 或 ZRS 的 Azure 進階版 檔案上使用 NFS 共用的 SUSE 或 Red Hat Pacemaker。 不支援 Azure 標準檔案
  • 除了 Azure NetApp Files 以外，使用原生 Azure 儲存體類型支援使用兩個 drdb VM 之間的設定 SUSE Pacemaker。 不過，我們建議搭配 Azure 進階版 檔案或 Azure NetApp Files 使用第一方服務之一。
  • 除了 Azure NetApp Files 之外，Red Hat Pacemaker 使用 glusterfs 提供 NFS 共用的 Red Hat Pacemaker 支援使用原生 Azure 儲存體類型。 不過，我們建議搭配 Azure 進階版 檔案或 Azure NetApp Files 使用第一方服務之一。

重要

Microsoft Azure Marketplace 提供各種軟設備，可在 Azure 原生儲存體上提供儲存體解決方案。 這些儲存體軟設備也可以用來建立 NFS 或 SMB 共用，理論上也可以在容錯移轉叢集 SAP 中央服務中使用。 Microsoft 不會直接支援 SAP 工作負載的這些解決方案。 如果您決定使用這類解決方案來建立 NFS 或 SMB 共用，則必須由在儲存體軟設備中擁有軟體的協力廠商提供 SAP Central Service 設定的支援。

多重 SID SAP 中央服務容錯移轉叢集

為了減少大型 SAP 環境所需的 VM 數目，SAP 允許在容錯移轉叢集設定中執行多個不同 SAP 系統的 SAP 中央服務實例。 假設您有 30 個以上的 NetWeaver 或 S/4HANA 生產系統。 如果沒有多重 SID 叢集，這些設定需要 30 個以上的 Windows 或 Pacemaker 容錯移轉叢集設定中的 60 部或更多 VM。 在容錯移轉叢集設定的兩個節點之間部署多個 SAP 中央服務，可大幅減少 VM 數目。 不過，在單一兩個節點叢集組態上部署多個 SAP Central 服務實例也有一些缺點。 叢集組態中單一 VM 的相關問題會套用至多個 SAP 系統。 在叢集組態中執行的客體 OS 上進行維護需要更多協調，因為會影響多個生產 SAP 系統。 SAP LaMa 之類的工具不支援其系統複製程式中的多 SID 叢集。

在 Azure 上，使用 ENSA1 和 ENSA2 的 Windows 作業系統支援多重 SID 叢集設定。 建議不要將較舊的排入佇列複寫服務架構 （ENSA1） 與單一多重 SID 叢集上的新架構 （ENSA2） 結合。 這類架構的詳細資料記載于文章中

針對 SUSE，也支援以 Pacemaker 為基礎的多 SID 叢集。 到目前為止，支援下列設定：

  • 最多五個 SAP ASCS/SCS 實例
  • 舊的排入佇列複寫伺服器冰架構 （ENSA1）
  • 兩個節點 Pacemaker 叢集組態

設定記載于 SUSE Linux Enterprise Server for SAP 應用程式多重 SID 指南上的 Azure VM 上的 SAP NetWeaver 高可用性

具有排入佇列複寫伺服器的多重 SID 叢集看起來類似

Diagram that shows a multi-SID cluster with Enqueue Replication server.

SAP HANA 向外延展案例

SAP HANA 向外延展案例支援 HANA 認證的 Azure VM 子集，如 SAP HANA 硬體目錄中 所列 。 在 [叢集] 資料行中標示為 'Yes' 的所有 VM 都可用於 OLAP 或 S/4HANA 向外延展。Azure 儲存體類型支援不含待命的設定：

AZURE NetApp Files 上裝載的 NFS 共用支援 OLAP 或 S/4HANA 與待命節點的 SAP HANA 向外延展設定。

如需有關具有或不含待命節點之確切儲存體組態的詳細資訊，請參閱文章：

災害復原案例

支援各種災害復原案例。 我們會將災害架構定義為架構，以補償從方格外的完整 Azure 區域。 這表示我們需要災害復原目標成為不同的 Azure 區域，作為執行 SAP 環境的目標。 我們會分隔 DBMS 層和非 DBMS 層中的方法和組態。

DBMS 層

針對 DBMS 層，支援使用 DBMS 原生複寫機制的設定，例如 AlwaysOn、Oracle Data Guard、Db2 HADR、SAP ASE Always-On 或 HANA 系統複寫。 在這類情況下，複寫資料流程是非同步，而不是同步處理，就像在單一 Azure 區域內部署的典型高可用性案例一樣。 這類支援的 DBMS 災害復原組態的一般範例，請參閱跨 Azure 區域的 SAP HANA 可用性一文 。 該區段中的第二個圖形描述具有 HANA 的案例作為範例。 SAP 應用程式支援的主要資料庫都能夠在這類案例中部署。

支援在災害復原區域中使用較小的 VM 作為目標實例，因為該 VM 不會體驗到完整的工作負載流量。 這麼做時，您必須記住下列考慮：

  • 較小的 VM 類型不允許連結比較小的 VM 多磁片
  • 較小的 VM 具有較少的網路和儲存體輸送量
  • 在一個 Azure 可用性設定組中收集不同的 VM 時，調整 VM 系列的大小可能會是問題，或者當 M 系列系列與 Mv2 系列 VM 之間應該進行調整大小時，可能會發生問題
  • 資料庫實例的 CPU 和記憶體耗用量，能夠以最少的延遲和足夠的 CPU 和記憶體資源接收變更資料流程，以將這些變更套用至資料最少的延遲

如需不同 VM 大小限制的詳細資訊，請參閱 VM 大小 頁面

部署 DR 目標的另一個支援方法是將第二個 DBMS 實例安裝在執行非生產環境 SAP 實例之非生產 DBMS 實例的 VM 上。 這可能會更具挑戰性，因為您需要找出 DR 案例中應作為主要實例的特定目標實例所需的記憶體、CPU 資源、網路頻寬和儲存體頻寬。 特別是在 HANA 中，強烈建議您將實例設定為共用主機上的 DR 目標，讓資料不會預先載入 DR 目標實例。

注意

Azure Site Recovery 的使用 方式尚未針對 SAP 工作負載下的 DBMS 部署進行測試。 因此，目前不支援 SAP 系統的 DBMS 層。 不支援 Microsoft 和 SAP 所列出的其他複寫方法。 使用協力廠商軟體在不同 Azure 區域之間複寫 SAP 系統的 DBMS 層，必須受到軟體廠商的支援，且不會透過 Microsoft 和 SAP 支援通道支援。

非 DBMS 層

針對所需的 SAP 應用層和最終共用或儲存體位置，客戶會使用這兩個主要案例：

  • 第二個 Azure 區域中的災害復原目標不會用於任何生產或非生產用途。 在此案例中，作為災害復原目標的 VM 最好不會部署，而且生產 SAP 應用層映射的映射和變更會複寫到災害復原區域。 可執行這類工作的功能是 Azure Site Recovery 。 Azure Site Recovery 支援 Azure 對 Azure 複寫案例，如下所示。
  • 災害復原目標是非生產系統實際使用的 VM。 整個 SAP 環境會分散到兩個不同的 Azure 區域，其中生產系統通常位於一個區域，另一個區域中的非生產系統。 在許多客戶部署中，客戶具有相當於生產系統的非生產系統。 客戶已在應用層非生產系統上預先安裝生產應用程式實例。 在容錯移轉事件中，非生產實例將會關閉、生產 VM 的虛擬名稱移至非生產 VM（在 DNS 中指派新的 IP 位址之後），以及預先安裝的生產實例已開始

SAP 中央服務叢集

使用共用磁片 （Windows）、SMB 共用 （Windows） 或 NFS 共用的 SAP 中央服務叢集較難複寫。 在 Windows 端，Windows 儲存體複寫是可行的解決方案。 在 Linux 上，rsync 是可行的解決方案。 此外，Azure NetApp Files 的跨區域複寫也是可行的解決方案。

不支援的案例

Azure 架構上不支援 SAP 工作負載的案例清單。 不支援 表示 SAP 和 Microsoft 無法提供這些設定的支援，而且必須延遲最終涉及的協力廠商，以提供軟體來建立這類架構。 其中兩個類別包括：

  • 儲存體軟電器：市場上有各種儲存軟電器。 有些廠商提供自己的檔，說明如何在與 SAP 軟體相關的 Azure 上使用其儲存體軟設備。 需要由存放裝置軟設備的廠商提供涉及這類儲存軟設備的設定或部署支援。 此事實也會顯示在 SAP 支援附注中 #2015553
  • 高可用性架構：Azure 上的 SAP 工作負載僅支援 Pacemaker 和 Windows Server 容錯移轉叢集的高可用性架構。 如先前所述，Microsoft 會描述並記載 SIOS Datakeeper 解決方案。 不過，SIOS 的元件必須透過 SIOS Datakeeper 支援，因為廠商會提供這些元件。 SAP 也會在各種 SAP 附注中列出其他經認證的高可用性架構。 其中有些也已獲得 Azure 協力廠商廠商的認證。 不過，使用這些產品的組態支援必須由產品廠商提供。 不同的廠商在 SAP 支援程式中有不同的整合。 您應該先厘清哪些支援程式最適合特定廠商，再決定將產品與部署在 Azure 上的 SAP 組態搭配使用。
  • 除了 maxDB 之外，不支援資料庫檔案位於共用磁片上的共用磁片叢集。 針對所有其他資料庫，支援的解決方案是有個別的儲存位置，而不是 SMB 或 NFS 共用或共用磁片，以設定高可用性案例

不支援的其他案例如下：

  • 在 NetWeaver、S/4HANA 等 NetWeaver、S/4HANA 中，在 SAP 應用層與 SAP DBMS 層之間引進較大網路延遲的部署案例。 Hybris 這包括：
    • 在內部部署其中一層，而另一層則部署在 Azure 中
    • 在與 DBMS 層不同的 Azure 區域中部署系統的 SAP 應用層
    • 在共置至 Azure 的資料中心中部署一層，以及 Azure 中的另一層，但 Azure 原生服務會提供這類架構模式的位置除外
    • 在 SAP 應用層與 DBMS 層之間部署網路虛擬裝置
    • 針對 SAP DBMS 層或 SAP 全域傳輸目錄，使用裝載在資料中心的儲存體共置至 Azure 資料中心
    • 使用兩個不同的雲端廠商部署這兩個層級。 例如，在 Oracle 雲端基礎結構中部署 DBMS 層和 Azure 中的應用層
  • 多重實例 HANA Pacemaker 叢集組態
  • 透過 ANF 上的 SOFS 或 SMB，針對 Windows 上支援的 SAP 資料庫，使用共用磁片的 Windows 叢集設定。 相反地，我們建議使用特定資料庫的原生高可用性複寫，並使用個別的儲存體堆疊
  • 在 Linux 上支援的 SAP 資料庫部署，其資料庫檔案位於 ANF 之上的 NFS 共用，但 SAP HANA、Oracle Linux 上的 Oracle 和 Suse 和 Red Hat 上的 Db2 除外
  • 在 Windows 和 Oracle Linux 以外的任何其他客體 OS 上部署 Oracle DBMS。 另 請參閱 SAP 支援附注 #2039619

未測試的案例，因此沒有清單的經驗，例如：

  • Azure Site Recovery 會複寫 DBMS 層 VM。 因此，我們建議針對潛在的災害復原組態使用資料庫原生非同步複寫功能

後續步驟

閱讀適用于 SAP NetWeaver 的 Azure 虛擬機器規劃和實作中的 後續步驟