规划 Azure 文件部署Planning for an Azure Files deployment

可通过以下主要方式部署 Azure 文件存储:直接装载无服务器 Azure 文件共享。Azure Files can be deployed in a main way: by directly mounting the serverless Azure file shares.

直接装载 Azure 文件共享:由于 Azure 文件存储提供 SMB 访问,因此你可以使用 Windows、macOS 和 Linux 中提供的标准 SMB 客户端在本地或云中装载 Azure 文件共享。Direct mount of an Azure file share: Since Azure Files provides SMB access, you can mount Azure file shares on-premises or in the cloud using the standard SMB client available in Windows, macOS, and Linux. 由于 Azure 文件共享是无服务器的,因此针对生产方案进行部署不需要管理文件服务器或 NAS 设备。Because Azure file shares are serverless, deploying for production scenarios does not require managing a file server or NAS device. 这意味着,无需应用软件修补程序或交换物理磁盘。This means you don't have to apply software patches or swap out physical disks.

本文主要阐述有关部署可供本地或云客户端直接装载的 Azure 文件共享时的部署注意事项。This article primarily addresses deployment considerations for deploying an Azure file share to be directly mounted by an on-premises or cloud client.

管理概念Management concepts

Azure 文件共享将部署到存储帐户。存储帐户是代表存储共享池的顶级对象。 Azure file shares are deployed into storage accounts, which are top-level objects that represent a shared pool of storage. 此存储池可用于部署多个文件共享和其他存储资源,例如 Blob 容器、队列或表。This pool of storage can be used to deploy multiple file shares, as well as other storage resources such as blob containers, queues, or tables. 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。All storage resources that are deployed into a storage account share the limits that apply to that storage account. 若要查看存储帐户的当前限制,请参阅 Azure 文件存储的可伸缩性和性能目标To see the current limits for a storage account, see Azure Files scalability and performance targets.

对于 Azure 文件存储部署,将使用主要类型的存储帐户:常规用途版本 2 (GPv2) 存储帐户:使用 GPv2 存储帐户可以在标准的/基于硬盘(基于 HDD)的硬件上部署 Azure 文件共享。There are a main type of storage accounts you will use for Azure Files deployments: General purpose version 2 (GPv2) storage accounts: GPv2 storage accounts allow you to deploy Azure file shares on standard/hard disk-based (HDD-based) hardware. 除了存储 Azure 文件共享以外,GPv2 存储帐户还可以存储其他存储资源,例如 Blob 容器、队列或表。In addition to storing Azure file shares, GPv2 storage accounts can store other storage resources such as blob containers, queues, or tables.

在 Azure 门户、PowerShell 或 CLI 中,可能会遇到一些其他的存储帐户类型。There are several other storage account types you may come across in the Azure portal, PowerShell, or CLI. 一个存储帐户类型(BlobStorage 存储帐户)不能包含 Azure 文件共享。One storage account type, BlobStorage storage accounts, cannot contain Azure file shares. 可能会看到的其他两个存储帐户类型为常规用途版本 1 (GPv1) 和经典存储帐户,二者都可以包含 Azure 文件共享。The other two storage account types you may see are general purpose version 1 (GPv1) and classic storage accounts, both of which can contain Azure file shares. 尽管 GPv1 和经典存储帐户可以包含 Azure 文件共享,但 Azure 文件存储的大多数新功能只能在 GPv2 和 FileStorage 存储帐户中使用。Although GPv1 and classic storage accounts may contain Azure file shares, most new features of Azure Files are available only in GPv2 and FileStorage storage accounts. 因此,我们建议仅将 GPv2 存储帐户用于新部署,而升级 GPv1 和经典存储帐户的前提是它们已经存在于环境中。We therefore recommend to only use GPv2 storage accounts for new deployments, and to upgrade GPv1 and classic storage accounts if they already exist in your environment.

将 Azure 文件共享部署到存储帐户时,我们建议:When deploying Azure file shares into storage accounts, we recommend:

  • 仅将 Azure 文件共享部署到已包含其他 Azure 文件共享的存储帐户。Only deploying Azure file shares into storage accounts with other Azure file shares. 尽管 GPv2 存储帐户允许使用混合用途的存储帐户,但由于 Azure 文件共享和 Blob 容器等存储资源共享存储帐户的限制,因此,将资源混合在一起可能会导致将来更难以排查性能问题。Although GPv2 storage accounts allow you to have mixed purpose storage accounts, since storage resources such as Azure file shares and blob containers share the storage account's limits, mixing resources together may make it more difficult to troubleshoot performance issues later on.

  • 部署 Azure 文件共享时请注意存储帐户的 IOPS 限制。Paying attention to a storage account's IOPS limitations when deploying Azure file shares. 理想情况下,应该以 1:1 的形式将文件共享与存储帐户相映射,但由于组织和 Azure 施加的各种限制和制约,不一定总能实现这种映射。Ideally, you would map file shares 1:1 with storage accounts, however this may not always be possible due to various limits and restrictions, both from your organization and from Azure. 无法在一个存储帐户中部署一个文件共享时,请考虑哪些共享高度活跃,哪些共享不够活跃,以确保不会将访问量最大的文件共享一起放到同一存储帐户中。When it is not possible to have only one file share deployed in one storage account, consider which shares will be highly active and which shares will be less active to ensure that the hottest file shares don't get put in the same storage account together.

  • 仅部署 GPv2 帐户和 FileStorage 帐户,在环境中找到 GPv1 帐户和经典存储帐户时对其进行升级。Only deploy GPv2 and FileStorage accounts and upgrade GPv1 and classic storage accounts when you find them in your environment.

标识Identity

若要访问某个 Azure 文件共享,该文件共享的用户必须完成身份验证,并已获得授权。To access an Azure file share, the user of the file share must be authenticated and have authorization to access the share. 这种授权是根据访问文件共享的用户的标识完成的。This is done based on the identity of the user accessing the file share. 使用 Azure 存储帐户密钥装载 Azure 文件共享。Azure file shares is mounted with an Azure storage account key. 若要以这种方式装载文件共享,需使用存储帐户名称作为用户名,使用存储帐户密钥作为密码。To mount a file share this way, the storage account name is used as the username and the storage account key is used as a password. 使用存储帐户密钥装载 Azure 文件共享实际上是一项管理员操作,因为装载的文件共享对其上的所有文件和文件夹拥有完全权限,即使对这些文件和文件夹应用了 ACL。Using the storage account key to mount the Azure file share is effectively an administrator operation, since the mounted file share will have full permissions to all of the files and folders on the share, even if they have ACLs. 使用存储帐户密钥通过 SMB 装载时,将使用 NTLMv2 身份验证协议。When using the storage account key to mount over SMB, the NTLMv2 authentication protocol is used.

我们建议根据网络部分中所述使用服务终结点。We recommend using service endpoints as described in the Networking section.

网络Networking

可在任意位置通过存储帐户的公共终结点访问 Azure 文件共享。Azure file shares are accessible from anywhere via the storage account's public endpoint. 这意味着,已经过身份验证的请求(例如已由用户登录标识授权的请求)可以安全地从 Azure 内部或外部发起。This means that authenticated requests, such as requests authorized by a user's logon identity, can originate securely from inside or outside of Azure. 在许多客户环境中,最初在本地工作站上装载 Azure 文件共享的操作会失败,尽管可以成功地从 Azure VM 装载。In many customer environments, an initial mount of the Azure file share on your on-premises workstation will fail, even though mounts from Azure VMs succeed. 其原因是,许多组织和 Internet 服务提供商 (ISP) 阻止 SMB 用来通信的端口 445。The reason for this is that many organizations and internet service providers (ISPs) block the port that SMB uses to communicate, port 445. 如需大致了解允许或禁止从端口 445 进行访问的 ISP,请访问 TechNetTo see the summary of ISPs that allow or disallow access from port 445, go to TechNet.

若要取消阻止对 Azure 文件共享的访问,可以采用两种做法:To unblock access to your Azure file share, you have two main options:

  • 对组织的本地网络取消阻止端口 445。Unblock port 445 for your organization's on-premises network. 在外部,只能使用 Internet 安全协议(例如 SMB 3.0 和 FileREST API)通过公共终结点访问 Azure 文件共享。Azure file shares may only be externally accessed via the public endpoint using internet safe protocols such as SMB 3.0 and the FileREST API. 这是从本地访问 Azure 文件共享的最简单方法,因为它不需要进行高级网络配置,而只需更改组织的出站端口规则;但是,我们建议删除传统的已弃用版本的 SMB 协议,即 SMB 1.0。This is the easiest way to access your Azure file share from on-premises since it doesn't require advanced networking configuration beyond changing your organization's outbound port rules, however, we recommend you remove legacy and deprecated versions of the SMB protocol, namely SMB 1.0. 若要了解如何执行此操作,请参阅保护 Windows/Windows Server保护 LinuxTo learn how to do this, see Securing Windows/Windows Server and Securing Linux.

  • 通过 ExpressRoute 或 VPN 连接访问 Azure 文件共享。Access Azure file shares over an ExpressRoute or VPN connection. 通过网络隧道访问 Azure 文件共享时,可以像装载本地文件共享一样装载 Azure 文件共享,因为 SMB 流量不会通过组织边界。When you access your Azure file share via a network tunnel, you are able to mount your Azure file share like an on-premises file share since SMB traffic does not traverse your organizational boundary.

尽管从技术角度讲,通过公共终结点装载 Azure 文件共享要容易得多,但我们预期大多数客户会选择通过 ExpressRoute 或 VPN 连接装载其 Azure 文件共享。Although from a technical perspective it's considerably easier to mount your Azure file shares via the public endpoint, we expect most customers will opt to mount their Azure file shares over an ExpressRoute or VPN connection. 为此,需要为环境配置以下设置:To do this, you will need to configure the following for your environment:

  • 使用 ExpressRoute、站点到站点或点到站点 VPN 的网络隧道:通过隧道连接到虚拟网络后,即使端口 445 已被阻止,也能从本地访问 Azure 文件共享。Network tunneling using ExpressRoute, Site-to-Site, or Point-to-Site VPN: Tunneling into a virtual network allows accessing Azure file shares from on-premises, even if port 445 is blocked.
  • DNS 转发:配置本地 DNS,以将存储帐户的名称(例如 storageaccount.file.core.chinacloudapi.cn)解析为专用终结点的 IP 地址。DNS forwarding: Configure your on-premises DNS to resolve the name of your storage account (i.e. storageaccount.file.core.chinacloudapi.cn) to resolve to the IP address of your private endpoints.

若要规划与 Azure 文件共享部署相关的网络,请参阅 Azure 文件存储网络注意事项To plan for the networking associated with deploying an Azure file share, see Azure Files networking considerations.

EncryptionEncryption

Azure 文件存储支持两种不同类型的加密:传输中加密(与装载/访问 Azure 文件共享时使用的加密相关),以及静态加密(与存储在磁盘中的数据的加密方式相关)。Azure Files supports two different types of encryption: encryption in transit, which relates to the encryption used when mounting/accessing the Azure file share, and encryption at rest, which relates to how the data is encrypted when it is stored on disk.

传输中加密Encryption in transit

默认情况下,所有 Azure 存储帐户均已启用传输中加密。By default, all Azure storage accounts have encryption in transit enabled. 即通过 SMB 装载文件共享或通过 FileREST 协议(例如,通过 Azure门户、PowerShell/CLI 或 Azure SDK)访问文件共享时,Azure 文件存储仅允许通过加密或 HTTPS 使用 SMB 3.0 及更高版本建立的连接。This means that when you mount a file share over SMB or access it via the FileREST protocol (such as through the Azure portal, PowerShell/CLI, or Azure SDKs), Azure Files will only allow the connection if it is made with SMB 3.0+ with encryption or HTTPS. 如果启用了传输中加密,则不支持 SMB 3.0 的客户端或支持 SMB 3.0 但不支持 SMB 加密的客户端将无法装载 Azure 文件共享。Clients that do not support SMB 3.0 or clients that support SMB 3.0 but not SMB encryption will not be able to mount the Azure file share if encryption in transit is enabled. 要详细了解哪些操作系统支持具有加密功能的 SMB 3.0,请参阅适用于 WindowsmacOSLinux 的详细文档。For more information about which operating systems support SMB 3.0 with encryption, see our detailed documentation for Windows, macOS, and Linux. PowerShell、CLI 和 SDK 的所有当前版本均支持 HTTPS。All current versions of the PowerShell, CLI, and SDKs support HTTPS.

可以为 Azure 存储帐户禁用传输中加密。You can disable encryption in transit for an Azure storage account. 禁用加密后,Azure 文件存储还将允许没有加密功能的 SMB 2.1、SMB 3.0,以及通过 HTTP 进行的未加密 FileREST API 调用。When encryption is disabled, Azure Files will also allow SMB 2.1, SMB 3.0 without encryption, and unencrypted FileREST API calls over HTTP. 禁用传输中加密的主要原因是为了支持必须在更低版本的操作系统(例如,Windows Server 2008 R2 或更低版本的 Linux 发行版)上运行的旧版应用程序。The primary reason to disable encryption in transit is to support a legacy application that must be run on an older operating system, such as Windows Server 2008 R2 or older Linux distribution. Azure 文件存储仅允许在与 Azure 文件共享相同的 Azure 区域内建立 SMB 2.1 连接;Azure 文件共享的 Azure 区域之外的 SMB 2.1 客户端(例如,本地或其他 Azure 区域)将无法访问文件共享。Azure Files only allows SMB 2.1 connections within the same Azure region as the Azure file share; an SMB 2.1 client outside of the Azure region of the Azure file share, such as on-premises or in a different Azure region, will not be able to access the file share.

强烈建议启用传输中数据加密。We strongly recommend ensuring encryption of data in-transit is enabled.

有关传输中加密的详细信息,请参阅要求在 Azure 存储中进行安全传输For more information about encryption in transit, see requiring secure transfer in Azure storage.

静态加密Encryption at rest

使用 Azure 存储服务加密 (SSE) 对存储在 Azure 文件存储中的所有数据进行静态加密。All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). 存储服务加密的工作方式类似于 Windows 上的 BitLocker:在文件系统级别下对数据进行加密。Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. 由于数据在 Azure 文件共享的文件系统下加密,因此,在将数据编码到磁盘时,无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share.

默认情况下,使用 Microsoft 托管密钥对存储在 Azure 文件存储中的数据进行加密。By default, data stored in Azure Files is encrypted with Microsoft-managed keys. 使用 Microsoft 托管密钥,Azure 保存用于加密/解密数据的密钥,并负责定期轮换这些密钥。With Microsoft-managed keys, Azure holds the keys to encrypt/decrypt the data, and is responsible for rotating them on a regular basis. 还可以选择管理自己的密钥,这样就可以控制轮换过程。You can also choose to manage your own keys, which gives you control over the rotation process. 如果选择使用客户托管密钥来加密文件共享,则 Azure 文件存储有权访问你的密钥,以满足来自客户端的读取和写入请求。If you choose to encrypt your file shares with customer-managed keys, Azure Files is authorized to access your keys to fulfill read and write requests from your clients. 使用客户托管密钥,你可以随时撤销此授权,但这意味着无法再通过 SMB 或 FileREST API 对 Azure 文件共享进行访问。With customer-managed keys, you can revoke this authorization at any time, but this means that your Azure file share will no longer be accessible via SMB or the FileREST API.

Azure 文件存储使用与其他 Azure 存储服务(如 Azure Blob 存储)相同的加密方案。Azure Files uses the same encryption scheme as the other Azure storage services such as Azure Blob storage. 若要详细了解 Azure 存储服务加密 (SSE),请参阅静态数据的 Azure 存储加密To learn more about Azure storage service encryption (SSE), see Azure storage encryption for data at rest.

存储层Storage tiers

Azure 文件存储提供了标准的存储层,可让你根据方案的性能和价格要求定制共享:Azure Files offers a standard tiers of storage to allow you to tailor your shares to the performance and price requirements of your scenario:

-标准文件共享:标准文件共享由硬盘驱动器 (HDD) 提供支持,部署在常规用途版本2 (GPv2) 存储帐户类型中。-Standard file shares: Standard file shares are backed by hard disk drives (HDDs) and are deployed in the general purpose version 2 (GPv2) storage account type. 标准文件共享为对性能波动不太敏感的 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.

通常,Azure 文件存储功能以及与其他服务的互操作性在高级文件共享和标准文件共享之间是相同的,但有几个重要区别:In general, Azure Files features and interoperability with other services are the same between premium file shares and standard file shares, however there are a few important differences:

  • 冗余选项Redundancy options
    • 高级文件共享仅适用于本地冗余 (LRS) 存储。Premium file shares are only available for locally redundant (LRS) storage.
    • 标准文件共享可用于本地冗余、异地冗余 (GRS) 和异地区域冗余 (GZRS) 存储。Standard file shares are available for locally redundant, geo-redundant (GRS), and geo-zone redundant (GZRS) storage.
  • 文件共享的最大大小Maximum size of file share
    • 高级文件共享最多可预配 100 TiB,无需任何额外的操作。Premium file shares can be provisioned for up to 100 TiB without any additional work.
    • 默认情况下,标准文件共享的上限是 5 TiB,但可以通过选择“大文件共享”存储帐户功能标志将共享限制增加到 100 TiB。By default, standard file shares can span only up to 5 TiB, although the share limit can be increased to 100 TiB by opting into the large file share storage account feature flag. 对于本地冗余存储帐户或区域冗余存储帐户,标准文件共享的上限是 100 TiB。Standard file shares may only span up to 100 TiB for locally redundant or zone redundant storage accounts. 有关增加文件共享大小的详细信息,请参阅启用和创建大文件共享For more information on increasing file share sizes, see Enable and create large file shares.
  • 区域可用性Regional availability
    • 高级文件共享并非在每个区域中都可用。Premium file shares are not available in every region.
    • 标准文件共享在每个 Azure 区域中可用。Standard file shares are available in every Azure region.
  • Azure Kubernetes 服务 (AKS) 在 1.13 及更高版本中支持高级文件共享。Azure Kubernetes Service (AKS) supports premium file shares in version 1.13 and later.

将文件共享创建为高级文件共享或标准文件共享后,便无法自动将其转换为其他层。Once a file share is created as either a premium or a standard file share, you cannot automatically convert it to the other tier. 若要切换到其他层,必须在该层中创建新的文件共享,并手动将原始共享中的数据复制到所创建的新共享。If you would like to switch to the other 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. 建议使用 robocopy(适用于 Windows)或 rsync(适用于 macOS 和 Linux)来执行该复制。We recommend using robocopy for Windows or rsync for macOS and Linux to perform that copy.

了解高级文件共享的预配Understanding provisioning for premium file shares

高级文件共享是基于固定的 GiB/IOPS/吞吐量比率预配的。Premium file shares are provisioned based on a fixed GiB/IOPS/throughput ratio. 对于预配的每个 GiB,将向该共享分配 1 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 3 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. (最大可为 100,000 IOPS)。(Up to a max of 100,000 IOPS).

突发限制 = 3 * 基准 IOPS。Burst Limit = 3 * Baseline IOPS. (最大可为 100,000 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.

下表演示了这些预配共享大小公式的几个示例: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 最大 1,500Up to 1,500 9090 6060
1,0241,024 1,0241,024 最大 3,072Up to 3,072 122122 8181
5,1205,120 5,1205,120 最大 15,360Up to 15,360 368368 245245
10,24010,240 10,24010,240 最大 30,720Up to 30,720 675675 450450
33,79233,792 33,79233,792 最大 100,000Up to 100,000 2,0882,088 1,3921,392
51,20051,200 51,20051,200 最大 100,000Up to 100,000 3,1323,132 2,0882,088
102,400102,400 100,000100,000 最大 100,000Up 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.

突发Bursting

高级文件共享最大可按系数 3 突发其 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.

提示

突发桶的大小 = 基线 IOPS * 2 * 3600。Size of the burst bucket = Baseline IOPS * 2 * 3600.

每当共享超过基线 IOPS 并且在突发桶中具有额度,就会突发。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 小于基线 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.

启用标准文件共享最高可以扩展到 100 TiBEnable standard file shares to span up to 100 TiB

默认情况下,虽然可将共享限制增加到 100 TiB,但标准文件共享只能跨越最多 5 TiB。By default, standard file shares can span only up to 5 TiB, although the share limit can be increased to 100 TiB. 为此,必须在存储帐户级别启用大文件共享** 功能。To do this, large file share feature must be enabled at the storage account-level.

只能在本地冗余的标准存储帐户上启用大文件共享。You can only enable large file shares on locally redundant standard storage accounts. 启用大文件共享功能标志后,不能将冗余级别更改为异地冗余存储。Once you have enabled the large file share feature flag, you can't change the redundancy level to geo-redundant storage.

若要在现有存储帐户上启用大文件共享,请导航到存储帐户的目录中的“配置”视图,将大文件共享摇杆开关切换到“启用”:****To enable large file shares on an existing storage account, navigate to the Configuration view in the storage account's table of contents, and switch the large file share rocker switch to enabled:

在 Azure 门户中启用大文件共享摇杆开关的屏幕截图

还可以通过 Set-AzStorageAccount PowerShell cmdlet 和 az storage account update Azure CLI 命令启用 100 TiB 文件共享。You can also enable 100 TiB file shares through the Set-AzStorageAccount PowerShell cmdlet and the az storage account update Azure CLI command. 有关启用大型文件共享的详细说明,请参阅启用和创建大型文件共享For detailed instructions on enabling large files shares, see enable and create large file shares.

要详细了解如何在新存储帐户上创建大型文件共享,请参阅创建 Azure 文件共享To learn more about how to create file shares on new storage accounts, see creating an Azure file share.

限制Limitations

具有 100 TiB 容量的标准文件共享存在一定限制。Standard file shares with 100 TiB capacity have certain limitations.

  • 目前仅支持本地冗余存储 (LRS) 帐户。Currently, only locally redundant storage (LRS) account is supported.
  • 启用大型文件共享后,不能将存储帐户转换为异地冗余存储 (GRS) 帐户。Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) account.
  • 启用大型文件共享后,不能禁用。Once you enable large file shares, you can't disable it.

冗余Redundancy

为了在 Azure 文件共享中保护数据以防数据丢失或损坏,所有 Azure 文件共享都在写入每个文件时存储了该文件的多个副本。To protect the data in your Azure file shares against data loss or corruption, all Azure file shares store multiple copies of each file as they are written. 可以根据工作负载的要求选择额外的冗余度。Depending on the requirements of your workload, you can select additional degrees of redundancy. Azure 文件存储目前支持以下数据冗余选项:Azure Files currently supports the following data redundancy options:

  • 本地冗余:本地冗余存储(通常称为 LRS)表示每个文件在 Azure 存储群集中存储三次。Locally redundant: Locally redundant storage, often referred to as LRS, means that every file is stored three times within an Azure storage cluster. 这可以防止由于硬件故障(例如磁盘驱动器损坏)而导致数据丢失。This protects against loss of data due to hardware faults, such as a bad disk drive.
  • 异地冗余:异地冗余存储(通常称为 GRS)类似于本地冗余存储,因为文件在主要区域的 Azure 存储群集内存储三次。Geo-redundant: Geo-redundant storage, often referred to as GRS, is like locally redundant storage, in that a file is stored three times within an Azure storage cluster in the primary region. 然后,所有写入都将异步复制到 Azure 定义的次要区域。All writes are then asynchronously replicated to a Azure-defined secondary region. 异地冗余存储提供 6 个数据副本,这些副本分布在两个 Azure 区域。Geo-redundant storage provides 6 copies of your data spread between two Azure regions. 如果发生重大灾难(例如,由于自然灾害或其他类似事件而导致 Azure 区域永久性丢失),Azure 会执行故障转移,使次要区域实际上成为主要区域,为所有操作提供服务。In the event of a major disaster such as the permanent loss of an Azure region due to a natural disaster or other similar event, Azure will perform a failover so that the secondary in effect becomes the primary, serving all operations. 由于主要区域和次要区域之间的复制是异步的,因此,在发生重大灾难时,尚未复制到次要区域的数据会丢失。Since the replication between the primary and secondary regions are asynchronous, in the event of a major disaster, data not yet replicated to the secondary region will be lost. 还可以对异地冗余存储帐户执行手动故障转移。You can also perform a manual failover of a geo-redundant storage account.

标准 Azure 文件共享支持这两种冗余类型。Standard Azure file shares support all two redundancy types.

常规用途版本 2 (GPv2) 存储帐户提供 Azure 文件存储不支持的额外冗余选项:读取访问异地冗余存储,通常称为“RA-GRS”。General purpose version 2 (GPv2) storage accounts provide a additional redundancy option that are not supported by Azure Files: read accessible geo-redundant storage, often referred to as RA-GRS. 可以在设置了这些选项的存储帐户中预配 Azure 文件共享,但 Azure 文件存储不支持从次要区域读取。You can provision Azure file shares in storage accounts with these options set, however Azure Files does not support reading from the secondary region. 部署到读取访问异地冗余存储帐户中的 Azure 文件共享会按异地冗余存储计费。Azure file shares deployed into read-accessible geo-redundant storage accounts will be billed as geo-redundant storage.

迁移Migration

在很多情况下,你不想要为组织建立全新的文件共享,而是将现有文件共享从本地文件服务器或 NAS 设备迁移到 Azure 文件存储。In many cases, you will not be establishing a net new file share for your organization, but instead migrating an existing file share from an on-premises file server or NAS device to Azure Files. Microsoft 和第三方提供了许多用于迁移到文件共享的工具,这些工具大致划分为两种类别:There are many tools, provided both by Microsoft and 3rd parties, to do a migration to a file share, but they can roughly be divided into two categories:

后续步骤Next steps