使用 SAP 應用程式將網路等待時間降至最低的組態選項
重要
在 2021 年 11 月，區域性部署中 SAP 工作負載使用鄰近放置群組的方式已有重大變更。
當 SAP 應用程式以 SAP NetWeaver 或 SAP S/4HANA 架構為基礎，便會感知到 SAP 應用程式層與 SAP 資料庫層之間的網路延遲。 此敏感性源自於應用程式層所執行的大部分商務邏輯。 由於 SAP 應用層會執行商業規則，因此會以每秒數千或數萬的速率，以高頻率對資料庫層發出查詢。 在大部分情況下，這些查詢的本質很單純。 這些查詢在資料庫層的執行時間通常可能低於 500 毫秒。
這類查詢從應用程式層傳送到資料庫層、接收所傳回結果的時間，對商務程序的執行時間影響甚大。 正由於這種對網路延遲的敏感度，因此您在部署 SAP 專案時會希望能達到一定程度的網路延遲下限。 如需網路延遲的分類指南，請參閱 SAP 附註 #1100926 - 常見問題：網路效能。
許多 Azure 區域的資料中心數目已有所成長。 同時，客戶，特別是針對高端 SAP 系統，會使用更特殊的 VM 系列，例如 Mv2 或 Mv3 系列和更新版本。 這些 Azure 虛擬機器類型不一定皆可用於 Azure 區域所收集的各資料中心。 這些事實都是讓 SAP 應用程式層與 SAP DBMS 層間網路延遲最佳化的好機會。
Azure 為 SAP 工作負載提供不同的部署選項。 針對選擇的部署類型，您可以選擇視需要優化網路等待時間。 本文下列各節將詳細說明每個選項的詳細資訊：
鄰近放置群組
鄰近放置群組 可讓您在單一網路脊椎下分組不同的 VM 類型，確保它們之間的最佳低網路等待時間。 當第一個 VM 部署在鄰近放置群組中時，該 VM 會系結至特定的網路脊椎。 由於其他所有 VM 也要部署至相同的鄰近放置群組，因此這些 VM 皆會分組在相同的網路骨幹下。 儘管這樣的前景很吸引人，但採用這種建構時也會帶來一些限制和陷阱：
- 您無法假設所有 Azure VM 類型皆可用於每個 Azure 資料中心或每個網路骨幹。 因此，一個鄰近放置群組內有不同 VM 類型的組合可能大幅受限。 產生這些限制的原因是，獲派鄰近放置群組的網路骨幹或資料中心可能沒有執行特定 VM 類型所需的主機硬體
- 當您為某鄰近放置群組內的 VM 部分調整大小時，無法自動假設：新的 VM 類型一律可用於同一個資料中心，或獲派鄰近放置群組的網路骨幹
- 當 Azure 將硬體解除委任時，可能會將鄰近放置群組的特定 VM 強制分組至其他 Azure 資料中心或其他網路骨幹。 如需了解涵蓋此案例的詳細資料，請閱讀鄰近放置群組文件
重要
由於有潛在限制，因此鄰近放置群組應僅用於以下情況：
- 視某些情況需要 (參閱後文)
- 當應用程式層與 DBMS 層間的網路延遲過高，且會影響工作負載
- 細微性僅限於單一 SAP 系統，而不是整個系統架構或整個 SAP 架構
- 盡可能減少鄰近放置群組內的不同 VM 類型和 VM 數目
鄰近放置群組可用來優化網路等待時間的案例：
- 您想要將 SAP 工作負載的重要資源部署到不同的可用性區域，另一方面，需要使用每個區域中的可用性設定組，將應用層的 VM 分散到不同的容錯網域。 在此情況下，如檔稍後所述，鄰近放置群組是所需的黏附。
- 您可以使用可用性設定組來部署 SAP 工作負載。 其中 SAP 資料庫層，SAP 應用層和 ASCS/SCS VM 會分組在三個不同的可用性設定組中。 在這種情況下，您想要確定可用性設定組不會分散到完整的 Azure 區域，因為這可能會依存於 Azure 區域，而導致網路等待時間可能會對 SAP 工作負載造成負面影響。
- 您可以使用鄰近放置群組將 VM 群組在一起，以達到 VM 中裝載的服務之間的最低可能網路等待時間。 例如，單獨可用性區域內的延遲不符合應用程式需求。
至於部署案例 #2，在許多區域中，特別是沒有可用性區域的區域，以及具有可用性區域的大部分區域，VM 可接受所在位置的網路等待時間。 但不使用鄰近放置群組、且不共置三個不同的可用性設定組時，有些 Azure 區域所提供的體驗差強人意。
何謂鄰近放置群組？
Azure 鄰近放置群組屬於邏輯建構。 鄰近放置群組定義時，便會繫結至 Azure 區域和 Azure 資源群組。 部署 VM 時，在以下情況會參考鄰近放置群組：
- 第一個 Azure VM 所部署的網路骨幹具有許多 Azure 計算單位及低網路延遲。 這類網路骨幹通常符合單一 Azure 資料中心。 您可將第一個虛擬機器視為「範圍 VM」：採用 Azure 配置演算法，最終結合部署參數，以計算縮放單位進行部署。
- 參考該鄰近放置群組的所有後續 VM，皆會部署於第一個虛擬機器的相同網路骨幹下。
注意
若未部署可在第一個 VM 所在網路骨幹下執行特定 VM 類型的主機硬體，便無法成功部署要求的 VM 類型。 您將會看到配置失敗訊息，表示鄰近放置群組周邊無法支援該 VM。
若要降低上述風險，建議您在建立鄰近放置群組時使用意圖選項。 意圖選項可讓您列出您想要包含在鄰近放置群組中的 VM 類型。 系統會使用此 VM 類型清單來尋找裝載這些 VM 類型的最佳資料中心。 如果找到這類資料中心，將會建立 PPG，並針對符合 VM SKU 需求的資料中心設定範圍。 如果找不到這類資料中心，則鄰近放置群組的建立將會失敗。 您可以在 PPG - 使用意圖來指定 VM 大小文件中找到詳細資訊。 請注意，意圖選項所觸發的檢查不會考慮實際容量情況。 因此，仍有配置錯誤根植於容量不足。
您可指派多個鄰近放置群組給單一 Azure 資源群組。 但一個鄰近放置群組僅可指派給一個 Azure 資源群組。
如需鄰近放置群組的詳細資訊和部署範例，請參閱 可用的檔。
區域性部署的鄰近放置群組
請務必在 SAP 應用層與 DBMS 層之間提供相當低的網路等待時間。 在大部分情況下，僅區域性部署就能滿足這項需求。 對於一組有限的案例，單靠區域性部署可能無法符合應用程式延遲需求。 這類情況需要 VM 放置盡可能接近並啟用合理的低網路等待時間，Azure 鄰近放置群組可以針對這類 SAP 系統定義。
避免將數個 SAP 生產或非生產系統組合成單一鄰近放置群組。 避免組合多個 SAP 系統，由於鄰近放置群組中的群組系統越多，便越有可能：
- 您需要在指派鄰近放置群組的網路脊椎下無法使用的 VM 類型。
- 當您需要隨著時間的推移將 VM 數目擴充到鄰近放置群組時，非主流 VM (例如 M 系列 VM) 的資源最終可能無法滿足需求。
根據Microsoft部署至 Azure 區域以降低 Azure 可用性區域內網路等待時間的許多改善，使用鄰近放置群組進行區域部署時的部署指引看起來如下：
這與先前建議的差異在於，兩個區域中的資料庫 VM 不再是鄰近放置群組的一部分。 各區域的鄰近放置群組範圍，現在已設定為執行 SAP ASCS/SCS 執行個體的 VM 部署。 這也表示，針對多個數據中心收集可用性區域的區域，ASCS/SCS 實例和應用層可以在一個網路脊椎下執行，而資料庫 VM 可以在另一個網路微調下執行。 網路雖有所改善，SAP 應用程式層與 DBMS 層之間的網路延遲仍應足以提供一定的效能和輸送量。 這項新組態的優點是，VM 可彈性調整大小，或移至 SAP 系統 DBMS 層或/和應用程式層的新 VM 類型。
針對針對 DBMS 環境使用 Azure NetApp Files 的特殊案例，以及適用於 SAP HANA 的 Azure NetApp Files 應用程式磁碟區群組的 Azure NetApp Files 相關功能，以及鄰近放置群組的必要條件，請檢查 Azure NetApp Files for SAP HANA 上的 NFS v4.1 磁碟區檔。
使用可用性設定組及鄰近放置群組進行部署
在此情況下，目的是透過不同的可用性設定組來部署 VM，並使用鄰近放置群組進行共置。 在此使用案例中，您不會在區域中的不同可用性區域使用受控部署。 您要改用可用性設定組來部署 SAP 系統。 因此，您至少有 DBMS VM、ASCS/SCS VM 和應用程式層 VM 的可用性設定組。 由於您無法在 VM 的部署時間指定可用性設定組和可用性區域，因此您無法控制要設定不同可用性設定組中的 VM 的位置。 這可能會導致某些 Azure 區域不同 VM 間的網路延遲可能仍過高，而使效能體驗差強人意。 產生的架構如下所示：
在此圖中，單一鄰近放置群組會指派給單一 SAP 系統。 此 PPG 會指派給三個可用性設定組。 將第一個資料庫層 VM 部署至 DBMS 可用性設定組，便已設定鄰近放置群組的範圍。 此架構建議會將相同網路脊椎下的所有 VM 共置。 這項做法也帶來了本文前述的限制。 因此，應少量使用鄰近放置群組架構。
結合可用性設定組和可用性區域與鄰近放置群組
針對 SAP 系統部署使用可用性區域的問題之一，就是您無法在特定可用性區域內使用可用性設定組來部署 SAP 應用層。 您希望將 SAP 應用程式層部署於 SAP ASCS/SCS VM 所在的同一區域。 目前還不可能在部署單一 VM 時參考可用性區域和可用性設定組。 但是，只要部署指示可用性區域的 VM，您就失去了確保應用層 VM 分散到不同更新和失敗網域的能力。
使用鄰近放置群組時可略過此限制。 以下為部署順序：
- 建立鄰近放置群組。
- 藉由參考可用性區域來部署錨點 VM，建議使用 ASCS/SCS VM。
- 建立參考 Azure 鄰近放置群組的可用性設定組。 (請參閱後文命令。)
- 藉由參考可用性設定組和鄰近放置群組來部署應用程式層 VM。
重要
請務必瞭解，應用層 VM 的磁碟不保證會配置在與 VM 相同的可用性區域中使用鄰近放置群組。 後續步驟中顯示的部署結果可能是 VM 配置在相同的網路脊椎中，且與錨點 VM 具有相同的可用性區域。 但是，重新配置磁碟（基底 VHD 和掛接的 Azure 區塊記憶體磁碟）可能不會配置在相同的網路脊椎或甚至相同的可用性區域下。 相反地，這些 VM 的磁碟可以配置於特定區域的任何資料中心。 雖然定義區域所部署的錨點 VM 磁碟將會部署在與部署 VM 相同的區域中。
部署 VM 時，您不需要如上一節所示部署第一個 VM，而是參考可用性區域和鄰近放置群組：
New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"
此虛擬機的成功部署會在一個可用性區域中裝載SAP系統的ASCS/SCS實例。 在此情況下，VM 和 VM 的基底 VHD 和可能掛接的 Azure 區塊記憶體磁碟會配置在相同的可用性區域內。 鄰近放置群組的範圍會固定在您定義的可用性區域中的其中一個網路微調。
下一步，您必須建立要用於 SAP 系統應用程式層的可用性設定組。
定義並建立鄰近放置群組。 用於建立可用性設定組的命令，需要額外參考鄰近放置群組識別碼 (不是名稱)。 您可使用此命令取得鄰近放置群組的識別碼：
Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"
建立可用性設定組時，必須考量使用受控磁碟 (預設，除非另指定) 和鄰近放置群組時的額外參數：
New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2
理想情況下應使用三個容錯網域。 但支援的容錯網域數目可能因區域而異。 在此情況下，特定區域的容錯網域數目上限為兩個。 若要部署應用程式層 VM，則須新增可用性設定組名稱和鄰近放置群組名稱的參考，如下所示：
New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"
注意
部署至上述可用性設定組的 VM 磁碟不會強制配置在 VM 所在的相同可用性區域中。 雖然您達成了應用層 VM 會分散到與錨點 VM 相同的網路脊椎下的不同容錯網域，但磁碟也會配置在不同的容錯網域中，但範圍範圍不同的位置可能會配置不同的容錯網域。
此部署結果如下：
- 位於特定可用性區域的 SAP 系統的中央服務。
- SAP 應用程式層，位於與 SAP 中央服務 (ASCS/SCS) VM 同一網路骨幹中的可用性設定組。
注意
由於您將一個 DBMS 和 ASCS/SCS VM 部署至某區域，而第二個 DBMS 和 ASCS/SCS VM 部署至另一個區域，以建立高可用性設定，因此兩個區域將需要不同的鄰近放置群組。 您所使用的任何可用性設定組也不例外。
變更現有系統的鄰近放置群組組態
若您已依目前提供的建議來實作鄰近放置群組，且希望調整為新的組態，則可使用下列文章中所述的方法來進行：
- 使用 Azure CLI 將 VM 部署至鄰近放置群組。
- 使用 PowerShell 將 VM 部署至鄰近放置群組。
若發生配置錯誤，鄰近放置群組中的現有 VM 無法移至新 VM 類型時，您也可使用這些命令。
具有彈性協調流程的虛擬機擴展集
若要避免與鄰近放置群組相關聯的限制，建議您使用具有 FD=1 的彈性擴展集，跨可用性區域部署 SAP 工作負載。 此部署策略可確保部署在每個區域中的 VM 不會限制為單一數據中心或網路脊椎，而且所有 SAP 系統元件，例如資料庫、ASCS/ERS 和應用層的範圍都在區域內。 由於所有 SAP 系統元件都在區域層級範圍內，單一 SAP 系統的不同元件之間的網路等待時間必須足以確保令人滿意的效能和輸送量。 這個具有 FD=1 彈性擴展集的新部署選項的主要優點是，它為調整 VM 大小或切換至 SAP 系統所有層的新 VM 類型提供更大的彈性。 此外，擴展集會在單一區域內跨多個容錯網域配置 VM，非常適合在每個區域中執行應用層的多個 VM。 如需詳細資訊，請參閱 SAP 工作負載 的虛擬機擴展集檔。
在非生產或非HA環境中，您可以使用具有 FD=1 的彈性擴展集，在單一區域內部署所有 SAP 系統元件，包括資料庫、ASCS 和應用層。
先前建議的部署選項
本節包含先前建議部署選項的詳細數據，以優化 SAP 的網路等待時間。 隨著一段時間的新功能和 Azure 成長，本節中的詳細數據只應用於罕見的情況。
具有區域性部署之整個SAP系統的鄰近放置群組
到目前為止建議的鄰近放置群組使用方式，如下圖所示。
您會在部署 SAP 系統的兩個可用性區域中，建立鄰近放置群組 （PPG）。 特定區域的所有 VM 皆屬於該特定區域的個別鄰近放置群組。 您會在每個區域中開始部署 DBMS VM 來設定 PPG 的範圍，然後將 ASCS VM 部署到相同的區域和 PPG。 在第三個步驟中，您會建立 Azure 可用性設定組、將可用性設定組指派給限定範圍的 PPG，並將 SAP 應用層部署到其中。 此組態的優點是，所有元件在相同的網路脊椎下會很好地對齊。 而較大的缺點則是，調整虛擬機器大小的彈性可能有限。
根據Microsoft部署至 Azure 區域以降低 Azure 可用性區域內網路等待時間的許多改善，本文中目前 已提供區域部署的 部署指引。
鄰近放置群組和 HANA 大型執行個體
如果您的某些 SAP 系統依賴資料庫層的 HANA 大型實例，當您使用部署在修訂 4 數據列或戳記中的 HANA 大型實例單位時，可以在 HANA 大型實例單位與 Azure VM 之間的網路等待時間大幅改善。 其中一項改善是：HANA 大型執行個體單位會使用鄰近放置群組進行部署。 您可使用該鄰近放置群組來部署應用程式層 VM。 因此，這些 VM 將會部署於主控 HANA 大型執行個體單位的同一個資料中心。
若要判斷修訂版本 4 的戳記或資料列是否已部署您的 HANA 大型執行個體單位，請參閱透過 Azure 入口網站控制 Azure HANA 大型執行個體一文。 在 HANA 大型執行個體單位的屬性概觀中，您也可判斷鄰近放置群組的名稱，因為其建立時間為 HANA 大型執行個體單位部署時。 屬性概觀所顯示的名稱，即是應部署應用程式層 VM 的鄰近放置群組名稱。
相較於只使用 Azure 虛擬機器的 SAP 系統，當您使用 HANA 大型執行個體，決定 Azure 資源群組使用數目時的彈性較小。 HANA 大型執行個體租用戶的所有 HANA 大型執行個體單位皆會歸為單一資源群組，如本文所述。 例如若您要區別實際執行、非實際執行系統或其他系統，才部署至不同租用戶，否則所有 HANA 大型執行個體單位皆會部署於一個 HANA 大型執行個體租用戶。 此租用戶與資源群組為一對一關係。 但各單位將會定義個別的鄰近放置群組。
因此，單一租用戶 Azure 資源群組及鄰近放置群組的關係如下所示：
下一步
參閱文件：