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} 預留位置，為什麼 hostid (例如 00001) 仍新增至我的名稱中？
應用程式磁碟區群組需要預留位置 {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 掛接選項。
如何針對 SAP HANA 的使用調整 Azure NetApp Files 磁碟區大小，以獲得最佳效能和成本效益？
針對最佳調整大小，請務必針對完整環境大小進行調整，包括快照集和備份。 決定生產環境、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 的應用程式磁碟區群組，而且您應該調整命名提案以符合上述建議。
如需此主題的詳細資訊，請參閱使用 SAP HANA 適用的 Azure NetApp Files AVG 部署具有多個分割區的 HANA。
我的 HANA 資料和記錄磁碟區建議輸送量背後的規則為何？
SAP 針對 HANA 磁碟區定義關鍵效能指標 (KPI)，資料為 400 MiB/秒，記錄磁碟區則為 250 MiB/秒。 此定義與 HANA 資料庫的大小或工作負載無關。 應用程式磁碟區群組調整輸送量值的方式，可讓即便最小的資料庫也能符合 SAP HANA KPI，較大的資料庫則能受益於更高的輸送量層級，並根據輸入的 HANA 資料庫大小調整提案。
下表描述 HANA 資料磁碟區的記憶體範圍和建議輸送量：
| 記憶體範圍 (TB) | 建議輸送量 (MB/s) | |
|---|---|---|
| 最小值 | 最大值 | |
| 0 | 1 | 400 |
| 1 | 2 | 600 |
| 2 | 4 | 800 |
| 4 | 6 | 1000 |
| 6 | 8 | 1200 |
| 8 | 10 | 1400 |
| 10 | 無限制 | 1500 |
下表描述 HANA 記錄磁碟區的記憶體範圍和建議輸送量：
| 記憶體範圍 (TB) | 建議輸送量 (MB/s) | |
|---|---|---|
| 最小值 | 最大值 | |
| 0 | 4 | 250 |
| 4 | 無限制 | 500 |
資料庫磁碟區輸送量大多會影響資料庫啟動時將資料讀取至記憶體所需的時間。 然而，在執行階段，大部分的 I/O 都是寫入 I/O，即便是 KPI 也顯示較低的值。 使用者體驗顯示，對於較小的資料庫而言，HANA KPI 值大部分時間可能會高於需求。
在執行階段，您可以調整每個磁碟區的 Azure NetApp Files 效能。 因此，您可以隨時根據特定需求來調整資料與記錄磁碟區輸送量，藉此調整資料庫效能。 例如，您可以在啟動時允許較高的輸送量，同時降低一般作業期間的 KPI，進而微調效能並降低成本。
所有磁碟區是否都會在我的 SAP HANA 伺服器鄰近位置佈建？
使用應用程式磁碟區群組時，您可以選擇使用可用性區域或鄰近放置群組磁碟區放置來部署磁碟區。 這兩種方法都可確保資料磁碟區與 HANA VM 皆放置於鄰近區域，但使用不同原則。
使用可用性區域磁碟區放置 (可搭配延伸模組 1 使用) 會將磁碟區放置在與應用程式 VM 相同的可用性區域中。 使用可用性區域也支援標準網路功能，其支援透過網路安全性群組支援增強的安全性。 此方法不需要手動釘選。 因此，使用起來更簡單快速。
使用鄰近放置群組需要為您的 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 並不保證這些 VM 會在與之前相同的資料中心啟動。 為了避免發生這種情況，強烈建議您使用與所有 VMs 和 PPG 相關的 AVset，並使用 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 虛擬機器的可用性區域。 針對不支援可用性區域的區域，磁碟區會放置在區域範圍內。
如何針對 Oracle 的使用調整 Azure NetApp Files 磁碟區大小，以獲得最佳效能和成本效益？
針對最佳調整大小，請務必針對完整資料庫環境大小進行調整，包括 HA、快照集和備份。 決定生產環境、HA 和資料保護的磁碟區配置，並根據在不犧牲效能或可擴縮性的情況下，於 Azure 中執行最嚴苛的 Oracle 工作負載，和調整 Oracle 工作負載為 Azure IaaS VM 的預估工具。 您也可以使用 [新增單一磁碟區] 輸入選項，以使用在 Azure NetApp Files 調整大小估算器上的 SAP。
在為每個磁碟區調整大小時，您必須提供的重要資訊包括：SID、角色 (生產、開發、生產階段前/QA)、快照集保留百分比、本機快照集保留天數、檔案備份數目、具有主機數目的單一主機/多主機，以及資料成立條件需求 (主要、次要)。 請連絡 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 Database 的優勢和在 Azure NetApp Files 多磁碟區上的 Oracle Database 效能，以取得詳細資料。
若要達到大型資料庫的最佳效能，建議您在資料庫伺服器上使用 dNFS 以裝載磁碟區。 若要簡化 dNFS 設定，建議您使用 NFSv3 建立磁碟區。
我應該為 Oracle 磁碟區使用哪項快照集原則？
此問題與 Oracle 的應用程式磁碟區群組並無直接關聯。 您可以使用 AzAcSnap 或 Commvault 等產品，為 Oracle Database 進行應用程式一致備份。 您無法使用 Azure NetApp Files 內建快照集原則所排程的標準快照集，來進行一致的 Oracle Database 資料保護。
Oracle 環境中快照集的一般建議如下：
- 使用資料庫感知快照集工具來確保建立資料庫一致的快照集。
- 密切監視資料磁碟區快照集。 長時間保留快照集可能導致容量需求增加。 請務必監視已使用的容量與已配置的容量。
- 如果您為備份磁碟區自動建立快照集，請務必監視其保留期，以避免未預期的磁碟區成長。
Oracle ASM 是否可以與適用於 Oracle 建立磁碟區的 AVG 搭配使用？
支援與適用於 Oracle 的 Azure NetApp Files 應用程式磁碟區群組搭配使用 Oracle ASM，但不支援在應用程式磁碟區群組中磁碟區間保持快照集一致性。 建議客戶在使用 ASM 時使用其他相容的資料保護選項，直至另行通知。
為何可以選擇使用鄰近放置群組 (PPG) 進行 Oracle 部署？
在資源可用性有限的區域中部署時，可能無法在最佳位置部署磁碟區。 在這種情況下，您可以選擇使用鄰近放置群組函式來部署磁碟區，以在提供的條件下使用盡可能最佳的磁碟區放置來達成部署。 在預設設定下已停用 PPG 的使用。 您必須要求可透過支援管道使用鄰近放置群組。
下一步
- 關於 SAP Hana 的應用程式磁碟區群組：
- 關於 Oracle 的應用程式磁碟區群組：
- 刪除應用程式磁碟區群組
- 針對應用程式磁碟區群組錯誤進行疑難排解