本指南提供一組經過證實的做法，以在支援 Azure 上的災害復原 （DR） 的高可用性環境中執行 S/4HANA 和 Suite on HANA。 Fiori 資訊僅適用於 S/4HANA 應用程式。
架構
下載此架構的 Visio 檔案。
注意
部署此架構需要適當授權 SAP 產品和其他非Microsoft技術。
本指南說明常見的生產系統。 此架構是使用虛擬機器 （VM） 大小來部署，您可以變更以符合組織的需求。 為了符合您的業務需求，您可以將此設定縮減為單一 VM。
本指南會大幅簡化網路配置，以示範架構原則。 其並非用來描述完整的企業網路。
架構會使用下列元件。 某些共用服務是選擇性的。
Azure 虛擬網路。 虛擬網絡 服務會安全地將 Azure 資源彼此連線。 在此架構中，虛擬網路會透過部署在中樞輪輻拓撲中樞的 網關聯機到內部部署環境。 輪輻是用於 SAP 應用程式和資料庫層的虛擬網路。
虛擬網路對等互連。 此架構會使用多個已對等互連的虛擬網路。 此拓撲會針對部署在 Azure 上的服務提供網路分割和隔離。 對等互連會透過Microsoft骨幹網路以透明方式連線網路，如果在單一區域內實作，則不會產生效能損失。 每個階層應用程式（SAP NetWeaver）、資料庫和共用服務都會使用個別子網，例如跳躍方塊和 Windows Server Active Directory。
VM。 此架構會使用針對應用層和資料庫層執行Linux的VM，並以下列方式分組：
應用程式層。 此架構層包含 Fiori 前端伺服器集區、SAP Web 發送器集區、應用程式伺服器集區和 SAP 中央服務叢集。 如需在Linux VM中執行的 Azure 上中央服務的高可用性，則需要高可用性網路檔案共用服務，例如 Azure 檔案儲存體、Azure NetApp Files、叢集網路文件系統 （NFS） 伺服器或適用於 Linux 的 SIOS 保護套件中的 NFS 檔案共用。 若要為 Red Hat Enterprise Linux （RHEL） 上的中央服務叢集設定高可用性檔案共用，您可以在執行 RHEL 的 Azure VM 上設定 GlusterFS 。 在 SUSE Linux Enterprise Server （SLES） 15 SP1 和更新版本或 SLES for SAP Applications 上，您可以使用 Pacemaker 叢集上的 Azure 共用磁碟 來達到高可用性。
SAP HANA。 資料庫層會使用叢集中的兩個或多個 Linux VM，在相應增加部署中達到高可用性。 HANA 系統復寫 （HSR） 是用來復寫主要和次要 HANA 系統之間的內容。 Linux 叢集會用來偵測系統失敗，並協助自動容錯移轉。 記憶體型或雲端式隔離機制必須用來確保失敗的系統已隔離或關閉，以避免叢集分割大腦狀況。 在 HANA 向外延展部署中，您可以使用下列其中一個選項來達到資料庫高可用性：
- 在沒有Linux叢集元件的情況下，使用 Azure NetApp Files 設定 HANA 待命節點。
- 使用 Azure 進階記憶體來相應放大，而不需要待命節點。 使用 Linux 叢集進行故障轉移。
Azure Bastion。此服務可讓您使用瀏覽器和 Azure 入口網站，或透過本機電腦上已安裝的原生 SSH 或 RDP 用戶端連線到虛擬機。 如果只使用 RDP 和 SSH 進行管理，Azure Bastion 是絕佳的解決方案。 如果您使用其他管理工具，例如 SQL Server Management Studio 或 SAP 前端，請使用傳統的自我部署跳躍方塊。
私用 DNS 服務。Azure 私用 DNS 為您的虛擬網路提供可靠且安全的 DNS 服務。 Azure 私人 DNS 可管理及解析虛擬網路的網域名稱，而無需設定自訂的 DNS 解決方案。
負載平衡器。 若要將流量分散到 SAP 應用層子網中的 VM 以達到高可用性，建議您使用 Azure Standard Load Balancer。 請注意，標準 Load Balancer 預設會提供一層安全性。 標準Load Balancer後方的 VM 沒有輸出因特網連線能力。 若要在 VM 上啟用輸出因特網，您必須更新 Standard Load Balancer 設定。 您也可以使用 Azure NAT 閘道 來取得輸出連線能力。 針對 SAP Web 應用程式高可用性，請使用內 建的 SAP Web Dispatcher，或其他商業可用的負載平衡器。 根據您的選擇：
- 您的流量類型，例如 HTTP 或 SAP GUI。
- 您需要的網路服務，例如安全套接字層 （SSL） 終止。
標準 Load Balancer 支援多個前端虛擬 IP。 此支援適用於包含這些元件的叢集實作：
- 進階商務應用程式程式設計 （ABAP） SAP Central Service （ASCS）
- 加入佇列複寫伺服器 (ERS)
這兩個元件可以共用負載平衡器來簡化解決方案。
標準 Load Balancer 也支援多重系統識別碼 （多重 SID） SAP 叢集。 換句話說，SLES 或 RHEL 上的多個 SAP 系統可以共用常見的高可用性基礎結構，以降低成本。 建議您評估節省成本，並避免將太多系統放在一個叢集中。 每個叢集 Azure 支援 不超過五個 SID。
應用程式閘道。 Azure 應用程式閘道 是 Web 流量負載平衡器，可用來管理 Web 應用程式的流量。 傳統負載平衡器會在傳輸層運作（OSI 第 4 層 - TCP 和 UDP）。 他們會根據來源IP位址和埠將流量路由傳送至目的地IP位址和埠。 應用程式閘道 可以根據 HTTP 要求的其他屬性來進行路由決策，例如 URI 路徑或主機標頭。 此類型的路由稱為應用程式層 (OSI 第 7 層) 負載平衡。 S/4HANA 透過 Fiori 提供 Web 應用程式服務。 您可以使用 應用程式閘道 來平衡此 Fiori 前端，其中包含 Web 應用程式。
閘道。 網關會連線不同的網路，並將內部部署網路延伸至 Azure 虛擬網路。 Azure ExpressRoute 是建議的 Azure 服務，用來建立不會經過公用因特網的私人連線，但您也可以使用 站對站 連線。 為了減少延遲， ExpressRoute Global Reach 和 ExpressRoute FastPath 是本文稍後討論的連線選項。
區域備援閘道。 您可以跨區域部署 ExpressRoute 或虛擬專用網 （VPN） 閘道，以防範區域失敗。 此架構會使用 區域備援 虛擬網路網關進行復原，而不是以相同可用性區域為基礎的區域性部署。
鄰近放置群組。 此邏輯群組會將條件約束放在可用性設定組或虛擬機擴展集所部署的 VM 上。 鄰近放置群組偏好共置，這會將 VM 放在相同的數據中心，以將應用程式延遲降到最低。
注意
使用 SAP 應用程式獲得最佳網路等待時間的組態選項一文包含更新的設定策略。 您應該閱讀本文，特別是如果您想要部署具有最佳網路等待時間的 SAP 系統。
網路安全性群組。 若要限制虛擬網路中的連入、傳出和內部子網流量，您可以建立 網路安全組。
應用程式安全性群組。 若要定義以工作負載為基礎且以應用程式為中心的精細網路安全策略，請使用 應用程式安全組 ，而不是明確的IP位址。 您可以篩選來自網路受信任區段的流量，依名稱和保護應用程式分組 VM。
Azure 儲存體。 記憶體會以虛擬硬碟的形式為 VM 提供數據持續性。 我們建議 使用 Azure 受控磁碟。
建議
此架構描述小型生產層級部署。 部署會根據商務需求而有所不同，因此請將這些建議視為起點。
VM
在應用程式伺服器集區和叢集中，根據您的需求調整 VM 數目。 如需在 VM 上執行 SAP NetWeaver 的詳細資訊，請參閱 Azure 虛擬機器 規劃和實作指南。 本指南也適用於 SAP S/4HANA 部署。
如需 Azure VM 類型和輸送量計量的 SAP 支援詳細數據，請參閱 SAP 附註1928533。 若要存取 SAP 附注，您需要 SAP 服務 Marketplace 帳戶。 如需 HANA 資料庫的認證 Azure VM 清單，請參閱 SAP 認證和支援的 SAP HANA 硬體目錄。
SAP Web 發送器
Web Dispatcher 元件用於負載平衡 SAP 應用程式伺服器之間的 SAP 流量。 為了達到 SAP Web Dispatcher 的高可用性，Azure Load Balancer 會實作故障轉移叢集或平行 Web 發送器設定。 針對因特網對向通訊，周邊網路中的獨立解決方案是滿足安全性考慮的建議架構。 ASCS 上的內嵌 Web 發送器是一種特殊選項。 如果您使用此選項，請考慮適當重設大小，因為 ASCS 上的額外工作負載。
Fiori 前端伺服器 （FES）
此架構可解決許多需求，並假設使用內嵌 Fiori FES 模型。 所有技術元件都安裝在 S/4 系統本身上，這表示每個 S/4 系統都有自己的 Fiori 啟動台。 此部署模型的高可用性設定是 S/4 系統的高可用性設定，不需要額外的叢集或 VM。 因此，架構圖表不會顯示 FES 元件。
如需主要部署選項的描述，無論是內嵌或中樞，視案例而定，請參閱 SAP Fiori 部署選項和系統環境建議。 為了簡單和效能，Fiori 技術元件與 S/4 應用程式之間的軟體版本緊密結合。 此設定可讓中樞部署只適合少數狹窄的使用案例。
如果您使用 FES 中樞部署，FES 是傳統 SAP NetWeaver ABAP 堆疊的附加元件。 設定高可用性的方式與保護具有叢集或多主機功能的三層 ABAP 應用程式堆疊相同：使用待命伺服器資料庫層、具有高可用性 NFS 的叢集 ASCS 層，以及至少兩部應用程式伺服器。 流量會透過一組可叢集或平行的 Web Dispatcher 實例進行負載平衡。 針對因特網面向的 Fiori 應用程式，我們建議在周邊網路中部署 FES 中樞。 使用 應用程式閘道 上的 Azure Web 應用程式防火牆 作為轉移威脅的重要元件。 使用 Microsoft Entra ID 搭配 SAML 進行使用者驗證和 SAP Fiori 的 SSO。
如需某些因特網面向的輸入/輸出設計範例，請參閱 Azure 上 SAP 的輸入和輸出因特網連線。
應用程式伺服器集區
若要管理 ABAP 應用程式伺服器的登入群組，通常會使用 SMLG 交易來平衡登入使用者負載、將 SM61 用於批處理伺服器群組、將 RZ12 用於遠端函數調用 （RFC） 群組等等。 這些交易會使用中央服務訊息伺服器中的負載平衡功能，在處理SAP GUIs和 RFC 流量的 SAP 應用程式伺服器集區之間散發傳入會話或工作負載。
SAP 中央服務叢集
當 Azure 單一實體 VM 可用性服務等級協定 （SLA） 符合您的需求時，您可以將中央服務部署至單一 VM。 不過，VM 會變成 SAP 環境的潛在單一失敗點（SPOF）。 針對高可用性中央服務部署，請使用NFS over Azure 檔案儲存體 或 Azure NetApp Files 服務和中央服務叢集。
另一個選項是使用 Azure 共用磁碟 來達到高可用性。 在 SLES 15 SP1 和更新版本或適用於 SAP 應用程式的 SLES 上，您可以使用適用於 Linux 的 Azure 共用磁碟來設定 Pacemaker 叢集。
或者，您可以針對 Linux 叢集共用記憶體使用 NFS 檔案共用。
在 Azure 部署上，應用程式伺服器會透過中央服務或 ERS 服務的虛擬主機名稱，連線到高可用性中央服務。 這些主機名會指派給負載平衡器的叢集前端IP組態。 Load Balancer 支援多個前端 IP，因此中央服務和 ERS 虛擬 IP（VIP） 都可以設定為一個負載平衡器。
Azure 上的 ASCS 多重 SID 安裝 Linux 叢集支援現已正式推出。 在多個 SAP 系統之間共用可用性叢集可簡化 SAP 環境。
網路
此架構會使用中樞輪輻拓撲，其中中樞虛擬網路會作為內部部署網路的連線中心點。 輪輻是與中樞對等互連的虛擬網路。 您可以使用輪輻隔離工作負載。 流量會透過閘道連線，在內部部署資料中心與中樞之間流動。
網路介面卡 (NIC)
傳統內部部署 SAP 部署會為每部電腦實作多個 NIC，以隔離系統管理流量與商務流量。 在 Azure 上，虛擬網路是軟體定義的網路，可透過相同的網路網狀架構傳送所有流量。 因此，基於效能考量，不需要使用多個 NIC。 不過，如果您的組織需要隔離流量，您可以為每個 VM 部署多個 NIC、將每個 NIC 連線到不同的子網，然後使用網路安全組來強制執行不同的訪問控制原則。
Azure NIC 支援多個IP。 此支援符合 SAP 建議使用虛擬主機名進行安裝的做法，如 SAP 附註962955中所述。若要存取 SAP 附注，您需要 SAP 服務 Marketplace 帳戶。
子網路和網路安全群組
此架構會將虛擬網路位址空間分成子網。 您可以將每個子網路與定義子網路存取政策的網路安全群組連結。 將應用程式伺服器放在不同的子網上。 如此一來，您可以藉由管理子網安全策略，而不是個別伺服器，更輕鬆地保護它們。
當您將網路安全組與子網建立關聯時，網路安全組會套用至子網內的所有伺服器，並提供對伺服器進行更細緻的控制。 使用 Azure 入口網站、PowerShell 或 Azure CLI 設定網路安全組。
ExpressRoute Global Reach
如果您的網路環境包含兩個或多個 ExpressRoute 線路， ExpressRoute Global Reach 可協助您減少網路躍點和降低延遲。 這項技術是邊界網關通訊協定 （BGP） 路由對等互連，在兩個或多個 ExpressRoute 線路之間設定，以橋接兩個 ExpressRoute 路由網域。 當網路流量周遊多個 ExpressRoute 線路時，Global Reach 會降低延遲。 它目前僅適用於 ExpressRoute 線路上的私人對等互連。
目前沒有可在 Global Reach 中變更的網路存取控制清單或其他屬性。 因此，指定 ExpressRoute 線路所學習的所有路由（從內部部署和 Azure）都會在線路對等互連與其他 ExpressRoute 線路之間公告。 建議您在內部部署建立網路流量篩選，以限制對資源的存取。
ExpressRoute FastPath
FastPath 會在 Azure 網路的進入點實作 Microsoft Edge 交換。 FastPath 可減少大部分數據封包的網路躍點。 因此，FastPath 會降低網路等待時間、改善應用程式效能，並且是新 ExpressRoute 連線至 Azure 的預設組態。
針對現有的 ExpressRoute 線路，請連絡 Azure 支援 以啟用 FastPath。
FastPath 不支援虛擬網路對等互連。 如果其他虛擬網路與連線至 ExpressRoute 的虛擬網路對等互連，則從內部部署網路到其他輪輻虛擬網路的網路流量會傳送至虛擬網路網關。 因應措施是將所有虛擬網路直接連線到 ExpressRoute 線路。
負載平衡器
SAP Web Dispatcher 會處理對 SAP 應用程式伺服器集區之 HTTP（S） 流量的負載平衡。 此軟體負載平衡器提供應用層服務（稱為 ISO 網路模型中的第 7 層），能夠終止 SSL 和其他卸載功能。
Load Balancer 是網路傳輸層服務（第 4 層），使用來自數據流的五 Tuple 哈希來平衡流量。 哈希是以來源IP、來源埠、目的地IP、目的地埠和通訊協定類型為基礎。 負載平衡器用於叢集設定，以在發生錯誤時將流量導向至主要服務實例或狀況良好的節點。 建議您針對所有 SAP 案例使用 Azure Standard Load Balancer 。 請務必注意，標準 Load Balancer 預設是安全的，且標準 Load Balancer 後方沒有 VM 具有輸出因特網連線能力。 若要在 VM 中啟用輸出因特網，您必須調整 標準 Load Balancer 組態。
針對透過 DIAG 通訊協定或 RFC 連線到 SAP 伺服器的 SAP GUI 用戶端流量，中央服務訊息伺服器會透過 SAP 應用程式伺服器 登入群組平衡負載。 不需要額外的負載平衡器。
儲存體
有些客戶會針對其應用程式伺服器使用標準儲存體。 由於不支持標準受控磁碟，如 SAP 附注1928533所述，建議您在所有情況下使用進階 Azure 受控磁碟 或 Azure NetApp Files 。 SAP 附註的最新更新 2015553 排除在少數特定使用案例中使用標準 HDD 記憶體和標準 SSD 記憶體。
因為應用程式伺服器不會裝載任何商務數據，因此您也可以使用較小的 P4 和 P6 進階磁碟來協助管理成本。 若要瞭解記憶體類型如何影響 VM 可用性 SLA，請參閱 虛擬機器 的 SLA。 針對高可用性案例， Azure 共用磁碟 功能可在 Azure 進階 SSD 和 Azure Ultra 磁碟記憶體上使用。 如需詳細資訊，請參閱 Azure 受控磁碟。
您可以使用 Azure 共用磁碟搭配 Windows Server、SLES 15 SP 1 和更新版本，或 SLES for SAP。 當您在Linux叢集中使用 Azure 共用磁碟時，Azure 共用磁碟會作為 STONITH 區塊裝置（SBD）。 它會在叢集網路分割的情況下提供仲裁投票。 此共用磁碟沒有文件系統，且不支援從多個叢集成員 VM 同時寫入。
Azure NetApp Files 具有 NFS 和 SMB 的內建檔案共用功能。
針對 NFS 共用案例， Azure NetApp Files 提供可用於 /hana/shared、 /hana/data和 /hana/log 磁碟區的 NFS 共用可用性。 如需可用性保證，請參閱 Azure NetApp Files 的 SLA。 如果您針對 /hana/data 和 /hana/log 磁碟區使用 Azure NetApp Files 型 NFS 共用，則必須使用 NFS v4.1 通訊協定。 針對磁碟區 /hana/shared ，支援 NFS v3 通訊協定。
針對備份數據存放區，建議您使用 Azure 非經常性存取層和封存存取層。 這些儲存層是符合成本效益的方式，可儲存不常存取的長期數據。 您也可以考慮使用 Azure NetApp Files 標準層 作為備份目標或 Azure NetApp Files 備份選項。 針對受控磁碟，建議的備份數據層是 Azure 非經常性存取層或封存存取層。
Ultra 磁碟記憶體 和 Azure NetApp Files 超效能層級 可大幅降低磁碟延遲，並讓效能關鍵應用程式和 SAP 資料庫伺服器受益。
Azure 進階 SSD v2 是專為 SAP 等效能關鍵性工作負載所設計。 如需此記憶體解決方案的優點及其目前限制的相關信息，請參閱 部署進階 SSD v2 。
效能考量
SAP 應用程式伺服器會持續與資料庫伺服器通訊。 針對在任何資料庫平台上執行的效能關鍵性應用程式，包括 SAP HANA，如果您使用進階 SSD v1，請啟用 記錄磁碟區的寫入加速器 。 這樣做可以改善記錄寫入延遲。 進階 SSD v2 不使用寫入加速器。 寫入加速器適用於 M 系列 VM。
若要優化伺服器間通訊，請使用 加速網路。 具有兩個或多個 vCPU 的一般用途和計算優化 VM 實例大小都支援加速網路。 在支援超執行緒的執行個體上，具有四個或多個 vCPU 的 VM 執行個體支援加速網路。
如需 SAP HANA 效能需求的詳細資訊，請參閱 SAP 附註1943937 - 硬體設定檢查工具。 若要存取 SAP 附注，您需要 SAP 服務 Marketplace 帳戶。
若要達到高 IOPS 和磁碟頻寬輸送量，記憶體磁碟區 效能優化 中的常見做法適用於您的記憶體配置。 例如，如果您結合多個磁碟來建立等量磁碟磁碟區，您可以改善IO效能。 藉由在不常變更的記憶體內容上啟用讀取快取，您可以提升數據擷取的速度。 如需執行 SAP HANA 時各種 VM 大小的記憶體組態建議，請參閱 SAP HANA Azure 虛擬機記憶體組態。
Azure 進階 SSD v2 是專為 SAP 等效能關鍵性工作負載所設計。 請參閱 Azure 受控磁碟類型 ，以瞭解其優點和限制和最佳使用案例。
Ultra 磁碟記憶體 是新一代的記憶體，符合密集的 IOPS 和 SAP HANA 等應用程式的傳輸頻寬需求。 您可以動態變更 Ultra 磁碟的效能，並獨立設定 IOPS 和 MB/秒等計量，而不需要重新啟動 VM。 當 Ultra 磁碟記憶體可用時，建議使用 Ultra 磁碟記憶體，而不是寫入加速器。
某些 SAP 應用程式需要經常與資料庫通訊。 由於距離，應用程式和資料庫層之間的網路等待時間可能會對應用程式效能造成負面影響。 Azure 鄰近放置群組 會為部署在可用性設定組中的 VM 設定放置條件約束。 在群組的邏輯建構中，共置和效能優先於延展性、可用性和成本。 鄰近放置群組可以大幅改善大部分 SAP 應用程式的用戶體驗。
不支援在應用程式與任何 SAP 應用程式堆疊的資料庫層之間放置網路虛擬裝置 （NVA）。 NVA 需要大量的時間來處理數據封包。 因此，應用程式效能無法接受。
我們也建議您在部署具有 可用性區域的資源時考慮效能，這可以增強服務可用性，如本文稍後所述。 請考慮在目標區域的所有區域之間建立明確的網路等待時間配置檔。 此方法可協助您決定資源位置，以取得區域之間的最小延遲。 若要建立此設定檔，請在每個區域中部署小型 VM 來執行測試。 測試的建議工具包括 PsPing 和 Iperf。 測試之後，請移除這些 VM。 如需您可以改用的公用網域網路等待時間測試工具，請參閱 可用性區域延遲測試。
Azure NetApp Files 具有獨特的效能功能，可讓即時調整符合最需求 SAP 環境的需求。 如需使用 Azure NetApp Files 時的效能考慮，請參閱 Azure NetApp Files 上的 HANA 資料庫大小調整。
可擴縮性考量
在 SAP 應用層，Azure 提供各種不同的 VM 大小，以相應增加和相應放大。如需內含清單，請參閱 SAP 附注1928533中的「Azure 上的 SAP 應用程式：支援的產品和 Azure VM 類型」。 若要存取 SAP 附注，您需要 SAP 服務 Marketplace 帳戶。 更多 VM 類型會持續通過認證，因此您可以在相同的雲端部署中相應增加或減少。
在資料庫層上，此架構會在 Azure VM 上執行 SAP HANA S/4 應用程式，其可在一個實例中相應增加至 24 TB（TB）。 如果您的工作負載超過 VM 大小上限，您可以使用最多 96 TB（4 x 24） 的多節點組態來進行在線事務處理 （OLTP） 應用程式。 如需詳細資訊，請參閱 認證和支援的 SAP HANA 硬體目錄。
可用性考慮
資源備援是高可用性基礎結構解決方案中的一般主題。 如需各種記憶體類型的單一實例 VM 可用性 SLA，請參閱 虛擬機器 SLA。 若要在 Azure 上增加服務可用性，請使用彈性協調流程、可用性區域或可用性設定組來部署具有 虛擬機器擴展集 的 VM 資源。
在此 SAP 應用程式的分散式安裝中，會復寫基底安裝以達到高可用性。 針對架構的每個層級，高可用性設計會有所不同。
部署方法
在 Azure 上，SAP 工作負載部署可以是區域或區域性，視 SAP 應用程式的可用性和復原需求而定。 Azure 提供不同的部署選項，例如 虛擬機器擴展集 彈性協調流程 （FD=1）、可用性區域和可用性設定組，以增強資源的可用性。 若要全面瞭解可用的部署選項及其在不同 Azure 區域中的適用性（包括跨區域、在單一區域內或沒有區域的區域），請參閱 SAP NetWeaver 的高可用性架構和案例。
應用伺服器層中的 Web 發送器
您可以使用備援 Web 發送器實例來達到高可用性。 如需詳細資訊，請參閱 SAP 檔中的 SAP Web 發送器 。 可用性層級取決於 Web Dispatcher 背後的應用程式大小。 在具有少數延展性考慮的小型部署中，您可以與 ASCS VM 共置 Web Dispatcher。 如此一來，您即可節省獨立OS維護，並同時獲得高可用性。
應用伺服器層中的中央服務
如需 Azure Linux VM 上中央服務的高可用性，請針對選取的 Linux 散發套件使用適當的高可用性擴充功能。 使用 SUSE DRBD 或 Red Hat GlusterFS，將共用文件系統放在高可用性 NFS 記憶體上是慣用的。 若要提供高可用性 NFS 並消除 NFS 叢集的需求，您可以改用其他符合成本效益或健全的解決方案，例如透過 Azure 檔案儲存體 或 Azure NetApp Files 的 NFS。 請注意，Azure NetApp Files 共用可以裝載 SAP HANA 數據和記錄檔。 此設定會啟用具有待命節點的 HANA 向外延展部署模型，而 NFS over Azure 檔案儲存體 適用於高可用性的非資料庫檔案共用。
NFS over Azure 檔案儲存體 現在支援 SLES 和 RHEL 的高可用性檔案共用。 此解決方案適用於 SAP 安裝中的高可用性檔案共用，例如 /sapmnt/saptrans 的檔案共用。
Azure NetApp Files 支援 SLES 上的 ASCS 高可用性。 如需 RHEL 高可用性 ASCS 的詳細資訊，請參閱 適用於 Linux 的 SIOS 保護套件。
改善的 Azure Fence 代理程式適用於 SUSE 和 Red Hat ，並提供比舊版代理程式更快的服務故障轉移。
另一個選項是使用 Azure 共用磁碟 來達到高可用性。 在 SLES 15 SP 1 和更新版本或 SLES for SAP 上，您可以使用 Azure 共用磁碟來設定 Pacemaker 叢集，以達到高可用性。
在 Azure Standard Load Balancer 上，您可以啟用 高可用性埠 ，並避免需要為許多 SAP 埠設定負載平衡規則。 一般而言，如果您在設定負載平衡器時啟用直接伺服器傳回 （DSR） 功能，則對客戶端查詢的伺服器回應可能會略過負載平衡器。 這項功能也稱為浮動IP。 負載平衡器可以是內部部署或 Azure。 此直接連線可讓負載平衡器成為數據傳輸路徑的瓶頸。 針對 ASCS 和 HANA DB 叢集，建議您啟用 DSR。 如果後端集區中的 VM 需要公用輸出連線，則需要更多 設定 。
針對透過 DIAG 通訊協定或 RFC 連線到 SAP 伺服器的 SAP GUI 用戶端流量，中央服務訊息伺服器會使用 SAP 應用程式伺服器 登入群組來平衡負載。 不需要額外的負載平衡器。
應用伺服器層中的應用程式伺服器
您可以藉由負載平衡應用程式伺服器集區內的流量來達到高可用性。
ASCS 層
和應用伺服器層一樣，適用於 Linux 的常用 HANA 高可用性解決方案是 Pacemaker。
資料庫層
本指南中的架構描述由兩個 Azure VM 組成的高可用性 SAP HANA 資料庫系統。 資料庫層的原生系統複寫功能可在複寫的節點之間提供手動或自動故障轉移：
- 針對手動故障轉移，請部署多個 HANA 實例，並使用 HSR。
- 針對自動故障轉移，請使用 HSR 和 Linux 高可用性延伸模組 （HAE） 來取得 Linux 發行版。 Linux HAE 會將叢集服務提供給 HANA 資源、偵測失敗事件，以及協調將錯誤服務故障轉移至狀況良好的節點。
跨可用性區域部署 VM
可用性區域 可以增強服務可用性。 區域是指特定 Azure 區域內實體分隔的位置。 它們可改善工作負載可用性，並保護應用程式服務和 VM 免於資料中心中斷。 單一區域中的 VM 會被視為在單一更新或容錯網域中。 選取區域部署時，相同區域中的 VM 會以最佳方式散發至容錯網域和升級網域。
在 支援這項功能的 Azure 區域中 ，至少有三個區域可供使用。 不過，不保證這些區域中數據中心之間的最大距離。 若要跨區域部署多層式 SAP 系統，您必須知道區域內和目標區域之間的網路等待時間，以及已部署的應用程式對網路等待時間有多敏感。
當您決定跨可用性區域部署資源時，請將這些 考慮 納入考慮：
- 一個區域中 VM 之間的延遲
- 跨所選區域的 VM 之間的延遲
- 選取區域中相同 Azure 服務 （VM 類型） 的可用性
注意
不建議使用可用性區域進行災害復原。 在發生自然災害時，災害復原地點應至少距離主要地點100英里。 數據中心之間沒有距離的確定性。
主動/被動部署範例
在此範例部署中，主動 /被動 狀態是指區域內的應用程式服務狀態。 在應用層中，SAP 系統的所有四個作用中應用程式伺服器都位於區域 1。 另一組四部被動應用程式伺服器建置在區域 2 中，但已關閉。 只有在需要時，才會啟動它們。
中央服務和資料庫的兩個節點叢集會延伸至兩個區域。 如果區域 1 失敗，中央服務和資料庫服務會在區域 2 中執行。 區域 2 中的被動應用程式伺服器會啟動。 由於此 SAP 系統的所有元件共置於相同區域中，網路等待時間會降至最低。
主動/主動部署範例
在主動 /主動 部署中，兩組應用程式伺服器會跨兩個區域建置。 在每個區域中，每個集合中的兩部應用程式伺服器都處於非使用中狀態，或關閉。 因此，在正常作業中，這兩個區域中都有作用中的應用程式伺服器。
ASCS 和資料庫服務會在區域 1 中執行。 區域 2 中的應用程式伺服器在連線到 ASCS 和資料庫服務時，可能會有較長的網路等待時間，因為區域之間的實體距離。
如果區域 1 離線，ASCS 和資料庫服務會故障轉移至區域 2。 休眠的應用程式伺服器可以上線，以提供應用程式處理的完整容量。
DR 考慮
SAP 應用程式堆疊中的每個層都會使用不同的方法來提供DR保護。 如需DR策略和實作詳細數據，請參閱 SAP工作負載 的災害復原概觀和基礎結構指導方針和 SAP應用程式的災害復原指導方針。
注意
如果某個區域災害會導致一個區域中許多 Azure 客戶發生大規模故障轉移事件，則無法保證目標區域 的資源容量 。 如同所有 Azure 服務，Site Recovery 會繼續新增特性和功能。 如需 Azure 對 Azure 複寫的最新資訊，請參閱 支援矩陣。
成本考量
使用 Azure 定價計算機來預估成本。
有關詳細資訊，請參閱 Microsoft Azure 架構完善的框架中的 DevOps 成本部分。
VM
此架構會使用針對管理、SAP 應用程式和資料庫層執行 Linux 的 VM。
一般而言，VM 有數種付款選項：
對於沒有可預測完成時間或資源耗用量的工作負載，請考慮隨用隨付選項。
如果您承諾在一年或三年內使用 VM，請考慮使用 Azure 保留 。 VM 保留可以大幅降低成本。 您只需要支付 72% 的隨用隨付服務成本。
使用 Azure 現成 VM 來執行可以中斷且不需要在預先決定的時間範圍或 SLA 內完成的工作負載。 Azure 會在有可用的容量時部署現成 VM，並在需要容量後收回 VM。 與現成 VM 相關聯的成本低於其他 VM 的成本。 請考慮針對這些工作負載找出 VM：
- 高效能運算案例、批處理作業或可視化轉譯應用程式
- 測試環境，包括持續整合和持續傳遞工作負載
- 大規模無狀態應用程式
Azure 保留的虛擬機實例可將 Azure 保留的虛擬機實例費率與隨用隨付訂用帳戶結合，以降低總擁有成本，以便管理可預測和可變工作負載的成本。 如需此供應專案的詳細資訊，請參閱 Azure 保留的虛擬機實例。
如需定價的概觀，請參閱Linux虛擬機器定價。
負載平衡器
在此案例中，Azure 負載平衡器可用來將流量分散到應用層子網中的 VM。
您只需支付已設定的負載平衡和輸出規則數目。 輸入網路位址轉換 （NAT） 規則是免費的。 未設定任何規則時，Standard Load Balancer 不會每小時收費。
ExpressRoute
在此架構中，ExpressRoute 是用於在內部部署網路與 Azure 虛擬網路之間建立私人連線的網路服務。
所有輸入數據傳輸都是免費的。 所有輸出數據傳輸都會根據預先決定的費率收費。 如需詳細資訊，請參閱 Azure ExpressRoute 定價。
管理和作業考慮
若要協助讓系統在生產環境中執行，請考慮下列幾點。
Azure SAP 解決方案中心解決方案
Azure SAP 解決方案中心是一種端對端解決方案，可讓您在 Azure 上建立及`執行 SAP 系統做為統一工作負載，並提供更順暢的創新基礎。 此外，適用於 SAP 解決方案的 Azure 中心引導式部署體驗會建立執行 SAP 系統所需的計算、記憶體和網路元件。 然後，其可協助您根據Microsoft最佳做法自動安裝SAP軟體。 您可以針對新的和現有的 Azure 型 SAP 系統使用管理功能。 如需詳細資訊，請參閱 適用於 SAP 解決方案的 Azure 中心。
Backup
您可以透過許多方式備份 SAP HANA 資料。 移轉至 Azure 之後，請繼續使用您擁有的任何現有備份解決方案。 Azure 提供兩種原生方法來備份。 您可以在 VM 上備份 SAP HANA，或在檔案層級使用 Azure 備份。 Azure 備份 為由 SAP 認證的 BackInt。 如需詳細資訊，請參閱 Azure 備份 常見問題和支援矩陣，以備份 Azure VM 上的 SAP HANA 資料庫。
注意
目前只有 HANA 單一容器或相應增加部署支援 Azure 記憶體快照集。
身分識別管理
使用集中式身分識別管理系統來控制所有層級資源的存取：
透過 Azure 角色型存取控制 （Azure RBAC） 提供 Azure 資源的存取權。
透過輕量型目錄存取通訊協定（LDAP）、Microsoft Entra ID、Kerberos 或其他系統授與 Azure VM 的存取權。
支援應用程式本身透過 SAP 所提供的服務存取，或使用 OAuth 2.0 和Microsoft Entra 識別符。
監視
若要將 Azure 上的應用程式和服務可用性與效能最大化，請使用 Azure 監視器，這是一個全方位的解決方案，可用來收集、分析及處理來自雲端和內部部署環境的遙測數據。 Azure 監視器會顯示應用程式如何執行並主動識別影響它們的問題，以及其相依的資源。 如需在 SAP HANA 和其他主要資料庫解決方案上執行的 SAP 應用程式，請參閱 適用於 SAP 的 Azure 監視器解決方案 ，以瞭解適用於 SAP 的 Azure 監視器如何協助您管理 SAP 服務的可用性和效能。
安全性考量
SAP 有自己的使用者管理引擎 （UME）來控制 SAP 應用程式和資料庫內的角色型存取和授權。 如需詳細資訊，請參閱 SAP HANA 安全性：概觀。
若要改善網路安全性，請考慮使用 使用 NVA 的周邊網路 ，在 Web Dispatcher 和 Fiori 前端伺服器集區子網前面建立防火牆。 數據傳輸成本是將作用中前端伺服器放在與 S/4 系統相同的虛擬網路中執行 Fiori 應用程式的原因。 替代方法是將它們放在周邊網路中，並透過虛擬網路對等互連將它們連線到 S/4。
針對基礎結構安全性，數據會在傳輸和待用時加密。 Azure 上 SAP NetWeaver 的「安全性考慮」一節 虛擬機器–規劃和實作指南包含適用於 S/4HANA 的網路安全性相關信息。 本指南也會指定要在防火牆上開啟的網路埠，以允許應用程式通訊。
若要加密 Linux VM 磁碟，您有各種選擇，如磁碟加密概觀中所述。 針對 SAP HANA 待用數據加密，建議您使用 SAP HANA 原生加密技術。 如需特定 Linux 散發套件、版本和映像上的 Azure 磁碟加密支援，請參閱 Linux VM 的 Azure 磁碟加密。
針對 SAP HANA 待用數據加密，建議您使用 SAP HANA 原生加密技術。
注意
請勿在相同的記憶體磁碟區上使用 HANA 待用數據加密和 Azure 磁碟加密。 針對 HANA，僅使用 HANA 資料加密。 此外，使用客戶管理的金鑰可能會影響 I/O 輸送量。
社群
社群可以回答問題，並協助您設定成功的部署。 請考慮下列資源：
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Ben Trinh |主體架構師
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
如需使用此架構一些相同技術之 SAP 工作負載的詳細資訊和範例，請參閱下列文章：