Azure NetApp Files 的資源限制
了解 Azure NetApp Files 的資源限制有助於管理磁碟區。
資源限制
下表說明 Azure NetApp Files 的資源限制:
資源 | 預設限制 | 可透過支援要求調整 |
---|---|---|
每個訂用帳戶的區域容量配額 | 25 TiB | Yes |
每個訂用帳戶在每個 Azure 區域的 NetApp 帳戶數目 | 10 | Yes |
每個 NetApp 帳戶的容量集區數目 | 25 | Yes |
每個訂用帳戶的磁碟區數目 | 500 | Yes |
每個容量集區的磁碟區數目 | 500 | Yes |
每個磁碟區的快照集數目 | 255 | No |
對裝載 VNet 的 Azure NetApp Files 中的磁碟區進行存取的虛擬網路 (包括直接對等互連的 VNet) 中的 IP 數目 |
|
No |
單一容量集區的大小下限 | 1 TiB* | No |
單一容量集區的大小上限 | 2,048 TiB | No |
單一一般磁碟區的大小下限 | 100 GiB | No |
單一一般磁碟區的大小上限 | 100 TiB | No |
單一大型磁碟區的大小下限 | 50 TiB | No |
大型磁碟區大小增加 | 30% 的最低佈建大小 | Yes |
單一大型磁碟區的大小上限 | 1,024 TiB | No |
專用容量上單一大型磁碟區的大小上限 (預覽) | 2,048 TiB | No |
單一檔案的大小上限 | 16 TiB | No |
單一目錄中的目錄中繼資料大小上限 | 320 MB | No |
單一目錄中的檔案數目上限 | 大約 400 萬個。 請參閱確認目錄是否接近限制大小。 |
No |
每個磁碟區的檔案數目上限 maxfiles |
請參閱maxfiles |
Yes |
每個磁碟區的匯出原則規則數目上限 | 5 | No |
每個磁碟區的配額規則數目上限 | 100 | No |
指派給手動 QoS 磁碟區的輸送量下限 | 1 MiB/秒 | No |
指派給手動 QoS 磁碟區的輸送量上限 | 4,500 MiB/秒 | No |
跨區域複寫資料保護磁碟區 (目的地磁碟區) 的數目 | 50 | Yes |
跨可用性區域複寫資料保護磁碟區 (目的地磁碟區) 的數目 | 50 | Yes |
每個磁碟區的原則式 (排程) 備份數目上限 |
「合併的」每小時、每日、每週和每月備份保留計數上限為 1019。 |
No |
受保護的磁碟區大小上限 | 100 TiB | No |
每個訂用帳戶可備份的磁碟區數目上限 | 20 | Yes |
每天每個磁碟區的手動備份數上限 | 5 | Yes |
每個區域每個訂用帳戶支援非經常性存取的磁碟區數目上限 | 10 | Yes |
* 如果容量集區中的所有磁碟區都使用標準網路功能,則您最低只能利用 1 TiB。 1 TiB 容量集區已正式推出。 您必須先註冊才能使用此功能。 如果有任何使用基本網路功能的磁碟區,則最小大小為 4 TiB。
如需詳細資訊,請參閱容量管理常見問題。
如需與 Azure NetApp Files 網路功能相關的限制和條件約束,請參閱 Azure NetApp Files 網路規劃指導方針。
確認目錄是否接近限制大小
您可以從用戶端使用 stat
命令,查看目錄是否接近目錄中繼資料的大小上限 (320 MB)。 若達到 Azure NetApp Files 單一目錄的大小上限,則會發生錯誤 No space left on device
。
320 MB 目錄的區塊數目為 655,360,每個區塊的大小為 512 個位元組。 (即 320x1024x1024/512。)此數字大約可將 320 MB 的目錄轉換為最多 400 萬個檔案。 不過,實際的檔案上限數目可能會較低,視目錄中含有非 ASCII 字元的檔案數目等因素而定。 因此,您應依照下列方式使用 stat
命令,確認您的目錄是否接近其限制。
範例:
[makam@cycrh6rtp07 ~]$ stat bin
File: 'bin'
Size: 4096 Blocks: 8 IO Block: 65536 directory
[makam@cycrh6rtp07 ~]$ stat tmp
File: 'tmp'
Size: 12288 Blocks: 24 IO Block: 65536 directory
[makam@cycrh6rtp07 ~]$ stat tmp1
File: 'tmp1'
Size: 4096 Blocks: 8 IO Block: 65536 directory
Maxfiles
限制
Azure NetApp Files 磁碟區具有稱為 maxfiles
的值,代表一個磁碟區可以包含的檔案和資料夾數目上限 (也稱為 Inode)。 若達到 maxfiles
限制,客戶端在嘗試建立新的檔案或資料夾時,會收到「空間不足」的訊息。 如果您遇到此問題,請聯繫 Microsoft 技術支援部門。
Azure NetApp Files 磁碟區的 maxfiles
限制是以磁碟區的大小 (配額) 為基礎,其中服務會根據磁碟區的佈建大小動態調整其 maxfiles
限制,並使用下列指導方針。
- 若是小於或等於 683 GiB 的一般磁碟區,預設的
maxfiles
限制為 21,251,126 個。 - 若是大於 683 GiB 的一般磁碟區,預設的
maxfiles
限制大約是配置磁碟區容量中每 32 KiB 一個檔案 (或 Inode),上限可達 2,147,483,632 個。 - 若是大型磁碟區,預設的
maxfiles
限制大約是配置磁碟區容量中每 32 KiB 一個檔案 (或 Inode),預設上限可達 15,938,355,048 個。 - 每個 Inode 在磁碟區中使用大約 288 個位元組的容量。 在磁碟區中有大量 Inode,可能會在實際資料容量之外,佔用相當多的額外實體空間。
- 如果檔案的大小小於 64 個位元組,則會儲存在 Inode 本身,而且不會使用額外的容量。 只有當檔案實際配置給磁碟區時,才會使用此容量。
- 大於 64 個位元組的檔案會耗用磁碟區上的額外容量。 例如,如果 Azure NetApp Files 磁碟區中有一百萬個大於 64 個位元組的檔案,則大約 274 MiB 的容量會用於 Inode。
下表以一般磁碟區的磁碟區大小為基礎,顯示 maxfiles
的關聯值範例。
Volume size | 估計的 maxfiles 限制 |
---|---|
0 – 683 GiB | 21,251,126 |
1 TiB (1,073,741,824 KiB) | 31,876,709 |
10 TiB (10,737,418,240 KiB) | 318,767,099 |
50 TiB (53,687,091,200 KiB) | 1,593,835,519 |
100 TiB (107,374,182,400 KiB) | 2,147,483,632 |
下表以大型磁碟區的磁碟區大小為基礎,顯示 maxfiles
的關聯值範例。
Volume size | 估計的 maxfiles 限制 |
---|---|
50 TiB (53,687,091,200 KiB) | 1,593,835,512 |
100 TiB (107,374,182,400 KiB) | 3,187,671,024 |
200 TiB (214,748,364,800 KiB) | 6,375,342,024 |
500 TiB (536,870,912,000 KiB) | 15,938,355,048 |
若要查看特定磁碟區大小的 maxfiles
配置,請檢查磁碟區概觀窗格中的 [檔案數目上限] 欄位。
您無法透過配額要求設定資料保護磁碟區的 maxfiles
限制。 Azure NetApp Files 會自動增加資料保護磁碟區的 maxfiles
限制,以容納複寫至磁碟區的檔案數目。 當資料保護磁碟區發生容錯移轉時,maxfiles
限制會保持為容錯移轉前的最後一個值不變。 在此情況下,您可以提交該磁碟區的 maxfiles
配額要求。
要求限制增加
您可以建立 Azure 支援要求,以增加 [資源限制] 資料表中的可調整限制。
注意
根據區域中可用的資源和所要求的限制增加,Azure 支援可能需要額外的資訊,才能判斷要求的可行性。
移至 [支援 + 疑難排解] 下方的 [新增支援要求]。
在 [問題描述] 索引標籤底下,提供必要的資訊:
- 針對 [問題類型],選取 [服務與訂用帳戶限制 (配額)]。
- 在 [訂閱] 的部分,選取您的訂閱。
- 針對 [配額類型],選取 [儲存體:Azure NetApp Files 限制]。
在 [其他詳細資料] 索引標籤底下,選取 [要求詳細資料] 欄位中的 [輸入詳細資料]。
若要要求增加限制,請在出現的 [配額詳細資料] 視窗中提供下列資訊:
在 [配額類型] 中,選取您要增加的資源類型。
例如:- 每個訂用帳戶的區域容量配額 (TiB)
- 每個訂用帳戶在每個 Azure 區域的 NetApp 帳戶數目
- 每個訂用帳戶的磁碟區數目
在 [要求的區域] 中,選取您的區域。
目前和預設的大小會顯示在 [配額狀態] 底下。輸入一個值,以要求增加您所指定的配額類型。
選取 [儲存並繼續] 。 選取 [檢閱 + 建立] 以建立要求。
下一步
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應