Azure 文件部署的成本由四个关键因素决定:
计费模型:Azure 文件存储支持三种不同的计费模型,这些模型塑造了 Azure 文件部署的成本结构:
- 预配 v2:预配的计费模型,可在其中单独预配存储、IOPS 和吞吐量。 无论实际使用多少,你都根据预配的内容付费。 建议为所有新的 Azure 文件部署预配 v2 模型。
- 预配 v1:预配的计费模型,用于预配所需的存储量,而 IOPS 和吞吐量由预配的存储量决定。 建议使用预配的 v2 模型,除非有特定理由使用预配的 v1 模型。
- 即用即付:一种按用量计费的模型,其费用基于您使用文件共享的情况,并以已用存储空间、事务处理和数据传输成本的形式体现。 建议使用预配的 v2 模型,除非有特定理由使用即用即付模型。
媒体层:Azure 文件支持两个不同的存储、SSD 和 HDD 媒体层。 这样就可以根据方案的性能和价格要求定制文件共享。
- SSD (高级版):托管在固态硬盘(SSD)上的文件共享提供一致的高性能和低延迟,大多数 IO作的毫秒级延迟为一位数。
- HDD (标准):托管在硬盘驱动器(HDD)上的文件共享提供经济高效的存储,以便进行常规用途使用。
冗余:Azure 文件支持四种不同的冗余选项,可用于控制所存储的数据的副本数以及复制的副本放置在 Azure 的基础结构中的位置。 更具弹性的选项提供更高的持久性和可用性,但成本更高:
- 本地:本地冗余存储(LRS)在一个区域中的单个数据中心内保留三个数据副本。
- 区域:区域冗余存储(ZRS)在一个区域内跨独立的数据中心(可用性区域)存储数据的三个副本。
- 异地:异地冗余存储(GRS)将三个数据副本存储在主要区域中,并异步复制到配对区域,总共有六个副本。 仅在 HDD 存储上可用。
- GeoZone:GeoZone 冗余存储(GZRS)将主要区域中的区域冗余与异步复制到次要区域相结合。 仅在 HDD 存储上可用。
有关 Azure 文件存储的定价信息,请参阅 Azure 文件存储定价页。
存储单元
Azure 文件存储使用 base-2 度量单位来表示存储容量:KiB、MiB、GiB 和 TiB。
缩略词 | Definition | 单位 |
---|---|---|
KiB | 1,024 字节 | kibibyte |
MiB | 1,024 KiB(1,048,576 字节) | mebibyte |
GiB | 1,024 MiB(1,073,741,824 字节) | gibibyte |
TiB | 1,024 GiB(1,099,511,627,776 字节) | tebibyte |
大多数作系统和工具通常使用基本 2 个度量单位来度量存储数量。 但是,它们经常被错误地标记为 base-10 单位,你可能更熟悉这些单位:KB、MB、GB 和 TB。 操作系统(如 Windows)错误标记存储单元的常见原因是,许多操作系统在被国际电工委员会(IEC)、国际计量局(BIPM)和美国国家标准与技术研究所(NIST)标准化之前就开始使用这些缩写。
下表显示了常见操作系统如何度量和标写存储:
操作系统 | 测量系统 | 标记 |
---|---|---|
Windows | Base-2 | 始终错误地标记为 base-10。 |
Linux 分布 | 通常为 base-2,某些软件使用 base-10 | 不一致的标写方式,度量与标写方式之间的一致性取决于软件包。 |
macOS、iOS 和 iPad OS | Base-10 | 始终错误地标记为 base-10。 |
如果你的操作系统未列出,请咨询操作系统供应商。
文件共享总拥有成本清单
如果你要从本地迁移到 Azure 文件存储,或者要将 Azure 文件存储与其他云存储解决方案相比较,请考虑以下因素以确保公平且对等地进行比较:
如何为存储、IOPS 和带宽付费? 大多数云解决方案都有与 预配存储(例如价格确定性和简单性)或 即用即付存储(即用即付存储)原则相符的模型,这些模型只需为实际使用的内容收费即可优化成本。 预配的计费模型可能因最小预配共享大小、预配单位以及是否能够增加或减少预配而异。
如何实现存储复原和冗余? 借助 Azure 文件存储,可以将存储的复原能力和冗余融入到产品中。 所有层和冗余级别都可确保数据高度可用,你的数据至少有三个可供访问的副本。 考虑其他文件存储选项时,请考虑是内置存储复原能力和冗余,还是必须自行组装的内容。
您需要管理什么? Azure 文件存储是一个完全托管的解决方案。 其他解决方案可能需要作系统更新或管理虚拟资源,例如 VM、磁盘和网络 IP 地址。
增值产品的成本是多少? Azure 文件存储支持与多种第一方和第三方增值服务集成。 Azure 备份、Azure 文件同步、Microsoft Defender for Storage 等增值服务为 Azure 文件存储提供备份、复制和缓存以及安全功能。 增值解决方案(无论是在本地还是云中)具有自身的许可和产品成本,但通常被视为文件存储总拥有成本的一部分。
预配 v2 模型
Azure 文件存储的预配 v2 模型将总拥有成本的可预测性与灵活性相结合,使您可以创建满足您确切存储和性能需求的文件共享功能。 创建新的预配 v2 文件共享时,需要指定文件共享所需的存储量、IOPS 和吞吐量。 预配的每个数量的金额决定了帐单总额。
预配的存储量、IOPS 和吞吐量是文件共享使用情况的保证限制。 例如,如果预配 2 TiB 共享并将 2 TiB 的数据上传到共享,则共享将已满。 除非增加共享的大小或删除某些数据,否则无法添加更多数据。 基于额度的 IOPS 突发可以最大程度地尽量提高使用灵活性,同时额度保持不变。
预配的存储、IOPS 和吞吐量可以根据需要动态纵向扩展或缩减。 但是,自上次增加数量以来,只能在 24 小时后减少预配数量。 存储、IOPS 和吞吐量更改将在预置更改后的几分钟内生效。
默认情况下,使用预配的 v2 模型创建新的文件共享时,我们针对所需的 IOPS 数和吞吐量提供建议。 这是根据指定的预配存储量计算的。 这些建议基于所选媒体层预配存储量的典型客户使用情况。 但是,你可能会发现工作负荷需要的 IOPS 和吞吐量比“典型的文件共享”要多或少。在这种情况下,可以根据单个文件共享要求,选择预配或多或少 IOPS 和吞吐量。
预配 v2 的可用性
预配的 v2 模型适用于媒体层、冗余和文件共享协议的以下组合:
媒体层 | Redundancy | 文件共享协议 | 经典文件共享 (Microsoft.Storage ) |
---|---|---|---|
SSD | Local | SMB |
![]() |
SSD | 区域 | SMB |
![]() |
SSD | Local | NFS |
![]() |
SSD | 区域 | NFS |
![]() |
HDD | Local | SMB |
![]() |
HDD | 区域 | SMB |
![]() |
HDD | 地域 | SMB |
![]() |
HDD | GeoZone | SMB |
![]() |
HDD | Local | NFS |
![]() |
HDD | 区域 | NFS |
![]() |
HDD | 地域 | NFS |
![]() |
HDD | GeoZone | NFS |
![]() |
预配 v2 预配详细信息
创建预配 v2 文件共享时,需要在存储量、IOPS 和吞吐量方面指定文件共享的预配容量。 文件共享受到以下属性的限制:
条目 | SSD 值 | HDD 值 |
---|---|---|
存储预配单元 | 1 GiB | 1 GiB |
IOPS 预配单元 | 1 IO/秒 | 1 IO/秒 |
吞吐量预配单元 | 1 MiB/秒 | 1 MiB/秒 |
最低预配存储 | 32 GiB | 32 GiB |
最低预配的 IOPS | 3,000 IOPS | 500 IOPS |
最小预配吞吐量 | 100 MiB /秒 | 60 MiB/秒 |
最大预配存储数 | 256 TiB (262,144 GiB) | 256 TiB (262,144 GiB) |
预配的 IOPS 上限 | 102,400 IOPS | 50,000 IOPS |
预配吞吐量上限 | 10,340 MiB/秒 | 5,120 MiB/秒 |
默认情况下,我们建议根据指定的预配存储进行 IOPS 和吞吐量预配。 这些建议公式基于客户对 Azure 文件存储中该媒体层的预配存储量的典型使用情况:
公式名称 | SSD 公式 | HDD 公式 |
---|---|---|
IOPS 建议 | MIN(MAX(3000 + CEILING(1 * ProvisionedStorageGiB), 3000), 102400) |
MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000) |
吞吐量建议 | MIN(MAX(100 + CEILING(0.1 * ProvisionedStorageGiB), 100), 10340) |
MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120) |
根据单个文件共享要求,你可能会发现所需的 IOPS 或吞吐量比我们的建议要多或少。 可以选择根据需要使用自己的值替代这些建议。
预配 v2 突发
基于额度的 IOPS 突发提供更高的 IOPS 使用灵活性。 这种灵活性最适合用来缓冲意外的 IO 峰值。 对于已建立的 IO 模式,建议为 IO 峰值进行预配。
每当文件共享的流量低于预配(基线)IOPS 时,就会累积突发 IOPS 额度。 每当文件共享的 IOPS 使用量超过预配 IOPS 并且有可用的突发 IOPS 额度时,文件共享就会突发,直到允许的最大突发 IOPS 限制。 只要还有剩余额度,文件共享就可以基于累积的突发额度数量继续突发。 超出预配 IOPS 的每个 IO 都会消耗一个信用额度。 一旦用尽所有额度,共享就会返回到预配的 IOPS。 针对文件共享的 IOPS 无需采取任何特殊措施即可使用突发。 突发是按照尽力而为的原则进行的。
共享额度具有三种状态:
- 累积,当文件共享使用的 IOPS 少于预配的 IOPS 时将进入此状态。
- 下降,当文件共享使用的 IOPS 超过预配的 IOPS 且处于突发模式时,将进入此状态。
- 常量,当文件共享完全使用预配的 IOPS 并且没有累积或使用的信用额度时。
新文件共享最初在其突发桶中包含所有额度。 如果由于服务器限制导致共享 IOPS 低于预配的限制,则不会累积突发额度。 以下公式用于确定突发 IOPS 限制和文件共享可用的额度数量:
条目 | SSD 公式 | HDD 公式 |
---|---|---|
突发 IOPS 限制 | MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) |
MIN(MAX(3 * ProvisionedIOPS, 5000), 50000) |
突发 IOPS 额度 | (BurstLimit - ProvisionedIOPS) * 3600 |
(BurstLimit - ProvisionedIOPS) * 3600 |
下表演示了这些适用于各种预配 IOPS 量的公式的几个示例:
预配的 IOPS | SSD 突发 IOPS 限制 | SSD 突发额度 | HDD 突发 IOPS 限制 | HDD 突发额度 |
---|---|---|---|---|
500 | -- | -- | 最多 5,000 | 16,200,000 |
1,000 | -- | -- | 最多 5,000 | 14,400,000 |
3,000 | 最高 10,000 | 25,200,000 | 最多 9,000 | 21,600,000 |
5,000 | 最多 15,000 人 | 36,000,000 | 最多 15,000 人 | 36,000,000 |
1万 | 最多 30,000 | 72,000,000 | 最多 30,000 | 72,000,000 |
25,000 | 最多 75,000 | 180,000,000 | 最多 50,000 | 90,000,000 |
50,000 | 最大 102,400 | 188,640,000 | 最多 50,000 | 0 |
75,000 | 最大 102,400 | 98,640,000 | -- | -- |
102,400 | 最大 102,400 | 0 | -- | -- |
预配的 v2 资源模型
预配的 v2 经典文件共享(Microsoft.Storage)
若要使用预配的 v2 模型创建经典文件共享,存储帐户必须使用以下设置组合之一:
存储帐户类型 | 存储帐户 SKU | 可用的经典文件共享的类型 |
---|---|---|
FileStorage | PremiumV2_LRS | 已指定本地冗余的 SSD 预配 v2 经典文件共享。 |
FileStorage | PremiumV2_ZRS | 已指定区域冗余的 SSD 预配 v2 经典文件共享。 |
FileStorage | StandardV2_LRS | 已指定本地冗余的 HDD 预配 v2 经典文件共享。 |
FileStorage | StandardV2_ZRS | 已指定区域冗余的 HDD 预配 v2 经典文件共享。 |
FileStorage | StandardV2_GRS | HDD 预配的 v2 经典文件共享,并指定了异地冗余。 |
FileStorage | StandardV2_GZRS | 已指定异地区域冗余的 HDD 预配 v2 经典文件共享。 |
有关如何使用预配的 v2 模型创建经典文件共享的详细信息,请参阅 创建经典文件共享。
在同一存储帐户中创建的经典文件共享将与该存储帐户共享存储、IOPS 和吞吐量的限制。
Attribute | SSD 值 | HDD 值 | 强制策略 |
---|---|---|---|
每个存储帐户的最大预配存储 | 256 TiB (262,144 GiB) | 4 PiB(4,194,304) | 预配时。 |
每个存储帐户的最大预配 IOPS | 102,400 IOPS | 50,000 IOPS | 预配时。 |
每个存储帐户的最大预配吞吐量 | 10,340 MiB/秒 | 5,120 MiB/秒 | 预配时。 |
每个存储帐户的经典文件共享数上限 | 50 个经典文件共享 | 50 个经典文件共享 | 预配时。 |
若要使用经典文件共享上预配的 v2 计费模型正确部署 Azure 文件存储,需要考虑容量规划的以下维度:
每个经典文件共享需要多少预配的存储、IOPS 和吞吐量? 这些要求如何随时间而变化?
由于存储帐户具有共享限制,因此在将经典文件共享分配给存储帐户时,需要考虑现在和一段时间内每个经典文件共享的需求。 预配 v2 模型的预配逻辑可防止预配的存储、IOPS 或吞吐量超过存储帐户支持的吞吐量。 如果将足够多的经典文件共享放置在单个存储帐户中,以至于其中一个维度达到最大容量,那么除非首先迁移到其他存储帐户,否则现有的经典文件共享将无法增长。 若要降低此风险,请在每个存储帐户中规划足够的空间,以便可以保持经典文件共享到存储帐户的映射至少 3 到 5 年。你是否有特殊要求,需要将每个经典文件共享的账单追溯到单个项目、部门或客户?
在 Azure 中,可以看到计费的最低粒度是 资源,这意味着如果将两个经典文件共享放在同一存储帐户中,则无法轻松地将成本跟踪回单个项目、部门或客户。 若要解决此问题,请根据计费需求将经典文件共享分组到存储帐户中。目标区域的订阅中有多少个存储帐户可用?
另一个复杂因素是每个区域每个订阅可以拥有的存储帐户数。 有关详细信息,请参阅Microsoft.Storage
控制平面限制 。 根据所需的存储帐户数,可能需要使用其他订阅来实现其他存储帐户。
预配 v2 快照
Azure 文件存储支持快照,快照类似于 Windows 文件服务器上的卷影副本 (VSS)。 有关共享快照的详细信息,请参阅 Azure 文件存储的快照概述。
快照始终与实时共享以及彼此之间存在差异。 在预配的 v2 计费模型中,如果所有快照的总差异大小符合文件共享的超额预配存储空间,则快照存储不会产生额外的费用。 如果实时共享数据的大小加上差异快照数据大于共享的预配存储,则会根据“溢出快照使用量”计量对快照的超额使用容量计费。 用于确定溢出量的公式为:MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)
Azure 文件存储的一些增值服务使用快照作为其价值主张的一部分。 有关详细信息,请参阅 Azure 文件存储的增值服务。
预配的 v2 软删除
在启用了软删除的存储帐户中,已删除的文件共享是根据已定义的保留期已删除共享的已用存储容量计费的。 为了确保始终可以还原已删除的文件共享,预配的存储、IOPS 和共享吞吐量将计入存储帐户的限制,直到清除文件共享为止。 但是它们不会计费。 有关软删除的详细信息,请参阅如何在 Azure 文件共享上启用软删除。
预配 v2 计费计量
使用预配 v2 计费模型预配的文件共享按以下计费计量器进行计费:
- 预配的存储:预配的存储量(以 GiB 为单位)。
- 预配的 IOPS:预配的 IOPS(IO/秒)量。
- 预配的吞吐量 MiBPS:预配的吞吐量数量(以 MiB/秒为单位)。
- 溢出快照使用情况:任何使用量超过预配存储容量的差异快照使用量(以 GiB 为单位)。 有关详细信息,请参阅 预配的 v2 快照。
- 软删除使用量:用于软删除文件共享的存储容量(以 GiB 为单位)。 有关详细信息,请参阅预配 v2 软删除。
根据预配 v2 计费计量器每小时发出消耗单位。 例如,对于已预配 1024 GiB 的共享,你将看到:
- 根据“预配的存储”计量,一小时为 1,024 个单元。
- 根据“预配的存储”计量,一天的汇总量为 24,576 个单元。
- 根据月份中的天数,一个月的汇总单元数是可变的:
- 28 天(平年 2 月):根据“预配的存储”计量,688,128 个单元。
- 29 天(闰年 2 月):根据“预配的存储”计量,712,704 个单元。
- 30 天:根据“预配的存储”计量,737,280 个单元。
- 31 天:根据“预配的存储”计量,761,856 个单元。
预配的 v2 迁移
将 SMB Azure 文件共享从即用即付模型迁移到预配的 v2 计费模型的过程因是否使用 Azure 文件同步而异。
- 如果使用的是没有 Azure 文件同步的 Azure 文件存储,请参阅将文件从一个 SMB Azure 文件共享迁移到另一个 SMB Azure 文件共享。
- 如果使用的是 Azure 文件同步,请参阅使用 Azure 文件同步时,将文件从一个 Azure 文件共享迁移到另一个 Azure 文件共享。
预配版本 v1 模型
预配 v1 方法以固定费率提供存储量、IOPS 和吞吐量,与在本地存储解决方案中购买存储的方式类似。 在创建新的预配 v1 经典文件共享时,可以指定共享所需的存储量。同时,IOPS 和吞吐量是计算得出的参数。 Azure 文件的预配 v1 模型仅适用于 SSD 媒体层。
你预配的存储量决定了经典文件共享的有保证存储、IOPS 和吞吐量的使用限制。 例如,如果您配置了一个 2 TiB 的共享,并将 2 TiB 的数据上传到经典文件共享中,它就会满。 除非增加经典文件共享的大小或删除某些数据,否则无法添加更多数据。 基于额度的 IOPS 突发可以最大程度地尽量提高使用灵活性,同时额度保持不变。
与在本地购买存储不同,预配的 v1 经典文件共享可以根据需要动态纵向扩展或缩减。 但是,自上次增加存储以来,只能在 24 小时后减少预配的存储。 存储、IOPS 和吞吐量更改将在预置更改后的几分钟内生效。
可将预配共享的大小减至所用 GiB 以下。 如果这样做,则不会丢失数据,但仍会根据所用大小计费。 你将获得预配共享的性能,而不是使用的大小。
预配版本 v1 可用性
预配的 v1 模型适用于媒体层、冗余和文件共享协议的以下组合:
媒体层 | Redundancy | 文件共享协议 | 经典文件共享 (Microsoft.Storage ) |
---|---|---|---|
SSD | Local | SMB |
![]() |
SSD | 区域 | SMB |
![]() |
SSD | Local | NFS |
![]() |
SSD | 区域 | NFS |
![]() |
HDD | Local | SMB |
![]() |
HDD | 区域 | SMB |
![]() |
HDD | 地域 | SMB |
![]() |
HDD | GeoZone | SMB |
![]() |
HDD | Local | NFS |
![]() |
HDD | 区域 | NFS |
![]() |
HDD | 地域 | NFS |
![]() |
HDD | GeoZone | NFS |
![]() |
使用预配的 v1 模型的 SSD 经典文件共享在大多数 Azure 区域中已正式发布。 有关详细信息,请参阅 Azure 产品在各区域中的推出情况。
预配版本 v1 预配详细信息
创建预配的 v1 经典文件共享时,可以指定共享所需的存储量。 每预配一个 GiB,您就有权以固定比例获得更多的 IOPS 和吞吐量。 预配的 v1 经典文件共享基于以下属性进行限制:
条目 | 价值 |
---|---|
存储预配单元 | 1 GiB |
最低预配存储 | 100 GiB |
最低预配的 IOPS (计算) | 3,100 IOPS |
最小预配吞吐量(计算) | 110 MiB /秒 |
最大预配存储数 | 100 TiB (102,400 GiB) |
预配的最大 IOPS (计算) | 102,400 IOPS |
最大预配吞吐量(计算) | 10,340 MiB/秒 |
计算以下公式以确定在共享中分配的 IOPS 和吞吐量:
条目 | Formula |
---|---|
计算的预配(基准)IOPS | MIN(3000 + 1 * ProvisionedStorageGiB, 102400) |
计算预配吞吐量(MiB/秒) | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
根据单独的经典文件共享要求,你可能会发现所需的 IOPS 或吞吐量比预配公式提供的要多。 在这种情况下,需要预配更多存储才能获取所需的 IOPS 或吞吐量。
预配版本 v1 突发
基于额度的 IOPS 突发提供更高的 IOPS 使用灵活性。 这种灵活性最适合用来缓冲意外的 IO 峰值。 对于已建立的 IO 模式,建议为 IO 峰值进行预配。
每当经典文件共享的输入/输出流量小于配置的(基础)IOPS时,突发IOPS额度将累积。 每当经典文件共享的 IOPS 使用率超过预配的 IOPS 并且存在可用的突发 IOPS 额度时,经典文件共享可以突发到允许的最大突发 IOPS 限制。 只要还有剩余额度,经典文件共享就可以基于累积的突发额度数量继续突发。 超出预配 IOPS 的每个 IO 都会消耗一个信用额度。 使用所有信用额度后,经典文件共享将返回到预配的 IOPS。 针对经典文件共享的 IOPS 无需执行任何特殊操作即可使用突发。 突发是按照尽力而为的原则进行的。
共享额度具有三种状态:
- 当经典文件共享使用的 IOPS 小于预配的 IOPS 时,会进行积累。
- 下降,当经典文件共享使用的 IOPS 超过预配的 IOPS 且处于突发模式时,将进入此状态。
- 常量,当经典文件共享完全使用预配的 IOPS 并且没有累积或使用的信用额度时。
新经典文件共享最初在其突发桶中包含所有额度。 如果由于服务器限制导致共享 IOPS 低于预配的限制,则不会累积突发额度。 以下公式用于计算经典文件共享的突发 IOPS 限制和可能的积分数:
条目 | Formula |
---|---|
突增限制 | MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400) |
突发额度 | (BurstLimit - BaselineIOPS) * 3600 |
下表说明了预配大小的这些公式的几个示例:
容量(GiB) | 基准 IOPS | 突发 IOPS | 突发额度 | 吞吐量(MiB/秒) |
---|---|---|---|---|
100 | 3,100 | 最高 10,000 | 24,840,000 | 110 |
500 | 3,500 | 最高 10,000 | 23,400,000 | 150 |
1,024 | 4,024 | 最高 10,000 | 21,513,600 | 203 |
5,120 | 8,120 | 最大 15,360 | 26,064,000 | 613 |
10,240 | 13,240 | 最大 30,720 | 62,928,000 | 1,125 |
33,792 | 36,792 | 最大 102,400 | 227,548,800 | 3,480 |
51,200 | 54,200 | 最大 102,400 | 164,880,000 | 5,220 |
102,400 | 102,400 | 最大 102,400 | 0 | 10,340 |
预配的 v1 资源模型
预配的 v1 经典文件共享(Microsoft.Storage)
若要使用预配的 v1 模型创建经典文件共享,存储帐户必须使用以下设置组合之一:
存储帐户类型 | 存储帐户 SKU | 可用的文件共享类型 |
---|---|---|
FileStorage | Premium_LRS | 已指定本地 (LRS) 冗余的 SSD 预配 v1 文件共享。 |
FileStorage | Premium_ZRS | 指定了具有区域 (ZRS) 冗余的 SSD 已预配 v1 文件共享。 |
有关如何使用预配的 v1 模型创建经典文件共享的详细信息,请参阅 创建经典文件共享。
在同一存储帐户中创建的经典文件共享将与该存储帐户共享存储、IOPS 和吞吐量的限制。
Attribute | SSD 值 | 强制策略 |
---|---|---|
每个存储帐户的最大预配存储 | 100 TiB (102,400 GiB) | 预配时 |
每个存储帐户使用的最大 IOPS | 102,400 IOPS | 可以预配超过 102,400 IOPS,但超出此限制的使用量会受到限制。 |
每个存储帐户使用的最大吞吐量 | 10,340 MiB/秒 | 可以预配超过 10,340 MiB/秒,但超出此限制的使用量会受到限制。 |
每个存储帐户的经典文件共享数上限 | 1,024 个经典文件共享 | 此限制由存储帐户的最大预配存储隐式强制实施。 |
若要使用经典文件共享上预配的 v1 计费模型正确部署 Azure 文件存储,需要考虑容量规划的以下维度:
每个经典文件共享需要多少预配的存储、IOPS 和吞吐量? 这些要求如何随时间而变化?
由于共享存储帐户的限制,将经典文件共享分配给存储帐户时,需要考虑一段时间后每个经典文件共享的需求。 预配 v1 模型的逻辑可防止配置的存储量超过存储帐户的支持限额。 虽然允许预配的 IOPS 和吞吐量超过存储帐户提供的吞吐量,但不能使用超过存储帐户对 IOPS 和吞吐量的限制。 为了避免意外的性能限制,请不要预配超过存储帐户支持的 IOPS 或吞吐量。此外,在存储帐户中放置过多的经典文件共享可能会限制将来的增长。 存储帐户已满后,无需先将一些经典文件共享迁移到另一个存储帐户,就无法扩展现有经典文件共享。 为降低这种风险,请在存储帐户中预留足够的空余空间,以便你能够在至少 3 到 5 年内维持经典文件共享与存储帐户之间的映射关系。
你是否有特殊要求,需要将每个经典文件共享的账单追溯到单个项目、部门或客户?
在 Azure 中,可以看到计费的最低粒度是 资源,这意味着如果将两个经典文件共享放在同一存储帐户中,则无法轻松地将成本跟踪回单个项目、部门或客户。 若要解决此问题,请根据计费需求将经典文件共享分组到存储帐户中。目标区域的订阅中有多少个存储帐户可用?
另一个复杂因素是每个区域每个订阅可以拥有的存储帐户数。 有关详细信息,请参阅Microsoft.Storage
控制平面限制 。 根据所需的存储帐户数,可能需要使用其他订阅来实现其他存储帐户。
预配版本 v1 快照
Azure 文件存储支持快照,快照类似于 Windows 文件服务器上的卷影副本 (VSS)。 有关共享快照的详细信息,请参阅 Azure 文件存储的快照概述。
快照始终与实时共享以及彼此之间存在差异。 在预配的 v1 计费模型中,无论有多少预配的存储未使用,总差异大小都是根据使用量计费的。 与预配存储价格相比,所用的快照存储计量器的价格更低。
预配版本 v1 软删除
在启用了软删除的存储帐户中,被删除的经典文件共享在定义的保留期内根据其已用存储容量进行计费。 已软删除的使用存储容量是根据所用快照存储计量器发出的。 有关软删除的详细信息,请参阅如何在 Azure 文件共享上启用软删除。
预配版本 v1 计费计量器
使用 v1 计费模型预配的经典文件共享将根据以下计量进行计费:
- 高级预配:以 GiB 为单位预配的存储量。
- 高级快照:已使用的快照数量和已使用的软删除容量。
根据预配 v1 计费计量的消耗量每小时发出一次,以每月单元数为单位。 例如,对于已预配 1024 GiB 的共享,你将看到:
- 根据月份的天数,单个小时的单位数量是可变的:
- 只有 28 天的月份(常规年份的二月):根据 Premium Provisioned 计量器为 1.5238 个单位。
- 只有 29 天的月份(闰年的二月):根据 Premium Provisioned 计量器为 1.4713 个单位。
- 有 30 天的月份:根据 Premium Provisioned 计量器为 1.4222 个单位。
- 有 31 天的月份:根据 Premium Provisioned 计量器为 1.3763 个单位。
- 如果按天聚合,则单位数量会根据当月的天数而变化:
- 只有 28 天的月份(常规年份的二月):根据 Premium Provisioned 计量器为 36.5714 个单位。
- 只有 29 天的月份(闰年的二月):根据 Premium Provisioned 计量器为 35.3103 个单位。
- 有 30 天的月份:根据 Premium Provisioned 计量器为 34.1333 个单位。
- 有 31 天的月份:根据 Premium Provisioned 计量器为 33.0323 个单位。
- 如果按月聚合,则根据“高级预配”计量器为 1,024 个单位。
即用即付模型
在即用即付模型中,你根据使用的存储量(而不是预配的存储量)计费。 概括来讲,你需要为存储的逻辑数据量支付成本,还需要根据你对此数据的使用情况支付事务费用。 作为预算流程的一部分,您可能很难为即用即付型服务制定计划,因为是根据终端用户的消耗付费。 因此,我们建议为新的经典文件共享部署使用 预配的 v2 模型 。 即用即付模型仅适用于 HDD 存储。
即用即付可用性
即用即付模型适用于媒体层、冗余和文件共享协议的以下组合:
媒体层 | Redundancy | 文件共享协议 | 经典文件共享 (Microsoft.Storage ) |
---|---|---|---|
SSD | Local | SMB |
![]() |
SSD | 区域 | SMB |
![]() |
SSD | Local | NFS |
![]() |
SSD | 区域 | NFS |
![]() |
HDD | Local | SMB |
![]() |
HDD | 区域 | SMB |
![]() |
HDD | 地域 | SMB |
![]() |
HDD | GeoZone | SMB |
![]() |
HDD | Local | NFS |
![]() |
HDD | 区域 | NFS |
![]() |
HDD | 地域 | NFS |
![]() |
HDD | GeoZone | NFS |
![]() |
使用即用即付模型的 HDD 经典文件共享已在所有 Azure 区域中正式发布。
访问层的差异
在即用即付存储帐户中创建经典文件共享时,可在以下访问层之间进行选择:事务优化、热和冷。 所有三个访问层都存储在完全相同的存储硬件上。 这三个访问层的主要区别是静态数据存储价格(层级越冷,价格越低)和事务价格(层级越冷,价格越高)。 这意味着:
- 事务优化,顾名思义,是为了优化高 IOPS(事务)工作负荷的成本。 事务优化层的静态数据存储价格最高,但事务价格最低。
- 热层适用于不涉及大量事务的活动工作负载。 与事务优化层相比,它的静态数据存储价格略低,但事务价格略高。 可以将它看作是事务优化层和冷层之间的中间地带。
- 冷层为没有大量活动工作负载优化了价格,提供了最低的静态数据存储价格,但事务价格最高。
为用例选择适当的访问层可以大大降低你的成本。 如果您将不经常访问的工作负荷放置在事务优化访问层,那么在一个月内针对经典文件共享进行的几次事务中,您几乎不需要支付什么费用。 但是,需要为数据存储成本支付大量费用。 如果你将此同一共享迁移到冷访问层中,则仍然几乎不用支付事务成本,这仅仅是因为你很少为此工作负载执行事务。 但是,冷访问层的数据存储价格更便宜。
同样,如果在冷访问层中放置了高度访问的工作负荷,则会在事务成本方面支付更多费用,但数据存储成本较低。 这可能会导致一种情况,即事务价格上涨带来的成本增加超过了数据存储价格下降带来的金额节省,导致你在冷层中支付的成本可能多于事务优化层。 对于某些使用级别,热访问层可能是最具成本效益的层,而冷访问层比事务优化更昂贵。
您的工作负荷和活动级别决定了最适合您的按需付费经典文件共享的成本效益最高的访问层级。 在实践中,选择最具成本效益的访问层的最佳方法是,查看共享的实际资源使用量(存储的数据量、写入的事务量等)。 对于即用即付经典文件共享,建议在初始迁移到 Azure 文件存储期间从事务优化层开始,然后在迁移完成后根据使用情况选取正确的访问层。 迁移期间的事务使用情况通常不指示正常的事务使用情况。
什么是事务?
使用 SMB 在计算机上挂载基于即用即付模型的经典文件共享时,该文件共享将在您的计算机上显示为本地存储。 这意味着计算机上的应用程序、脚本和其他程序可以访问经典文件共享上的文件和文件夹,而无需知道它们存储在 Azure 中。
读取或写入文件时,所使用的应用程序会对操作系统提供的文件系统 API 执行一系列 API 调用。 然后,操作系统将这些调用解释为 SMB 协议事务,这些事务通过线路发送到 Azure 文件存储来履行。 最终用户认为是单一操作的简单任务(例如完整读取文件),可能被转换为由 Azure 文件存储处理的多个 SMB 事务。
传统文件共享在计费上采用即用即付模式,根据使用量收费。 应用程序和脚本进行的 SMB 和 FileREST 事务表示经典文件共享的使用,它们显示为帐单的一部分。 同一概念适用于可添加到共享中的增值云服务,例如 Azure 文件同步或 Azure 备份。
事务分为五个不同的交易类别,这些交易类别根据它们对经典文件共享的影响而有不同的价格。 这些类别为:写入、列出、读取、其他和删除。
下表显示了每个事务的分类:
事务 Bucket | 管理操作 | 数据操作 |
---|---|---|
写入事务 |
|
|
列出事务 |
|
|
读取事务 |
|
|
其他/协议交易 |
|
|
删除交易 |
|
|
Note
NFSv4.1 仅适用于使用预配的 v2 或预配的 v1 计费模型的 SSD 文件共享。 事务桶不会影响已预配文件共享的计费。
在访问层之间切换
尽管可以使用即用即付模型更改经典文件共享的访问层,但在初始迁移后优化成本的最佳做法是选择最成本最佳的访问层,除非访问模式发生更改,否则请保留该层。 这是因为更改经典文件共享的访问层会产生额外的成本,如下所示:
事务:在将共享从更热的访问层移动到更冷的访问层时,经典文件共享中每个文件将产生更冷访问层的写入事务费用。 将经典文件共享从较冷的访问层移动到更热的访问层会产生较冷的访问层对经典文件共享中每个文件的读取事务费用。
数据检索:如果从冷访问层移动到热访问层或事务优化访问层,则将根据移动的数据大小产生相应的数据检索费用。 只有冷访问层会产生数据检索费用。
下表说明了移动访问层的成本明细:
访问层 | 事务优化(目的地) | 热门目的地 | 酷炫目的地 |
---|---|---|---|
事务优化(源) | -- |
|
|
热(源) |
|
-- |
|
冷(源) |
|
|
-- |
可以在 30 天内更改经典文件共享的访问层最多五次。 当第一个层级发生更改时,30天窗口期的第一天开始。 虽然在不同访问层之间的更改会立即生效,但是一旦更改了共享的访问层,即使在过去 30 天内更改访问层属性的次数少于 5 次,也无法在 24 小时内再次进行更改。
选择访问层
无论如何将现有数据迁移到 Azure 文件存储,我们建议最初在事务优化访问层中创建经典文件共享。 这是因为迁移期间发生的事务数过多。 迁移完成后,经过几天或几周的常规使用,您可以将事务计数输入 定价计算器 ,以确定哪一访问层最适合您的工作负载。
由于即用即付存储帐户仅显示存储帐户级别的事务信息,因此在经典文件共享级别使用存储指标来估算哪个访问层费用更低并不是十分精确的方法。 如果可能,我们建议在每个存储帐户中仅部署一个经典文件共享,以确保清晰了解计费。
若要查看以前的事务,请执行以下操作:
- 在 Azure 门户中导航到你的存储帐户。
- 在服务菜单中的监视下面,选择指标。
- 选择“范围”作为存储帐户名称,选择“指标命名空间”作为“文件”,选择“指标”作为“事务”,选择“聚合”作为“总和”。
- 选择“应用拆分”。
- 选择“值”作为“API 名称”。 选择所需的“限制”和“排序”。
- 选择所需的时间段。
Note
请确保在足够长的时间内查看事务,以便了解事务的平均数量。 确保所选时间段不与初始设置重叠。 将此时间段内的平均事务数相乘,以获取整月的估计事务数。
即用即付资源模型
按需付费经典文件共享(Microsoft.Storage)
若要使用即用即付模型创建经典文件共享,存储帐户必须使用以下设置组合之一:
存储帐户类型 | 存储帐户 SKU | 可用的文件共享类型 |
---|---|---|
StorageV2 | Standard_LRS | 指定了本地 (LRS) 冗余的 HDD 即用即付文件共享。 |
StorageV2 | Standard_ZRS | 指定了区域 (ZRS) 冗余的 HDD 即用即付文件共享。 |
StorageV2 | Standard_GRS | 指定了异地 (GRS) 冗余的 HDD 即用即付文件共享。 |
StorageV2 | Standard_GZRS | 指定了异地区域 (GZRS) 冗余的 HDD 即用即付文件共享。 |
StorageV2 | Standard_RAGRS | 指定了异地 (GRS) 冗余的 HDD 即用即付文件共享。 |
StorageV2 | Standard_RAGZRS | 指定了异地区域 (GZRS) 冗余的 HDD 即用即付文件共享。 |
在同一存储帐户中创建的经典文件共享将与该存储帐户共享存储、IOPS 和吞吐量的限制。
Attribute | HDD 值 | 强制策略 |
---|---|---|
每个存储帐户使用的最大存储数 | 5 PiB (5,242,880) | 使用量上限。 |
每个存储帐户使用的最大 IOPS |
|
超出限制的使用量会受到限制。 |
每个存储帐户使用的最大吞吐量 |
|
超出限制的使用量会受到限制。 |
每个存储帐户的经典文件共享数上限 | 无限制 | 存储、IOPS 和吞吐量限制是指对经典文件共享数量的实际限制。 |
有关更多详细信息,请参阅 存储帐户数据平面限制 ,包括哪些区域支持提高 IOPS 和吞吐量的限制。
若要使用经典文件共享上的即用即付计费模型正确部署 Azure 文件,需要考虑容量规划的以下维度:
每个经典文件共享所需的存储、IOPS 和吞吐量是多少? 这些要求如何随时间而变化?
由于共享存储帐户的限制,将经典文件共享分配给存储帐户时,需要考虑一段时间后每个经典文件共享的需求。 与预配的 v2 和预配的 v1 模型不同,即用即付模型仅提供有限的保护,帮助你在同一存储帐户中的经典文件共享之间共享存储帐户的限制。 在即用即付存储帐户中,每个经典文件共享的容量可以达到经典文件共享大小的上限,同时在 IOPS 和吞吐量方面可以达到存储帐户的限制。 将两个经典文件共享合并到一个按需付费的存储帐户中,可能会引起 IOPS 或吞吐量的争用。 为了避免意外的带宽限制,请限制在按需付费存储帐户中放置的经典文件共享数。你是否有特殊要求,需要将每个经典文件共享的账单追溯到单个项目、部门或客户?
在 Azure 中,可以看到计费的最低粒度是 资源,这意味着如果将两个经典文件共享放在同一存储帐户中,则无法轻松地将成本跟踪回单个项目、部门或客户。 若要解决此问题,请根据计费需求将经典文件共享分组到存储帐户中。目标区域的订阅中有多少个存储帐户可用?
另一个复杂因素是每个区域每个订阅可以拥有的存储帐户数。 有关详细信息,请参阅Microsoft.Storage
控制平面限制 。 根据所需的存储帐户数,可能需要使用其他订阅来实现其他存储帐户。
即用即付快照
Azure 文件存储支持快照,快照类似于 Windows 文件服务器上的卷影副本 (VSS)。 有关共享快照的详细信息,请参阅 Azure 文件存储的快照概述。
快照始终与实时共享以及彼此之间存在差异。 在即用即付计费模型中,总差异大小是按照正常使用的存储计量器来计费的。 这意味着,你不会在账单中看到代表即用即付存储帐户快照的独立行项。 这也意味着差异快照的使用会计算在为即用即付经典文件共享购买的预留配额中。
即用即付软删除
在启用软删除的存储帐户中,被删除的经典文件共享会根据使用的存储容量在定义的保留期内计费。 已软删除的已用存储容量是根据正常使用的存储计量器发出的。 这意味着,您不会在账单上看到代表您的按需付费存储帐户中已软删除的经典文件共享的单独行项。 这也意味着,即便是处于软删除状态的经典文件共享,它们的使用量仍会计入购买的即用即付经典文件共享的预留配额中。
即用即付计费计量器
使用即用即付计费模型创建的经典文件共享服务按以下计量器计费:
- 数据存储:已使用的存储空间,包括实时共享文件、差异快照文件和软删除的经典文件共享,以 GiB 为单位。
- 元数据:与文件和目录(例如访问控制列表 (ACL) 和 GiB 中的其他属性)关联的文件系统元数据的大小。 此计费计量仅适用于热访问层或冷访问层中的经典文件共享。
- 写入操作数:写入事务存储桶数(1 个存储桶 = 10,000 个事务)。
- 列表操作:列表事务存储桶数(一个存储桶 = 10,000 个事务)。
- 读取操作:读取事务存储桶数(一个存储桶 = 10,000 个事务)。
- 其他操作 / 协议操作:其他事务存储桶的数量(一个存储桶 = 10,000 个事务)。
- 数据检索:从 GiB 中的经典文件共享读取的数据量。 此计量仅适用于冷访问层中的经典文件共享。
- 异地复制数据传输:如果经典文件共享具有异地或异地区域冗余,写入到经典文件共享的复制到次要区域的数据量(以 GiB 为单位)。
根据“存储的数据”和“元数据”计费计量器计算的消耗单位以月为单位每小时发出。 例如,对于已使用 1,024 GiB 的共享,你将看到:
- 根据月份的天数,单个小时的单位数量是可变的:
- 只有 28 天的月份(常规年份的二月):根据“存储的数据”计量器为 1.5238 个单位。
- 只有 29 天的月份(闰年的二月):根据“存储的数据”计量器为 1.4713 个单位。
- 有 30 天的月份:根据“存储的数据”计量器为 1.4222 个单位。
- 有 31 天的月份:根据“存储的数据”计量器为 1.3763 个单位。
- 如果按天聚合,则单位数量会根据当月的天数而变化:
- 只有 28 天的月份(常规年份的二月):根据“存储的数据”计量器为 36.5714 个单位。
- 只有 29 天的月份(闰年的二月):根据“存储的数据”计量器为 35.3103 个单位。
- 有 30 天的月份:根据“存储的数据”计量器为 34.1333 个单位。
- 有 31 天的月份:根据“存储的数据”计量器为 33.0323 个单位。
- 如果按月聚合,则根据“存储的数据”计量器为 1,024 个单位。
根据其他计量(例如“写入操作数”或“数据检索”)的消耗量每小时发出一次,但由于这些计量项目没有与之关联的特定时间范围,因此不涉及需要特别注意的单位换算。
预配/配额、逻辑大小和物理大小
Azure 文件存储跟踪与共享容量相关的三个不同的数量:
预配大小或配额:对于预配和即用即付文件共享,可以指定允许文件共享增长到的最大大小。 在预配文件共享中,此值称为预配大小。 无论预配了多少数量,你都需要按照此数量付费,而与实际使用量无关。 在按需付费文件共享中,此值称为配额,不会直接影响账单。 “预配大小”是预配文件共享的必填字段。 对于即用即付文件共享,如果未直接指定预配大小,则共享默认为存储帐户支持的最大值(100 TiB)。
逻辑大小:文件共享或文件的逻辑大小与文件大小相关,而无需考虑实际存储的方式,而无需进行任何存储优化。 文件的逻辑大小指的是如果将它复制到其他位置,通过网络需要传输的 KiB/MiB/GiB 的数量。 在预配和即用即付文件共享中,文件共享的逻辑总大小用于执行对预配大小/配额的限制。 在即用即付文件共享中,逻辑大小是用于静态数据使用量计费的数量。 逻辑大小在文件/文件夹的 Windows 属性对话框中称为“大小”,在 Azure 文件存储指标中称为“内容长度”。
物理大小:文件的物理大小与在磁盘上编码的文件大小相关。 物理大小可能与文件的逻辑大小保持一致,也可能更小,具体取决于作系统写入文件的方式。 逻辑大小和物理大小不同的一个常见原因是使用了稀疏文件。 共享中文件的物理大小用于快照计费,但如果快照未更改(差异存储),则分配的范围在快照之间共享。
增值服务
与许多本地存储解决方案一样,Azure 文件存储为第一方和第三方产品提供集成点,以便与客户拥有的文件共享集成。 尽管这些解决方案可为 Azure 文件存储提供可观的额外价值,但你应该考虑到,这些服务也会增加 Azure 文件存储解决方案的总成本。
成本分为三类:
增值服务的许可成本。 许可成本可能以每个客户、最终用户(有时称为“头成本”)、文件共享或存储帐户的固定成本形式出现。 它们也可能基于存储利用率单位,例如文件共享中每 500 GiB 数据块的固定成本。
增值服务的事务成本。 某些增值服务在所选 Azure 文件存储计费模型的基础上有自己的事务概念。 这些交易根据增值服务的费用显示在帐单上;但是,它们与将增值服务与文件共享配合使用的方式直接相关。
使用增值服务产生的 Azure 文件存储成本。 Azure 文件存储不直接向客户收取添加增值服务的费用,但在为 Azure 文件共享增值的同时,增值服务可能会增大 Azure 文件共享的成本。 由于事务费用,这些成本在即用即付文件共享中很容易看到。 如果增值服务代表你对文件共享执行事务,即使你自己没有直接执行这些事务,它们也会显示在 Azure 文件事务帐单中。 这也适用于预配文件共享,不过,这种影响可能不太明显。 增值服务对预配文件共享执行的事务将计入预配的 IOPS 数量,这意味着,增值服务可能需要预配更多存储,以便为工作负荷提供足够的 IOPS 或吞吐量。
在计算文件共享的总拥有成本时,应该考虑 Azure 文件存储的成本,以及要与 Azure 文件存储配合使用的所有增值服务的成本。
有多种增值第一方和第三方服务。 本文档将介绍客户与 Azure 文件共享配合使用的一部分常见第一方服务。 对于此处未列出的服务,可以阅读其定价页来了解详细信息。
Azure 文件同步
Azure 文件同步是适用于 Azure 文件存储的一个增值服务,它可以将一个或多个本地 Windows 文件共享与 Azure 文件共享同步。 由于云 Azure 文件共享具有本地已同步文件共享中数据的完整副本,因此你可以将本地 Windows 文件服务器转换为 Azure 文件共享的缓存,以减少本地占用空间。 请阅读 Azure 文件同步简介了解详细信息。
在考虑使用 Azure 文件同步部署的解决方案的总拥有成本时,请考虑以下成本方面:
具有一个或多个服务器终结点的 Windows 文件服务器的资本和运营成本。 Azure 文件同步作为一种复制解决方案,可以不依赖于与 Azure 文件同步的 Windows 文件服务器的位置; 这些服务器可以托管在本地、Azure 虚拟机中,甚至在其他云环境中。 在本地或其他云提供商中托管的同步服务器的成本包括未作为 Azure 帐单的一部分跟踪的资本和运营成本,但仍是解决方案总拥有成本的一部分。 资本开支是解决方案的前期硬件成本。 运营费用是劳动力、电力等持续成本。应考虑需要在本地缓存的数据量、Windows 文件服务器需要托管 Azure 文件同步工作负荷所需的 CPU 数和内存量,以及你可能拥有的其他组织特定的成本。 有关详细信息,请参阅 建议的系统资源。
注册到 Azure 文件同步的服务器的每服务器许可成本。要将 Azure 文件同步与特定的 Windows 文件服务器一起使用,必须先将它注册到 Azure 文件同步的 Azure 资源(即存储同步服务)。 除了第一台服务器之外,您注册的每台服务器都有固定的每月费用。 虽然此费用很小,但它是您账单中的一个重要组成部分,需要考虑。 若要查看所需区域的服务器注册费的当前价格,请参阅 Azure 文件存储定价页上的“文件同步”部分。
Azure 文件存储成本。 Azure 文件同步使用 Azure 文件共享中的资源。 其中一些资源(如存储消耗)相对明显,而其他资源(如事务和快照利用率)可能不明显。 对于大多数客户,我们建议将 HDD 预配的 v2 文件共享与 Azure 文件同步配合使用,尽管所有 Azure 文件存储计费模型都完全支持 Azure 文件同步(SSD 预配 v2、SSD 预配 v1 或 HDD 标准预付费套餐)。
存储利用率。 Azure 文件同步会将对服务器终结点所做的任何更改复制到 Azure 文件共享,从而导致存储被使用。 在预配的文件共享上,更改会占用预配的空间,因此你有责任定期增加预配,以考虑文件共享的增长。 在标准预付费产品的文件共享服务中,添加或增加服务器终结点上现有文件的大小会导致已用存储成本的增长,因为更改会被复制。
快照利用率。 Azure 文件同步将共享和文件级快照作为常规使用的一部分。 尽管快照利用率始终是不同的,但这可能会对 Azure 文件存储总帐单产生明显的影响。
IOPS/吞吐量利用率:Azure 文件同步驱动 IOPS 和吞吐量利用率,以将更改从服务器终结点传输到 Azure 文件共享。 如果您使用预配的文件共享,您应该监视文件共享的使用情况,以确保预配了足够的 IOPS 和吞吐量,以避免性能受限。 如果使用标准预付费套餐文件共享,则以事务形式收取 IOPS 利用率费用。 通常,需要考虑两种类型的事务:
变动后产生的事务。 服务器终结点上的文件发生更改时,更改会上传到云共享,从而生成事务。 启用云分层时,除了传出成本之外,还会生成用于管理分层文件的额外事务,包括分层文件上发生的 I/O。 尽管由于流失率和缓存效率,事务的数量和类型很难预测,但如果你认为将来的使用情况会与当前使用情况相似,可以使用以前的事务模式来估算将来的成本。
云枚举后产生的事务。 Azure 文件同步每日枚举一次云中的 Azure 文件共享,以发现直接对共享所做的更改,以便它们可以同步到服务器终结点。 此扫描会生成事务,这些事务将按照每日每个目录一个
ListFiles
事务的费率向存储帐户计费。 可以将此数字输入定价计算器中,以估算扫描成本。
Tip
如果不知道所具有的文件夹数量,请查看 JAM Software GmbH 提供的 TreeSize 工具。
Azure 备份
Azure 备份为 Azure 文件存储提供无服务器备份解决方案,该解决方案可与文件共享及其他增值服务(例如 Azure 文件同步)无缝集成。适用于 Azure 文件存储的 Azure 备份是一种基于快照的备份解决方案,可提供一种计划机制用于按照管理员定义的计划自动创建快照。 它还提供一个易用的界面,用于将已删除的文件/文件夹或整个共享还原到特定的时间点。 若要了解详细信息,请参阅关于 Azure 文件共享备份。
考虑使用 Azure 备份的成本时,请考虑以下因素:
Azure 文件共享数据的受保护实例许可成本。 Azure 备份对包含已备份 Azure 文件共享的每个存储帐户收取受保护实例许可费用。 受保护实例定义为 250 GiB 的 Azure 文件共享存储。 包含少于 250 GiB 的存储帐户将按照部分受保护实例成本收费。 有关详细信息,请参阅 Azure 备份定价。 请注意,必须从 Azure 备份可以保护的服务列表中选择“Azure 文件存储”。
Azure 文件存储成本。 Azure 备份在以下方面增大 Azure 文件存储的成本:
Azure 文件共享快照产生的差异成本。 Azure 备份按照管理员定义的计划自动创建 Azure 文件共享快照。 快照始终是差异性的;但是,增加的成本取决于快照的保留时长,以及在这段时间内文件共享的流动量。 这些因素决定了快照与实时文件共享的差异程度,因此影响 Azure 文件存储的额外数据量。
还原操作产生的事务成本。 从快照还原到实时共享的操作会导致事务成本。 对于标准文件共享,从快照读取/从还原写入将按正常文件共享事务计费。 对于预配的文件共享,这些操作会消耗文件共享的预配IOPS。
Microsoft 存储保护者 (Microsoft Defender for Storage)
作为 Microsoft Defender 产品的一部分,Microsoft Defender for Storage 支持 Azure 文件存储。 Microsoft Defender for Storage 可以检测通过 SMB 或 FileREST 对 Azure 文件共享进行访问或利用的非寻常且可能有害的企图。 Microsoft Defender for Storage 将在订阅级别启用,以覆盖该订阅中存储帐户内的所有文件共享。
Microsoft Defender for Storage 不支持 Azure 文件共享的防病毒功能。
Microsoft Defender for Storage 的主要成本产生于该产品在针对 Azure 文件共享执行的事务上征收的一系列额外事务成本。 尽管这些成本基于 Azure 文件存储中发生的事务,但它们不是 Azure 文件存储计费的一部分,而是 Microsoft Defender 定价的一部分。 Microsoft Defender for Storage 甚至对预配文件共享收取事务费,其中 Azure 文件存储将事务包含为 IOPS 预配的一部分。 可以在 Microsoft Defender for Cloud 定价页上的“Microsoft Defender for Storage”表行下找到当前事务费率。
使用 Microsoft Defender for Storage 产品时,事务繁重的文件共享会导致显著的成本。 面对这些成本,你可能希望为特定的存储帐户选择禁用 Microsoft Defender for Storage。 有关详细信息,请参阅在 Microsoft Defender for Storage 保护中排除存储帐户。