規劃 Azure 檔案服務部署Planning for an Azure Files deployment

Azure 檔案服務可提供在雲端中完全受控的檔案共用,可透過業界標準 SMB 通訊協定加以存取。Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard SMB protocol. 因為 Azure 檔案服務受到完整管理,所以部署於生產環境案例遠易於部署及管理檔案伺服器或 NAS 裝置。Because Azure Files is fully managed, deploying it in production scenarios is much easier than deploying and managing a file server or NAS device. 針對在組織中部署生產環境使用的 Azure 檔案共用,本文說明應考慮的主題。This article addresses the topics to consider when deploying an Azure file share for production use within your organization.

管理概念Management concepts

下圖說明 Azure 檔案服務管理建構:The following diagram illustrates the Azure Files management constructs:


  • 儲存體帳戶:所有對 Azure 儲存體的存取都是透過儲存體帳戶進行。Storage Account: All access to Azure Storage is done through a storage account. 如需關於儲存體帳戶容量的詳細資訊,請參閱延展性和效能目標See Scalability and Performance Targets for details about storage account capacity.

  • 共用:檔案儲存體共用是 Azure 中的 SMB 檔案共用。Share: A File Storage share is an SMB file share in Azure. 所有的目錄和檔案必須在上層共用中建立。All directories and files must be created in a parent share. 帳戶可以包含不限數目的共用,而共用可以儲存無限數量的檔案,最多可達檔案共用的總容量。An account can contain an unlimited number of shares and a share can store an unlimited number of files, up to the total capacity of the file share. 針對標準檔案共用,總容量為最多 5 TiB (GA)或 100 TiB (預覽),對於 premium 檔案共用,總容量為最高 100 TiB。For standard file shares, the total capacity is up to 5 TiB (GA) or 100 TiB (preview), for premium file shares, the total capacity is up to 100 TiB.

  • 目錄:選擇性的目錄階層。Directory: An optional hierarchy of directories.

  • 檔案:共用中的檔案。File: A file in the share. 檔案的大小可高達 1 TiB。A file may be up to 1 TiB in size.

  • URL 格式:若是透過檔案 REST 通訊協定以進行 Azure 檔案共用的要求,可以使用下列 URL 格式來定址檔案:URL format: For requests to an Azure file share made with the File REST protocol, files are addressable using the following URL format:

    https://<storage account>.file.core.windows.net/<share>/<directory>/<file>

資料存取方法Data access method

Azure 檔案服務提供兩種方便的內建資料存取方法,您可以個別或結合使用來存取資料:Azure Files offers two, built-in, convenient data access methods that you can use separately, or in combination with each other, to access your data:

  1. 雲端直接存取:利用業界標準伺服器訊息區 (SMB) 通訊協定或透過檔案 REST API,WindowsmacOS 及/或 Linux 可掛接任何 Azure 檔案共用。Direct cloud access: Any Azure file share can be mounted by Windows, macOS, and/or Linux with the industry standard Server Message Block (SMB) protocol or via the File REST API. 共用上的檔案藉由 SMB 讀取和寫入時,會直接在 Azure 中的檔案共用上進行。With SMB, reads and writes to files on the share are made directly on the file share in Azure. 若要由 Azure 中的 VM 掛接,作業系統中的 SMB 用戶端必須至少支援 SMB 2.1。To mount by a VM in Azure, the SMB client in the OS must support at least SMB 2.1. 若要掛接在內部 (例如使用者的工作站上),工作站所支援的 SMB 用戶端必須至少支援 SMB 3.0 (含加密)。To mount on-premises, such as on a user's workstation, the SMB client supported by the workstation must support at least SMB 3.0 (with encryption). 除了 SMB 之外,新的應用程式或服務可以透過檔案 REST 直接存取檔案共用,為軟體開發提供了方便且可擴充的應用程式開發介面。In addition to SMB, new applications or services may directly access the file share via File REST, which provides an easy and scalable application programming interface for software development.
  2. Azure 檔案同步:透過 Azure 檔案同步,您可以將共用複寫到內部部署或 Azure 中的 Windows Server。Azure File Sync: With Azure File Sync, shares can be replicated to Windows Servers on-premises or in Azure. 您的使用者可透過 Windows Server 存取檔案共用,像是透過 SMB 或 NFS 共用。Your users would access the file share through the Windows Server, such as through an SMB or NFS share. 這適用於從遠離 Azure 資料中心的位置 (例如分公司) 存取和修改資料的情況。This is useful for scenarios in which data will be accessed and modified far away from an Azure datacenter, such as in a branch office scenario. 資料可以在多個 Windows Server 端點之間複寫,例如多個分公司之間。Data may be replicated between multiple Windows Server endpoints, such as between multiple branch offices. 最後,資料可能會分層至 Azure 檔案服務,因此透過伺服器仍然可以存取所有資料,但伺服器並沒有資料的完整複本。Finally, data may be tiered to Azure Files, such that all data is still accessible via the Server, but the Server does not have a full copy of the data. 資料實際上是在使用者開啟時順暢地取回。Rather, data is seamlessly recalled when opened by your user.

下表說明使用者和應用程式如何存取您的 Azure 檔案共用:The following table illustrates how your users and applications can access your Azure file share:

雲端直接存取Direct cloud access Azure 檔案同步Azure File Sync
您需要使用哪些通訊協定?What protocols do you need to use? Azure 檔案服務支援 SMB 2.1、SMB 3.0 和檔案 REST API。Azure Files supports SMB 2.1, SMB 3.0, and File REST API. 透過 Windows Server 上任何支援的通訊協定 (SMB、NFS、FTPS 等) 存取您的 Azure 檔案共用Access your Azure file share via any supported protocol on Windows Server (SMB, NFS, FTPS, etc.)
您會在何處執行工作負載?Where are you running your workload? Azure 中:Azure 檔案服務提供對資料的直接存取。In Azure: Azure Files offers direct access to your data. 低速網路的內部部署:Windows、Linux 及 macOS 用戶端可掛接區域內部部署的 Windows 檔案共用,作為 Azure 檔案共用的快速快取。On-premises with slow network: Windows, Linux, and macOS clients can mount a local on-premises Windows File share as a fast cache of your Azure file share.
您需要何種 ACL 層級?What level of ACLs do you need? 共用和檔案層級。Share and file level. 共用、檔案和使用者層級。Share, file, and user level.

資料安全性Data security

Azure 檔案服務具有數個內建的選項,可用於確保資料安全性:Azure Files has several built-in options for ensuring data security:

  • 支援兩種網路通訊協定的加密:SMB 3.0 加密和經由 HTTPS 的檔案 REST。Support for encryption in both over-the-wire protocols: SMB 3.0 encryption and File REST over HTTPS. 依照預設:By default:

    • 支援 SMB 3.0 加密的用戶端會透過加密的通道傳送和接收資料。Clients that support SMB 3.0 encryption send and receive data over an encrypted channel.
    • 不支援 SMB 3.0 與加密的用戶端可以在資料中心內透過 SMB 2.1 或 SMB 3.0 進行通訊,而不需要加密。Clients that do not support SMB 3.0 with encryption can communicate intra-datacenter over SMB 2.1 or SMB 3.0 without encryption. 不允許 SMB 用戶端透過 SMB 2.1 或 SMB 3.0 進行無加密的資料中心之間通訊。SMB clients are not allowed to communicate inter-datacenter over SMB 2.1 or SMB 3.0 without encryption.
    • 用戶端可以藉由 HTTP 或 HTTPS 透過檔案 REST 進行通訊。Clients can communicate over File REST with either HTTP or HTTPS.
  • 待用資料加密 (Azure 儲存體服務加密):所有儲存體帳戶都會啟用儲存體服務加密 (SSE)。Encryption at-rest (Azure Storage Service Encryption): Storage Service Encryption (SSE) is enabled for all storage accounts. 靜止資料是使用完全受控金鑰加密。Data at-rest is encrypted with fully-managed keys. 待用加密不會增加儲存成本或降低效能。Encryption at-rest does not increase storage costs or reduce performance.

  • 傳輸中加密資料的選擇性需求:選取時,Azure 檔案儲存體拒絕透過未加密的通道存取資料。Optional requirement of encrypted data in-transit: when selected, Azure Files rejects access to the data over unencrypted channels. 具體來說,只允許具有加密連線的 HTTPS 和 SMB 3.0。Specifically, only HTTPS and SMB 3.0 with encryption connections are allowed.


    要求資料安全傳輸將導致舊版 SMB 用戶端通訊失敗,因為它無法與加密的 SMB 3.0 通訊。Requiring secure transfer of data will cause older SMB clients not capable of communicating with SMB 3.0 with encryption to fail. 如需詳細資訊,請參閱掛接在 Windows 上掛接在 Linux 上掛接在 macOS 上For more information, see Mount on Windows, Mount on Linux, and Mount on macOS.

為了有最高安全性,當您使用新式用戶端來存取資料時,強烈建議您一律啟用加密待用資料與加密傳輸資料。For maximum security, we strongly recommend always enabling both encryption at-rest and enabling encryption of data in-transit whenever you are using modern clients to access your data. 例如,如果您需要在僅支援 SMB 2.1 的 Windows Server 2008 R2 VM 上掛接共用,因為 SMB 2.1 不支持加密,因此儲存體帳戶必須允許未加密的流量。For example, if you need to mount a share on a Windows Server 2008 R2 VM, which only supports SMB 2.1, you need to allow unencrypted traffic to your storage account since SMB 2.1 does not support encryption.

如果您使用 Azure 檔案同步來存取 Azure 檔案共用,則無論是否需要對待用資料進行加密,我們一律會使用加密的 HTTPS 和 SMB 3.0 將資料同步處理至 Windows Server。If you are using Azure File Sync to access your Azure file share, we will always use HTTPS and SMB 3.0 with encryption to sync your data to your Windows Servers, regardless of whether you require encryption of data at-rest.

檔案共用效能層級File share performance tiers

Azure 檔案儲存體提供兩個效能層級: standard 和 premium。Azure Files offers two performance tiers: standard and premium.

標準檔案共用Standard file shares

標準檔案共用是由硬碟(Hdd)所支援。Standard file shares are backed by hard disk drives (HDDs). 標準檔案共用可針對效能變化較不敏感的 IO 工作負載提供可靠的效能,例如一般用途的檔案共用和開發/測試環境。Standard file shares provide reliable performance for IO workloads that are less sensitive to performance variability such as general-purpose file shares and dev/test environments. 標準檔案共用僅適用於隨用隨付計費模型。Standard file shares are only available in a pay-as-you-go billing model.

標準檔案共用的大小最多為 5 TiB,以 GA 供應專案的形式提供。Standard file shares up to 5 TiB in size are available as a GA offering. 雖然較大的檔案共用(也就是大於 5 TiB 的任何共用,最多 100 TiB)目前以預覽供應專案的形式提供。While larger file shares, which are any shares larger than 5 TiB, up to a maximum of 100 TiB, are currently available as a preview offering.


請參閱上架至較大的檔案共用(標準層)一節,以取得上架的步驟,以及預覽的範圍和限制。See the Onboard to larger file shares (standard tier) section for steps to onboard, as well as the scope and restrictions of the preview.

Premium 檔案共用Premium file shares

Premium 檔案共用是由固態硬碟(Ssd)支援。Premium file shares are backed by solid-state drives (SSDs). 高階檔案共用可針對 IO 密集型工作負載,在大部分 IO 作業的單一位數毫秒內,提供一致的高效能和低延遲。Premium file shares provide consistent high performance and low latency, within single-digit milliseconds for most IO operations, for IO-intensive workloads. 這讓它們適用于各種不同的工作負載,例如資料庫、網站裝載和開發環境。This makes them suitable for a wide variety of workloads like databases, web site hosting, and development environments. 進階檔案共用僅適用於佈建計費模型。Premium file shares are only available in a provisioned billing model. Premium 檔案共用會使用與標準檔案共用分開的部署模型。Premium file shares use a deployment model separate from standard file shares.

Azure 備份適用于 premium 檔案共用,Azure Kubernetes Service 支援1.13 版和更新版本中的高階檔案共用。Azure Backup is available for premium file shares and Azure Kubernetes Service supports premium file shares in version 1.13 and above.

如果您想要瞭解如何建立 premium 檔案共用,請參閱主題的文章:如何建立 Azure premium 檔案儲存體帳戶If you'd like to learn how to create a premium file share, see our article on the subject: How to create an Azure premium file storage account.

目前,您無法直接在標準檔案共用和 premium 檔案共用之間轉換。Currently, you cannot directly convert between a standard file share and a premium file share. 如果您想要切換至任一層,您必須在該階層中建立新的檔案共用,並手動將資料從原始共用複製到您建立的新共用。If you would like to switch to either tier, you must create a new file share in that tier and manually copy the data from your original share to the new share you created. 您可以使用任何 Azure 檔案儲存體支援的複製工具(例如 Robocopy 或 AzCopy)來執行這項操作。You can do this using any of the Azure Files supported copy tools, such as Robocopy or AzCopy.


在大部分區域中,提供儲存體帳戶和 ZRS 的高階檔案共用在較小的區域子集中,可供 LRS 使用。Premium file shares are available with LRS in most regions that offer storage accounts and with ZRS in a smaller subset of regions. 若要找出您的區域目前是否有 premium 檔案共用,請參閱 Azure 的依區域提供的產品頁面。To find out if premium file shares are currently available in your region, see the products available by region page for Azure. 若要瞭解哪些區域支援 ZRS,請參閱支援涵蓋範圍和區域可用性To find out what regions support ZRS, see Support coverage and regional availability.

為協助我們設定新區域和進階層功能的優先順序,請填寫這份問卷To help us prioritize new regions and premium tier features, please fill out this survey.

佈建共用Provisioned shares

進階檔案共用會以固定的 GiB/IOPS/輸送量比例為基礎佈建。Premium file shares are provisioned based on a fixed GiB/IOPS/throughput ratio. 對於每個佈建的 GiB,共用將會發出一個 IOPS 和 0.1 MiB/秒輸送量,直到每個共用的上限為止。For each GiB provisioned, the share will be issued one IOPS and 0.1 MiB/s throughput up to the max limits per share. 允許佈建的最小值為 100 GiB 與最小 IOPS/輸送量。The minimum allowed provisioning is 100 GiB with min IOPS/throughput.

在盡可能達成的基礎上,每個佈建之儲存體 Gib 的所有共用都可高載至最多三個 IOPS,並持續 60 分鐘或更久的時間 (視共用大小而定)。On a best effort basis, all shares can burst up to three IOPS per GiB of provisioned storage for 60 minutes or longer depending on the size of the share. 新的共用一開始有以佈建容量為基礎的完整高載額度。New shares start with the full burst credit based on the provisioned capacity.

共用必須以 1 GiB 遞增的方式布建。Shares must be provisioned in 1 GiB increments. 大小下限為 100 GiB,下一個大小為 101 GiB 等等。Minimum size is 100 GiB, next size is 101 GiB and so on.


基準 IOPS = 1 * 已布建的 GiB。Baseline IOPS = 1 * provisioned GiB. (最多 100000 IOPS)。(Up to a max of 100,000 IOPS).

高載限制 = 3 * 基準 IOPS。Burst Limit = 3 * Baseline IOPS. (最多 100000 IOPS)。(Up to a max of 100,000 IOPS).

輸出速率 = 60 MiB/秒 + 0.06 * 已布建的 GiBegress rate = 60 MiB/s + 0.06 * provisioned GiB

輸入速率 = 40 MiB/秒 + 0.04 * 已布建的 GiBingress rate = 40 MiB/s + 0.04 * provisioned GiB

布建的共用大小是由共用配額指定。Provisioned share size is specified by share quota. 共用配額可以隨時增加,但只能在上一次增加後的24小時內減少。Share quota can be increased at any time but can be decreased only after 24 hours since the last increase. 等待24小時後,如果沒有增加配額,您可以視需要多次減少共用配額,直到您再次增加為止。After waiting for 24 hours without a quota increase, you can decrease the share quota as many times as you like, until you increase it again. IOPS/輸送量調整變更將于大小變更後的幾分鐘內生效。IOPS/Throughput scale changes will be effective within a few minutes after the size change.

您可以將布建的共用大小減少到您使用的 GiB 下方。It is possible to decrease the size of your provisioned share below your used GiB. 如果您這樣做,您將不會遺失資料,但仍會向您收取所用大小的費用,並接收已布建共用的效能(基準 IOPS、輸送量和高載 IOPS),而不是使用的大小。If you do this, you will not lose data but, you will still be billed for the size used and receive the performance (baseline IOPS, throughput, and burst IOPS) of the provisioned share, not the size used.

下表說明這些 homebrew 公式針對布建共用大小所提供的幾個範例:The following table illustrates a few examples of these formulae for the provisioned share sizes:

容量(GiB)Capacity (GiB) 基準 IOPSBaseline IOPS 高載 IOPSBurst IOPS 輸出(MiB/秒)Egress (MiB/s) 輸入(MiB/秒)Ingress (MiB/s)
100100 100100 最多 300Up to 300 6666 4444
500500 500500 最多1500Up to 1,500 9090 6060
1,0241,024 1,0241,024 最多3072Up to 3,072 122122 8181
5,1205,120 5,1205,120 最多15360Up to 15,360 368368 245245
10,24010,240 10,24010,240 最多30720Up to 30,720 675675 450450
33,79233,792 33,79233,792 最多100000Up to 100,000 2,0882,088 1,3921,392
51,20051,200 51,20051,200 最多100000Up to 100,000 3,1323,132 2,0882,088
102,400102,400 100,000100,000 最多100000Up to 100,000 6,2046,204 4,1364,136


檔案共用效能受限於機器網路限制、可用的網路頻寬、IO 大小、平行處理,還有許多其他因素。File shares performance is subject to machine network limits, available network bandwidth, IO sizes, parallelism, among many other factors. 若要達到最大效能等級,請將負載分散到多個 Vm。To achieve maximum performance scale, spread the load across multiple VMs. 請參閱疑難排解指南,以瞭解一些常見的效能問題和因應措施。Please refer troubleshooting guide for some common performance issues and workarounds.


高階檔案共用可以將其 IOPS 高載至三倍。Premium file shares can burst their IOPS up to a factor of three. 高載會自動化,並根據信用系統運作。Bursting is automated and operates based on a credit system. 高載會以最大的方式運作,而且高載限制並不保證,檔案共用最多可達限制。Bursting works on a best effort basis and the burst limit is not a guarantee, file shares can burst up to the limit.

當您檔案共用的流量低於基準 IOPS 時,點數會累積在高載值區中。Credits accumulate in a burst bucket whenever traffic for your file share is below baseline IOPS. 例如,100 GiB 共用具有100基準 IOPS。For example, a 100 GiB share has 100 baseline IOPS. 如果共用上的實際流量為特定1秒間隔的 40 IOPS,則會將60未使用的 IOPS 貸到高載值區。If actual traffic on the share was 40 IOPS for a specific 1-second interval, then the 60 unused IOPS are credited to a burst bucket. 之後,當作業會超過基準 IOPs 時,就會使用這些信用額度。These credits will then be used later when operations would exceed the baseline IOPs.


高載 bucket 的大小 = 基準 IOPS * 2 * 3600。Size of the burst bucket = Baseline IOPS * 2 * 3600.

每當共用超過基準 IOPS,而且在高載 bucket 中有信用額度時,就會進行高載。Whenever a share exceeds the baseline IOPS and has credits in a burst bucket, it will burst. 只要剩餘信用額度,共用就可以繼續高載,但是小於 50 TiB 的共用則只會保持高載限制達一小時。Shares can continue to burst as long as credits are remaining, though shares smaller than 50 TiB will only stay at the burst limit for up to an hour. 在技術上,大於 50 TiB 的共用可能會超過此一小時的限制,最多兩個小時,但這是根據所累積的高載點數數目。Shares larger than 50 TiB can technically exceed this one hour limit, up to two hours but, this is based on the number of burst credits accrued. 除了基準 IOPS 以外的每個 IO 都會取用一個點數,一旦取用所有信用額度,該共用就會回到基準 IOPS。Each IO beyond baseline IOPS consumes one credit and once all credits are consumed the share would return to baseline IOPS.

共用信用額度有三種狀態:Share credits have three states:

  • 當檔案共用使用低於基準 IOPS 時產生。Accruing, when the file share is using less than the baseline IOPS.
  • 在檔案共用進行高載時拒絕。Declining, when the file share is bursting.
  • 當沒有任何點數或基準 IOPS 正在使用時,剩餘的常數。Remaining constant, when there are either no credits or baseline IOPS are in use.

新的檔案共用會從其高載值區中的完整點數開始。New file shares start with the full number of credits in its burst bucket. 如果由於伺服器進行節流,所以共用 IOPS 低於基準 IOPS 時,將不會產生高載點數。Burst credits will not be accrued if the share IOPS fall below baseline IOPS due to throttling by the server.

檔案共用備援File share redundancy

Azure 檔案儲存體標準共用支援四個數據冗余選項:本機冗余儲存體(LRS)、區域冗余儲存體(ZRS)、異地多餘儲存體(GRS)和異地區域冗余儲存體(切換)(預覽)。Azure Files standard shares supports four data redundancy options: locally redundant storage (LRS), zone redundant storage (ZRS), geo-redundant storage (GRS), and geo-zone-redundant storage (GZRS) (preview).

Azure 檔案儲存體 premium 共用同時支援 LRS 和 ZRS,但 ZRS 目前可用於較小的區域子集。Azure Files premium shares support both LRS and ZRS, ZRS is currently available in a smaller subset of regions.

下列各節說明不同備援選項之間的差異:The following sections describe the differences between the different redundancy options:

本地備援儲存體Locally redundant storage

本機多餘儲存體(LRS)會在單一資料中心內複寫您的資料三次。Locally redundant storage (LRS) replicates your data three times within a single data center. LRS 在指定的一年內提供至少 99.999999999% (11個9)的物件持久性。LRS provides at least 99.999999999% (11 nines) durability of objects over a given year. 相較於其他選項,LRS 是成本最低的複寫選項,而且提供的持久性最弱。LRS is the lowest-cost replication option and offers the least durability compared to other options.

如果發生資料中心層級的嚴重損壞(例如,火災或水災),則使用 LRS 的儲存體帳戶中的所有複本可能會遺失或無法復原。If a datacenter-level disaster (for example, fire or flooding) occurs, all replicas in a storage account using LRS may be lost or unrecoverable. 為了降低此風險,Microsoft 建議使用區域冗余儲存體(ZRS)、異地多餘儲存體(GRS)或異地區域冗余儲存體(切換)。To mitigate this risk, Microsoft recommends using zone-redundant storage (ZRS), geo-redundant storage (GRS), or geo-zone-redundant storage (GZRS).

只有在將資料寫入所有三個複本之後,才會成功傳回 LRS 儲存體帳戶的寫入要求。A write request to an LRS storage account returns successfully only after the data is written to all three replicas.

在下列案例中,您可能會想要使用 LRS:You may wish to use LRS in the following scenarios:

  • 如果您的應用程式儲存的資料,可在發生資料遺失時輕鬆重新建構,則您可以選擇使用 LRS。If your application stores data that can be easily reconstructed if data loss occurs, you may opt for LRS.
  • 由於資料控管需求,某些應用程式僅限於在國家/地區內複寫資料。Some applications are restricted to replicating data only within a country/region due to data governance requirements. 在某些情況下,針對 GRS 帳戶複寫資料的配對區域可能位於另一個國家/地區。In some cases, the paired regions across which the data is replicated for GRS accounts may be in another country/region. 如需配對區域的詳細資訊,請參閱 Azure 區域For more information on paired regions, see Azure regions.

區域備援儲存體Zone redundant storage

區域備援儲存體 (ZRS) 會以同步方式,將您的資料複寫到單一區域中的三個儲存體叢集。Zone-redundant storage (ZRS) replicates your data synchronously across three storage clusters in a single region. 每個儲存體叢集實際上都與其他叢集分隔且位在自己的可用性區域 (AZ) 中。Each storage cluster is physically separated from the others and is located in its own availability zone (AZ). 每個可用性區域—及其中的 ZRS 叢集—都是自發的,且包含個別的工具和網路功能。Each availability zone—and the ZRS cluster within it—is autonomous and includes separate utilities and networking features. 只有在將資料寫入至三個叢集的所有複本之後,才會成功傳回 ZRS 儲存體帳戶的寫入要求。A write request to a ZRS storage account returns successfully only after the data is written to all replicas across the three clusters.

當您使用 ZRS 複寫將資料儲存在儲存體帳戶中時,如果有可用性區域變得無法使用,您仍然可以繼續存取和管理您的資料。When you store your data in a storage account using ZRS replication, you can continue to access and manage your data if an availability zone becomes unavailable. ZRS 的效能優異且延遲性低。ZRS provides excellent performance and low latency. ZRS 提供與本地備援儲存體 (LRS) 相同的延展性目標ZRS offers the same scalability targets as locally redundant storage (LRS).

針對需要一致性、耐久性和高可用性的案例,請考慮使用 ZRS。Consider ZRS for scenarios that require consistency, durability, and high availability. 在給定的一年中,即使發生中斷或自然災害使可用性區域變得無法取得,ZRS 仍提供至少 99.9999999999% (12 個 9) 的儲存體物件耐久性。Even if an outage or natural disaster renders an availability zone unavailable, ZRS offers durability for storage objects of at least 99.9999999999% (12 9's) over a given year.

異地區域冗余儲存體(切換)(預覽)會在主要區域中的三個 Azure 可用性區域之間同步複寫您的資料,然後以非同步方式將資料複寫至次要區域。Geo-zone-redundant storage (GZRS) (preview) replicates your data synchronously across three Azure availability zones in the primary region, then replicates the data asynchronously to the secondary region. 切換提供高可用性以及最大持久性。GZRS provides high availability together with maximum durability. 切換的設計目的是要在指定的一年內提供至少 99.99999999999999% (16個9)的物件持久性。GZRS is designed to provide at least 99.99999999999999% (16 9's) durability of objects over a given year. 如需次要區域中資料的讀取權限,請啟用讀取權限異地區域-多餘儲存體(RA-切換)。For read access to data in the secondary region, enable read-access geo-zone-redundant storage (RA-GZRS). 如需切換的詳細資訊,請參閱高可用性和最大持久性(預覽)的異地區域冗余儲存體For more information about GZRS, see Geo-zone-redundant storage for highly availability and maximum durability (preview).

如需可用性區域的詳細資訊,請參閱可用性區域概觀For more information about availability zones, see Availability Zones overview.

異地備援儲存體Geo-redundant storage


若您使用 Azure 檔案共用作為 GRS 儲存體帳戶中的雲端端點,您不應該啟動儲存體帳戶的容錯移轉。If you are using your Azure file share as a cloud endpoint in a GRS storage account, you shouldn't initiate storage account failover. 這麼做將導致同步停止運作,且可能會在新分層的檔案中產生未預期的資料遺失。Doing so will cause sync to stop working and may also cause unexpected data loss in the case of newly tiered files. 若發生 Azure 區域遺失,Microsoft 將會觸發與 Azure 檔案同步相容的儲存體帳戶容錯移轉。In the case of loss of an Azure region, Microsoft will trigger the storage account failover in a way that is compatible with Azure File Sync.

異地備援儲存體 (GRS) 設計為將您的資料複寫到與主要區域相隔數百英哩遠的次要區域,以在指定年份為物件提供至少 99.99999999999999% (16 9's) 的持久性。Geo-redundant storage (GRS) is designed to provide at least 99.99999999999999% (16 9's) durability of objects over a given year by replicating your data to a secondary region that is hundreds of miles away from the primary region. 如果您的儲存體帳戶已啟用 GRS,即使主要區域發生全區中斷或災害而無法復原的情況,您的資料仍會是永久性。If your storage account has GRS enabled, then your data is durable even in the case of a complete regional outage or a disaster in which the primary region isn't recoverable.

如果您選擇讀取權限異地多餘儲存體(RA-GRS),您應該知道 Azure 檔案目前不支援任何區域中的讀取權限異地多餘儲存體(RA-GRS)。If you opt for read-access geo-redundant storage (RA-GRS), you should know that Azure File does not support read-access geo-redundant storage (RA-GRS) in any region at this time. GRS 儲存體帳戶中的檔案共用的工作方式與在 GRS 帳戶中一樣,而且會以 GRS 價格收費。File shares in the RA-GRS storage account work like they would in GRS accounts and are charged GRS prices.

GRS 會將您的資料複寫到次要區域中的另一個資料中心,但如果 Microsoft 起始從主要到次要區域的容錯移轉,該資料則為唯讀。GRS replicates your data to another data center in a secondary region, but that data is available to be read only if Microsoft initiates a failover from the primary to secondary region.

若儲存體帳戶已啟用 GRS,則會先使用本機多餘的儲存體(LRS)複寫所有資料。For a storage account with GRS enabled, all data is first replicated with locally redundant storage (LRS). 更新會先認可到主要位置,並使用 LRS 進行複寫。An update is first committed to the primary location and replicated using LRS. 接著會使用 GRS,以非同步的方式將更新複寫到次要區域。The update is then replicated asynchronously to the secondary region using GRS. 當資料寫入次要位置時,也會使用 LRS 在該位置中複寫。When data is written to the secondary location, it's also replicated within that location using LRS.

主要和次要區域會管理分散在儲存體縮放單位內不同容錯網域和升級網域之間的複本。Both the primary and secondary regions manage replicas across separate fault domains and upgrade domains within a storage scale unit. 儲存體縮放單位是資料中心內的基本複寫單位。The storage scale unit is the basic replication unit within the datacenter. 此層級的複寫是由 LRS 所提供;如需詳細資訊,請參閱 @no__t 0Locally 的多餘儲存體(LRS):適用於 Azure 儲存體的低成本資料備援](../common/storage-redundancy-lrs.md)。Replication at this level is provided by LRS; for more information, see Locally redundant storage (LRS): Low-cost data redundancy for Azure Storage.

當您決定要使用的複寫選項時,請記住下列幾點:Keep these points in mind when deciding which replication option to use:

  • 異地區域冗余儲存體(切換)(預覽)會以同步方式將資料複寫到三個 Azure 可用性區域,並以非同步方式將資料複寫到次要區域,藉此提供高可用性和最大耐久性。Geo-zone-redundant storage (GZRS) (preview) provides high availability together with maximum durability by replicating data synchronously across three Azure availability zones and then replicating data asynchronously to the secondary region. 您也可以啟用次要區域的讀取權限。You can also enable read access to the secondary region. 切換的設計目的是要在指定的一年內提供至少 99.99999999999999% (16個9)的物件持久性。GZRS is designed to provide at least 99.99999999999999% (16 9's) durability of objects over a given year. 如需切換的詳細資訊,請參閱高可用性和最大持久性(預覽)的異地區域冗余儲存體For more information on GZRS, see Geo-zone-redundant storage for highly availability and maximum durability (preview).
  • 區域冗余儲存體(ZRS)提供同步複寫的高可用性,而且在某些情況下可能是比 GRS 更好的選擇。Zone-redundant storage (ZRS) provides highly availability with synchronous replication and may be a better choice for some scenarios than GRS. 如需有關 ZRS 的詳細資訊,請參閱 ZRSFor more information on ZRS, see ZRS.
  • 非同步複寫會涉及從將資料寫入主要區域,到將資料複寫至次要區域這段時間的延遲。Asynchronous replication involves a delay from the time that data is written to the primary region, to when it is replicated to the secondary region. 當發生區域性災害時,如果無法從主要區域復原尚未複寫到次要區域的變更,則這些變更可能會遺失。In the event of a regional disaster, changes that haven't yet been replicated to the secondary region may be lost if that data can't be recovered from the primary region.
  • 使用 GRS 時,複本不提供讀取或寫入存取,除非 Microsoft 起始對次要區域的容錯移轉。With GRS, the replica isn't available for read or write access unless Microsoft initiates a failover to the secondary region. 在容錯移轉的情況下,當容錯移轉完成時,您會有該資料的讀取和寫入存取權。In the case of a failover, you'll have read and write access to that data after the failover has completed. 如需詳細資訊,請參閱災害復原指導方針For more information, please see Disaster recovery guidance.

上架至較大的檔案共用(標準層)Onboard to larger file shares (standard tier)

本節僅適用于標準檔案共用。This section only applies to the standard file shares. 所有 premium 檔案共用都隨附于 100 TiB,作為 GA 供應專案。All premium file shares are available with 100 TiB as a GA offering.


  • 在預覽期間,Azure 預覽條款適用于大型檔案共用,包括搭配 Azure 檔案同步部署使用時。Azure preview terms apply to large file shares while in preview including when used with Azure File Sync deployments.
  • 要求您建立新的一般用途儲存體帳戶(無法展開現有的儲存體帳戶)。Requires you to create a new general purpose storage account (cannot expand existing storage accounts).
  • 將訂用帳戶接受至較大的檔案共用預覽之後,所建立的任何新儲存體帳戶,都無法進行 LRS/ZRS to GRS/切換 account 轉換。LRS/ZRS to GRS/GZRS account conversion will not be possible on any new storage account created after the subscription is accepted to the larger file shares preview.

區域可用性Regional availability

標準檔案共用適用于最多 5 TiB 的所有區域。Standard file shares are available in all regions up to 5 TiB. 在特定區域中,有 100 TiB 限制可用,這些區域會列在下表中:In certain regions, it is available with a 100 TiB limit, those regions are listed in the following table:

區域Region 支援的冗余Supported redundancy 支援現有的儲存體帳戶Supports existing storage accounts 入口網站支援 *Portal support*
澳洲東部Australia East LRSLRS No Yes
澳大利亞東南部Australia Southeast LRSLRS No Yes
印度中部Central India LRSLRS No Yes
東亞East Asia LRSLRS No Yes
East USEast US LRSLRS No Yes
法國中部France Central LRS、ZRSLRS, ZRS No Yes
法國南部France South LRSLRS No Yes
北歐North Europe LRSLRS No 尚未提供Not yet
印度南部South India LRSLRS No Yes
東南亞Southeast Asia LRS、ZRSLRS, ZRS No Yes
美國中西部West Central US LRSLRS No Yes
西歐West Europe LRS、ZRSLRS, ZRS No Yes
美國西部West US LRSLRS No Yes
美國西部 2West US 2 LRS、ZRSLRS, ZRS No Yes

* 對於沒有入口網站支援的區域,您仍然可以使用 PowerShell 或 Azure 命令列介面(CLI)來建立大於5個 TiB 的共用。*For regions without portal support, you can still use PowerShell or Azure Command Line Interface (CLI) to create larger than 5 TiB shares. 或者,透過入口網站建立新的共用,而不指定配額。Alternatively, create a new share via portal without specifying quota. 這會建立預設大小為 100 TiB 的共用,稍後可透過 PowerShell 或 Azure CLI 進行更新。This will create a share with default size of 100 TiB, that can up updated later via PowerShell or Azure CLI.

為協助我們設定新區域和功能的優先順序,請填寫這份問卷To help us prioritize new regions and features, please fill out this survey.

上架的步驟Steps to onboard

若要將您的訂用帳戶註冊到較大的檔案共用預覽,您需要使用 Azure PowerShell。To enroll your subscription to the larger file shares preview, you need to use Azure PowerShell. 您可以使用Azure Cloud Shell或在本機安裝Azure PowerShell 模組來執行下列 PowerShell 命令:You can either use Azure Cloud Shell or install the Azure PowerShell module locally to run the following PowerShell commands:

首先,請確定已選取您要在預覽版中註冊的訂用帳戶:First, make sure the subscription you want to enroll in the preview is selected:

$context = Get-AzSubscription -SubscriptionId ...
Set-AzContext $context

然後,使用下列命令註冊預覽版:Then, enroll in the preview using the following commands:

Register-AzProviderFeature -FeatureName AllowLargeFileShares -ProviderNamespace Microsoft.Storage
Register-AzResourceProvider -ProviderNamespace Microsoft.Storage

這兩個命令都執行後,您的訂用帳戶會自動核准。Your subscription is automatically approved once both commands are run.

若要確認您的註冊狀態,您可以執行下列命令:To verify your registration status, you can run the following command:

Get-AzProviderFeature -FeatureName AllowLargeFileShares -ProviderNamespace Microsoft.Storage

最多可能需要15分鐘的時間,您的狀態才會更新為 [已註冊]。It may take up to 15 minutes for your status to update to registered. 註冊狀態之後,您應該能夠使用此功能。Once your status is registered, you should be able to use the feature.

使用較大的檔案共用Use larger file shares

若要開始使用較大的檔案共用,請建立新的一般用途 v2 儲存體帳戶和新的檔案共用。To begin using larger file shares, create a new general purpose v2 storage account and a new file share.

資料成長模式Data growth pattern

目前,Azure 檔案共用的大小上限為 5 TiB (100 TiB 為預覽狀態)。Today, the maximum size for an Azure file share is 5 TiB (100 TiB in preview). 由於目前的此一限制,當您在部署 Azure 檔案共用時,必須考量預期的資料成長。Because of this current limitation, you must consider the expected data growth when deploying an Azure file share.

使用 Azure 檔案同步可以將多個 Azure 檔案共用同步處理到單一 Windows 檔案伺服器。這可確保內部部署上較舊的大型檔案共用可以帶入 Azure 檔案同步。如需詳細資訊,請參閱規劃 Azure 檔案同步部署It is possible to sync multiple Azure file shares to a single Windows File Server with Azure File Sync. This allows you to ensure that older, large file shares that you may have on-premises can be brought into Azure File Sync. For more information, see Planning for an Azure File Sync Deployment.

資料傳輸方法Data transfer method

有許多簡單的選項可從現有檔案共用 (例如內部部署檔案共用) 大量傳輸資料到 Azure 檔案服務。There are many easy options to bulk transfer data from an existing file share, such as an on-premises file share, into Azure Files. 部分常用方法包括 (非完整清單):A few popular ones include (non-exhaustive list):

  • Azure 檔案同步:在 Azure 檔案共用 (雲端端點) 和 Windows 目錄命名空間 (伺服器端點) 之間的初次同步處理中,Azure 檔案同步會從現有檔案共用將所有資料複寫至 Azure 檔案服務。Azure File Sync: As part of a first sync between an Azure file share (a "Cloud Endpoint") and a Windows directory namespace (a "Server Endpoint"), Azure File Sync will replicate all data from the existing file share to Azure Files.
  • Azure 匯入/匯出 :您可將硬碟寄送至 Azure 資料中心,透過 Azure 匯入/匯出服務,安全地將大量資料傳送至 Azure 檔案共用。Azure Import/Export: The Azure Import/Export service allows you to securely transfer large amounts of data into an Azure file share by shipping hard disk drives to an Azure datacenter.
  • Robocopy :Robocopy 是隨附於 Windows 和 Windows Server 的常用複製工具。Robocopy: Robocopy is a well known copy tool that ships with Windows and Windows Server. Robocopy 可在本機掛接檔案共用,然後將掛接位置作為 Robocopy 命令中的目的地使用,以將資料傳輸到 Azure 檔案服務中。Robocopy may be used to transfer data into Azure Files by mounting the file share locally, and then using the mounted location as the destination in the Robocopy command.
  • AzCopy :AzCopy 是一種命令列公用程式,專為使用簡單命令高效率地在 Azure 檔案服務及 Azure Blob 儲存體之間複製資料所設計。AzCopy: AzCopy is a command-line utility designed for copying data to and from Azure Files, as well as Azure Blob storage, using simple commands with optimal performance.

後續步驟Next steps