共用方式為

瞭解 Azure 檔案儲存體 計費模型

Azure 檔案儲存體部署的成本是由四個主要因素所決定：

  • 計費模型：Azure 檔案儲存體支援三種不同的計費模型，以塑造 Azure 檔案儲存體部署的成本結構：

    • 佈建 v2：佈建計費模型，您可以在其中個別佈建儲存體、IOPS 和輸送量。 無論您實際使用多少，您都會根據佈建的內容支付費用。 建議針對所有新的 Azure 檔案儲存體部署佈建 v2 模型。
    • 佈建 v1：佈建計費模型，您可以在其中佈建所需的儲存量，而 IOPS 和輸送量則取決於您佈建的儲存量。 除非您有使用佈建的 v1 模型的特定原因，否則建議您使用佈建的 v2 模型。
    • 隨用隨付：基於使用量的計費模型，費用將根據您使用檔案共用的程度來決定，包含已使用儲存體、交易及資料傳輸成本等形式。 建議您使用預設的 v2 模型，除非您有特定理由使用隨用隨付模型。

  • 媒體層：Azure 檔案儲存體支援兩個不同的儲存體媒體層：SSD 和 HDD。 這可讓您根據情境的效能和價格需求量身調整檔案共用。

    • SSD （進階版）：裝載在固態硬碟 （SSD） 上的檔案共用提供一致的高效能和低延遲，大部分的 IO 作業延遲為個位數毫秒。
    • HDD（標準）：託管在硬碟 （HDD） 上的檔案共用為一般用途提供經濟高效的儲存。

  • 備援：Azure 檔案儲存體支援四種不同的備援選項，可讓您控制儲存的資料複本數目，以及複製的資料在 Azure 基礎結構中的位置。 更具彈性的選項可提供更高的耐用性和可用性，但成本更高：

    • 本機：本地備援儲存體 (LRS) 會在一個區域的單一資料中心內保留三個資料複本。
    • 區域：區域備援儲存體 （ZRS） 會在區域內的獨立資料中心 （可用性區域） 之間儲存三個資料複本。
    • 異地：異地備援儲存體 （GRS） 會在主要區域中儲存三個資料複本，並以非同步方式複寫至配對區域，總共有六個複本。 僅適用於 HDD 儲存設備。
    • GeoZone：GeoZone 備援儲存體 （GZRS） 會結合主要區域中的區域備援，以及次要區域的非同步複寫。 僅適用於 HDD 儲存設備。

  • 資源模型：Azure 檔案儲存體支援兩種不同類型的 資源，即您在 Azure 訂用帳戶和資源群組中建立和設定的可管理專案。 每個資源類型都支援略有不同的計費模型選項，這反過來又會影響成本和成本結構：

    • 儲存體帳戶 代表儲存體、IOPS 和輸送量的共用集區，您可以在其中部署 傳統檔案共用 或其他儲存體資源，視儲存體帳戶類型而定。 儲存體帳戶支援所有計費模型、媒體層和備援選項。 部署到儲存體帳戶的所有儲存體資源，都共用適用於該儲存體帳戶的限制。 傳統檔案共用同時支援 SMB 和 NFS 通訊協定、但 NFS 僅支援 SSD 儲存設備。 儲存體帳戶是由資源提供者 Microsoft.Storage 提供。

    • 檔案共用 （預覽） 是一種新的最上層資源類型，可藉由消除儲存體帳戶來簡化 Azure 檔案儲存體的部署。 檔案共用僅支援建議的佈建v2模型、且僅支援具有NFS檔案系統通訊協定的SSD媒體層。 檔案共用是由Microsoft.FileShares資源提供者提供的。

如需 Azure 檔案服務定價資訊，請參閱 Azure 檔案服務定價頁面。

此影片提供各種 Azure 檔案儲存體計費模型之間差異的完整概觀，包括隨用隨付、佈建的 v1 和佈建的 v2。

這段影片深入探討 Azure 檔案服務布建 v2 計費模型，並提供設定指示和建議，以降低總擁有成本。

儲存單位

Azure 檔案儲存體使用二進位的測量單位來代表儲存容量：KiB、MiB、GiB 和 TiB。

縮略字 Definition 單位
KiB 1,024 個位元組 kibibyte
MiB 1,024 KiB (1,048,576 個位元組) mebibyte
GiB 1,024 MiB (1,073,741,824 個位元組) gibibyte
TiB 1,024 GiB (1,099,511,627,776 個位元組) tebibyte

大多數作業系統和工具在測量儲存容量時，通常會使用基底 2 的單位。 不過，它們經常被錯誤標記為十進制單位，您可能更熟悉的是：KB、MB、GB和TB。 類似 Windows 的作業系統標示儲存單元錯誤的常見原因是，許多作業系統在被國際電工委員會（IEC）、國際度量衡局（BIPM）和美國國家標準技術研究所（NIST）標準化之前就開始使用這些縮寫。

下表顯示常見的作業系統如何測量和標記儲存體：

操作系統 測量系統 標籤化
窗戶 2 進位 一致錯誤標記為 10 進位。
Linux 發行版 通常使用二進位，有些軟體使用十進位。 標籤不一致，測量和標籤的對齊方式取決於軟體套件。
macOS、iOS 和 iPad OS 10 進位 以一致方式標示為 10 進位。

如果您的作業系統未列出，請洽詢您的作業系統廠商。

檔案共用擁有權總成本的檢查清單

如果您要從內部部署移轉至 Azure 檔案儲存，或比較 Azure 檔案儲存與其他雲端儲存解決方案，請考慮下列因素，以確保公平、等同的比較。

  • 您為儲存體、IOPS 和頻寬支付了多少費用？ 大部分的雲端解決方案都有符合布建 記憶體原則的模型，例如價格決定性和簡單性，或隨用隨 付記憶體，其只需為您實際使用的內容收費，即可將成本優化。 佈建的計費模型可能因最小的佈建共用大小、佈建單位，以及增加和減少佈建的能力而有所不同。

  • 是否有任何方法可將儲存體成本最佳化呢？ 您可以使用Azure Files 保留來獲得儲存空間高達 36% 的折扣。 其他解決方案可能會採用重複數據刪除或壓縮等策略，選擇性地將儲存效率優化。 不過，這些儲存體優化策略通常會有非貨幣成本，例如降低效能。 Azure 檔案預留對效能沒有副作用。

  • 如何實現儲存體復原和備援？ 透過 Azure Files，產品中提供的功能包含儲存復原能力和冗餘。 所有層級和備援層級都可確保資料具有高可用性，而且至少有三份資料複本可供存取。 考慮其他檔案儲存選項時，請思考是否內建儲存的復原能力和備援性，還是需要您自行組裝。

  • 您需要管理什麼？ Azure 檔案服務是完全受控的解決方案。 其他解決方案可能需要作系統更新或管理虛擬資源，例如 VM、磁碟和網路 IP 位址。

  • 增值產品的成本為何？ Azure 檔案服務支援與多個第一方和第三方 增值服務的整合。 Azure 備份、Azure 檔案同步 和 Microsoft Defender for Storage 等增值服務提供備份、復寫和快取，以及 Azure 檔案儲存體 的安全性功能。 無論是內部部署或雲端中的加值解決方案，均具備自己的授權和產品成本，但經常視為檔案儲存體擁有權總成本的一部分。

已佈建的 v2 模型

Azure 檔案服務布建的 v2 模型結合總持有成本的可預見性與彈性，讓您能建立符合您確切儲存和效能需求的檔案共用。 當您建立新的佈建 v2 檔案共享時，您可以指定檔案共用所需的記憶體、IOPS 和輸送量。 您提供的每個數量都會影響您的總帳單金額。

您布建的記憶體、IOPS 和輸送量是檔案共用使用量的保證限制。 例如，如果您布建 2 TiB 儲存空間並將 2 TiB 的資料上傳至您的儲存空間，您的儲存空間已滿。 除非您增加共用的大小或刪除部分數據，否則您將無法新增更多數據。 額度型 IOPS 高載會儘可能增加使用量的彈性，同時額度維持不變。

您布建的記憶體、IOPS 和輸送量可以隨著需求變更而動態地相應增加或減少。 然而，您只能在自上次增加數量起超過24小時後減少配置的數量。 布建變更后的幾分鐘內，記憶體、IOPS 和輸送量變更就會生效。

根據預設，當您使用布建的 v2 模型建立新的檔案共用時，我們會針對您需要多少 IOPS 和輸送量提供建議。 這會根據您指定的布建記憶體數量來計算。 這些建議是以您所選擇的媒體層布建記憶體數量的典型客戶使用量為基礎。 不過，您可能會發現工作負載需要比「一般檔案共用」更多的或更少 IOPS 和輸送量。在此情況下，視個別檔案共用需求而定，您可以選擇性地布建或減少 IOPS 和輸送量。

已佈建的 v2 可用性

佈建的 v2 模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 是的 不
SSD 區域 SMB 是的 不
SSD Local NFS 是的 是的
SSD 區域 NFS 是的 是的
HDD Local SMB 是的 不
HDD 區域 SMB 是的 不
HDD 地理 SMB 是的 不
HDD 地理區域 SMB 是的 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

目前，配置的 v2 模型已在有限的區域子集內普遍可用：

  • 所有 Azure 公用雲端區域。
  • 所有 Azure 美國政府雲端區域。

附註

並非所有地區都支援所有媒體等級和冗餘選項。

已佈建 v2 佈建詳細資料

當您建立布建的 v2 檔案共享時，您會在記憶體、IOPS 和輸送量方面指定檔案共用的布建容量。 檔案共享會根據下列屬性來限制：

Item SSD 值 HDD 值
儲存體佈建單位 1 GiB 1 GiB
IOPS 佈建單位 1 IO / 秒 1 IO / 秒
輸送量佈建單位 1 MiB / 秒 1 MiB / 秒
佈建儲存體下限 32 GiB 32 GiB
佈建的最小 IOPS 3,000 IOPS 500 IOPS
最低佈建輸送量 100 MiB / 秒 60 MiB / 秒
佈建儲存體上限 256 TiB （262,144 GiB） 256 TiB （262,144 GiB）
佈建的 IOPS 上限 102,400 IOPS 50,000 IOPS
佈建的輸送量上限 10,340 MiB / 秒 5,120 MiB / 秒

根據預設，我們建議根據您指定的佈建儲存進行 IOPS 和輸送量佈建。 這些建議公式是以該媒體層在 Azure 檔案儲存體中已佈建儲存體數量的一般客戶使用量為基礎：

公式名稱 SSD 公式 HDD 公式
IOPS 建議 MIN(MAX(3000 + CEILING(1 * ProvisionedStorageGiB), 3000), 102400) MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
輸送量建議 MIN(MAX(100 + CEILING(0.1 * ProvisionedStorageGiB), 100), 10340) MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

根據您的個別檔案共用需求，您可能會發現您需要比我們的建議多或少 IOPS 或輸送量。 您可以根據需要，以自己的數值取代這些建議。

已佈建的 v2 高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 這種彈性最適合用來作為針對非預期 IO 尖峰的緩衝區。 針對已建立的 I/O 模式，我們建議為 I/O 高峰做好資源配置。

當檔案共享的流量低於佈建的 (基準) IOPS 時，突發 IOPS 點數會累積。 每當檔案共用的 IOPS 使用量超過所配置的 IOPS，且有可用的突增 IOPS 點數時，檔案共用可以突增至允許的最大突增 IOPS 限制。 只要額度有剩餘，檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 一旦用完所有額度，IOPS 就會回到預先配置的水平。 針對檔案共用的 IOPS 不需要執行任何特殊動作，即可使用高載。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，表示檔案共用使用小於已佈建 IOPS。
  • 減少，表示檔案共用使用超過已佈建 IOPS，且處於高載模式。
  • 持平，表示檔案共用使用所有已佈建 IOPS，沒有任何累積或使用的額度。

新的檔案共用最初會具有其高載貯體中的完整額度。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定檔案共用的高載 IOPS 限制和可能的額度數量：

Item SSD 公式 HDD 公式
高載 IOPS 限制 MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
高載 IOPS 額度 (BurstLimit - ProvisionedIOPS) * 3600 (BurstLimit - ProvisionedIOPS) * 3600

下表說明這些公式的幾個範例，適用於各種布建的 IOPS 數量：

已佈建 IOPS SSD 高載 IOPS 限制 SSD 高載額度 HDD 高載 IOPS 限制 HDD 高載額度
500 -- -- 最高 5,000 16,200,000
1,000 -- -- 最高 5,000 14,400,000
3,000 最高 10,000 25,200,000 最高 9,000 21,600,000
5,000 最高 15,000 36,000,000 最高 15,000 36,000,000
一萬 最高 30,000 72,000,000 最高 30,000 72,000,000
25,000 最高 75,000 180,000,000 最高 50,000 90,000,000
50,000 最高 102,400 188,640,000 最高 50,000 0
75,000 最高 102,400 98,640,000 -- --
102,400 最高 102,400 0 -- --

配置的 v2 資源模型

布建的 v2 計費模型適用於 Azure 檔案儲存體所使用的兩種資源類型。 有兩種能夠建立已佈建 v2 檔案共用的方式，作為儲存體帳戶內的傳統檔案共用 (Microsoft.Storage)，或直接建立為頂層檔案共用 (Microsoft.FileShares)。

已佈建 v2 傳統檔案共用 (Microsoft.Storage)

若要使用佈建的 v2 模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一個設定組合：

儲存體帳戶種類 儲存帳戶 SKU 可用的傳統檔案共用類型
文件儲存 PremiumV2_LRS SSD 已佈建 v2 傳統檔案共用，已指定本機備援。
文件儲存 PremiumV2_ZRS SSD 已佈建 v2 傳統檔案共用，已指定區域備援。
文件儲存 StandardV2_LRS HDD 已佈建 v2 傳統檔案共用，已指定本機備援。
文件儲存 StandardV2_ZRS HDD 已佈建 v2 傳統檔案共用，已指定區域備援。
文件儲存 StandardV2_GRS HDD 已佈建 v2 傳統檔案共用，已指定異地備援。
文件儲存 StandardV2_GZRS HDD 已佈建 v2 傳統檔案共用，已指定異地備援。

如需如何使用佈建的 v2 模型建立傳統檔案共用的詳細資訊，請參閱 建立傳統檔案共用。

在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

Attribute SSD 值 HDD 值 執法策略
每個記憶體帳戶布建的記憶體上限 256 TiB （262,144 GiB） 4 PiB （4,194,304） 在佈建時。
每個儲存體帳戶佈建的最大 IOPS 102,400 IOPS 50,000 IOPS 在佈建時。
每個儲存體帳戶佈建的輸送量上限 10,340 MiB / 秒 5,120 MiB / 秒 在佈建時。
每個儲存體帳戶的傳統檔案共用數上限 50 個經典檔案共用 50 個經典檔案共用 在佈建時。

若要在傳統檔案共用上使用佈建的 v2 計費模型正確部署 Azure 檔案儲存體，您必須考慮下列容量規劃維度：

  • 每個傳統檔案共用需要多少佈建儲存體、IOPS 和輸送量？ 這些要求如何隨時間變化？
    由於儲存體帳戶具有共用限制，因此當您將傳統檔案共用配置給儲存體帳戶時，您必須考慮每個傳統檔案共用現在和一段時間的需求。 佈建 v2 模型的佈建邏輯可防止您佈建超過儲存體帳戶支援的儲存體、IOPS 或輸送量。 如果將足夠的傳統檔案共用放置在單一儲存體帳戶中，讓其中一個維度達到上限，則現有的傳統檔案共用無法在未先移轉至不同的儲存體帳戶的情況下成長。 若要降低此風險，請在每個儲存體帳戶中規劃足夠的餘裕，以便至少在未來 3 到 5 年，您可以維持傳統檔案共用與儲存體帳戶的對應。

  • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
    在 Azure 中，您可以看到計費的最低細微度是 資源，這表示如果您將兩個傳統檔案共用放在相同的儲存體帳戶中，則無法輕鬆地將其成本追蹤回個別專案、部門或客戶。 若要解決此問題，請根據計費追蹤需求，將傳統檔案共用分組至儲存體帳戶中。

  • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
    另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 視您需要的儲存體帳戶數目而定，您可能需要使用其他訂用帳戶來達到額外的儲存體帳戶。

設定的 v2 檔案共用（Microsoft.FileShares）

使用管理模型建立 Microsoft.FileShares 檔案共用，可讓部署 Azure 檔案儲存體變得相當容易：

  • 您不需要考慮每個檔案共用目前和未來的需求，即可決定要部署該檔案共用的位置。
    每個檔案共用的佈建都獨立於每個其他檔案共用的佈建。 檔案共用增長時唯一需要考量的是檔案共用的限制，詳見已配置的 v2 配置詳細資料。

  • 每個檔案共用的帳單均獨立追蹤。
    由於文件共享是最高層級的資源，因此您可以獨立追蹤每個文件共享的費用，而不依賴於其他文件共享。 您也可以使用標籤，輕鬆地將資源分組在一起，以追蹤專案、部門或客戶的成本。

  • 雖然檔案共用仍具有每個區域每個訂用帳戶的限制，但檔案共用的限制遠高於儲存體帳戶的限制。
    如需詳細資訊，請參閱 Microsoft.FileShares 控制平面限制。

已佈建 v2 快照集

Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

快照集總是與即時共用及彼此不同。 在已佈建的 v2 計費模型中，如果所有快照的總大小差異在檔案共用的過剩佈建儲存空間內，則快照儲存體不會產生額外費用。 如果即時共享資料的大小加上差異化快照資料大於所配置的共享存儲容量，則快照的超出容量部分將根據溢位快照使用量計費。 判斷溢位量的公式為： MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Azure 檔案儲存體 的一些增值服務會使用快照集作為其價值主張的一部分。 如需詳細資訊，請參閱 Azure 檔案記憶體的增值服務。

已佈建 v2 虛刪除

啟用軟刪除時，已刪除的檔案共用會根據其在保留期間使用的儲存體容量計費。 已刪除共用的已佈建儲存體、IOPS 和輸送量會持續計入儲存體帳戶的限制中，直到該共用已清除為止，以確保可以還原它。 不過，這些資源不會計費。 如需啟用虛刪除的詳細資訊，請參閱 如何在 Azure 檔案共用上啟用虛刪除。

已佈建 v2 計費計量

使用已佈建 v2 計費模型佈建的檔案共用會根據下列計費計量收費：

  • 已布建的記憶體：GiB 中布建的記憶體數量。
  • 已布建的 IOPS：布建的 IOPS 數量（IO/秒）。
  • 布建的輸送量MiBPS：以MiB / 秒布建的輸送量數量。
  • 溢位快照使用量：任何超出配置的儲存容量的差異快照使用量，以GiB計。 如需詳細資訊，請參閱佈建的 v2 快照集。
  • Soft-Deleted 使用量：以 GiB 計算的軟刪除檔案分享的已用儲存容量。 如需詳細資訊，請參閱佈建的 v2 虛刪除。

針對佈建的 v2 計費計量，每小時發出取用單位。 例如，針對已佈建 1,024 GiB 的共用，您應該會看到：

  • 1,024 單位，根據單一小時的已佈建儲存體計量。
  • 24,576 單位，根據彙總一天的已佈建儲存體計量。
  • 根據月份中的天數，彙總一個月的可變單位數：
    • 一個月 28 天 (正常的 2 月)：688,128 單位，根據已佈建儲存體計量。
    • 一個月 29 天 (閏年的 2 月)：712,704 單位，根據已佈建儲存體計量。
    • 一個月 30 天：737,280 單位，根據已佈建儲存體計量。
    • 一個月 31 天：761,856 單位，根據已佈建儲存體計量。

已佈建 v2 移轉

將您的 SMB Azure 檔案共用的遷移過程從隨需即用模式轉換至布建 v2 計費模式取決於您是否使用 Azure 檔案同步，因此流程會因而有所不同。

已佈建 v1 模型

布建的 v1 方法會以固定比例提供記憶體、IOPS 和輸送量，類似於在內部部署記憶體解決方案中購買記憶體的方式。 當您建立新的佈建 v1 傳統檔案共用時，您可以指定共用所需的儲存空間量，而 IOPS 和輸送量是計算值。 Azure 檔案儲存體的布建 v1 模型僅適用於 SSD 媒體層。

您配置的儲存空間數量會決定您的傳統檔案共享的保證儲存空間、IOPS 和頻寬限制。 例如，如果您佈建 2 TiB 共用，並將 2 TiB 的資料上傳至傳統檔案共用，則該共用將會已滿。 除非您增加傳統檔案共用的大小，或刪除部分資料，否則您將無法新增更多資料。 額度型 IOPS 高載會儘可能增加使用量的彈性，同時額度維持不變。

與購買內部部署儲存體不同，已佈建的 v1 傳統檔案共用可隨需求變化，動態擴大或縮小。 不過，在上次增加記憶體之後，您只能在經過 24 小時之後減少布建的記憶體。 布建變更后的幾分鐘內，記憶體、IOPS 和輸送量變更就會生效。

您可以將配置的配額縮減到小於您使用的 GiB 大小。 如果您這麼做，則不會遺失資料，但仍會針對占用的容量計費。 您將會收到佈建共用的效能，而不是所使用的大小。

已佈建 v1 可用性

佈建的 v1 模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 是的 不
SSD 區域 SMB 是的 不
SSD Local NFS 是的 不
SSD 區域 NFS 是的 不
HDD Local SMB 不 不
HDD 區域 SMB 不 不
HDD 地理 SMB 不 不
HDD 地理區域 SMB 不 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

使用佈建的 v1 模型的 SSD 傳統檔案共用已在大部分的 Azure 區域中正式推出。 如需詳細資訊，請參閱不同區域的 Azure 產品。

已佈建 v1 佈建詳細資料

當您建立佈建的 v1 傳統檔案共用時，您可以指定共用所需的儲存空間量。 您布建的每個 GiB 都可讓您以固定比例獲得更多 IOPS 和輸送量。 佈建的 v1 傳統檔案共用會根據下列屬性進行限制：

Item 價值觀
儲存體佈建單位 1 GiB
佈建儲存體下限 100 GiB
佈建的最小 IOPS （計算） 3,100 IOPS
最低佈建輸送量 （計算） 110 MiB/秒
佈建儲存體上限 100 TiB （102,400 GiB）
佈建IOPS上限（計算） 102,400 IOPS
佈建輸送量上限 （計算） 10,340 MiB / 秒

下列公式決定在共用上佈建的 IOPS 和輸送量：

Item Formula
計算已佈建 (基準) IOPS MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
計算布建輸送量 （MiB / 秒） 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

根據您的個別傳統檔案共用需求，您可能會發現您需要比佈建公式提供的更多 IOPS 或輸送量。 在此情況下，您必須佈建更多儲存體，以取得所需的 IOPS 或輸送量。

已佈建 v1 高載

布建的 v1 模型支援兩種類型的高載： 信用型高載，這是免費布建的一部分，以及 付費高載，這是一項進階功能，可讓您選擇性地啟用，以在 IOPS 和輸送量超過布建金額時支援以使用量為基礎的計費。

已佈建 v1 額度型高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 這種彈性最適合用來作為針對非預期 IO 尖峰的緩衝區。 針對已建立的 I/O 模式，我們建議為 I/O 高峰做好資源配置。

當傳統檔案共用的流量低於已佈建 (基準) IOPS 時，將會累積高載 IOPS 額度。 每當傳統檔案共用的 IOPS 使用量超過佈建的 IOPS 且有可用的高載 IOPS 點數時，傳統檔案共用可能會高載至允許的最高高載 IOPS 限制。 只要額度有剩餘，傳統檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 一旦使用所有額度，傳統檔案共用就會回到已佈建 IOPS。 針對傳統傳統檔案共用的 IOPS 不需要執行任何特殊動作即可使用突增。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，表示傳統檔案共用使用小於已佈建 IOPS。
  • 減少，表示傳統檔案共用使用超過已佈建 IOPS，且處於高載模式。
  • 持平，表示傳統檔案共用使用所有已佈建 IOPS，沒有任何累積或使用的額度。

新的傳統檔案共用最初會具有其高載貯體中的完整額度。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定傳統檔案共用的高載 IOPS 限制和可能的額度數量：

Item Formula
高載限制 MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
高載額度 (BurstLimit - BaselineIOPS) * 3600

下表展示一些針對佈建大小的公式範例：

容量 （GiB） 基準 IOPS 高載 IOPS 高載額度 輸送量 （MiB/秒）
100 3,100 最高 10,000 24,840,000 110
500 3,500 最高 10,000 23,400,000 150
1,024 4,024 最高 10,000 21,513,600 203
5,120 8,120 最高 15,360 26,064,000 613
10,240 13,240 最高 30,720 62,928,000 1,125
33,792 36,792 最高 102,400 227,548,800 3,480
51,200 54,200 最高 102,400 164,880,000 5,220
102,400 102,400 最高 102,400 0 10,340

已佈建 v1 付費高載

付費高載是已佈建 v1 模型的進階功能，其設計目的是支援從未想要節流的客戶。 付費高載會針對佈建儲存體上方的任何 IOPS 或輸送量，增加額外的使用量型計費。 這與額度型高載不同，後者免費包含在已佈建的儲存體中。 雖然付費高載可以增加您佈建傳統檔案共享的強大彈性，但如果使用不正確，也可能會導致非預期的計費。

與額度型高載一樣，付費高載並不是用來佈建正確 IOPS 和輸送量的替代方式。 相反地，如果您遇到非預期的需求，它會提供進一步保護來防止節流 如果您有一致的 IOPS 或輸送量使用量層級，佈建足夠的 IOPS 和輸送量 (透過儲存體佈建) 以滿足需求更為便宜，而不是依賴付費高載。

預設情況下，付費突增功能會被停用，但您可以按照指示啟用該功能，以修改已配置的 v1 經典檔案共享的成本和效能特性（僅適用於 PowerShell 和 CLI）。 如果已啟用付費突增功能，建議您使用透過 Azure 監視器提供的下列指標來仔細監控 IOPS 和輸送量使用量：

  • 檔案共用佈建的 IOPS
  • 檔案共用布建頻寬 MiB/秒 （輸送量）
  • 根據最大 IOPS 的交易
  • 最大 MiB/秒的頻寬 (輸送量)
  • IOPS 高載額度 (額度型高載)
  • 付費高載 IOS (IO)
  • 付費高載頻寬

配置的 v1 資源模型

您只能將已佈建的 v1 檔案共用建立為儲存體帳戶 (Microsoft.Storage) 內的傳統檔案共用。

已佈建 v1 傳統檔案共用 (Microsoft.Storage)

若要使用佈建的 v1 模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一種設定組合：

儲存體帳戶種類 儲存帳戶 SKU 可用的檔案共用類型
文件儲存 Premium_LRS SSD 已佈建 v1 檔案共用，已指定本地 (LRS) 備援。
文件儲存 Premium_ZRS SSD 已佈建 v1 檔案共用，已指定區域 (ZRS) 備援。

如需如何使用佈建的 v1 模型建立傳統檔案共用的詳細資訊，請參閱 建立傳統檔案共用。

在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

Attribute SSD 值 執法策略
每個記憶體帳戶布建的記憶體上限 100 TiB （102,400 GiB） 在佈建時
每個儲存體帳戶的已用 IOPS 上限 102,400 IOPS 您可以佈建超過 102,400 IOPS，但超過此限制的用量會受到限制。
每個儲存帳戶的最大使用吞吐量 10,340 MiB / 秒 您可以配置超過 10,340 MiB/秒的資源，但超過此限制的用量將會被限制。
每個儲存體帳戶的傳統檔案共用數上限 1,024 個傳統檔案共用 儲存體帳戶的最大配置儲存上限隱含地強制執行此限制。

若要在傳統檔案共用上使用佈建的 v1 計費模型正確部署 Azure 檔案儲存體，您必須考慮下列容量規劃維度：

  • 每個傳統檔案共用需要多少佈建儲存體、IOPS 和輸送量？ 這些要求如何隨時間變化？
    由於共用儲存體帳戶的限制，當您將傳統檔案共用配置給儲存體帳戶時，必須同時考慮每個傳統檔案共用目前以及未來一段時間的需求。 佈建的 v1 模型的預配置邏輯可防止您配置超過儲存帳戶支援的儲存空間。 雖然您可以佈建比儲存體帳戶提供的 IOPS 和輸送量更多的 IOPS 和輸送量，但您不能使用超過儲存體帳戶的 IOPS 和輸送量限制。 若要避免非預期的節流，請勿佈建超過儲存體帳戶支援的 IOPS 或輸送量。

    此外，在儲存體帳戶中放置太多傳統檔案共用可能會限制未來的成長。 儲存體帳戶已滿之後，除非先將某些儲存體帳戶移轉至另一個儲存體帳戶，否則就無法擴充現有的傳統檔案共用。 若要降低此風險，請在儲存體帳戶中規劃足夠的餘裕，讓您可以將傳統檔案共用與儲存體帳戶的對應維護至少 3 到 5 年。

  • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
    在 Azure 中，您可以看到計費的最低細微度是 資源，這表示如果您將兩個傳統檔案共用放在相同的儲存體帳戶中，則無法輕鬆地將其成本追蹤回個別專案、部門或客戶。 若要解決此問題，請根據計費追蹤需求，將傳統檔案共用分組至儲存體帳戶中。

  • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
    另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 視您需要的儲存體帳戶數目而定，您可能需要使用其他訂用帳戶來達到額外的儲存體帳戶。

已佈建 v1 快照集

Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

快照集總是與即時共用及彼此不同。 在布建的 v1 計費模型中，不論未使用多少布建記憶體，總差異大小都會根據使用量計量計費。 已使用快照集儲存體計費的價格比已佈建儲存體價格更低。

已佈建 v1 虛刪除

在已啟用虛刪除的儲存體帳戶中，已刪除的傳統檔案共用會根據定義的保留期間內已刪除共用的已使用儲存體容量進行計費。 虛刪除使用量儲存體容量會針對使用的快照集儲存體計量發出。 如需虛刪除的詳細資訊，請參閱 如何在 Azure 檔案共享上啟用虛刪除。

已佈建 v1 計費計量

使用已佈建 v1 計費模型佈建的傳統檔案共用會根據下列計量進行收費：

  • 進階布建：GiB 中布建的記憶體數量。
  • 高級快照：已使用的快照數量和已使用的軟刪除容量。

針對已佈建 v1 計費計量的使用量，會以每月單位每小時發出。 例如，針對已佈建 1,024 GiB 的共用，您應該會看到：

  • 個別小時的可變單位數，視月份的天數而定：
    • 一個月 28 天 (正常的 2 月)：1.5238 單位，根據進階已佈建計量。
    • 一個月 29 天 (閏年的 2 月)：1.4713 單位，根據進階已佈建計量。
    • 一個月 30 天：1.4222 單位，根據進階已佈建計量。
    • 一個月 31 天：1.3763 單位，根據進階已佈建計量。
  • 根據每月天數，彙總一天的可變單位數目：
    • 一個月 28 天 (正常的 2 月)：36.5714 單位，根據進階已佈建計量。
    • 一個月 29 天 (閏年的 2 月)：35.3103 單位，根據進階已佈建計量。
    • 一個月 30 天：34.1333 單位，根據進階已佈建計量。
    • 一個月 31 天：33.0323 單位，根據進階已佈建計量。
  • 1,024 個單位，根據彙總一個月的進階已佈建計量。

隨用隨付模型

在隨用隨付模型中，您會依您使用的記憶體量計費，而不是布建多少。 概括而言，您會為儲存的邏輯數據量支付費用，而且您也會根據該數據的使用量支付交易費用。 隨用隨付計費可能難以在預算程式中進行規劃，因為您會根據使用者耗用量付費。 因此，建議您針對新的傳統檔案共用部署使用 佈建的 v2 模型 。 隨用隨付模式僅適用於 HDD 存儲。

隨用即付可用性

隨用隨付模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 不 不
SSD 區域 SMB 不 不
SSD Local NFS 不 不
SSD 區域 NFS 不 不
HDD Local SMB 是的 不
HDD 區域 SMB 是的 不
HDD 地理 SMB 是的 不
HDD 地理區域 SMB 是的 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

使用隨用隨付模型的 HDD 傳統檔案共用已在所有 Azure 區域正式推出。

存取層的差異

當您在隨用隨付儲存帳戶中建立經典檔案共用時，您可以在下列存取層之間進行選擇：交易最佳化、熱和冷。 這三個存取層都會儲存在完全相同的儲存硬體上。 這三個存取層的主要差異在於其靜態資料儲存價格，較冷層級的價格較低，而交易價格則較高。 這表示：

  • 交易優化，如名稱所示，將高 IOPS（交易）工作負載的價格優化。 交易最佳化具有最高的待用資料儲存體價格，但交易價格最低。
  • 經常性存取層適用於未涉及大量交易的作用中工作負載。 相較於交易最佳化，其待用資料儲存體價格略低，但交易價格略高。 您可以將其視為介於交易最佳化和非經常性存取層之間的中間方案。
  • Cool 優化沒有高活動量的工作負載的價格，提供最低的靜態數據儲存成本，但交易價格較高。

為您的使用案例選取適當的存取層可讓您大幅降低成本。 如果您將不常存取的工作負載放在交易最佳化存取層中，則您幾乎不需要支付一個月內針對傳統檔案共用進行交易的幾次費用。 不過，您會為數據儲存成本支付大量費用。 如果要將這個相同的共用移至非經常性存取層，您仍然幾乎不用支付交易成本，因為您不常進行此工作負載的交易。 不過，冷存取層具有更便宜的數據儲存成本。

同樣地，如果您在冷存取層中放置高頻率存取的工作負載，則會支付較高的交易成本，但數據儲存成本較低。 這可能會導致一種情況，即因交易價格增加而增加的成本超過減少資料儲存體價格所省下的費用，您在非交易最佳化的情況下可能支付更多的非經常性存取層費用。 對於某些使用量層級，熱存取層可能會最符合成本效益，而冷存取層會比交易優化層更昂貴。

您的工作負載和活動層級會為隨用隨付傳統檔案共用決定最具成本效益的存取層。 實際上，挑選最具成本效益存取層的最佳方式包括查看共用的實際資源耗用量（儲存的數據、寫入交易等）。 針對隨用隨付傳統檔案共用，建議您在初始移轉至 Azure 檔案儲存體期間從交易最佳化層開始，然後在移轉完成後根據使用量挑選正確的存取層。 移轉期間的交易使用量通常不表示一般交易使用量。

什麼是交易？

當您在電腦上使用 SMB，以隨用隨付模型裝傳統典檔案共用時，該傳統檔案共用將如同本機存放區般，直接呈現在您的電腦上。 這表示您電腦上的應用程式、腳本和其他程式可以存取傳統檔案共用上的檔案和資料夾，而不需要知道它們儲存在 Azure 中。

當您讀取或寫入檔案時，您使用的應用程式會對作系統所提供的檔案系統 API 執行一系列 API 呼叫。 接著，您的作系統會將這些呼叫解譯成SMB通訊協定交易，這些交易會透過網路傳送至 Azure 檔案儲存體來完成。 最終使用者視為單一操作的簡單工作，例如從頭到尾讀取檔案，實際上可能涉及 Azure 檔案服務提供的多個 SMB 交易。

原則上，傳統檔案共用會使用隨用隨付的模型，並根據使用量進行計費。 應用程式和腳本所進行的 SMB 和 FileREST 交易代表傳統檔案共用的使用量，而且它們會顯示為帳單的一部分。 相同的概念適用於您可能新增至共用的加值雲端服務，例如 Azure 檔案同步或 Azure 備份。

交易會分組為五個不同的交易類別，這些類別會根據其對傳統檔案共用的影響而具有不同的價格。 這些類別包括：寫入、列出、讀取、其他和刪除。

下表顯示每個交易的分類：

交易池 管理作業 資料作業
寫入交易
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • SetShareAcl
  • SnapshotShare
  • RestoreShare
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • Write
  • PutFilePermission
  • Flush
  • SetDirectoryProperties
列出交易
  • ListShares
  • ListFileRanges
  • ListFiles
  • ListHandles
讀取交易紀錄
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
其他/通訊協定交易
  • AcquireShareLease
  • BreakShareLease
  • ReleaseShareLease
  • RenewShareLease
  • ChangeShareLease
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
刪除交易
  • DeleteShare
  • ClearRange
  • DeleteDirectory
  • DeleteFile

附註

NFSv4.1 僅適用於使用佈建 v2 或佈建 v1 計費模型的 SSD 檔案共用。 交易貯體不會影響已佈建檔案共用的計費。

在存取層之間切換

雖然您可以使用隨用隨付模型來變更傳統檔案共用的存取層，但在初始移轉之後優化成本的最佳做法是挑選要加入的成本最佳存取層，並保留在那裡，除非您的存取模式變更。 這是因為變更傳統檔案共用的存取層會導致額外成本，如下所示：

  • 交易：將傳統檔案共用從經常性儲存層移至非經常性儲存層時，會針對共用中的每個檔案產生非經常性儲存層的寫入交易費用。 將傳統檔案共用從冷存取層移至熱存取層，將對冷存取層中的每個檔案產生讀取交易費用。

  • 數據檢索：如果您要從冷存取層移至熱存取層或交易優化層，則會根據移動的數據大小產生數據檢索費。 只有非經常性存取層會收取資料擷取費用。

下表說明移動存取層的成本明細：

存取層 交易最佳化 （目的地） 熱門（目的地） 酷炫的目的地
交易優化 （來源） --
  • 每個檔案有一個經常性寫入交易。
  • 每個檔案有一個非經常性寫入交易。
經常性 (來源)
  • 每個檔案有一個經常性讀取交易。
    		 --
    • 每個檔案有一個非經常性寫入交易。
    非經常性 (來源)
    • 每個檔案有一個非經常性讀取交易。
    • 每個已使用 GiB 總計的資料擷取。
    • 每個檔案有一個非經常性讀取交易。
    • 每個已使用 GiB 總計的資料擷取。
    		 --

    您可以在 30 天的期間內變更傳統檔案共用的存取層最多五次。 當第一層變更發生時，30 天視窗的第一天就會開始。 更改存取層會立即生效，然而，一旦您變更共用的存取層，即使在過去 30 天內變更存取層屬性少於 5 次，您仍然不能在 24 小時內再次進行更改。

    選擇存取層

    無論您如何將現有資料移轉至 Azure 檔案儲存體，建議您一開始在交易最佳化存取層中建立傳統檔案共用。 這是因為移轉期間產生的大量交易。 移轉完成且您正常使用數天或數周之後，您可以將交易計數插入 定價計算機 ，以判斷哪一個存取層最適合您的工作負載。

    由於隨用隨付儲存體帳戶只會在儲存體帳戶層級顯示交易資訊，因此使用儲存體計量來估計傳統檔案共用層級哪個存取層更便宜是一門不完美的科學。 如果可能，建議您在每個儲存帳戶中只部署一個傳統檔案共用，以確保帳單的完整可見性。

    若要查看先前的交易：

    1. 在 Azure 入口網站中進入您的儲存帳戶。
    2. 在服務功能表中的 [ 監視] 底下，選取 [ 計量]。
    3. 選取 [範圍] 作為您的儲存體帳戶名稱、選取 [命名空間] 作為「檔案」、選取 [計量] 作為「交易」，然後選取 [彙總] 作為「總和」。
    4. 選取 [套用分割]。
    5. 選取 [值] 作為「API 名稱」。 選取所需的 [限制] 和 [排序]。
    6. 選取所需的時段。

    附註

    請確定您在足夠長的時間內檢視交易，以實際瞭解平均交易數目。 確定所選的時間週期不會與初始布建重疊。 乘以在此時段內的平均交易數目，得出整個月份的預估交易。

    隨用隨付資源模型

    您只能將隨用隨付的檔案共用建立為儲存體帳戶 (Microsoft.Storage) 內的傳統檔案共用。

    隨用隨付傳統檔案共用服務（Microsoft.Storage）

    若要使用隨用隨付模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一個設定組合：

    儲存體帳戶種類 儲存帳戶 SKU 可用的檔案共用類型
    StorageV2 Standard_LRS HDD 隨用隨付檔案共用，已指定 Local (LRS) 備援。
    StorageV2 Standard_ZRS HDD 隨用隨付檔案共用，已指定 Zone (ZRS) 備援。
    StorageV2 Standard_GRS HDD 隨用隨付檔案共用，已指定 Geo (GRS) 備援。
    StorageV2 Standard_GZRS HDD 隨用隨付檔案共用，已指定 GeoZone (GZRS) 備援。
    StorageV2 Standard_RAGRS HDD 隨用隨付檔案共用，已指定 Geo (GRS) 備援。
    StorageV2 Standard_RAGZRS HDD 隨用隨付檔案共用，已指定 GeoZone (GZRS) 備援。

    在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

    Attribute HDD 值 執法策略
    每個儲存體帳戶的已用儲存體上限 5 PiB （5,242,880） 使用量有上限。
    每個儲存體帳戶的已用 IOPS 上限
    • 選取區域：40,000 IOPS
    • 預設值：20,000 IOPS
    		 超過限制的使用量會受到流量限制。
    每個儲存帳戶的最大使用吞吐量
    • 選取區域：
      • 輸入：7,680 MiB / 秒
      • 輸出：25,600 MiB / 秒
    • 預設：
      • 輸入：3,200 MiB / 秒
      • 輸出：6,400 MiB / 秒
    		 超過限制的使用量會受到流量限制。
    每個儲存體帳戶的傳統檔案共用數上限 無限制 儲存體、IOPS 和輸送量限制是傳統檔案共用數量的實際限制。

    如需詳細資訊，請參閱 儲存體帳戶資料平面限制， 包括哪些區域支援增加 IOPS 和輸送量的限制。

    若要在傳統檔案共用上使用隨用隨付計費模型正確部署 Azure 檔案儲存體，您必須考慮下列容量規劃維度：

    • 需要多少已使用的儲存空間、IOPS 和吞吐量來支援每個傳統檔案共用？ 這些要求如何隨時間變化？
      由於共用儲存體帳戶的限制，當您將傳統檔案共用配置給儲存體帳戶時，必須同時考慮每個傳統檔案共用目前以及未來一段時間的需求。 不同於已佈建的 v2 和 v1 模型，隨用隨付模型提供的保護措施較少，較難以協助您在同一儲存體帳戶內的傳統檔案共用之間共用儲存體帳戶的限制。 隨用隨付儲存體帳戶中的每個傳統檔案，其大小可達傳統檔案共用設定的上限，同時其 IOPS 與輸送量亦可達該儲存體帳戶的設定上限。 將兩個傳統檔案共用放在相同的隨用隨付儲存體帳戶中，可能會導致 IOPS 或輸送量爭用。 若要避免非預期的節流，請限制您放置在隨用隨付儲存體帳戶中的傳統檔案共用數目。

    • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
      在 Azure 中，您可以看到計費的最低細微度是 資源，這表示如果您將兩個傳統檔案共用放在相同的儲存體帳戶中，則無法輕鬆地將其成本追蹤回個別專案、部門或客戶。 若要解決此問題，請根據計費追蹤需求，將傳統檔案共用分組至儲存體帳戶中。

    • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
      另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 視您需要的儲存體帳戶數目而定，您可能需要使用其他訂用帳戶來達到額外的儲存體帳戶。

    隨用隨付快照集

    Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

    快照集總是與即時共用及彼此不同。 在隨用隨付計費模型中，差異大小總計會根據一般使用儲存體計量計費。 這表示您不會在帳單上看到個別明細項目，顯示隨用隨付儲存體帳戶的快照集。 這也表示差異快照集使用量會計入為隨用隨付傳統檔案共用所購買的保留。

    隨用隨付虛刪除

    在已啟用虛刪除的儲存體帳戶中，已刪除的傳統檔案共用會根據所定義保留期間內的已使用儲存體容量進行計費。 虛刪除已使用儲存體容量會針對一般已使用儲存體計量發出。 這表示您不會在帳單上看到個別明細項目，顯示隨用隨付儲存體帳戶的虛刪除傳統檔案共用。 這也表示虛刪除傳統檔案共用使用量會計入為隨用隨付傳統檔案共用所購買的保留。

    隨用隨付計費計量

    使用隨用隨付計費模型建立的傳統檔案共享會根據下列計價表計費：

    • 已儲存資料：已使用的儲存體包括即時共用、差異快照集和虛刪除傳統檔案共用 (以 GiB 為單位)。
    • 元數據：與檔案和目錄相關聯的檔案系統元數據大小，例如 GiB 中的存取控制清單 （ACL） 和其他屬性。 此計費計量僅用於經常性存取層或非經常性存取層中的傳統檔案共用。
    • 寫入作業：寫入存儲桶的數量（一個存儲桶 = 10,000 筆交易）。
    • 清單作業：清單交易桶的數量（一個桶 = 10,000 筆交易）。
    • 讀取作業：讀取交易桶的數目（一個桶 = 10,000 筆交易）。
    • 其他作業 / 通訊協議作業：其他交易貯體的數目（一個貯體 = 10,000 筆交易）。
    • 資料擷取：從傳統檔案共用讀取的資料量（以 GiB 為單位）。 此計量僅用於非經常性存取層中的傳統檔案共用。
    • 異地複寫資料傳輸：如果傳統檔案共用具有異地複寫或異地區域備援，則寫入傳統檔案共用的資料量會複寫到次要區域 (以 GiB 為單位)。

    針對已儲存資料和中繼資料計費計量，會以月為單位每小時發出取用單位。 例如，針對使用 1,024 GiB 的共用，您應該會看到：

    • 個別小時的可變單位數，視月份的天數而定：
      • 一個月 28 天 (正常的 2 月)：1.5238 單位，根據已儲存的資料計量。
      • 一個月 29 天 (閏年的 2 月)：1.4713 單位，根據已儲存的資料計量。
      • 一個月 30 天：1.4222 單位，根據已儲存的資料計量。
      • 一個月 31 天：1.3763 單位，根據已儲存的資料計量。
    • 根據每月天數，彙總一天的可變單位數目：
      • 一個月 28 天 (正常的 2 月)：36.5714 單位，根據已儲存的資料計量。
      • 一個月 29 天 (閏年的 2 月)：35.3103 單位，根據已儲存的資料計量。
      • 一個月 30 天：34.1333 單位，根據已儲存的資料計量。
      • 一個月 31 天：33.0323 單位，根據已儲存的資料計量。
    • 1024 單位，根據彙總一個月的已儲存的資料計量。

    針對其他計量 （例如 寫入作業 或 資料擷取） 的耗用量會每小時發出一次，但由於這些計量沒有與其相關聯的特定時間範圍，因此它們沒有任何需要注意的特殊單位轉換。

    已佈建/配額、邏輯大小和實體大小

    Azure 檔案儲存體追蹤與共用容量相關的三個相異數量：

    • 已佈建大小或配額：使用已佈建和隨用隨付檔案共用，您可以指定允許檔案共用成長的大小上限。 在預設的檔案共用中，此值稱為預設大小。 無論您預留的金額是多少，您都將支付這個金額，而不管實際使用量。 在隨用隨付的檔案共用中，此值稱為配額，不會直接影響您的帳單。 佈建的大小是佈建檔案共用的必要欄位。 針對隨用隨付檔案共用，如果未直接指定佈建的大小，則共用會預設為儲存體帳戶支援的最大值 (100 TiB)。

    • 邏輯大小：檔案共享或檔案的邏輯大小與它的大小有關，而不考慮實際儲存的方式，而不需要任何記憶體優化。 檔案的邏輯大小是指如果您將其複製到其他位置，透過網路會傳輸多少 KiB/MiB/GiB。 在預先設定和隨用隨付的檔案共享中，會根據總邏輯大小來控制設定的容量/配額。 在隨用隨付檔案共用中，邏輯大小為用於待用資料使用量計費的數量。 邏輯大小針對檔案/資料夾的 Windows 內容對話方塊稱為「大小」，而 Azure 檔案儲存體計量稱為「內容長度」。

    • 實體大小：檔案的實體大小與磁碟上編碼的檔案大小有關。 實體大小可能會與檔案的邏輯大小一致，或者因作業系統寫入檔案的方式而較小。 邏輯大小和實體大小不同的常見原因是使用 疏鬆檔案。 共用中的檔案實體大小會用於快照集計費，但如果快照集未變更 (差異儲存體)，則會將配置的範圍共用在快照集間。

    加值服務

    與許多內部部署儲存體解決方案一樣，Azure 檔案儲存體提供第一方和第三方產品的整合點，以便與客戶擁有的檔案共用整合。 雖然這些解決方案可為 Azure 檔案儲存體 提供相當多的額外價值，但您應該考慮這些服務新增至 Azure 檔案儲存體 解決方案總成本的額外成本。

    成本分成三個類別：

    • 加值服務的授權成本。 授權成本可能以每個客戶、終端使用者 （有時稱為「人頭成本」） 、檔案共用或儲存體帳戶的固定成本的形式出現。 它們也可能以記憶體使用率單位為基礎，例如檔案共用中每 500 GiB 區塊數據的固定成本。

    • 加值服務的交易成本。 某些增值服務在選取的 Azure 檔案儲存體 計費模型之上有自己的交易概念。 這些交易會顯示在加值服務費用之下的帳單上;不過，它們與您如何搭配檔案共用使用加值服務直接相關。

    • 使用 Azure Files 的加值服務成本。 Azure 檔案儲存體 不會直接向客戶收取增加增值服務的費用，但作為將值新增至 Azure 檔案共用的一部分，增值服務可能會增加您在 Azure 檔案共用上看到的成本。 因為交易費用，這些成本很容易從隨用隨付檔案共用中看出來。 如果加值服務代表您對檔案共享執行交易，它們會顯示在 Azure 檔案服務交易帳單中，即使您自己沒有直接執行這些交易也一樣。 這也適用於已配置的檔案共用，但可能較不明顯。 加值服務中根據已佈建檔案共用的交易會計入您已佈建 IOPS 號碼，表示加值服務可能需要佈建額外儲存體，才有足夠的 IOPS 或輸送量可供您的工作負載使用。

    計算檔案共用的擁有權總成本時，您應該考慮 Azure 檔案儲存體的成本，以及您要搭配 Azure 檔案儲存體使用的所有加值服務成本。

    有多個加值的第一方和第三方服務。 使用 Azure 檔案共用的常用第一方服務的子集概述於本文件中。 您可以閱讀該服務的定價頁面，以深入了解此處未列出的服務。

    Azure 檔案同步

    Azure 檔案同步是 Azure 檔案儲存服務的一項增值服務，它可同步處理一個或多個內部部署的 Windows 檔案共用與 Azure 檔案共用。 由於雲端的 Azure 檔案共用有同步檔案共用中可供內部部署使用的完整資料副本，因此您可以將內部部署的 Windows 檔案伺服器轉換為 Azure 檔案共用的快取，來降低內部部署使用量。 若要深入瞭解，請參閱 Azure 檔案同步簡介。

    考慮使用 Azure 檔案同步部署解決方案的擁有權總成本時，您應該考慮下列成本層面：

    • 具有一或多個伺服器端點 Windows 檔案伺服器的資本和營運成本。 Azure 檔案同步為複寫解決方案，與 Azure 檔案儲存體同步處理 Windows 檔案伺服器無關；這些伺服器可以裝載在內部部署、Azure 虛擬機器，甚至是另一個雲端。 裝載於內部部署或其他雲端提供者的同步處理伺服器成本包括資本和營運成本，這些費用雖未計入您的 Azure 帳單，但仍屬於解決方案擁有權總成本的組成部分。 資本支出是解決方案的前期硬體成本。 營運支出是指勞動力、電力等持續性成本。您應該考慮快取內部部署所需的資料量、Windows 檔案伺服器裝載 Azure 檔案同步工作負載所需的 CPU 數目和記憶體數量，以及您可能擁有的其他組織特定成本。 如需詳細資訊，請參閱建議的系統資源 (部分內容可能是機器或 AI 翻譯)。

    • 向 Azure 檔案同步註冊伺服器的每部伺服器授權成本。若要搭配特定 Windows 檔案伺服器使用 Azure 檔案同步，您必須先向 Azure 檔案同步的 Azure 資源 (儲存體同步服務) 註冊。 您在第一部伺服器之後註冊的每個伺服器都有一般每月費用。 雖然此費用很小，但這是帳單需要考慮的一個部分。 若要查看所需區域的伺服器註冊費用目前價格，請參閱 Azure 檔案服務定價頁面上的檔案同步一節。

    • Azure 檔案儲存成本。 Azure 檔案同步會取用 Azure 檔案共用中的資源。 其中一些資源相當明顯 (例如儲存體使用量)，而其他資源可能不是 (例如交易和快照集使用率)。 對於大多數客戶，我們建議使用 HDD 佈建的 v2 檔案共用搭配 Azure 檔案同步，儘管 Azure 檔案同步在所有 Azure 檔案儲存體計費模式下均獲得完整支援 (包括 SSD 佈建的 v2、SSD 佈建的 v1 或 HDD 隨用隨付)。

      • 儲存體使用率。 Azure 檔案同步會將您對伺服器端點所做的任何變更複寫到 Azure 檔案共用，導致儲存體耗用。 在已佈建的檔案共用上，變更會取用已佈建的空間 - 您必須負責定期增加佈建，依需求考慮檔案共用成長。 在隨用隨付的檔案共用上，在伺服器端點上新增或增加現有檔案的大小會導致已使用的儲存體成本增加，因為會複寫變更。

      • 快照使用率。 Azure 檔案同步以共用和檔案層級快照集作為一般使用方式的一部分。 雖然快照使用率一律有差異，但這可能會對整體 Azure 檔案總帳單造成顯著的影響。

      • IOPS / 輸送量使用率：Azure 檔案同步會驅動 IOPS 和輸送量使用率，以將變更從伺服器端點傳輸至 Azure 檔案共用。 如果您使用佈建的檔案共用，則應監視檔案共用使用量，以確保佈建了足夠的 IOPS 和輸送量，避免發生節流。 如果您使用隨用隨付的檔案共用，則會以交易的形式向您收取 IOPS 使用率的費用。 一般來說，有兩種類型的交易需要考慮：

        • 流失的交易。 當伺服器端點上的檔案變更時，系統會將變更上傳至雲端共用，因而產生交易。 啟用雲端階層處理時，將會產生額外的交易來管理階層式檔案，包括階層式檔案上發生的 I/O，以及輸出成本。 雖然由於流失率和快取效率而難以預測交易的數量和類型，但如果您認為未來使用量與目前的使用量類似，您可以使用先前的交易模式來估算未來的成本。

        • 雲端列舉的交易。 Azure 檔案同步每天會掃描雲端中的 Azure 檔案共用，以識別直接對共用進行的變更，並將這些變更同步至伺服器端點。 這項掃描會產生交易，這些交易會依每個目錄每天一次 ListFiles 交易的費率，向儲存體帳戶收取費用。 您可以將此數位放入 定價計算機 中，以估計掃描成本。

        提示

        如果您不知道有多少個資料夾，請參考 JAM Software GmbH 的 TreeSize 工具。

    Azure 備份

    Azure 備份為 Azure 檔案儲存體提供無伺服器備份解決方案，可順暢地與您的檔案共用、Azure 檔案同步等其他增值服務進行整合。適用於 Azure 檔案儲存體的 Azure 備份，是以快照集為基礎的備份解決方案，可提供排程機制，以在系統管理員定義的排程上自動建立快照集。 也提供使用者友善的介面，可用於將已刪除的檔案/資料夾或整個共用還原至特定時間點。 若要深入瞭解，請參閱 關於 Azure 檔案共用備份。

    考慮使用 Azure 備份的成本時，請考慮下列因素：

    • Azure 檔案共用資料的受保護執行個體授權成本。 Azure 備份會針對包含已備份 Azure 檔案共用的每個儲存體帳戶收取受保護的執行個體授權成本。 受保護的執行個體定義為 Azure 檔案共用儲存體的 250 GiB。 包含小於 250 GiB 的儲存帳戶將承擔部分受保護實例的成本。 如需詳細資訊，請參閱 Azure 備份定價。 您必須從 Azure 備份可以保護的服務清單中選取 Azure 檔案 服務。

    • Azure 檔案儲存成本。 Azure 備份會以下列方式增加 Azure 檔案儲存體的成本：

      • Azure 檔案共用快照集的差異成本。 Azure 備份在系統管理員定義的排程上自動擷取 Azure 檔案共用快照集。 快照集一律為差異;不過，新增的成本取決於保留快照集的時間長度，以及該時間期間檔案共享的變換量。 這些因素會影響快照與即時檔案共用之間的差異，因此 Azure Files 會儲存額外的數據量。

      • 還原作業的交易成本。 將作業從快照集還原到即時共享會產生交易成本。 對於標準檔案共用，從快照集讀取/從還原寫入將以一般檔案共用交易來計費。 對於已佈建檔案共用，這些作業會計入檔案共用的已佈建 IOPS。

    微軟儲存體防護裝置

    Microsoft Defender 支援 Azure 檔案儲存體 作為其 Microsoft Defender for Storage 產品的一部分。 適用於儲存體的 Microsoft Defender 會透過 SMB 或 FileREST 偵測到針對您的 Azure 檔案共用存取或惡意探索的異常和潛在有害嘗試。 適用於儲存體的 Microsoft Defender 會在該訂用帳戶儲存體帳戶中所有檔案共用的訂用帳戶層級上啟用。

    Microsoft Defender for Storage 不支援 Azure 檔案共用的防毒功能。

    適用於儲存體的 Microsoft Defender 主要成本是一組額外的交易成本，是在針對 Azure 檔案共用執行交易上收取的產品稅。 雖然上述成本是基於發生在 Azure 檔案儲存體上的交易，但此類成本並非 Azure 檔案儲存體帳單的一部分，而是屬於 Microsoft Defender 定價的一部分。 適用於儲存體的 Microsoft Defender 即使在已佈建檔案共用上也會收取交易費率，其中 Azure 檔案儲存體會包含交易作為 IOPS 佈建過程的一部分。 在 適用於雲端的 Microsoft Defender 定價頁面上 ，可以在 適用於記憶體的 Microsoft Defender 數據表數據列底下找到目前的交易費率。

    使用適用於儲存體的 Microsoft Defender 時，交易大量檔案共用會產生大量成本。 根據這些成本，您可能會想要針對某些儲存體帳戶停用 Microsoft Defender for Storage。 如需詳細資訊，請參閱 從 Microsoft Defender for Storage 保護中排除儲存體帳戶。

    Reservations

    Azure 檔案儲存體支援已佈建 v1 和隨用隨付模型的保留 (也稱為保留執行個體)。 預約可讓您藉由預先承諾使用儲存空間來實現儲存空間的折扣。 對於任何生產工作負載或具有穩定資源需求的開發/測試工作負載，您應考量購買保留執行個體。 在購買保留時，您必須指定下列維度：

    • 容量大小：保留可以是 10 TiB 或 100 TiB，購買更高容量的保留可享更顯著的折扣。 您可以購買多個保留，包括不同容量大小的保留，以滿足您的工作負載需求。 例如，如果您的生產部署有 120 TiB 的傳統檔案共用，您可以購買一個 100 TiB 預留容量和兩個 10 TiB 預留容量，以符合總儲存容量需求。
    • 期限：您可以購買一年或三年期的保留，購買較長保留期限的折扣更為顯著。
    • 階層：保留的 Azure 檔案儲存體階層。 目前已佈建 SSD v1 (進階版) 和 HDD 隨用隨付 (僅限經常性存取層和非經常性存取層) 計費模型可以使用保留。
    • 位置：保留的 Azure 區域。 保留可在 Azure 區域的子集中使用。
    • 冗餘：儲存空間的預留冗餘。 所有備援 Azure 檔案儲存體都支援保留，包括 LRS、ZRS、GRS 和 GZRS。
    • 計費頻率：指出帳戶對保留計費的頻率。 選項包括 每月 或 預付。

    購買保留之後，您現有的儲存體使用將會自動取用該保留量。 如果您使用的儲存空間多於您保留的儲存空間，則您需要為保留未涵蓋的餘額支付標價。 預約中不包含交易、頻寬、數據傳輸和中繼資料儲存的費用。

    針對隨用隨付和已佈建 v1 檔案共用，快照集和保留的運作方式會有所不同。 如果您要建立隨用隨付傳統檔案共用的快照集，則快照集差異會計入保留，並作為正常使用的儲存體計量一部分進行計費。 不過，如果您要建立已佈建 v1 傳統檔案共用的快照集，則快照集會使用個別的計量來計費，且不會計入保留。

    如需如何購買保留的詳細資訊，請參閱 Azure 檔案儲存體搭配保留的最優惠成本 (部分內容可能是機器或 AI 翻譯)。

    另請參閱

    • Last updated on