SAP HANA Azure 虛擬機器儲存體設定

Azure 提供不同類型的儲存體，適合執行 SAP Hana 的 Azure VM。 SAP Hana 認證的 Azure 儲存體類型，可考慮用於 SAP Hana 部署清單，例如：

• Azure 進階 SSD 或進階記憶體 v1/v2
• Ultra 磁碟
• Azure NetApp Files

若要了解這些磁碟類型，請參閱適用於 SAP 工作負載的 Azure 儲存體類型和選取磁碟類型文章

針對 Azure 標準和進階儲存體 v1/v2 上的 VHD，Azure 提供兩個部署方法。 我們預期您會利用 Azure 受控磁碟進行 Azure 區塊儲存體部署。

若要了解磁碟類型的列表，以及其在 IOPS 的 SLA 和儲存體輸送量，請檢閱管理磁碟的 Azure 文件。

重要

無論所選擇的 Azure 儲存體類型為何，適用於特定作業系統和 DBMS 的 SAP 必須可支援該存放裝置所使用的檔案系統。 SAP 支援附註 #2972496 會列出不同作業系統和資料庫 (包括 SAP Hana) 支援的檔案系統。 這適用於所有 SAP Hana 可能會存取以進行任何工作讀取和寫入的磁碟區。 特別是在適用於 SAP Hana 的 Azure 上使用 NFS，這將會套用其他 NFS 版本限制，如本文稍後所述

針對不同儲存體類型的 SAP Hana 認證最低情況為：

• Azure 進階儲存體 v1 - /hana/log 必須由 Azure 寫入加速器支援。 /hana/data 磁碟區可以放置於進階儲存體 v1 中，而不用 Azure 寫入加速器或放置在 Ultra 磁碟上。 Azure 進階儲存體 v2 或 Azure 進階 SSD v2 不支援使用 Azure 寫入加速器
• Azure Ultra 磁碟，/hana/log 磁碟區的最低需求。 /hana/data 磁碟區可以不用寫入加速器就放置於進階儲存體 v1/v2，或在 Ultra 磁碟上達成更快的重新開機時間
• Azure NetApp Files 上方的 NFS v4.1 磁碟區，適用於 /hana/log 和 /hana/data。 /hana/shared 的磁碟區可以使用 NFS v3 或 NFS 4.1 通訊協定

根據客戶獲得的經驗，我們變更了在 /hana/data 與 /hana/log 之間結合不同記憶體類型的支援。 支持結合以 Azure NetApp Files 為基礎的 HANA AND NFS 共用認證之不同 Azure 區塊記憶體的使用方式。 例如，可以將 /hana/data 放入進階儲存體 v1 或 v2 中，而 /hana/log 可以放在 Ultra 磁碟儲存體中以達成需要減少的延遲。 如果您根據 ANF 使用 /hana/data 磁碟區，則 /hana/log 磁碟區也可能會置於其中一個 HANA 認證的 Azure 區塊儲存體。 支援針對其中一個磁碟區 (例如 /hana/data) 在 ANF 上方使用 NFS 和針對其他磁碟區 (例如 /hana/log) 使用 Azure 進階磁碟區 v1/v2 或 Ultra 磁碟。

在內部部署環境中，您很少需要在意 I/O 子系統及其功能。 原因是設備廠商必須確認最低儲存體需求符合 SAP HANA。 當您自行建置 Azure 基礎結構時，您應該對這些 SAP 發出的需求有些了解。 SAP 建議的一些最小輸送量特性如下：

• 在 /hana/log 上的 250MB/秒及 1 MB I/O 大小讀取/寫入
• 針對 /hana/data 至少 400MB/秒、16MB 和 64MB I/O 大小的讀取活動
• 針對 /hana/data 至少 250MB/秒、16MB 和 64MB I/O 大小的寫入活動

因為 DBMS 系統的關鍵要素是低儲存體延遲，就算作為 SAP Hana 之類的 DBMS，也請將資料存在記憶體中。 儲存體中的關鍵路徑通常在 DBMS 系統的交易紀錄寫入附近。 但像是寫入儲存點或是在損毀修復之後載入記憶體內部資料之類的作業也很重要。 因此，針對 /hana/data 和 /hana/log 磁碟區，必須使用 Azure 進階記憶體 v1/v2、Ultra 磁碟或 ANF。

選取 HANA 儲存體組態的一些指導準則，如下所示：

• 根據適用於 SAP 工作負載的 Azure 儲存體類型和選取磁碟類型決定儲存體類型
• 當調整 VM 大小或決定 VM 時，請注意整體 VM I/O 輸送量和 IOPS 限制。 整體 VM 記憶體輸送量記載於記憶體優化虛擬機大小一文 中
• 在決定儲存體設定時，請嘗試使用 /hana/data 磁碟區設定，維持在 VM 的整體輸送量之下。 SAP Hana 寫入儲存點時，Hana 可能會積極發出 I/O。 寫入儲存點時，可以輕鬆地推送至 /hana/data 磁碟區的輸送量限制。 如果您的磁碟建置輸送量高於 VM 允許輸送量的 /hana/data 磁碟區，您可能會遇到儲存點寫入所使用的輸送量干擾重做記錄寫入的輸送量需求的情況。 可能會影響應用程式輸送量的情況
• 如果您考慮使用 HANA 系統復寫，每個複本上用於 /hana/data 的儲存體必須相同，且每個復本上用於 /hana/log 的儲存體類型必須相同。 例如，針對 /hana/data 使用 Azure 進階記憶體 v1 搭配一部 VM，而另一個執行相同 HANA 系統復寫組態複本之另一部 VM 中的 /hana/data 的 Azure Ultra 磁碟則不受支援。

重要

本文件或後續文件中儲存體組態的建議是作為開始的指示。 執行工作負載並分析儲存體使用率模式，您可能會發現您並未使用所提供的所有儲存體頻寬或 IOPS。 您接著可能會考慮在儲存體上縮減大小。 或者相反地，您的工作負載可能需要比這些組態建議更多的儲存體輸送量。 因此，您可能需要部署更多容量、IOPS 或輸送量。 在所需的儲存體容量、所需的儲存體延遲、所需的儲存體輸送量和 IOPS 以及最低成本組態的張力之間，Azure 提供足夠的不同儲存體類型，且具有不同功能和不同價格點，可為您和 HANA 工作負載尋找並調整正確的折衷。

等量集與 SAP Hana 資料磁碟區分割

當您將 /hana/data 和/或 /hana/log 磁碟區等量分割在多個 Azure 磁碟上時，您可以使用 Azure 進階記憶體 v1 達到最佳價格/效能比率。 而不是部署較大的磁碟區，提供更多所需的 IOPS 或輸送量。 使用屬於 Linux 的 LVM 和 MDADM 磁碟區管理員，即可跨多個 Azure 磁碟建立單一磁碟區。 等量分割磁碟的方法相當老舊且眾所周知。 由於這些等量磁碟區的優點是取得您可能需要的 IOPS 或輸送量功能，因此會增加管理這些等量磁碟區的複雜性。 特別是在需要擴充容量的磁碟區時。 至少針對 /hana/data，SAP 引進了一個替代方法，以達到與跨多個 Azure 磁碟等量分割相同的目標。 從 SAP Hana 2.0 SPS03 開始，HANA 索引伺服器能夠在位於不同 Azure 磁碟上的多個 HANA 資料檔案之間等量分割其 I/O 活動。 優點是您不需要負責在不同 Azure 磁碟上建立和管理等量磁碟區。 資料磁碟區分割的 SAP Hana 功能詳述如下：

• HANA 管理員指南
• 關於 SAP Hana 的部落格 - 分割資料磁碟區
• SAP 附註編號 2400005
• SAP 附註 #2700123

閱讀詳細資料，套用這項功能很明顯地可以擺脫磁碟區管理員型等量集合的複雜性。 您也意識到 HANA 數據磁碟區分割不僅適用於 Azure 區塊記憶體，例如 Azure 進階記憶體 v1/v2。 如果這些共用有 IOPS 或輸送量限制，您也可以使用這項功能來跨 NFS 共用等量分割。

Linux I/O 排程器模式

Linux 具有數種不同的 I/O 排程模式。 Linux 廠商和 SAP 的一般建議是重新設定磁碟區的 I/O 排程器模式，從 mq-deadline 或 kyber 模式設定為 noop (非 multiqueue) 或 none (multiqueue) 模式 (如果尚未由 SLES saptune 設定檔完成)。 詳細資料記載於：

• SAP 附註編號 1984787
• SAP 附註 #2578899
• SLES 12 SP4 中 noop 設定的問題

在 Red Hat 上，保留由特定調整設定檔針對不同 SAP 應用程式所建立的設定。

使用邏輯磁碟區管理員時的等量大小

如果您使用 LVM 或 mdadm 在數個 Azure 進階磁碟上建置等量集，則需要定義等量大小。 /hana/data 與 /hana/log 之間的這些大小不同。 建議：對於等量磁碟大小，建議使用：

• 針對 /hana/data 使用 256 KB
• 針對 /hana/log 使用 64 KB

注意

/hana/data 的等量大小已在先前的建議中變更，根據最近 Linux 版本的客戶經驗，將 64 KB 或 128 KB 變更為 256 KB。 256 KB 的大小會提供稍微較好的效能。 我們也會將 /hana/log 等量大小的建議從 32 KB 變更為 64 KB，以取得具有較大 I/O 大小的足夠輸送量。

注意

您不需要使用 RAID 磁碟區設定任何備援層級，因為 Azure 區塊儲存體會保存三個 VHD 的映像。 使用 Azure 進階磁碟的等量集，只是為了設定磁碟區，以提供足夠的 IOPS 和/或 I/O 輸送量。

等量集下的多個 Azure 磁碟累計，是從 IOPS 和儲存體輸送量端累計。 因此，如果您將等量分割設定在超過 3 個 P30 Azure 進階記憶體 v1 磁碟上，它應該提供 IOPS 的三倍，以及單一 Azure 進階記憶體 v1 P30 磁碟的記憶體輸送量三倍。

重要

如果您使用 LVM 或 mdadm 作為磁碟區管理員，跨多個 Azure 進階磁碟建立等量集，則三個 SAP Hana FileSystems /data、/log 和 /shared 不得放在預設或根磁碟區群組中。 強烈建議您遵循 Linux 廠商的指導方針，這通常會引導您針對 /data、/log 和/shared 建立個別的磁碟區群組。

HANA 共用檔系統的考慮

調整 HANA 檔系統大小時，會最注意數據和記錄檔 HANA 系統。 不過， /hana/shared 也會在操作穩定的 HANA 系統中扮演重要角色，因為它裝載了 HANA 二進位檔等基本元件。
如果大小過低， /hana/shared 可能會因為讀取/寫入作業過多而變成 I/O 飽和 -例如，在寫入大型傾印時，或在密集追蹤期間，或備份寫入 /hana/shared 文件系統時。 延遲也可能增加。

如果 HANA 系統處於 HA 組態中，共用檔系統的回應速度緩慢，例如 /hana/shared 可能會導致叢集資源逾時。 這些逾時可能會導致不必要的故障轉移，因為 HANA 資源代理程式可能會錯誤地假設資料庫無法使用。

/hana/shared 建議大小的 SAP 指導方針看起來會像這樣：

體積	建議的大小
/hana/shared 向上延展	Min(1 TB, 1 x RAM)
/hana/shared 向外延展	背景工作節點的 1 x RAM 每四個背景工作節點

如需詳細資訊，請參閱下列 SAP 附注：
3288971 - 常見問題：SAP HANA 系統復寫環境中的 SUSE HAE/RedHat HAA Pacemaker 叢集資源管理員
1999930 - 常見問題：SAP HANA I/O 分析

最佳做法是大小 /hana/shared 以避免效能瓶頸。 請記住，大小 良好的 /hana/shared 文件系統有助於 SAP HANA 系統的穩定性和可靠性，特別是在 HA 案例中。

適用於 HANA 的 Azure 進階儲存體 v1 組態

如需使用 Azure 進階記憶體 v1 的詳細 HANA 記憶體設定建議，請閱讀 SAP HANA Azure 虛擬機進階 SSD 記憶體設定檔。

適用於 HANA 的 Azure 進階 SSD v2 設定

如需使用 Azure 進階 ssd v2 記憶體的詳細 HANA 記憶體設定建議，請閱讀 SAP HANA Azure 虛擬機進階 SSD v2 記憶體設定檔。

適用於 SAP Hana 的 Azure Ultra 磁碟儲存體設定

如需使用 Azure Ultra 磁碟的詳細 HANA 記憶體設定建議，請閱讀 SAP HANA Azure 虛擬機 Ultra 磁碟記憶體設定檔。

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

如需適用於 HANA 的 Azure NetApp Files 的詳細數據，請閱讀適用於 SAP HANA 的 Azure NetApp Files 上的 NFS v4.1 磁碟區檔。

下一步

如需詳細資訊，請參閱

• SAP Hana Azure 虛擬機器進階 SSD 儲存體組態。
• SAP Hana Azure 虛擬機器 Ultra 磁碟儲存體組態。
• 適用於 SAP Hana 的 Azure NetApp Files 上的 NFS v4.1 磁碟區。
• Azure 虛擬機器的 SAP Hana 高可用性指南。