共用方式為

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

  • 發行項

在 Azure 中設計 SAP NetWeaver、Business One、Hybris 或 S/4HANA 系統架構讓您有許多不同的機會，可使用各種架構和工具來獲得可調整、有效率且高可用性的部署。 視所使用的作業系統或 DBMS 而定，這些部署會有一些限制。 此外，能在內部部署環境獲得支援的案例，不一定能在 Azure 中獲得同樣的支援。 本文件會引導您了解，如何僅使用 Azure VM 來實現受支援的非高可用性設定和高可用性設定與架構。

注意

HANA 大型執行個體服務為終止模式，不再接受新客戶。 仍可為現有 HANA 大型執行個體客戶提供單位。 如需替代方案，請參閱 HANA 硬體目錄中的 HAVA 認證的 Azure VM 供應項目。 針對現有 HANA 大型執行個體客戶，如需 HANA 大型執行個體過去或仍支援的案例，請參閱HANA 大型執行個體的支援案例一文。

一般平台限制

除了作為第一方服務提供的所謂原生 Azure VM，Azure 還有各種平台。 HANA 大型執行個體，這是其中一個終止模式的平台。 Azure VMware 服務是其他第一方服務。 一般而言，SAP 不支援 Azure VMware 服務裝載 SAP 工作負載。 如需不同平台上 VMware 支援的詳細資料，請參閱SAP 支援附註 2138865 - VMware Cloud 上的 SAP 應用程式︰支援的產品和 VM 組態。

除了 內部部署的 Active Directory，Azure 還提供受控 Active Directory SaaS 服務，其中包含 Microsoft Entra Domain Services（由 Microsoft 管理的傳統 AD），以及 Microsoft Entra ID。 Windows 作業系統上裝載的 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 作業系統上以 SAP NetWeaver 和 S/4 HANA 為基礎的應用程式
內部部署 Windows Active Directory 支援
Microsoft Entra 網域服務 支援
Microsoft Entra ID 不支援

上述專案不會影響使用 sap 應用程式的單一登錄 （SSO） 案例Microsoft Entra 帳戶。

雙層設定

所謂的 SAP 雙層設定會透過合併 SAP DBMS 層和應用程式層來建成，並且會在相同伺服器或 VM 單位上執行。 第二層是所謂的使用者介面層。 針對二層設定，DBMS 和 SAP 應用程式層會共用 Azure VM 的資源。 因此，您在設定不同的元件時，必須讓這些元件不會爭用資源。 您也必須小心不要過度訂閱 VM 的資源。 除了所涉及的不同 Azure 元件的 Azure 服務等級協定，這類設定不會提供任何高可用性。

這類設定如果用圖表表示，情況會像下面這樣：

簡單2層設定

Windows、Red Hat、SUSE 和 Oracle Linux 針對 SQL Server、Oracle、Db2、maxDB 和 SAP ASE 的 DBMS 系統，支援在生產和非生產案例中使用這類設定。 如需將 SAP HANA 作為 DBMS，SAP 支援這類案例，如 SAP 註記 1953429 所述。 Linux 發行版本目前都未提供足夠的 HA 文件，以在這類設定中設定和操作 Pacemaker 叢集。 因此，Azure 僅針對不需要高可用性容錯移轉叢集的非生產案例支援這類設定。

在 Azure 上獲得支援的所有 OS/DBMS 組合都支援這種類型的設定。 不過，您在設定 DBMS 和 SAP 元件的設定時，必須讓 DBMS 和 SAP 元件不會爭用記憶體和 CPU 資源而超過實體可用的資源。 想要做到這一點，就必須限制 DBMS 能夠配置的記憶體數量。 您也需要限制應用程式執行個體上的 SAP 延伸記憶體。 您也需要監視整體 VM 的 CPU 使用量，以確保元件不會將 CPU 資源使用到極致。

注意

若為生產 SAP 系統，建議您使用其他高可用性和最終災害復原設定，本文件稍後會有說明

三層設定

在這類設定中，SAP 應用程式層和 DBMS 層會分到不同的 VM。 會這麼做通常是因為系統較大，且需要更彈性的 SAP 應用程式層資源。 以最簡單的方式進行設定時，除了所涉及不同 Azure 元件的 Azure 服務等級協定 之外，不會有任何高可用性。

用圖表表示時，情況會像下面這樣：

顯示簡單 3 層設定的圖表。

Windows、Red Hat、SUSE 和 Oracle Linux 針對 SQL Server、Oracle、Db2、SAP HANA、maxDB 和 SAP ASE 的 DBMS 系統，支援在生產和非生產案例中使用這種設定。 為求簡化，我們不會在 SAP 應用程式層區分 SAP 中央服務和 SAP 對話方塊執行個體。 在這個簡單的三層設定中，SAP 中央服務沒有高可用性保護。

注意

若為生產 SAP 系統，建議您使用其他高可用性和最終災害復原設定，本文件稍後會有說明

每個 VM 的多個 DBMS 執行個體

在此設定類型中，每個 Azure VM 會裝載多個 DBMS 執行個體。 其動機可能是為了減少需要維護的作業系統並降低成本。 其他的動機則是要讓多個 DBMS 執行個體共用較大 VM 或 HANA 大型執行個體單位的資源，以提升彈性和效率。 到目前為止，這些設定大多出現在非生產系統。

這類設定可能如下所示：

一個單位中的多個 DBMS 實例

這種類型的 DBMS 部署支援用於：

要在一部主機上執行多個資料庫執行個體，您必須確定不同的執行個體不會爭用資源，而超過 VM 的實體資源限制。 如果您需要針對共用 VM 的任何執行個體，限制其可以配置的記憶體的話，就更需要注意這一點。 對於不同資料庫執行個體可以取用的 CPU 資源，也可能需要注意。 前面提到的所有資料庫系統都有能夠在執行個體層級限制記憶體配置和 CPU 資源的設定。 為了支援 Azure VM 使用這類設定，不同執行個體所管理的資料庫，其資料和記錄/重做記錄檔所使用的磁碟或磁碟區應該要分開。 或者換句話說，不同 DBMS 執行個體所管理的資料庫，其資料或記錄/重做記錄檔不應該共用相同的磁碟或磁碟區。

注意

若為生產 SAP 系統，建議您使用其他高可用性和最終災害復原設定，本文件稍後會有說明。 具有多個 DBMS 執行個體的 VM 不支援使用本文件稍後會說明的高可用性設定。

一部 VM 中有多個 SAP 對話方塊執行個體

在許多情況下，我們會將多個對話方塊執行個體部署在裸機伺服器上，甚至是部署在執行於私人雲端的 VM 中。 會這麼設定是為了針對特定工作負載、商務功能或工作負載類型來量身打造特定的 SAP 對話方塊執行個體。 未將這些執行個體分散到不同 VM，原因在於作業系統的維護和運作工作。 或者，在許多情況下，如果 VM 的主機服務提供者或操作員會針對所運作和管理的每一 VM 要求每月費用的話，則原因是成本。 在 Azure 中，Windows、Red Hat、SUSE 和 Oracle Linux 的作業系統支援在生產和非生產用途下，於單一 VM 內裝載多個 SAP 對話方塊執行個體。 如果在單一 VM 上執行多個 SAP 應用程式伺服器執行個體，則應設定 Windows 上可用的 SAP 核心參數 PHYS_MEMSIZE 和新式 Linux 核心。另也建議您限制在作業系統 (例如 Windows) 上延伸 SAP 延伸記憶體，因為已實作 SAP 延伸記憶體的自動增長。 若要進行限制，請使用 SAP 設定檔參數 em/max_size_MB。

有多個 SAP 對話方塊執行個體執行於 Azure VM 內的三層設定看起來如下：

此圖顯示 3 層組態，其中多個 SAP 對話框實例會在 Azure VM 內執行。

為求簡化，我們不會在 SAP 應用程式層區分 SAP 中央服務和 SAP 對話方塊執行個體。 在這個簡單的三層設定中，SAP 中央服務沒有高可用性保護。 若為生產系統，不建議讓 SAP 中央服務保持未受保護的狀態。 如需有關 SAP 中央執行個體的所謂多重 SID 設定以及這類多重 SID 設定高可用性的具體資訊，請參閱本文件的後續各節。

SAP DBMS 層的高可用性保護

如果您想要部署 SAP 生產系統，就需要考慮高可用性設定的熱待命節點類型。 特別是使用 SAP HANA 時，如果必須先將資料載入到記憶體才能獲得完整效能和可擴縮性，就不適合使用 Azure 服務修復來獲得高可用性。

一般而言，Microsoft 只會支援 SAP 工作負載案例中所描述的高可用性設定和軟體套件。 您可以在 SAP 附註 #1928533 中看到相同的陳述。 如果是 Microsoft 未記載可用於 SAP 工作負載的其他高可用性第三方軟體架構，Microsoft 不會為其提供支援。 在這種情況下，就必須由高可用性架構的第三方供應商支援高可用性設定，而且必須由您聯繫該供應商以客戶的身分加入到支援程序。 例外狀況會於本文中提及。

一般而言，Microsoft 在 Azure VM 或 HANA 大型執行個體單位上所支援的高可用性設定數量有限。

至於 Azure VM，則會在 DBMS 層級上支援下列高可用性設定：

重要

上述案例都不支援一個 VM 中有多個 DBMS 執行個體的設定。 這表示上述每個案例都只能在每一 VM 中部署一個資料庫執行個體，並使用所述的高可用性方法加以保護。 目前不支援在相同 Windows 或 Pacemaker 容錯移轉叢集底下保護多個 DBMS 執行個體。 此外，Oracle Data Guard 也只支援用於每一 VM 單一執行個體的部署案例。

市面上有各種可在一個 DBMS 執行個體底下裝載多個資料庫的資料庫系統。 如同 SAP HANA，多個資料庫可以裝載到多個資料庫容器 (MDC) 中。 這些多資料庫設定如果是在一個容錯移轉叢集資源內運作，便可獲得支援。 如果需要多個叢集資源，這樣的設定就不會獲得支援。 例如，您會在一個 SQL Server 執行個體底下定義多個 SQL Server 可用性群組的設定。

DBMS HA 組態

視 DBMS 和 (或) 作業系統而定，Azure 負載平衡器等元件不一定需要作為解決方案架構的一部分。

具體來說，maxDB 就必須有不同的儲存體設定。 使用 maxDB 時，資料和記錄檔必須位於共用儲存體上，才能實現高可用性設定。 只有 maxDB 才支援使用共用儲存體來實現高可用性。 至於其他 DBMS，唯一支援的磁碟設定就只有每一節點使用不同的儲存體堆疊。

市面上存在其他也已知會在 Microsoft Azure 上執行的高可用性架構。 不過，Microsoft 並未測試過這些架構。 如果您想要使用這些架構來建置高可用性設定，就必須與該軟體的提供者合作，以便：

  • 開發部署架構
  • 進行架構部署
  • 進行架構支援

重要

Microsoft Azure Marketplace 提供各種軟設備，且這些軟設備會提供以 Azure 原生儲存體為基礎的儲存體解決方案。 這些軟設備也可以用來建立 NFS 共用，因此理論上可以在需要待命節點的 SAP HANA 擴增部署中使用。 由於各種原因，Microsoft 和「Azure 上的 SAP」所提供的 DBMS 部署都不支援這些儲存體軟設備。 目前完全不支援在 SMB 共用上部署 DBMS。 在 NFS 共用上部署 DBMS 則只能在 Azure NetApp Files 上的 NFS 4.1 共用中進行。

SAP 中央服務的高可用性

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

在列出的解決方案中，您與 SIOS 之間需要有支援關係，才能支援 Datakeeper 產品，並在發生問題時直接與 SIOS 聯繫。 根據您授權 Windows、Red Hat 和/或 SUSE OS 的方式，您也可能必須與 OS 提供者簽訂支援合約，才能獲得所列出高可用性設定的完整支援。

設定也可能會像下面這樣：

DBMS 和 ASCS HA 設定

圖中右側顯示的是高可用性 SAP 中央服務。 除了透過容錯移轉叢集架構保護 SAP Central，可在失敗案例中容錯移轉。 還需要高可用性 NFS 或 SMB 共用或 Windows 共用磁碟，確保 sapmnt 和全域傳輸目錄可供使用，無論是否存在於單一 VM 中。 其他的某些解決方案 (例如 Windows 容錯移轉叢集伺服器和 Pacemaker) 則必須有 Azure 負載平衡器才能將流量導向或重新導向到狀況良好的節點。

所顯示的清單中沒有提及 Oracle Linux 作業系統。 Oracle Linux 不支援使用 Pacemaker 作為叢集架構。 如果您想要在 Oracle Linux 上部署 SAP 系統，而且需要 Oracle Linux 的高可用性架構，則必須與第三方供應商合作。 其中一個供應商是 SIOS，其適用於 Linux 的保護套件已獲得 Azure 上的 SAP 所支援。 如需詳細資訊，請參閱 SAP 附註 #1662610 - 適用於 Linux 的 SIOS 保護套件支援詳細資料。

上面所列的 SAP 中央服務案例支援的儲存體

由於只有一部分的 Azure 儲存體類型會提供有資格在 SAP 中央服務叢集案例中使用的高可用性的 NFS 共用或 SMB 共用，支援的儲存體類型清單

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

重要

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

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

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

在 Azure 上，支援將多重 SID 叢集設定用於具有 ENSA1 和 ENSA2 的 Windows 作業系統。 建議不要在一個多重 SID 叢集上合併使用較舊的「加入佇列複寫服務架構 (ENSA1)」與新的架構 (ENSA2)。 下列文章會記載這類架構的詳細資料

若為 SUSE，也支援以 Pacemaker 為基礎的多重 SID 叢集。 到目前為止，支援將此設定用於：

  • 最多五個 SAP ASCS/SCS 執行個體
  • 舊的加入佇列複寫伺服器 ice 架構 (ENSA1)
  • 雙節點 Pacemaker 叢集設定

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

具有加入佇列複寫伺服器的多重 SID 叢集示意圖如下

此圖顯示具有加入佇列復寫伺服器的多重 SID 叢集。

SAP HANA 擴增案例

SAP HANA 擴增案例支援用於一部分通過 HANA 認證的 Azure VM，如 SAP HANA 硬體目錄所列。 [叢集] 欄中標示為 'Yes' 的所有 VM 可用於 OLAP 或 S/4HANA 向外延展。下列 Azure 儲存體類型支援無待命的設定：

OLAP 或 S/4HANA 的 SAP HANA 擴增設定 (具有待命節點) 僅支援用於裝載到 Azure NetApp Files 上的 NFS 共用。

如需具有或不具有待命節點的確切儲存體設定詳細資訊，請參閱文章：

災害復原案例

有各種災害復原案例會受到支援。 我們將災害架構定義為架構，這應該會彌補完整的 Azure 區域離線的問題。 這表示我們需要將災害復原目標設為不同的 Azure 區域，才能執行 SAP 環境。 我們將方法和設定區分為 DBMS 層和非 DBMS 層。

DBMS 層

在 DBMS 層中，支援使用 DBMS 原生複寫機制的設定，例如 Always On、Oracle Data Guard、Db2 HADR、SAP ASE Always-On 或 HANA 系統複寫。 在這種情況下，和在單一 Azure 區域內部署的典型高可用性案例一樣，複寫串流必須非同步 (而不是同步)。 跨 Azure 區域的 SAP HANA 可用性一文會說明這類受支援 DBMS 災害復原設定的典型範例。 該節的第二張示意圖會描述 HANA 案例來作為範例。 支援用於 SAP 應用程式的主要資料庫都能夠部署到這類案例。

其支援使用較小的 VM 來作為災害復原區域中的目標執行個體，因為該 VM 不會遇到完整的工作負載流量。 如果要這樣做，就必須記住下列考量：

  • 較小的 VM 類型不允許連結比較小的 VM 還多的磁碟
  • 較小的 VM 具有較少的網路和儲存體輸送量
  • 在一個 Azure 可用性設定組中集合了不同 VM 時，或應該在 M 系列 VM 與 Mv2 系列 VM 之間重新調整大小時，跨 VM 系列來重新調整大小會是個問題
  • 資料庫執行個體的 CPU 和記憶體使用量要能夠以最少的延遲接收變更串流，並要有足夠的 CPU 和記憶體資源，而能以最少的延遲將這些變更套用至資料

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

另一種支援用於部署 DR 目標的方法，是在 VM 上安裝第二個 DBMS 執行個體，且這個 VM 要執行非生產 SAP 執行個體的非生產 DBMS 執行個體。 這可能會有點困難，因為您需要了解，應該在 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 上，重新同步是可行的解決方案。 Azure NetApp Files 磁碟區的跨區域複寫也是可行的解決方案。

不支援的案例

提供案例清單，這些案例不受 Azure 架構上的 SAP 工作負載支援。 不支援表示 SAP 和 Microsoft 無法支援這些設定，必須委由提供軟體來建立這類架構的最終相關第三方提供支援。 其中兩個類別包括：

  • 儲存體軟設備：市場上有各種儲存體軟設備。 有些廠商會提供自己的文件，說明如何在與 SAP 軟體相關的 Azure 上使用這些儲存體軟設備。 如果設定或部署的支援涉及這類儲存體軟設備，就必須由儲存體軟設備的廠商來提供。 SAP 支援附註 #2015553 也載明了此一事實
  • 高可用性架構：針對 Azure 上的 SAP 工作負載，只有 Pacemaker 和 Windows Server 容錯移轉叢集是支援的高可用性架構。 如先前所述，Microsoft 會描述並記載 SIOS Datakeeper 的解決方案。 不過，SIOS Datakeeper 的元件必須透過 SIOS 來獲得支援，因為其為提供這些元件的廠商。 SAP 也在各種 SAP 附註中列出了其他已通過認證的高可用性架構。 其中的某些架構也已通過 Azure 第三方廠商的認證。 不過，使用這些產品來進行設定時，其支援就必須由產品廠商來提供。 不同廠商對於 SAP 支援程序有進行不同的整合。 請先釐清哪些支援程序最適合特定廠商，再決定要在部署於 Azure 的 SAP 設定中使用什麼產品。
  • 資料庫檔案位於共用磁碟的共用磁碟叢集不受支援 (但 maxDB 除外)。 至於其他資料庫，支援的解決方案則都是使用不同的儲存位置 (而不是 SMB 或 NFS 共用或共用磁碟) 來設定高可用性案例

不支援的其他案例如下：

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

我們未測試過，因此沒有清單體驗的案例如下：

  • 複寫 DBMS 層 VM 的 Azure Site Recovery。 因此，建議您使用資料庫原生的非同步複寫功能來進行可能的災害復原設定

後續步驟

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