Azure 檔案服務延展性和效能目標

  • 發行項

Azure 檔案服務可提供在雲端中完全受控、並且可透過 SMB 和 NFS 檔案系統通訊協定來存取的檔案共用。 本文討論 Azure 檔案服務和 Azure 檔案同步的延展性和效能目標。

此處所列目標可能會受到您部署中的其他變數影響。 例如，檔案 I/O 效能可能會受到 SMB 用戶端行為和可用網路頻寬的影響。 您應該測試您的使用模式，以判斷 Azure 檔案服務的延展性和效能是否符合需求。

適用於

檔案共用類型 SMB NFS
標準檔案共用 (GPv2)、LRS/ZRS 是 否
標準檔案共用 (GPv2)、GRS/GZRS 是 否
進階檔案共用 (FileStorage)、LRS/ZRS Yes Yes

Azure 檔案擴展目標

Azure 檔案共用已部署到儲存體帳戶，這是代表共用儲存體集區的最上層物件。 此儲存體集區可以用來部署多個檔案共用。 因此，有三個要考慮的類別：儲存體帳戶、Azure 檔案共用和個別檔案。

儲存體帳戶擴展目標

儲存體帳戶調整目標適用於儲存體帳戶層級。 Azure 檔案儲存體的儲存體帳戶有兩種主要類型：

  • 一般用途第 2 版 (GPv2) 儲存體帳戶：GPv2 儲存體帳戶可讓您在標準/硬碟型 (HDD 型) 硬體上部署 Azure 檔案共用。 除了儲存 Azure 檔案共用之外，GPv2 儲存體帳戶還可以儲存其他儲存體資源，例如 Blob 容器、佇列或資料表。 檔案共用可部署至交易最佳化 (預設)、經常性或非經常性存取層。

  • FileStorage 儲存體帳戶：FileStorage 儲存體帳戶可讓您在進階/固態磁碟型 (SSD 型) 硬體上部署 Azure 檔案共用。 FileStorage 帳戶只能用來儲存 Azure 檔案共用；無法將其他儲存體資源 (Blob 容器、佇列、資料表等) 部署在 FileStorage 帳戶中。

屬性 GPv2 儲存體帳戶 (標準) FileStorage 儲存體帳戶 (高階)
每個區域中每個訂用帳戶的儲存體帳戶數目 2501 2501
儲存體帳戶容量上限 5 PiB2 100 TiB (已佈建)
檔案共用的數目上限 不限定 無限制，所有共用的佈建大小總計必須小於最大儲存體帳戶容量
並行要求速率上限 20,000 IOPS2 102,400 IOPS
LRS/GRS 的輸送量 (輸入 + 輸出)
  • 澳大利亞東部
  • 美國中部
  • 東亞
  • 美國東部 2
  • 日本東部
  • 南韓中部
  • 北歐
  • 美國中南部
  • 東南亞
  • 英國南部
  • 西歐
  • 美國西部
  • 輸入：7,152 MiB/秒
  • 輸出：14,305 MiB/秒
 10,340 MiB/秒
ZRS 的輸送量 (輸入 + 輸出)
  • 澳大利亞東部
  • 美國中部
  • 美國東部
  • 美國東部 2
  • 日本東部
  • 北歐
  • 美國中南部
  • 東南亞
  • 英國南部
  • 西歐
  • 美國西部 2
  • 輸入：7,152 MiB/秒
  • 輸出：14,305 MiB/秒
 10,340 MiB/秒
未列於上一個資料列中的備援/區域組合輸送量 (輸入 + 輸出)
  • 輸入：2,980 MiB/秒
  • 輸出：5,960 MiB/秒
 10,340 MiB/秒
虛擬網路規則的最大數目 200 200
IP 位址規則的最大數目 200 200
管理讀取作業 每 5 分鐘 800 每 5 分鐘 800
管理寫入作業 每秒 10 次/每小時 1200 次 每秒 10 次/每小時 1200 次
管理清單作業 每 5 分鐘 100 每 5 分鐘 100

1 隨著配額的增加，您可以為每個區域建立最多 500 個具有標準端點的儲存體帳戶。 如需詳細資訊，請參閱增加 Azure 儲存體帳戶配額。 2 一般用途版本 2 儲存體帳戶支援較高的容量限制，以及依要求的輸入更高限制。 若要要求提高帳戶限制，請連絡 Azure 支援。

Azure 檔案共用調整目標

Azure 檔案共用調整目標適用於檔案共用層級。

屬性 標準檔案共用1 進階檔案共用
檔案共用大小上限 沒有下限 100 GiB (已佈建)
佈建大小增加/減少單位 N/A 1 GiB
檔案共用大小上限
  • 100 TiB，已啟用大型檔案共用功能2
  • 5 TiB，預設值
 100 TiB
檔案共用中的檔案數目上限 無限制 無限制
最大要求速率 (最大 IOPS)
  • 20,000，啟用大型檔案共用功能2
  • 每 100 ms 1,000 或 100 個要求 (預設值)
  • 基準 IOPS：每個 GiB 3000 + 1 IOPS，最多 102,400
  • IOPS 高載：每個 GiB 最多 10,000,3x IOPS，最高 102,400
單一檔案共用的輸送量 (輸入 + 輸出) (MiB/秒)
  • 最多啟用儲存體帳戶限制，且已啟用大型檔案共用功能2
  • 最高 60 MiB/秒，預設值
 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)
共用快照集的數目上限 200 快照集 200 快照集
物件名稱長度上限3 (完整路徑名稱，包括所有目錄、檔案名稱和反斜線字元) 2,048 個字元 2,048 個字元
個別路徑名稱元件長度上限3 (在路徑 \A\B\C\D 中，每個字母都代表個別元件的目錄或檔案) 255 個字元 255 個字元
固定連結限制 (僅限 NFS) N/A 178
SMB 多重通道的通道數目上限 N/A 4
每個檔案共用的預存存取原則的最大數目 5 5

1標準檔案共用的限制適用於標準檔案共用可用的三個層級：交易最佳化、經常性存取和非經常性存取。

2 標準檔案共用的預設值為 5 TiB，請參閱建立 Azure 檔案共用以深入瞭解如何以 100 TiB 大小建立檔案共用，以及將現有的標準檔案共用增加至 100 TiB。 若要利用較大的規模目標，您必須變更配額，使其大於 5 TiB。

3 Azure 檔案儲存體會針對目錄和檔案名稱強制執行特定命名規則。

檔案規模目標

檔案調整目標適用於 Azure 檔案共用中所儲存的個別檔案。

屬性 標準檔案共用中的檔案 進階檔案共用中的檔案
檔案大小上限 4 TiB 4 TiB
並行要求速率上限 1,000 IOPS 最高 8,0001
檔案的輸入上限 60 MiB/秒 200 MiB/秒 (SMB 多重通道最高可達 1 GiB/秒)2
檔案的輸出上限 60 MiB/秒 300 MiB/秒 (SMB 多重通道最高可達 1 GiB/秒)2
根目錄的最大並行控制代碼3 10,000 控制代碼 10,000 控制代碼
每個檔案和目錄的並行控制代碼上限3 2,000 處理 2,000 處理

1 適用於讀取和寫入 I/O (較小的 I/O 通常小於或等於 64 KiB)。 讀取和寫入以外的中繼資料作業可能較低。 這些是軟性限制，而且節流可能會超出這些限制。

2 受限於電腦網路限制、可用的頻寬、I/O 大小、佇列深度和其他因素。 如需詳細資訊，請參閱 SMB 多重通道效能。

3 Azure 檔案儲存體支援根目錄上的 10,000 個開啟控制代碼，以及共用內每個檔案和目錄 2,000 個開啟控制代碼。 每個共用支援的作用中使用者數目取決於存取共用的應用程式。 如果您的應用程式未在根目錄上開啟控制代碼，Azure 檔案儲存體可支援每個共享超過 10,000 個作用中使用者。 不過，如果您使用 Azure 檔案儲存體來儲存大型虛擬桌面工作負載的磁碟映像，您可能會用盡根目錄或每個檔案/目錄的控制代碼。 在此情況下，您可能需要使用多個 Azure 檔案共用。 如需詳細資訊，請參閱 Azure 虛擬桌面的 Azure 檔案儲存體大小調整指引。

Azure 虛擬桌面的 Azure 檔案儲存體大小調整指引

Azure 檔案儲存體的熱門使用案例是使用 FSLogix 或應用程式連結來儲存 Azure 虛擬桌面的使用者設定檔容器和磁碟映像。 在大規模的 Azure 虛擬桌面部署中，如果您使用單一 Azure 檔案共用，您可能會用盡根目錄或每個檔案/目錄的控制代碼。 本節說明各種磁碟映射如何使用控制代碼，並根據您使用的技術提供重設大小調整指引。

FSLogix

如果您使用 FSLogix 搭配 Azure 虛擬桌面，您的使用者設定檔容器會是虛擬硬碟 (VHD) 或 Hyper-V 虛擬硬碟 (VHDX) 檔案，而且它們會掛接在用戶內容中，而不是系統內容。 每個用戶都會開啟單一根目錄控制代碼，該控制代碼應為檔案共用。 Azure 檔案儲存體最多可以支援 10,000 位使用者，假設您有檔案共用 (\\storageaccount.file.core.windows.net\sharename) + 設定檔案目錄 (%sid%_%username%) + 設定檔容器 (profile_%username.vhd(x))。

如果您達到根目錄的 10,000 個並行控制代碼限制，或使用者看到效能不佳，請嘗試使用額外的 Azure 檔案共用，並在共用之間散發容器。

警告

雖然 Azure 檔案儲存體最多可支援來自單一檔案共用的 10,000 位並行使用者，但請務必根據您所建立的檔案共用大小和類型來正確測試工作負載。 您的需求可能會因使用者、設定檔大小和工作負載而有所不同。

例如，如果您有 2,400 個並行使用者，則根目錄上需要 2,400 個控制代碼 (每個使用者一個)，低於 10,000 個開啟控制代碼的限制。 對於 FSLogix 使用者，幾乎不可能達到 2,000 個開啟的檔案和目錄控制代碼的限制。 如果您為每個使用者配備了單一 FSLogix 設定檔容器，則只會取用兩個檔案/目錄控制代碼：一個用於設定檔目錄，另一個用於設定檔容器檔案。 如果使用者各有兩個容器 (設定檔和 ODFC)，則需要另外一個控制代碼以用于 ODFC 檔案。

使用 CimFS 附加應用程式

如果您使用 MSIX 應用程式連結或應用程式連結動態連結應用程式，則可以對磁碟映像使用複合映像檔案系統 (CimFS) 或 VHD/VHDX 檔案。 無論哪種方式，調整限制都是每個 VM 掛接映像，而不是每個使用者。 計算調整限制時，用戶數目無關緊要。 VM 開機時，它會掛接磁碟映像，即使沒有任何使用者。

如果您使用應用程式連結搭配 CimFS，磁碟映像只會取用磁碟映像檔上的控制代碼。 它們不會在根目錄或包含磁碟映像的目錄上取用控制代碼。 不過，由於 CimFS 映像是 .cim 檔案和至少另外兩個檔案的組合，因此對於掛接磁碟映射的每個 VM，您需要為目錄中的三個檔案都各分配一個控制代碼。 因此，如果您有 100 部 VM，則需要 300 個檔案控制代碼。

如果每個應用程式的 VM 數目超過 2,000，您可能會用盡檔案控制代碼。 在此情況下，請使用額外的 Azure 檔案共用。

使用 VHD/VHDX 附加應用程式

如果您將應用程式配合 VHD/VHDX 檔案使用，檔案會掛接在系統內容中，而不是掛接在用戶內容中，而且檔案是共用和唯獨的。 連線系統可以使用 VHDX 檔案上的多個控制代碼。 若要保持在 Azure 檔案儲存體調整限制內，乘以應用程式數目的 VM 數目必須小於 10,000，且每個應用程式的 VM 數目不能超過 2,000。 因此，限制式是您第一次達到的限制式。

在此案例中，如果單一 VHD/VHDX 有 2,000 次掛接，便會達到每個檔案/目錄限制。 或者，如果共用包含多個 VHD/VHDX 檔案，您可能會先達到根目錄限制。 例如，如果 100 部 VM 掛接 100 個共用 VHDX 檔案，則將會達到 10,000 個處理根目錄限制。

在另一個範例中，100 部存取 20 個應用程式的 VM 需要 2,000 個根目錄控制代碼 (100 x 20 = 2,000)，這完全沒有超過根目錄控制代碼的上限 10,000。 掛接 VHD(X) 映像的每個 VM 也需要一個檔案控制代碼和一個目錄/資料夾控制代碼，因此在此案例中為 200 個控制代碼 (100 個檔控制代碼 + 100 個目錄控制代碼)，這遠低於每個檔案/目錄的 2,000 個控制代碼上限。

如果您達到根目錄或每個檔案/目錄的最大並行控制代碼限制，請使用額外的 Azure 檔案共用。

Azure 檔案同步擴展目標

下表指出哪一個目標為軟性 (代表 Microsoft 測試的界限) 以及硬性 (代表強制執行的最大值)：

資源 目標 固定限制
每個區域的儲存體同步服務數目 100 個儲存體同步服務 Yes
每個訂用帳戶 儲存體 Sync Services 15 儲存體 同步服務 Yes
每個儲存體同步服務的同步群組 200 個同步群組 是
每個儲存體同步服務的已註冊伺服器 99 部伺服器 Yes
每個 儲存體 同步服務的私人端點 100 個私人端點 Yes
每個同步群組的雲端端點 1 個雲端端點 是
每個同步群組的伺服器端點 100 個伺服器端點 是
每部伺服器的伺服器端點 30 個伺服器端點 是
每個同步群組的檔案系統物件 (目錄和檔案) 1 億個物件 否
目錄中的檔案系統物件 (目錄和檔案) 數目上限 (非遞迴) 500 萬個物件 是
物件 (目錄和檔案) 安全性描述元大小上限 64 KiB 是
檔案大小 100 GiB 否
要分層之檔案的檔案大小下限 根據檔案系統叢集大小 (雙重檔案系統叢集大小)。 例如，如果檔案系統叢集大小為 4 KiB，則檔案大小下限將為 8 KiB。 Yes

注意

Azure 檔案同步端點可以擴大至 Azure 檔案共用的大小。 如果達到 Azure 檔案共用大小限制，同步處理將無法運作。

Azure 檔案同步效能計量

由於 Azure 檔案同步 代理程式會在連線到 Azure 檔案共用的 Windows Server 電腦上執行，因此有效的同步效能取決於您基礎結構中的一些因素：Windows Server 和基礎磁碟組態、伺服器與 Azure 記憶體之間的網路頻寬、檔案大小、數據集大小總計，以及數據集上的活動。 由於 Azure 檔案同步會在檔案層級上運作，因此 Azure 檔案同步解決方案的效能特性應以每秒處理的物件 (檔案和目錄) 數來測量，以獲得較精準的結果。

在下列兩個階段中，Azure 檔案同步必須達到高效能：

  1. 初始一次性佈建： 若要讓初始佈建達到最佳效能，請參閱透過 Azure 檔案同步上線以取得最佳部署的詳細資料。
  2. 持續同步：在 Azure 檔案共用中初次植入資料之後，Azure 檔案同步會將多個端點保持在同步狀態。

注意

當相同同步群組中的許多伺服器端點同時同步處理時，它們會爭用雲端服務資源。 因此，上傳效能會受到影響。 在極端情況下，部分同步工作階段將無法存取資源，進而失敗。 不過，上述同步工作階段會很快恢復，只要壅塞減少後就會成功執行。

內部測試結果

為了協助您規劃每個階段的部署（初始一次性布建和進行同步處理），以下是我們在系統內部測試期間觀察到的結果，其中包含下列設定：

系統設定 詳細資料
CPU 具有 64 MiB L3 快取的 64 個虛擬核心
記憶體 128 GiB
磁碟 具有電池供電式快取記憶體 RAID 10 的 SAS 磁碟
網路 1 Gbps 的網路
工作負載 一般用途檔案伺服器

初始一次性佈建

初始一次性佈建 詳細資料
物件數目 2500 萬個物件
資料集大小 ~4.7 TiB
平均檔案大小 ~200 KiB (最大檔案：100 GiB)
起始雲端變更列舉 每秒 80 個物件
上傳輸送量 每個同步處理群組每秒 20 個物件
命名空間下載輸送量 每秒 400 個物件

初始雲端變更列舉：建立新的同步群組時，初始雲端變更列舉是執行的第一個步驟。 在此程式中，系統會列舉 Azure 檔案共用中的所有專案。 在此程式中，將不會有同步活動。 不會將任何專案從雲端端點下載到伺服器端點，也不會將任何專案從伺服器端點上傳至雲端端點。 完成初次雲端變更列舉之後，將會繼續同步活動。

效能的速率是每秒 80 個物件。 您可以藉由判斷雲端共用中的項目數目，以及使用下列公式取得天數，來預估完成初始雲端變更列舉所需的時間。

初始雲端列舉的時間 (天) = (雲端端點中的物件數目) /(80 * 60 * 60 * 24)

將資料從 Windows 伺服器初始同步至 Azure 檔案共用： 許多 Azure 檔案同步部署都是從空的 Azure 檔案共用開始，因為所有資料都在 Windows 伺服器上。 在這些情況下，初始雲端變更列舉速度很快，而且大部分時間都是將 Windows Server 的變更同步至 Azure 檔案共用。

同步上傳數據至 Azure 檔案共享時，本機檔伺服器不會停機，而系統管理員可以 設定網路限制 來限制用於背景數據上傳的頻寬量。

初始同步通常會受限於每個同步群組每秒 20 個檔案的初始上傳速率。 客戶可以使用下列 homebrew 公式來預估將所有資料上傳至 Azure 的時間，以取得時間 (以天為單位)：

將檔案上傳至同步處理群組的時間 (天) = (伺服器端點中的物件數目) / (20 * 60 * 60 * 24)

將您的資料分割成多個伺服器端點和同步群組可以加速此初始資料上傳，因為多個同步處理群組的上傳可以平行進行，每秒 20 個專案。 因此，兩個同步群組會以每秒 40 個專案的結合速率來執行。 完成的總時間是同步處理群組中，具有最多要同步處理檔案的預估時間。

命名空間下載輸送量：將新的伺服器端點新增至現有的同步群組時，Azure 檔案同步 代理程式不會從雲端端點下載任何檔案內容。 它會先同步完整命名空間，然後再觸發背景回復以下載檔案；有可能是下載完整檔案，或者，如果已啟用雲端分層處理，則會根據伺服器端點上設定的雲端分層處理原則進行下載。

持續同步

持續同步 詳細資料
已同步的物件數目 125,000 個物件 (~1% 變換)
資料集大小 50 GiB
平均檔案大小 ~500 KiB
上傳輸送量 每個同步處理群組每秒 20 個物件
完整下載輸送量* 每秒 60 個物件

*如果已啟用雲端階層處理，您可能會發現效能較佳，因為只會下載部分檔案數據。 Azure 檔案同步 只會在任何端點上變更快取檔案時下載快取檔案的數據。 對於任何分層或新建立的檔案，代理程式不會下載檔案數據，而只會將命名空間同步至所有伺服器端點。 代理程式也支援使用者存取階層式檔案的部分下載。

注意

這些數位不表示您將經歷的效能。 實際效能取決於本節開頭所述的多個因素。

作為部署的一般指南，請記住一些事項：

  • 物件輸送量的消長大致上會與伺服器上的同步群組數目成正比。 在伺服器上將資料分割到多個同步群組時，會產生較佳的輸送量，但仍受限於伺服器和網路。
  • 物件輸送量與每秒 MiB 輸送量成反比。 對於較小的檔案，您會在每秒處理的物件數目方面遇到較高的輸送量，但每秒的MiB輸送量較低。 相反地，對於較大的檔案，您將每秒處理較少的物件，但每秒的MiB輸送量較高。 每秒的 MiB 輸送量會受限於 Azure 檔案擴展目標。

另請參閱