Azure NetApp Files 應用程式磁碟區群組常見問題

  • 發行項

本文會回答關於 Azure NetApp Files 應用程式磁碟區群組的常見問題集 (FAQ)。

一般常見問題

本節會回答關於 Azure NetApp Files 應用程式磁碟區群組的一般問題。

為什麼我應該針對所有資料庫磁碟區使用手動 QoS 容量集區？

手動 QoS 容量集區提供容量與輸送量之間的最佳平衡，以符合資料庫需求。 手動 QoS 容量集區可避免過度佈建，以達到如記錄磁碟區或資料磁碟區的效能。 此功能也可以為記錄備份保留較大空間，同時將效能保持在符合您需求的值。 整體而言，使用手動 QoS 容量集區會產生成本優勢。

注意

在應用程式磁碟區群組建立期間，只會在清單中顯示要選取的手動 QoS 容量集區。

我可以複製使用應用程式磁碟區群組建立的磁碟區嗎？

是，您可以複製應用程式磁碟區群組所建立的磁碟區。 若要執行此動作，您可選取快照集並將其還原至新磁碟區。 複製為應用程式磁碟區群組工作流程的外部流程。 因此，請考慮下列限制：

  • 當您複製單一磁碟區時，不會檢查任何磁碟區群組專屬的相依性。
  • 複製的磁碟區不是磁碟區群組的一部分。
  • 複製的磁碟區一律會放置在與來源磁碟區相同的儲存體端點上。
  • 若要實現複製磁碟區的最低延遲，您必須使用與來源磁碟區相同的 IP 位址掛接。

建立磁碟區群組需要多久的時間？

建立磁碟區群組牽涉到許多不同步驟，而並非所有步驟都可以同時完成。 特別是當您為指定位置建立第一個磁碟區群組時，完成可能需要 9-12 分鐘的時間。 後續的磁碟區群組應該花較少的時間來建立。

部署失敗，甚至未建立單一磁碟區。 這是為什麼？

這是正常行為。 應用程式磁碟區群組會以不可部分完成的方式布建磁碟區，並在其中一個元件無法部署時回復部署。 部署通常會失敗，因為指定的位置沒有足夠的可用資源來因應您的需求。 請檢查部署記錄檔以取得詳細數據，並視需要更正容量集區組態。

為什麼我無法編輯磁碟區群組描述？

在目前的實作中，應用程式磁碟區群組僅著重於磁碟區群組的初始建立和刪除。

我應該針對資料庫磁碟區使用哪一個快照集原則？

您可以將 AzAcSnap 或 Commvault 等產品用於資料庫環境的應用程式一致備份。 您無法使用 Azure NetApp Files 內建快照集原則所排程的標準快照集，以進行一致的數據保護。

資料庫環境中快照集的一般建議如下：

  • 密切監視資料磁碟區快照集。 長時間保留快照集可能導致容量需求增加。 請務必監視已使用的容量與已配置的容量。
  • 如果您自動建立主要數據保護的快照集，請務必監視其保留期，以避免未預測的磁碟區容量耗用量。

SAP HANA 應用程式磁碟區群組的常見問題

本節會回答 SAP HANA 的 Azure NetApp Files 應用程式磁碟區群組相關問題。

磁碟區的掛接指示包含 IP 位址清單。 我應該使用哪一個 IP 位址？

應用程式磁碟區群組可確保一部主機的數據和記錄磁碟區一律具有不同IP位址的個別記憶體端點，以達到最佳效能。 若要跨 Azure NetApp Files 記憶體資源裝載您的數據、記錄和共用磁碟區，每個使用的 Azure NetApp Files 記憶體資源最多可以建立六個記憶體端點。 基於這個理由，建議您據以調整委派子網的大小。 請參閱 SAP Hana 的應用程式磁碟區群組需求和考量。 儘管所有列出的 IP 位址都可用於掛接，但只有第一個列出的 IP 位址可提供最低延遲。 建議一律使用第一個IP位址。

我可以使用 nconnect 作為掛接選項嗎？

Azure NetApp Files 支援 NFSv4.1 的 nconnect，但需要下列 Linux OS 版本：

  • SLES 15SP2 和更新版本
  • RHEL 8.3 和更新版本

當您使用 nconnect 掛接選項時，讀取限制最高為 4500 MiB/秒 (請參閱 Azure NetApp Files 的 Linux NFS 掛接選項最佳做法)，並且可能須據此調整資料磁碟區的建議輸送量限制。

hostid 為什麼 （例如， 00001） 已新增至我的名稱，即使我移除了{Hostid}佔位元？

應用程式磁碟區群組需要預留位置 {Hostid} 成為名稱的一部分。 如果移除， hostid 會自動將 新增回提供的字串。

選取 [檢閱 + 建立] 之後，您可以看到每個磁碟區的最終名稱。

為什麼 SAP HANA 的應用程式磁碟區群組針對資料量建議的最大輸送量值為 1500 MiB/秒？

NFSv4.1 是 SAP HANA 和 Oracle 支援的通訊協定。 因此，當您掛接單一磁碟區時，則會支援一個 TCP/IP 工作階段。 就針對單一磁碟區執行單一 TCP 工作階段 (即從單一主機) 而言，1500 MiB/s 為已識別的一般 I/O 限制。 所以 SAP HANA 的應用程式磁碟區群組會避免配置超出實際可達到的輸送量。 若您需要更多輸送量，特別是針對較大的 HANA 資料庫 (例如 12 TiB)，您應該使用多個分割區或使用 nconnect 掛接選項。

如何? Azure NetApp Files 磁碟區的大小，以搭配 SAP HANA 使用，以獲得最佳效能和成本效益？

為了獲得最佳大小調整，請務必調整完整環境的大小，包括快照集和備份。 決定生產環境、HA 和數據保護的磁碟區配置，並使用適用於 SAP HANA 部署的 Azure NetApp Files 重設大小計算機來執行重設大小。

我收到警告訊息 "Not enough pool capacity"。 我能做什麼?

應用程式磁碟區群組會根據您的 HANA 記憶體輸入計算所有磁碟區的容量和輸送量需求。 當您選取容量集區時，它會立即檢查容量集區中是否有足夠容量和輸送量。

在初始 SAP HANA 畫面上，您可以按兩下一 步 按鈕來忽略此訊息並繼續工作流程。 您稍後可以個別調整每個磁碟區的建議值，讓所有磁碟區都符合容量集區。 當您變更每個個別磁碟區，直到所有磁碟區都符合容量集區為止，就會重新出現此錯誤訊息。

您可能想要增加集區的大小，以避免此警告訊息。

如何了解調整系統或整體系統環境大小的方式？

請連絡 SAP Azure NetApp Files 調整大小專家，協助您規劃整體 SAP 系統大小調整。

您需要為每個系統提供重要資訊包括下列專案：SID、角色（生產環境、開發、預先支援/QA）、HANA 記憶體、快照集保留百分比、本機快照保留天數、檔案型備份數目、具有主機數目的單一主機/多主機，以及 HSR（主要、次要）。

您可以使用 SAP HANA 重設大小估算器 ，將大小調整程式優化。

如果您知道您的系統（從之前執行 HANA），您可以手動提供您的資料，而不是這些一般假設。

我可以使用多個分割區的 SAP HANA 新功能嗎？

SAP HANA 的應用程式磁碟區群組並未針對多個分割區建立專用焦點，但您可以在調整輸入時，使用 SAP HANA 的應用程式磁碟區群組。

多個分割區的基本概念如下：

  • 多個分割區表示單一 SAP HANA 主機正使用多個磁碟區來儲存持續性。
  • 多個分割區必須掛接在不同的路徑上。 例如，第一個磁碟區位於 /hana/<SID>/data1/mnt00001，第二個磁碟區則需要不同路徑 (/hana/<SID>/data2/mnt00002)。 若要達成此結果，您應該手動調整命名慣例。 也就是說， <SID>-DATA1-MNT00001; <SID>-DATA2-MNT00002, ...。
  • 對於 SAP HANA 的應用程式磁碟區群組而言，記憶體是調整容量和輸送量大小的關鍵所在。 據此，您必須調整大小來因應分割區數目。 針對兩個分割區，您應該使用 50% 的記憶體。 針對三個分割區，您應該使用 33% 的記憶體，依此顯示。

針對您想要建立的每個主機和每個分割區，您必須重新執行SAP HANA 的應用程式磁碟區群組，而且您應該調整命名提案以符合上述建議。

如需本主題的詳細資訊，請參閱 使用 Azure NetApp Files AVG for SAP HANA 部署具有多個分割區的 HANA。

我的 HANA 資料和記錄磁碟區建議輸送量背後的規則為何？

SAP 會將 HANA 磁碟區的主要效能指標 （KPI） 定義為 400 MiB/秒的數據，以及記錄磁碟區的 250 MiB/秒。 此定義與 HANA 資料庫的大小或工作負載無關。 應用程式磁碟區群組會以即使是最小資料庫符合 SAP HANA KPI 的方式調整輸送量值，而且較大的資料庫受益於較高的輸送量層級，並根據輸入的 HANA 資料庫大小調整提案。

下表描述 HANA 資料磁碟區的記憶體範圍和建議輸送量：

記憶體範圍 （TB）建議的輸送量 （MB/秒）
最小值最大值
01400
12600
24800
461000
681200
8101400
10無限制1500

下表描述 HANA 記錄磁碟區的記憶體範圍和建議輸送量：

記憶體範圍 （TB）建議的輸送量 （MB/秒）
最小值最大值
04250
4無限制500

資料庫磁碟區輸送量大多會影響資料庫啟動時將數據讀入記憶體所需的時間。 不過，在運行時間，大部分的 I/O 都是寫入 I/O，甚至 KPI 也會顯示較低的值。 用戶體驗顯示，對於較小的資料庫，HANA KPI 值在大部分時間可能高於需求。

在執行階段，您可以調整每個磁碟區的 Azure NetApp Files 效能。 因此，您可以隨時根據特定需求來調整資料與記錄磁碟區輸送量，藉此調整資料庫效能。 例如，您可以微調效能並降低成本，方法是在啟動時允許較高的輸送量，同時在正常作業期間減少 KPI。

所有磁碟區是否會以接近我的 SAP HANA 伺服器的方式佈建？

使用您為 SAP HANA 伺服器建立的鄰近放置群組 （PPG），可確保數據、記錄和共用磁碟區會建立接近 SAP HANA 伺服器，以達到最佳的延遲和輸送量。 不過，記錄備份和數據備份磁碟區不需要低延遲。 從保護的觀點來看，將這些備份磁碟區儲存在與數據、記錄和共用磁碟區不同的位置很合理。 因此，應用程式磁碟區群組會將備份磁碟區放在區域內具有足夠容量和輸送量的不同儲存位置。

AVset、VM、PPG 和 Azure NetApp Files 磁碟區之間的關聯性為何？

鄰近放置群組 （PPG） 必須至少指派一個 VM，直接或透過 AVset。 PPG 的目的是擷取 VM 的確切位置，並將此資訊傳遞至應用程式磁碟區群組，以搜尋相同數據中心內的 Azure NetApp Files 資源。 此設定僅適用於至少啟動 PPG 中的一個 VM 時。 一般而言，您可以將資料庫伺服器新增至 PPG。

PPG 的副作用是，如果所有 VM 都關機，則下列 VM 重新啟動並不保證它們會在與之前相同的數據中心啟動。 為避免這種情況發生，強烈建議使用 AVset，其中所有 VM 和 PPG 都與 HANA 釘選工作流程相關聯，並使用 HANA 釘選工作流程。 工作流程不僅可確保 VM 在重新啟動時不會移動，也會確保已選取有足夠的計算和 Azure NetApp Files 資源可用的位置。

針對多主機 SAP HANA 系統，當我新增其他 HANA 主機時，共用磁碟區是否會調整大小？

否。 目前僅有少數案例須手動調整大小，而此案例便是其中之一。 SAP 建議您將共用磁碟區的大小調整為每四部 HANA 主機 1 x RAM。 由於您建立的共用磁碟區為第一個 SAP HANA 主機的一部分，因此磁碟區大小已經調整為 1 TB。 有兩個選項可正確調整 SAP HANA 的共用磁碟區大小。

  • 例如，如果您事先知道您需要六部主機，您可以在使用SAP HANA 的應用程式磁碟區群組初始建立期間修改 1 TB 提案。 此時，您也可以增加輸送量 (也就是 QoS) 來容納六部主機。
  • 在建立磁碟區之後，您隨時可以編輯共用磁碟區，並個別變更大小和輸送量。 您可以在磁碟區放置群組內執行此動作，或使用 Azure 資源提供者或 GUI 直接在磁碟區中執行此動作。

我想為多個 SAP HANA 資料庫建立資料備份磁碟區，不僅針對單一執行個體。 如何執行此作業？

記錄備份和數據備份磁碟區是選擇性的，而且不需要鄰近性。 若要達到預期結果，最佳方式是從 SAP HANA 的應用程式磁碟區群組建立第一個磁碟區時，移除資料備份或記錄備份磁碟區。 然後，您可以使用標準磁碟區布建來建立自己的磁碟區作為單一獨立磁碟區，然後選取適當的容量和輸送量，以符合您的需求。 您應該使用指出資料備份磁碟區並用於多個 SID 的命名慣例。

Oracle 應用程式磁碟區群組的常見問題

本節會回答 Oracle 的 Azure NetApp Files 應用程式磁碟區群組相關問題。

所有磁碟區都會布建在與 Oracle 資料庫伺服器相同的可用性區域中嗎？

部署工作流程可確保所有磁碟區都放在您在建立時選取的可用性區域中，這應該符合 Oracle 虛擬機的可用性區域。 對於不支援可用性區域的區域，磁碟區會放在區域範圍中。

如何? Azure NetApp Files 磁碟區的大小，以便與 Oracle 搭配使用，以獲得最佳效能和成本效益？

為了獲得最佳大小調整，請務必針對完整的資料庫環境重設大小，包括HA、快照集和備份。 決定生產環境、HA 和數據保護的磁碟區配置，並根據在 Azure 中執行最苛刻的 Oracle 工作負載來執行重設大小，而不犧牲效能或延展性和估計工具，將 Oracle 工作負載調整為 Azure IaaS VM 的大小。 您也可以使用 [新增單一磁碟區] 輸入選項，在 Azure NetApp Files 大小調整估算器上使用 SAP。

您需要針對每個磁碟區的大小提供重要資訊包括：SID、角色（生產、開發、預先支援/QA）、快照集保留百分比、本機快照保留天數、檔案備份數目、具有主機數目的單一主機/多主機，以及 Data Guard 需求（主要、次要）。 請連絡 Azure NetApp Files 重設大小專家的 Oracle，以協助您規劃整體 Oracle 系統大小調整。

磁碟區的掛接指示包含 IP 位址清單。 我應該針對 Oracle 使用哪個 IP 位址？

應用程式磁碟區群組可確保數據、重做記錄檔、封存記錄和備份磁碟區具有具有不同IP位址的個別記憶體端點，以達到最佳效能。 儘管所有列出的 IP 位址都可用於掛接，但只有第一個列出的 IP 位址可提供最低延遲。 建議一律使用第一個IP位址。

我應該針對 Oracle 磁碟區使用哪個版本的 NFS？

在用戶端使用 Oracle dNFS 掛接磁碟區。 使用 dNFS 掛接時，使用 NFSv3 和 NFSv4.1 所建立的磁碟區搭配運作，建議您使用 NFSv3 部署磁碟區。 如需詳細資訊和發行相依性，請參閱用戶端操作系統和 Oracle 附注。 您也可以在 Azure NetApp Files 上的多個磁碟區上搭配 Oracle 資料庫和 Oracle 資料庫效能使用 Azure NetApp Files 的優點中找到更多詳細數據。

若要達到大型資料庫的最佳效能，建議您在資料庫伺服器上使用 dNFS 掛接磁碟區。 若要簡化 dNFS 設定，建議您使用 NFSv3 建立磁碟區。

我應該針對 Oracle 磁碟區使用哪一個快照集原則？

這個問題與 Oracle 的應用程式磁碟區群組不直接相關。 您可以將 AzAcSnap 或 Commvault 等產品用於 Oracle 資料庫的應用程式一致備份。 您無法使用 Azure NetApp Files 內建快照集原則所排程的標準快照集，以維持 Oracle 資料庫的一致數據保護。

Oracle 環境中快照集的一般建議如下：

  • 使用資料庫感知快照集工具來確保建立資料庫一致快照集。
  • 密切監視資料磁碟區快照集。 長時間保留快照集可能導致容量需求增加。 請務必監視已使用的容量與已配置的容量。
  • 如果您自動為備份磁碟區建立快照集，請務必監視其保留期，以避免未預測的磁碟區成長。

Oracle ASM 可以與 AVG 搭配 Oracle 建立的磁碟區使用嗎？

支援搭配 Oracle 的 Azure NetApp Files 應用程式磁碟區群組使用 Oracle ASM，但不支援在應用程式磁碟區群組中的磁碟區之間取得快照集一致性。 建議客戶在使用 ASM 時使用其他相容的數據保護選項，直到進一步通知為止。

為什麼可以選擇性地使用鄰近放置群組 （PPG） 進行 Oracle 部署？

在資源可用性有限的區域中部署時，可能無法在最理想的位置部署磁碟區。 在這種情況下，您可以選擇使用鄰近放置群組函式來部署磁碟區，以在給定條件下以最佳的可能磁碟區放置來達成部署。 默認設定會停用 PPG 的使用。 您必須要求允許透過支援通道使用鄰近放置群組。

下一步