您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

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

可以通过两种主要方式部署Azure 文件:直接装载无服务器 Azure 文件共享,或使用 Azure 文件同步在本地缓存 azure 文件共享。你选择哪种部署选项会更改你在规划部署时需要考虑的事项。Azure Files can be deployed in two main ways: by directly mounting the serverless Azure file shares or by caching Azure file shares on-premises using Azure File Sync. Which deployment option you choose changes the things you need to consider as you plan for your deployment.

  • 直接装载 azure 文件共享:由于 azure 文件提供 (SMB) 或网络文件系统 (NFS) 访问的服务器消息块,因此可以使用操作系统中提供的标准 SMB 或 NFS 客户端将 Azure 文件共享装载到本地或云中。Direct mount of an Azure file share: Since Azure Files provides either Server Message Block (SMB) or Network File System (NFS) access, you can mount Azure file shares on-premises or in the cloud using the standard SMB or NFS clients available in your OS. 由于 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 文件同步在本地缓存 Azure 文件共享:借助 Azure 文件同步,可以在 Azure 文件存储中集中管理组织的文件共享,同时又能保留本地文件服务器的灵活性、性能和兼容性。Cache Azure file share on-premises with Azure File Sync: Azure File Sync enables you to centralize your organization's file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. Azure 文件同步将本地 (或云) Windows Server 转换为 Azure SMB 文件共享的快速缓存。Azure File Sync transforms an on-premises (or cloud) Windows Server into a quick cache of your Azure SMB file share.

本文主要阐述有关部署可供本地或云客户端直接装载的 Azure 文件共享时的部署注意事项。This article primarily addresses deployment considerations for deploying an Azure file share to be directly mounted by an on-premises or cloud client. 若要规划 Azure 文件同步部署,请参阅 规划 Azure 文件同步部署To plan for an Azure File Sync deployment, see Planning for an Azure File Sync deployment.

可用的协议Available protocols

Azure 文件提供了两种协议,可以在将文件共享、SMB 和网络文件系统 (NFS) 时使用。Azure Files offers two protocols which may be used when mounting your file shares, SMB and Network File System (NFS). 有关这些协议的详细信息,请参阅 Azure 文件共享协议For details on these protocols, see Azure file share protocols.

重要

本文的大部分内容仅适用于 SMB 共享。Most of the content of this article only applies to SMB shares. 适用于 NFS 共享的任何内容都将专门表明它适用。Anything that applies to NFS shares will specifically state it is applicable.

管理概念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 文件存储部署,将使用两种主要类型的存储帐户:There are two main types of storage accounts you will use for Azure Files deployments:

  • 常规用途版本 2 (GPv2) 存储帐户:使用 GPv2 存储帐户可以在标准的/基于硬盘(基于 HDD)的硬件上部署 Azure 文件共享。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.
  • FileStorage 存储帐户:使用 FileStorage 存储帐户可以在高级/基于固态磁盘(基于 SSD)的硬件上部署 Azure 文件共享。FileStorage storage accounts: FileStorage storage accounts allow you to deploy Azure file shares on premium/solid-state disk-based (SSD-based) hardware. FileStorage 帐户只能用于存储 Azure 文件共享;其他存储资源(Blob 容器、队列、表等)都不能部署在 FileStorage 帐户中。FileStorage accounts can only be used to store Azure file shares; no other storage resources (blob containers, queues, tables, etc.) can be deployed in a FileStorage account. 只有 FileStorage 帐户可同时部署 SMB 和 NFS 文件共享。Only FileStorage accounts can deploy both SMB and NFS file shares.

在 Azure 门户、PowerShell 或 CLI 中,可能会遇到一些其他的存储帐户类型。There are several other storage account types you may come across in the Azure portal, PowerShell, or CLI. 两种存储帐户类型(BlockBlobStorage 和 BlobStorage 存储帐户)不能包含 Azure 文件共享。Two storage account types, BlockBlobStorage and 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 和 FileStorage 存储帐户用于新部署,而升级 GPv1 和经典存储帐户的前提是它们已经存在于环境中。We therefore recommend to only use GPv2 and FileStorage 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 Files integrates with three main identity providers:

  • 本地 Active Directory 域服务 (AD DS 或本地 AD DS): Azure 存储帐户可以是加入到客户所有 Active Directory 域服务的域,就像 Windows Server 文件服务器或 NAS 设备一样。On-premises Active Directory Domain Services (AD DS, or on-premises AD DS): Azure storage accounts can be domain joined to a customer-owned, Active Directory Domain Services, just like a Windows Server file server or NAS device. 你可以在本地、在 Azure VM 中部署域控制器,甚至可以在其他云提供程序中部署为 VM;Azure 文件与托管域控制器的位置无关。You can deploy a domain controller on-premises, in an Azure VM, or even as a VM in another cloud provider; Azure Files is agnostic to where your domain controller is hosted. 存储帐户加入域后,最终用户可以使用登录到其 PC 的用户帐户装载文件共享。Once a storage account is domain-joined, the end user can mount a file share with the user account they signed into their PC with. 基于 AD 的身份验证使用 Kerberos 身份验证协议。AD-based authentication uses the Kerberos authentication protocol.
  • Azure Active Directory 域服务 (AZURE AD DS): Azure AD ds 提供了可用于 Azure 资源的 Microsoft 托管域控制器。Azure Active Directory Domain Services (Azure AD DS): Azure AD DS provides a Microsoft-managed domain controller that can be used for Azure resources. 将你的存储帐户加入到 Azure AD DS 的域可为加入到客户拥有的 Active Directory 的域提供类似的好处。Domain joining your storage account to Azure AD DS provides similar benefits to domain joining it to a customer-owned Active Directory. 此部署选项最适用于需要基于 AD 的权限的应用程序提升和移动方案。This deployment option is most useful for application lift-and-shift scenarios that require AD-based permissions. 由于 Azure AD DS 提供了基于 AD 的身份验证,因此此选项还使用 Kerberos 身份验证协议。Since Azure AD DS provides AD-based authentication, this option also uses the Kerberos authentication protocol.
  • Azure 存储帐户密钥:还可以使用 azure 存储帐户密钥装载 azure 文件共享。Azure storage account key: Azure file shares may also be 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.

对于从本地文件服务器迁移的客户,或在 Azure 文件中创建新的文件共享以与 Windows 文件服务器或 NAS 设备的行为类似,建议选择将存储帐户加入到 客户拥有的 Active Directory 域。For customers migrating from on-premises file servers, or creating new file shares in Azure Files intended to behave like Windows file servers or NAS appliances, domain joining your storage account to Customer-owned Active Directory is the recommended option. 若要详细了解如何将存储帐户“域加入”到客户拥有的 Active Directory,请参阅 Azure 文件存储 Active Directory 概述To learn more about domain joining your storage account to a customer-owned Active Directory, see Azure Files Active Directory overview.

如果要使用存储帐户密钥来访问 Azure 文件共享,我们建议使用 " 网络 " 部分中所述的服务终结点。If you intend to use the storage account key to access your Azure file shares, 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. 可以通过 SMB 和 NFS 共享来安装这些选项。Mounting with these options is possible with both SMB and NFS shares. 为此,需要为环境配置以下设置: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.
  • 专用终结点:专用终结点在虚拟网络的地址空间中为存储帐户指定了一个专用 IP 地址。Private endpoints: Private endpoints give your storage account a dedicated IP address from within the address space of the virtual network. 这样,无需打开本地网络就可以通过网络隧道连接到 Azure 存储群集拥有的所有 IP 地址范围。This enables network tunneling without needing to open on-premises networks up to all the of the IP address ranges owned by the Azure storage clusters.
  • DNS 转发:配置本地 DNS 以解析存储帐户的名称, (即 storageaccount.file.core.windows.net ,对于公有云区域) 解析为专用终结点的 IP 地址。DNS forwarding: Configure your on-premises DNS to resolve the name of your storage account (i.e. storageaccount.file.core.windows.net for the public cloud regions) 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

重要

本部分介绍 SMB 共享的传输中加密详细信息。This section covers encryption in transit details for SMB shares. 有关通过 NFS 共享进行传输中加密的详细信息,请参阅安全性For details regarding encryption in transit with NFS shares, see Security.

默认情况下,所有 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. 静态加密同时适用于 SMB 和 NFS 协议。Encryption at rest applies to both the SMB and NFS protocols.

默认情况下,Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。By default, data stored in Azure Files is encrypted with Microsoft-managed keys. 通过 Microsoft 管理的密钥,Microsoft 持有加密/解密数据的密钥,且负责定期轮换这些密钥。With Microsoft-managed keys, Microsoft 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.

数据保护Data protection

Azure 文件有一种多层方法来确保数据得到备份、恢复以及不受安全威胁。Azure Files has a multi-layered approach to ensuring your data is backed up, recoverable, and protected from security threats.

软删除Soft delete

Azure 文件共享的软删除(预览版)是一种存储帐户级别设置,使你在意外删除文件共享时对其进行恢复。Soft delete for file shares (preview) is a storage-account level setting that allows you to recover your file share when it is accidentally deleted. 已删除的文件共享会过渡到软删除状态,而非被永久擦除。When a file share is deleted, it transitions to a soft deleted state instead of being permanently erased. 可配置软删除数据被永久删除前的可恢复时间,并在此保留期内随时取消删除共享。You can configure the amount of time soft deleted data is recoverable before it's permanently deleted, and undelete the share anytime during this retention period.

我们建议对大多数文件共享启用软删除。We recommend turning on soft delete for most file shares. 如果你的工作流中共享删除是常见且预期的,那么你可能会决定很短的保留期,或者根本不启用软删除。If you have a workflow where share deletion is common and expected, you may decide to have a very short retention period or not have soft delete enabled at all.

有关软删除的详细信息,请参见防止意外数据删除For more information about soft delete, see Prevent accidental data deletion.

备份Backup

可以通过共享快照备份 Azure 文件共享,这些快照是共享的只读时间点副本。You can back up your Azure file share via share snapshots, which are read-only, point-in-time copies of your share. 快照是增量的,这意味着它们只包含自上一个快照以来更改的数据量。Snapshots are incremental, meaning they they only contain as much data as has changed since the previous snapshot. 每个文件共享最多可以有 200 个快照,并将其保留长达 10 年。You can have up to 200 snapshots per file share and retain them for up to 10 years. 你可以通过 PowerShell 或命令行接口 (CLI) 手动获取这些 Azure 门户快照,或者可以使用 Azure 备份You can either manually take these snapshots in the Azure portal, via PowerShell, or command-line interface (CLI), or you can use Azure Backup. 快照存储在文件共享中,这意味着如果删除文件共享,快照也将删除。Snapshots are stored within your file share, meaning that if you delete your file share, your snapshots will also be deleted. 若要保护快照备份不被意外删除,请确保为共享启用软删除。To protect your snapshot backups from accidental deletion, ensure soft delete is enabled for your share.

Azure文件共享的 Azure 备份处理快照的计划和保留。Azure Backup for Azure file shares handles the scheduling and retention of snapshots. 它的祖父- (GFS) 功能意味着您可以每日、每周、每月和每年的快照,每个快照都具有自己的独特的保留期。Its grandfather-father-son (GFS) capabilities mean that you can take daily, weekly, monthly, and yearly snapshots, each with their own distinct retention period. Azure 备份还会协调软删除的启用,并在存储帐户中的任何文件共享配置为进行备份时立即对存储帐户执行删除锁定。Azure Backup also orchestrates the enablement of soft delete and takes a delete lock on a storage account as soon as any file share within it is configured for backup. 最后,Azure 备份提供某些关键的监视和警报功能,使客户能够获得其备份空间的合并视图。Lastly, Azure Backup provides certain key monitoring and alerting capabilities that allow customers to have a consolidated view of their backup estate.

可以使用 Azure 备份在 Azure 门户中执行项级和共享级还原。You can perform both item-level and share-level restores in the Azure portal using Azure Backup. 只需选择特定快照) 的还原点、特定的文件或目录(如果相关),然后选择要还原到的原始或备用) 位置 ( (。All you need to do is choose the restore point (a particular snapshot), the particular file or directory if relevant, and then the location (original or alternate) you wish you restore to. 备份服务会处理复制快照数据,并在门户中显示还原进度。The backup service handles copying the snapshot data over and shows your restore progress in the portal.

有关备份的详细信息,请参阅 关于 Azure 文件共享备份For more information about backup, see About Azure file share backup.

(预览版的 Azure 文件的高级威胁防护) Advanced Threat Protection for Azure Files (preview)

高级威胁防护 (适用于 Azure 存储的 ATP) 提供额外的安全智能层,当它检测到你的存储帐户上的异常活动(例如,意外尝试访问存储帐户)时,它将提供警报。Advanced Threat Protection (ATP) for Azure Storage provides an additional layer of security intelligence that provides alerts when it detects anomalous activity on your storage account, for example unusual attempts to access the storage account. ATP 还会运行恶意软件哈希信誉分析,并对已知的恶意软件发出警报。ATP also runs malware hash reputation analysis and will alert on known malware. 可以通过 Azure 安全中心在订阅或存储帐户级别上配置 ATP。You can configure ATP on a subscription or storage account level via Azure Security Center.

有关详细信息,请参阅 Azure 存储的高级威胁防护For more information, see Advanced Threat protection for Azure Storage.

存储层Storage tiers

Azure 文件存储提供了四种不同的存储层(高级、事务优化、热和冷存储层),因此你能够根据方案的性能和价格要求定制共享:Azure Files offers four different tiers of storage, premium, transaction optimized, hot, and cool to allow you to tailor your shares to the performance and price requirements of your scenario:

  • Premium:高级文件共享由固态硬盘 (SSD) 支持,并部署在 FileStorage 存储帐户类型中。Premium: Premium file shares are backed by solid-state drives (SSDs) and are deployed in the FileStorage storage account type. 高级文件共享提供稳定的高性能和低延迟,对于大多数 IO 操作和 IO 密集型工作负荷,延迟不到 10 毫秒。Premium file shares provide consistent high performance and low latency, within single-digit milliseconds for most IO operations, for IO-intensive workloads. 高级文件共享适合各种各样的工作负载,例如数据库、网站托管和开发环境。Premium file shares are suitable for a wide variety of workloads like databases, web site hosting, and development environments. 高级文件共享既可用于服务器消息块 (SMB) 协议,也可用于网络文件系统 (NFS) 协议。Premium file shares can be used with both Server Message Block (SMB) and Network File System (NFS) protocols.
  • 事务优化:事务优化文件共享可实现事务繁重的工作负载,这些工作负荷不需要高级文件共享提供的延迟。Transaction optimized: Transaction optimized file shares enable transaction heavy workloads that don't need the latency offered by premium file shares. 事务优化文件共享在硬盘驱动器 (HDD) 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Transaction optimized file shares are offered on the standard storage hardware backed by hard disk drives (HDDs) and are deployed in the general purpose version 2 (GPv2) storage account type. 虽然事务优化一直被称为“标准”层,但这指的是存储介质类型而不是层本身(热和冷存储层也是“标准”层,因为它们位于标准存储硬件上)。Transaction optimized has historically been called "standard", however this refers to the storage media type rather than the tier itself (the hot and cool are also "standard" tiers, because they are on standard storage hardware).
  • Hot:热文件共享提供针对常规用途文件共享方案(如团队共享和 Azure 文件同步)优化的存储。热文件共享在 HDD 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Hot: Hot file shares offer storage optimized for general purpose file sharing scenarios such as team shares and Azure File Sync. Hot file shares are offered on the standard storage hardware backed by HDDs and are deployed in the general purpose version 2 (GPv2) storage account type.
  • Cool:冷文件共享提供针对在线存档存储方案优化的经济高效的存储。Cool: Cool file shares offer cost-efficient storage optimized for online archive storage scenarios. Azure 文件同步可能也适用于低改动工作负载。Azure File Sync may also be a good fit for lower churn workloads. 冷文件共享在 HDD 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Cool file shares are offered on the standard storage hardware backed by HDDs and are deployed in the general purpose version 2 (GPv2) storage account type.

高级文件共享只能在预配的计费模型下使用。Premium file shares are only available in a provisioned billing model. 有关高级文件共享的预配计费模型的详细信息,请参阅了解预配高级文件共享For more information on the provisioned billing model for premium file shares, see Understanding provisioning for premium file shares. 标准文件共享(包括事务优化、热和冷文件共享)以即用即付计费的形式提供。Standard file shares, including transaction optimized, hot, and cool file shares, are available through pay as you go billing.

热文件共享和冷文件共享在所有 Azure 公共区域和 Azure 政府区域中均可用。Hot and cool file shares are available in all Azure Public and Azure Government regions. 事务优化文件共享在所有 Azure 区域中可用,包括 Azure 中国和 Azure 德国区域。Transaction optimized file shares are available in all Azure regions, including Azure China and Azure Germany regions.

重要

可以在 GPv2 存储帐户类型中的各层(事务优化、热和冷)之间移动文件共享。You can move file shares between tiers within GPv2 storage account types (transaction optimized, hot, and cool). 共享在层间移动会产生事务:从较热层移动到较冷层会导致对共享中每个文件收取冷层的写入事务费用,而从较冷层移动到较热层会导致对共享中每个文件收取冷层的读取事务费用。Share moves between tiers incur transactions: moving from a hotter tier to a cooler tier will incur the cooler tier's write transaction charge for each file in the share, while a move from a cooler tier to a hotter tier will incur the cool tier's read transaction charge for each file the share.

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

  • 计费模式Billing model
    • 高级文件共享使用预配的计费模式进行计费,这意味着你预配了多少存储空间,而不是使用的存储量。Premium file shares are billed using a provisioned billing model, which means you pay fixed price for how much storage you provision rather than how much storage you use. 静态事务和元数据不会产生额外的费用。There are no additional costs for transactions and metadata at-rest.
    • 标准文件共享使用即用即付模型进行计费,其中包括实际使用的存储量的基本成本,并根据使用共享的方式增加事务成本。Standard file shares are billed using a pay-as-you-go model, which includes a base cost of storage for how much storage you're actually consuming and then an additional transaction cost based on how you use the share. 如果使用标准文件共享,则在 Azure 文件共享) 使用 (读/写/装载时,计费将会增加。With standard file shares, your bill will increase if you use (read/write/mount) the Azure file share more.
  • 冗余选项Redundancy options
    • 高级文件共享仅适用于本地冗余 (LRS) 和区域冗余 (ZRS) 存储。Premium file shares are only available for locally redundant (LRS) and zone redundant (ZRS) storage.
    • 标准文件共享可用于本地冗余、区域冗余、异地冗余 (GRS) 和地理区域冗余 (GZRS) 存储。Standard file shares are available for locally redundant, zone 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
    • 大多数 Azure 区域中都提供高级文件共享,但有几个区域除外。Premium file shares are available in most of Azure regions with an exception of a few regions. 区域冗余支持在区域的一个子集内提供。Zone redundant support is available in a subset of regions. 若要确定高级文件共享目前是否可在你的区域中使用,请参阅 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 Zone-redundant storage. 若要帮助我们确定新的区域和高级层功能的优先级,请填写此 调查To help us prioritize new regions and premium tier features, please fill out this survey.
    • 标准文件共享在每个 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. 所有共享大小均提供最小基线/吞吐量并允许突发。All shares sizes are offered minimum baseline/throughput and allowed to burst. 对于每个预配的 GiB,将会向共享颁发最小 IOPS/吞吐量和一个 IOPS 和 0.1 MiB/秒的吞吐量,最大限制为每个共享。For each GiB provisioned, the share will be issued minimum IOPS/throughput and 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 minimum IOPS/throughput.

所有高级共享会尽力提供免费突发。All premium shares are offered free bursting on a best effort basis. 对于每个预配的 GiB,所有共享大小都可以突发为 4000 IOPS 或最多三倍,为共享提供更大的突发 IOPS。All shares sizes can burst up to 4,000 IOPS or up to to three IOPS per provisioned GiB, whichever provides a greater burst IOPS to the share. 所有共享支持最大持续时间为60分钟的突发高峰限制。All shares support bursting for a max duration of 60 minutes at a peak burst limit. 新共享将根据预配的容量以完全突增额度开始。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 = 400 + 1 * 预配的 GiB。Baseline IOPS = 400 + 1 * provisioned GiB. (最大可为 100,000 IOPS)。(Up to a max of 100,000 IOPS).

突发限制 = 最大 (4000,3 * 基准 IOPS) 。Burst Limit = MAX (4,000, 3 * Baseline IOPS). (,其中任何一个限制越大,最大为 100000 IOPS) 。(whichever limit is greater, 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 500500 最大 4,000Up to 4,000 6666 4444
500500 900900 最大 4,000Up to 4,000 9090 6060
1,0241,024 14241,424 最大 4,000Up to 4,000 122122 8181
5,1205,120 55205,520 最大 15,360Up to 15,360 368368 245245
10,24010,240 1064010,640 最大 30,720Up to 30,720 675675 450450
33,79233,792 3419234,192 最大 100,000Up to 100,000 2,0882,088 1,3921,392
51,20051,200 5160051,600 最大 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 大小、并行性的限制,还有其他许多因素。It is important to note that effective file shares performance is subject to machine network limits, available network bandwidth, IO sizes, parallelism, among many other factors. 例如,基于具有8个 KiB 读取/写入 IO 大小的内部测试,不启用 SMB 多通道的单个 Windows 虚拟机, 标准 F16s_v2,通过 smb 连接到高级文件共享可以实现20K 读取 Iops 和15K 写入 iops。For example, based on internal testing with 8 KiB read/write IO sizes, a single Windows virtual machine without SMB Multichannel enabled, Standard F16s_v2, connected to premium file share over SMB could achieve 20K read IOPS and 15K write IOPS. 读/写 IO 大小为 512 MiB 时,同一 VM 可以实现 1.1 GiB/秒的出口吞吐量和 370 MiB/秒的入口吞吐量。With 512 MiB read/write IO sizes, the same VM could achieve 1.1 GiB/s egress and 370 MiB/s ingress throughput. ~如果对高级共享启用了 SMB 多通道,则同一客户端的性能最高可达3倍。The same client can achieve up to ~3x performance if SMB Multichannel is enabled on the premium shares. 若要实现最大性能规模,请 启用 SMB 多通道 并将负载分散到多个 vm。To achieve maximum performance scale, enable SMB Multichannel and spread the load across multiple VMs. 有关一些常见性能问题和解决方法,请参阅 SMB 多通道性能故障排除指南Please refer to SMB multichannel performance and troubleshooting guide for some common performance issues and workarounds.

突发Bursting

如果您的工作负荷需要额外的性能来满足峰值需求,则您的共享可以使用突发信用额度,以提供满足需求所需的共享性能。If your workload needs the extra performance to meet peak demand, your share can use burst credits to go above share baseline IOPS limit to offer share performance it needs to meet the demand. 高级文件共享可能会将其 IOPS 突发到4000或最高达3倍,两者的值越高。Premium file shares can burst their IOPS up to 4,000 or up to a factor of three, whichever is a higher value. 突发是自动进行的,根据额度系统运行。Bursting is automated and operates based on a credit system. 突发会尽力工作,并且突发限制并不保证,文件 共享的最 大持续时间限制为60分钟。Bursting works on a best effort basis and the burst limit is not a guarantee, file shares can burst up to the limit for a max duration of 60 minutes.

每当文件共享的流量低于基线 IOPS 时,额度将累积在突发桶中。Credits accumulate in a burst bucket whenever traffic for your file share is below baseline IOPS. 例如,100 GiB 共享有500的基线 IOPS。For example, a 100 GiB share has 500 baseline IOPS. 如果共享上的实际流量为特定1秒间隔的 100 IOPS,则会将400未使用的 IOPS 贷记到突发桶。If actual traffic on the share was 100 IOPS for a specific 1-second interval, then the 400 unused IOPS are credited to a burst bucket. 同样,一个空闲 1 TiB 共享,以 1424 IOPS 为突发信用额度。Similarly, an idle 1 TiB share, accrues burst credit at 1,424 IOPS. 以后在操作超过基线 IOPS 时,将使用这些信用额度。These credits will then be used later when operations would exceed the baseline IOPS.

每当共享超过基线 IOPS 并在突发桶中包含信用额度时,它将以允许的最大峰值脉冲速率突发。Whenever a share exceeds the baseline IOPS and has credits in a burst bucket, it will burst at the max allowed peak burst rate. 只要剩余信用额度,就可以继续突发共享,最多可达60分钟的持续时间,但这取决于所应计的突发富余点数。Shares can continue to burst as long as credits are remaining, up to max 60 minutes duration 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 the baseline IOPS.

共享额度具有三种状态:Share credits have three states:

  • 应计:文件共享使用的 IOPS 小于基线 IOPS。Accruing, when the file share is using less than the baseline IOPS.
  • 如果文件共享使用的基准 IOPS 超过基线 IOPS,则拒绝使用。Declining, when the file share is using more than the baseline IOPS and in the bursting mode.
  • 常量,h) 文件共享只使用基线 IOPS,没有任何信用额度或信用额度。Constant, hen the files share is using exactly the baseline IOPS, there are either no credits accrued or used.

新文件共享最初在其突发桶中包含所有额度。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. 高级存储帐户(FileStorage 存储帐户)没有大文件共享功能标志,因为所有高级文件共享都可以最高可预配到完整的 100 TiB 容量。Premium storage accounts (FileStorage storage accounts) don't have the large file share feature flag as all premium file shares are already enabled for provisioning up to the full 100 TiB capacity.

仅可在本地冗余或区域冗余标准存储帐户上启用大型文件共享功能。You can only enable large file shares on locally redundant or zone redundant standard storage accounts. 启用大型文件共享功能标志后,无法将冗余级别更改为异地冗余或异地区域冗余存储。Once you have enabled the large file share feature flag, you can't change the redundancy level to geo-redundant or geo-zone-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) 和区域冗余存储 (GRS) 帐户。Currently, only locally redundant storage (LRS) and zone redundant storage (ZRS) accounts are supported.
  • 启用大型文件共享功能后,无法将存储帐户转换为区域冗余存储 (GRS) 或异地区域冗余存储 (GZRS) 帐户。Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) accounts.
  • 启用大型文件共享后,不能禁用。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.
  • 区域冗余:区域冗余存储(通常称为 ZRS)指的是每个文件在三个不同的 Azure 存储群集中存储三次。Zone redundant: Zone redundant storage, often referred to as ZRS, means that every file is stored three times across three distinct Azure storage clusters. 就像使用本地冗余存储一样,区域冗余会提供每个文件的三个副本,但这些副本位于不同的 Azure 可用性区域的三个不同存储群集中,它们在物理上是隔离的。Just like with locally redundant storage, zone redundancy gives you three copies of each file, however these copies are physically isolated in three distinct storage clusters in different Azure availability zones. 可用性区域是 Azure 区域中独特的物理位置。Availability zones are unique physical locations within an Azure region. 每个区域由一个或多个数据中心组成,这些数据中心配置了独立电源、冷却和网络。Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. 在将副本写入所有三个可用性区域的存储群集前,不允许将其写入存储。A write to storage is not accepted until it is written to the storage clusters in all three availability zones.
  • 异地冗余:异地冗余存储(通常称为 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. 所有写入都将异步复制到 Microsoft 定义的次要区域。All writes are then asynchronously replicated to a Microsoft-defined secondary region. 异地冗余存储在两个 Azure 区域之间提供 6 个数据副本。Geo-redundant storage provides 6 copies of your data spread between two Azure regions. 如果发生重大灾难(如由于自然灾害或其他类似事件而导致 Azure 区域永久性丢失),Microsoft 将执行故障转移,使有效的次要区域成为主要区域,为所有操作提供服务。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, Microsoft 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.
  • 异地区域冗余:异地区域冗余存储(通常称为 GZRS)类似于区域冗余存储,因为文件在主要区域的三个不同存储群集内存储三次。Geo-zone redundant: Geo-zone redundant storage, often referred to as GZRS, is like zone redundant storage, in that a file is stored three times across three distinct storage clusters in the primary region. 所有写入都将异步复制到 Microsoft 定义的次要区域。All writes are then asynchronously replicated to a Microsoft-defined secondary region. 异地区域冗余存储的故障转移过程与异地冗余存储的故障转移过程相同。The failover process for geo-zone-redundant storage works the same as it does for geo-redundant storage.

标准 Azure 文件共享支持所有四种冗余类型,而高级 Azure 文件共享仅支持本地冗余存储和区域冗余存储。Standard Azure file shares support all four redundancy types, while premium Azure file shares only support locally redundant and zone redundant storage.

常规用途版本 2 (GPv2) 存储帐户提供了两个 Azure 文件存储不支持的额外冗余选项:可读取访问的异地冗余存储(通常称为 RA-GRS)和可读取访问的异地区域冗余存储(通常称为 RA-GZRS)。General purpose version 2 (GPv2) storage accounts provide two additional redundancy options that are not supported by Azure Files: read accessible geo-redundant storage, often referred to as RA-GRS, and read accessible geo-zone-redundant storage, often referred to as RA-GZRS. 可以在存储帐户中使用这些选项集预配 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- or geo-zone redundant storage accounts will be billed as geo-redundant or geo-zone-redundant storage, respectively.

迁移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. 为你的场景选择正确的迁移策略和工具对于迁移的成功非常重要。Picking the right migration strategy and tool for your scenario is important for the success of your migration.

" 迁移概述 " 一文简要介绍了基础知识,并包含一个表,该表格可引导你使用可能涵盖方案的迁移指南。The migration overview article briefly covers the basics and contains a table that leads you to migration guides that likely cover your scenario.

后续步骤Next steps