分享方式：

Azure NetApp Files for SAP HANA 上的 NFS v4.1 磁碟區

  • 文章

Azure NetApp Files 提供可用於 /hana/shared、/hana/data 和 /hana/log 磁碟區的原生 NFS 共用。 針對 /hana/data 和 /hana/log 磁碟區使用以 ANF 為基礎的 NFS 共用時，需要使用 4.1 NFS 通訊協定。 以 ANF 為共用的基礎時，不支援 /hana/data 和 /hana/log 磁碟區使用 NFS 通訊協定 v3。

重要

在 Azure NetApp Files 上實作的 NFS v3 通訊協定不支援用於 /hana/data 和 /hana/log。 從功能的觀點來看，/hana/data 和 /hana/log 磁碟區必須使用 NFS 4.1。 但從功能的觀點來看，//hana/shared 磁碟區則可以使用 NFS v3 或 NFS 4.1 通訊協定。

重要考量

考慮將 Azure NetApp Files 用於 SAP Netweaver 和 SAP HANA 時，請注意下列重要考量：

  • 如需磁碟區和容量集區限制，請參閱 Azure NetApp Files 資源限制。

  • Azure NetApp Files 型 NFS 共用和掛接這些共用的虛擬機必須位於相同 Azure 虛擬網絡 或相同區域中的對等互連虛擬網路中。

  • 選取的虛擬網路必須具有已委派給 Azure NetApp Files 的子網路。 針對 SAP 工作負載，強烈建議針對委派給 Azure NetApp Files 的子網設定 /25 範圍。

  • 請務必讓虛擬機器部署足夠的鄰近 Azure NetApp 儲存體，以降低延遲，例如 SAP HANA 針對重做記錄寫入的需求。

    • Azure NetApp Files 同時具有將 NFS 磁碟區部署到特定 Azure 可用性區域的功能。 在大部分情況下，這種區域性鄰近性就足以達到 1 毫秒內延遲。 此功能處於公開預覽狀態，如管理 Azure NetApp Files 的可用性區域磁碟區放置所述。 這項功能不需要 Microsoft 的任何互動式流程，即可達到 VM 與您配置的 NFS 磁碟區之間的鄰近性。
    • 為了達到最佳的鄰近性，提供應用程式磁碟區群組的功能。 這項功能不僅能夠找到最理想的鄰近性，而且可以獲得最佳的 NFS 磁碟區位置，因此 HANA 資料和重做記錄磁碟區會由不同的控制器處理。 缺點是此方法需要 Microsoft 的一些互動式流程來釘選您的 VM。

  • 請確定從資料庫伺服器到 Azure NetApp Files 磁碟區的延遲已測量，且低於 1 毫秒

  • Azure NetApp 磁碟區的輸送量是磁碟區配額和服務層級的函式，如 Azure NetApp Files 的服務層級中所記錄。 調整 HANA Azure NetApp 磁碟區大小時，請確定產生的輸送量符合 HANA 系統需求。 或者，考慮使用手動 QoS 容量集區，其中磁碟區容量和輸送量可以獨立設定和調整 (本文件提供 SAP Hana 具體範例)

  • 嘗試「合併」磁碟區，以形成更大磁碟區來提高效能，例如，使用一個磁碟區來容納 /sapmnt、/usr/sap/trans... (可能的話)

  • Azure NetApp Files 提供匯出原則：您可控制允許的用戶端、存取類型 (讀取及寫入、唯讀等)。

  • sidadm 的使用者識別碼，以及虛擬機器上 sapsys 的群組識別碼，都必須符合 Azure NetApp Files 中的設定。

  • 實作 SAP 附註 3024346 中所述的 Linux OS 參數

重要

對於 SAP HANA 工作負載，低延遲非常重要。 與您的 Microsoft 代表合作，以確保虛擬機器和 Azure NetApp Files 磁碟區部署在鄰近位置。

重要

在虛擬機器和 Azure NetApp 設定之間，如果使用者識別碼 sidadm 和群組識別碼 sapsys 不符，則 Azure NetApp 磁碟區 (裝載於虛擬機器) 上的檔案權限會顯示為 nobody。 將新系統上線至 Azure NetApp Files 時，請務必為 sidadm 指定正確的使用者識別碼，以及為 sapsys 指定群組識別碼。

NCONNECT 掛接選項

Nconnect 是 Azure NetApp Files 上裝載的 NFS 磁碟區的掛接選項，可讓 NFS 用戶端針對單一 NFS 磁碟區開啟多個會話。 使用大於 1 的 nconnect 值也會觸發 NFS 用戶端在用戶端使用多個 RPC 工作階段 (在客體 OS 中)，以處理客體 OS 與掛接的 NFS 磁碟區之間的流量。 處理一個 NFS 磁碟區流量的多個工作階段的使用方式，但也可使用多個 RPC 工作階段來解決效能和輸送量案例，例如：

  • 掛接多個 Azure NetApp Files 裝載的 NFS 磁碟區，並在一個 VM 中具有不同服務等級
  • 磁碟區和單一 Linux 工作階段的最大寫入輸送量介於 1.2 到 1.4 GB/秒之間。 針對一個 Azure NetApp Files 裝載的 NFS 磁碟區有多個會話可能會增加輸送量

針對支援 nconnect 做為掛接選項的 Linux OS 版本，以及 nconnect 的一些重要設定考量，特別是使用不同的 NFS 伺服器端點，請參閱適用於 Azure NetApp Files 的 Linux NFS 掛接選項最佳做法文件。

針對 Azure NetApp Files 上的 HANA 資料庫進行大小調整

Azure NetApp 磁碟區的輸送量取決於磁碟區大小和服務等級，如 Azure NetApp Files 的服務等級所述。

請務必了解效能與大小的關聯性，而且服務的儲存體端點有實體限制。 在磁碟區建立並接收IP位址時，每個記憶體端點都會動態插入 Azure NetApp Files 委派的子網 。 視可用的容量和部署邏輯而定，Azure NetApp Files 磁碟區可以共用儲存體端點

下表示範應該建立大型「標準」磁碟區來儲存備份，並不應該建立大於 12 TB 的 “Ultra” 磁碟區，因為會超過單一磁碟區的最大實體頻寬容量。

如果您的 /hana/data 磁碟區所需的寫入輸送量超過單一 Linux 工作階段所能達到的寫入輸送量上限，您也可以使用 SAP HANA 資料磁碟區分割作為替代方式。 SAP Hana 資料磁碟區分割可以在資料重新載入期間等量分割 I/O 活動，也可以在多個 NFS 共用上的多個 HANA 資料檔案之間使用 HANA 儲存點。 如需 HANA 資料磁碟區等量分割的詳細資訊，請參閱下列文章：

大小 標準輸送量 進階版輸送量 Ultra 輸送量
1 TB 16 MB/秒 64 MB/秒 128 MB/秒
2 TB 32 MB/秒 128 MB/秒 256 MB/秒
4 TB 64 MB/秒 256 MB/秒 512 MB/秒
10 TB 160 MB/秒 640 MB/秒 1,280 MB/秒
15 TB 240 MB/秒 960 MB/秒 1,400 MB/秒1
20 TB 320 MB/秒 1,280 MB/秒 1,400 MB/秒1
40 TB 640 MB/秒 1,400 MB/秒1 1,400 MB/秒1

1：寫入或單一工作階段讀取輸送量限制 (如果未使用 NFS 掛接選項 nconnect)

請務必了解資料會寫入儲存體後端的相同 SSD。 容量集區建立的效能配額能夠管理環境。 儲存體 KPI 等於所有 HANA 資料庫大小。 幾乎在所有情況下，此假設未能反映實際情況和客戶的期望。 HANA 系統的大小不一定表示小型系統需要低儲存體輸送量，而大型系統需要高儲存體輸送量。 但通常可預期較大的 HANA 資料庫執行個體有較高的輸送量需求。 由於 SAP 對大型 HANA 執行個體等基礎硬體的大小規則也提供更多 CPU 資源，並為執行個體重新啟動後載入資料等工作提供更大平行處理原則。 因此，採用的磁碟區大小應該符合客戶期望和需求。 而非只單純受容量需求影響。

在 Azure 中設計 SAP 的基礎結構時，應該注意 SAP 的一些最低儲存體輸送量需求 (針對生產系統)。 這些需求轉化為下表中的最低輸送量特性：

磁碟區類型和 I/O 類型 SAP 要求的最小 KPI 進階服務層級 Ultra 服務層級
記錄磁碟區寫入 250 MB/秒 4 TB 2 TB
資料磁碟區寫入 250 MB/秒 4 TB 2 TB
資料磁碟區讀取 400 MB/秒 6.3 TB 3.2 TB

由於需要三種 KPI，/hana/data 磁碟區必須調整為較大容量，以滿足最低讀取需求。 如果您使用手動 QoS 容量集區，則可以獨立定義磁碟區的大小和輸送量。 由於容量和輸送量都取自相同的容量集區，集區的服務等級和大小必須足夠達成整體績效 (請參閱此處的範例)

對於不需要高頻寬的 HANA 系統，Azure NetApp Files 磁碟區輸送量可以透過較小的磁碟區大小或直接調整輸送量來使用手動 QoS 來降低。 在任何情況下，HANA 系統需要更多輸送量，以便磁碟區配合線上調整容量大小。 備份磁碟區未定義 KPI。 但若要讓環境表現良好，備份磁碟區輸送量不可或缺。 記錄 – 和資料磁碟區效能必須依照客戶體驗進行設計。

重要

與您在單一 NFS 磁碟區上部署的容量無關，輸送量預期會在單一會話中取用者使用的 1.2-1.4 GB/秒带寬範圍內穩定。 這與 Azure NetApp Files 供應專案的基礎架構和相關 Linux 作業階段限制有關 NFS 有關。 適用於Azure NetApp Files 的效能基準測試一文所述的效能和輸送量數目是針對一個具有多個用戶端 VM 的共用 NFS 磁碟區進行，因此有多個工作階段。 該案例與我們在 SAP 中測量的案例不同，我們會針對 Azure NetApp Files 上裝載的 NFS 磁碟區測量來自單一 VM 的輸送量。

為了符合資料和記錄的 SAP 最低輸送量需求，以及遵循 /hana/shared 的指導方針，建議的大小如下：

體積 大小
進階儲存層		 大小
Ultra 儲存層		 支援的 NFS 通訊協定
/hana/log/ 4 TiB 2 TiB v4.1
/hana/data 6.3 TiB 3.2 TiB v4.1
/hana/shared 向上延展 Min(1 TB, 1 x RAM) Min(1 TB, 1 x RAM) v3 或 v4.1
/hana/shared 向外延展 背景工作節點的 1 x RAM
每四個背景工作節點		 背景工作節點的 1 x RAM
每四個背景工作節點		 v3 或 v4.1
/hana/logbackup 3 x RAM 3 x RAM v3 或 v4.1
/hana/backup 2 x RAM 2 x RAM v3 或 v4.1

我們高度建議在所有磁碟區使用 NFS v4.1。
請仔細檢閱重設大小 /hana/shared 的考慮，因為適當大小的 /hana/shared 磁碟區有助於系統的穩定性。

備份磁碟區的大小為估計值。 必須根據工作負載和作業流程定義實際需求。 針對備份，您可以將不同 SAP HANA 實例的許多磁碟區合併到一個（或兩個）較大的磁碟區，其中可能會有較低的 Azure NetApp Files 服務等級。

注意

本文件所述的 Azure NetApp Files 大小建議是為了符合 SAP 向其基礎結構提供者表示的最低需求。 在真實的客戶部署和工作負載案例中，這可能不夠。 根據您特定工作負載的需求，使用這些建議做為起點並調整。

因此，您可以考慮為 Azure NetApp Files 磁碟區部署類似的輸送量，如已針對 Ultra 磁碟記憶體所列。 另請考慮針對不同 VM SKU 的磁碟區所列大小的大小 (如 Ultra 磁碟資料表中已完成的)。

提示

您可以動態重新調整 Azure NetApp Files 磁碟區的大小，而無須 unmount 磁碟區、停止虛擬機器或停止 SAP HANA。 這可讓您彈性地滿足應用程式上預期和未預期的輸送量需求。

有關如何使用 Azure NetApp Files 型 NFS v4.1 磁碟區部署 SAP HANA 向外延展設定與待命節點的檔，會透過 SUSE Linux Enterprise Server 上的 Azure NetApp Files 搭配 Azure VM 上的待命節點發佈在 SAP HANA 向外延展。

Linux Kernel Settings

若要在 Azure NetApp Files 上成功部署 SAP HANA，您必須根據 SAP 附注 3024346實作 Linux 核心設定。

若是使用 Pacemaker 和 Azure Load Balancer 的高可用性 (HA) 系統，您需要在 /etc/sysctl.d/91-NetApp-HANA.conf 檔案中實作下列設定

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1

不使用 Pacemaker 和 Azure Load Balancer 執行的系統，應該實作 /etc/sysctl.d/91-NetApp-HANA.conf 中的這些設定

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

具有區域鄰近性的部署

若要取得 NFS 磁碟區和 VM 的區域鄰近性，您可以依照管理 Azure NetApp Files 的可用性區域磁碟區放置中所述的指示操作。 使用此方法，VM 和 NFS 磁碟區將會位於相同的 Azure 可用性區域中。 在大部分的 Azure 區域中，這種類型的鄰近性應該足以達到 SAP HANA 較小重做記錄寫入的 1 毫秒內延遲。 此方法不需要與 Microsoft 進行任何互動式工作，即可將 VM 放置並釘選到特定資料中心。 因此，您可以彈性地變更部署的可用性區域中全部 VM 類型和系列內的 VM 大小和系列。 因此，您可以按照變動的條件做出彈性反應，也可以更快速地移至更有成本效益的 VM 大小或系列。 針對非生產系統和生產系統，建議使用較接近 1 毫秒的重做記錄延遲。 此功能目前為公開預覽版。

透過 SAP Hana 的 Azure NetApp Files 應用程式磁碟區群組 (AVG) 進行部署

若要部署靠近您 VM 的 Azure NetApp Files 磁碟區，已開發稱為適用於 SAP HANA （AVG） 的 Azure NetApp Files 應用程式磁碟區群組新功能。 有一系列文章討論此功能。 最好從了解 SAP Hana 的 Azure NetApp Files 應用程式磁碟區群組一文開始。 隨著您閱讀這些文章時，就會明白使用 AVG 也會用到 Azure 鄰近放置群組。 新功能使用鄰近放置群組來繫結至要建立的磁碟區。 為了確保在 HANA 系統的存留期內，VM 不會從 Azure NetApp Files 磁碟區移開，建議您針對您部署的每個區域使用 Avset/ PPG 的組合。 部署順序如下所示：

  • 使用您需要的表單，要求將空白 AvSet 固定在計算 HW，以確保 VM 不會移動
  • 將 PPG 指派給可用性設定組，並啟動指派給此可用性設定組的 VM
  • 使用 SAP Hana 的 Azure NetApp Files 應用程式磁碟區群組功能來部署 HANA 磁碟區

以最佳方式使用 AVG 的鄰近放置群組設定如下所示：

Azure NetApp Files 應用程式磁碟區群組和鄰近放置群組架構的圖表。

此圖顯示您準備對 DBMS 層使用 Azure 鄰近放置群組。 以便與 AVG 一起使用。 最好只將執行 HANA 執行個體的 VM 放入鄰近放置群組中。 即使只使用一個具有單一 HANA 實例的 VM，平均仍需要鄰近放置群組，以識別 Azure NetApp Files 硬體最接近的距離。 並盡可能接近使用 NFS 磁碟區的 VM，在 Azure NetApp Files 上配置 NFS 磁碟區。

此方法會產生最理想的結果，因為它與低延遲有關。 不僅讓 NFS 磁碟區和 VM 盡可能接近。 但是，考慮將資料和重做記錄磁碟區放在 NetApp 後端的不同控制器上。 不過，缺點是您的 VM 部署僅釘選到一個資料中心。 如此一來，您就會失去變更 VM 類型和系列的彈性。 因此，您應該將此方法限制在絕對需要如此低儲存體延遲的系統。 針對所有其他系統，您應該嘗試使用 VM 和 Azure NetApp Files 的傳統區域性部署進行部署。 在大部分情況下，這在低延遲方面就已足夠。 這也可確保 VM 和 Azure NetApp Files 的維護與管理變得簡單。

可用性

套用 ANF 系統更新和升級不影響客戶環境。 定義的 SLA 為 99.99%。

磁碟區、IP 位址和容量集區

使用 ANF 時，請務必了解基礎結構的建立方式。 容量集區只是一種建構，根據容量集區服務等級提供容量和效能預算及計費單位。 容量集區與基礎結構沒有實體關聯性。 在服務上建立磁碟區時會建立儲存體端點。 單一 IP 位址會指派給此儲存體端點，以支援存取磁碟區的資料。 如果建立多個磁碟區，則所有磁碟區會分散至整個基礎裸機機群隊，並繫結至此儲存體端點。 一旦所設定儲存體的磁碟區或/和容量達到內部預先定義的層級，ANF 的邏輯會自動分散客戶工作負載。 例如，此情況可能是因為自動建立新的儲存體端點 (具有新的 IP 位址) 來存取磁碟區。 ANF 服務不允許客戶控制此散發邏輯。

記錄磁碟區和記錄備份磁碟區

「記錄磁碟區」(/hana/log) 用來寫入線上重做記錄。 亦即，此磁碟區中有開啟的檔案，建立此磁碟區的快照集毫無意義。 一旦線上重做記錄檔已滿或執行重做記錄備份，線上重做記錄檔就會封存或備份至記錄備份磁碟區。 為了達到合理的備份效能，記錄備份磁碟區需要足夠的輸送量。 為了將儲存體成本最佳化，應該合併多個 HANA 執行個體的記錄備份磁碟區。 因此，多個 HANA 執行個體使用相同的磁碟區，並將其備份寫入不同的目錄中。 由於您需要稍微擴大磁碟區，這樣使用合併可以取得更多輸送量。

您用來寫入完整 HANA 資料庫備份的磁碟區也是如此。
 

Backup

如 Azure 虛擬機器上的 SAP Hana 備份指南一文所述，除了串流備份和備份 SAP Hana 資料庫的 Azure 備份服務，Azure NetApp Files 有可能讓您執行以儲存體為基礎的快照集備份。

SAP Hana 支援：

  • 針對具有 SAP Hana 1.0 SPS7 和更新版本的單一容器系統，支援以儲存體為基礎的快照集備份
  • 針對具有單一租用戶及 SAP Hana 2.0 SPS1 和更新版本的多重資料庫容器 (MDC) HANA 環境，支援以儲存體為基礎的快照集備份
  • 針對具有多重租用戶及 SAP Hana 2.0 SPS4 和更新版本的多重資料庫容器 (MDC) HANA 環境，支援以儲存體為基礎的快照集備份

建立以儲存體為基礎的快照集備份是簡單的四步驟流程，

  1. 建立 HANA (內部) 資料庫快照集 - 您或工具需要執行的活動
  2. SAP Hana 將資料寫入資料檔案，在儲存體上建立一致狀態 - HANA 在建立 HANA 快照集後執行此步驟
  3. 在儲存體的 /hana/data 磁碟區上建立快照集 - 您或工具需要執行的步驟。 不需要在 /hana/log 磁碟區上執行快照集
  4. 刪除 HANA (內部) 資料庫快照集並繼續正常作業 - 您或工具需要執行的步驟

警告

遺漏最後一個步驟或無法執行最後一個步驟會嚴重影響 SAP Hana 的記憶體需求，還可能導致 SAP Hana 停止

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

SAP HANA 的 ANF 快照集備份

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname

SAP HANA part2 的 ANF 快照集備份

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

可利用各種工具以各種方式來管理此快照集備份流程。 例如，GitHub https://github.com/netapp/ntaphana 上提供的 Python 指令碼 “ntaphana_azure.py”。這是「依現狀」提供的範例程式碼，不需要任何維護或支援。

警告

快照集與您剛建立快照集的磁碟區位於相同的實體儲存體上，本身就不是受保護的備份。 每天必須將至少一個快照集放到不同位置來「保護」。 可放在相同的環境、遠端 Azure 區域或 Azure Blob 儲存體。

以儲存體快照集為基礎的應用程式一致備份可用的解決方案：

  • Microsoft 什麼是 Azure 應用程式一致快照集工具 是命令行工具，可針對第三方資料庫啟用資料保護。 它會處理在擷取儲存體快照集之前，將這些資料庫置於應用程式一致狀態所需的所有協調流程。 擷取儲存體快照集之後，此工具會將資料庫恢復為作業狀態。 AzAcSnap 支援對 HANA 大型執行個體和 Azure NetApp Files 建立以快照集為基礎的備份。 如需詳細資訊，請參閱文章什麼是 Azure 應用程式一致快照集工具
  • 對於 Commvault 備份產品的使用者，另一個選項是 Commvault IntelliSnap V.11.21 和更新版本。 此版本或更新版本的 Commvault 提供 Azure NetApp Files快照集支援。 Commvault IntelliSnap 11.21 一文提供詳細資訊。

使用 Azure Blob 儲存體來備份快照集

若要儲存以 ANF 為基礎的 HANA 資料庫儲存體快照集備份，備份至 Azure Blob 儲存體是符合成本效益又快速的方法。 若要將快照集儲存至 Azure Blob 儲存體，建議使用 AzCopy 工具。 下載並安裝此工具的最新版本，例如在 bin 目錄中，其中安裝 GitHub 的 Python 指令碼。 下載最新的 AzCopy 工具：

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

最進階的功能是 SYNC 選項。 如果您使用 SYNC 選項，azcopy 會將來源和目的地目錄保持同步。 使用參數 --delete-destination 很重要。 如果沒有此參數，azcopy 不會刪除目的地網站上的檔案，目的地那端的空間使用率會上升。 在 Azure 儲存體帳戶中建立區塊 Blob 容器。 然後建立 Blob 容器的 SAS 金鑰，並將快照集資料夾同步至 Azure Blob 容器。

例如，如果每日快照集應該同步至 Azure Blob 容器，以保護資料。 而且只需要保留一個快照集，則可以使用下列命令。

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

下一步

閱讀文章：