评估 Azure 存储的数据冗余选项
数据可用性对大多数组织来说都是业务关键。
假设你的客户偶尔会在访问音乐流时遇到问题。 进行调查后,你发现这些问题发生在影响整个区域的中断期间。 这种情况很少发生,但影响很大。
为了提高公司的数据可用性,你决定调查适用于 Azure 存储的复制选项。
在此,你将探索 Azure 存储的不同复制选项。 你将了解它们如何工作,以及何时使用它们。 你还将了解如何在它们之间切换和迁移数据。
Azure 存储的复制选项
在 Azure 存储中,你有多个复制选项。 你的选择取决于你所需的复原能力级别。
本地冗余存储
本地冗余存储 (LRS) 在一个区域内的某个数据中心中的不同硬件机架上复制数据三次。 即使出现硬件故障,或者数据中心正在维护,这种复制类型也可以确保数据可供使用。
LRS 无法保护你免受数据中心范围内中断的影响。 如果数据中心出故障,你可能会丢失数据。
异地冗余存储
使用异地冗余存储 (GRS),你的数据在一个区域内复制了三次,在与该区域配对的次要区域中也复制了三次。 这样,如果主要区域发生中断,则次要区域可供使用。
读取访问异地冗余存储
使用 GRS,在主要区域发生故障之前,次要区域不可用于读取访问。 如果主要区域没有出现故障,但你想要从次要区域读取数据,可使用读取访问异地冗余存储 (RA-GRS) 作为复制类型。
区域冗余存储
区域冗余存储 (ZRS) 将数据复制到单个区域中的三个存储群集中。 每个群集位于不同的物理位置,并被视为单个可用性区域。 每个群集都使用自己单独的实用程序来处理诸如网络和电源之类的事情。 如果一个数据中心出现中断,仍可以从同一 Azure 区域中的另一个可用性区域访问你的数据。
由于所有可用性区域都在一个区域中,因此 ZRS 无法保护你的数据免受区域级中断的影响。
异地区域冗余存储
异地区域冗余存储 (GZRS) 将 ZRS 的高可用性优势与 GRS 相结合。 使用此复制类型,你的数据将跨一个区域中的三个可用性区域进行复制。 数据还会被复制三次到与该区域配对的另一个次要区域。 通过这种方式,你的区域冗余数据也不会受到区域级中断的影响。
读取访问权限异地区域冗余存储
读取访问异地区域冗余存储 (RA-GZRS) 使用与 GZRS 相同的复制方法,但可让你从次要区域进行读取。 如果即使主要区域没有发生停机,你也想要读取复制到次要区域的数据,可使用 RA-GZRS 作为复制类型。
GZRS 和 RA-GZRS 目前在以下区域提供:
- 南非北部
- 澳大利亚东部
- 东亚
- Japan East
- 韩国中部
- 东南亚
- 印度中部
- 法国中部
- 德国中西部
- 北欧
- 挪威东部
- 瑞典中部
- 瑞士北部
- 英国南部
- 西欧
- 加拿大中部
- 美国中部
- 美国东部
- 美国东部 2
- 美国中南部
- 美国西部 2
- 美国西部 3
- US Gov 弗吉尼亚州
- 巴西南部
配对区域
配对区域是指一个 Azure 区域与同一地理位置的另一个区域配对,以防止发生区域中断的位置。 配对区域用于 GRS 和 GZRS 复制类型。
下面是一个列表,显示了一些配对在一起的区域。 可以在 Azure 配对区域获取完整列表。
区域 | 区域 | |
---|---|---|
亚洲 | 东亚 | 东南亚 |
澳大利亚 | 澳大利亚东部 | 澳大利亚东南部 |
加拿大 | 加拿大中部 | 加拿大东部 |
中国 | 中国北部 | 中国东部 |
欧洲 | 北欧(爱尔兰) | 西欧(荷兰) |
日本 | 日本东部 | 日本西部 |
北美 | 美国东部 | 美国西部 |
南非 | 南非北部 | 南非西部 |
英国 | 英国西部 | 英国南部 |
每种复制类型的用例
下表总结了对于每种复制类型,你可以获得的副本数,以及何时应该使用该类型。
复制类型 | 副本 | 使用案例 |
---|---|---|
LRS | 3 | 数据保持高度可用,但是由于符合性原因,不允许数据离开本地数据中心。 |
GRS | 6 | 即使整个区域发生中断,应用也可以访问数据。 |
RA-GRS | 6 | 应用从多个地理位置读取数据,因此你可以从更接近用户的位置为用户提供服务。 |
ZRS | 3 | 需要在多个物理位置实现冗余,但由于符合性原因,数据不允许离开区域。 |
GZRS | 6 | 即使主要区域发生故障,并且次要区域的一个数据中心正遭遇中断,应用也可以访问数据,但除非主要区域已停机,否则不需要从次要区域进行读取。 |
RA-GZRS | 6 | 定期从次要区域读取数据,可能是为了从离用户较近的位置为用户提供服务,即使主要区域有一个数据中心已启动也是如此。 |
切换复制策略
可以为任何存储帐户切换复制策略。 你使用的过程取决于你帐户的当前复制策略。 例如,如果要使用 LRS 从存储帐户进行迁移,你有两个选择:
- 使用 GZRS 手动将数据移动或复制到新帐户。
- 首先将复制类型切换为 GRS/RA-GRS,然后创建一个 Azure 支持请求,以便实时迁移到 GZRS。
转换帐户
如果你使用的是 ZRS 帐户,可以将其转换为使用 GZRS。 你可以使用 Azure 门户、Azure CLI 或 Azure PowerShell 转换帐户。
例如,若要使用 Azure PowerShell 将帐户转换为 GZRS 帐户,可以使用以下命令:
Set-AzStorageAccount -ResourceGroupName <resource-group> -AccountName <storage-account> -SkuName "Standard_GZRS"
在 Azure 门户中切换复制类型
你还可以在 Azure 门户中切换帐户的复制类型。 例如,若要从 ZRS 切换到 GZRS,请转到你的存储帐户,选择“冗余”,然后更改复制类型。
实时迁移
你还可以使用实时迁移将数据迁移到使用 ZRS、GZRS 或 RA-GZRS 的帐户。 使用实时迁移以避免故障时间或数据丢失。 实时迁移的持续时间通常取决于帐户中的数据量。
可通过在 Azure 门户中创建 Azure 支持请求来完成实时迁移。
然后,支持代表会就你的实时迁移请求与你联系。
实时迁移存在一些限制。 例如:
- 与手动应用不同,你无法确切知道实时迁移何时完成。
- 数据只能迁移到同一区域。
- 仅以标准存储帐户类型保存的数据支持进行实时迁移。
- 如果帐户包含大型文件共享,则不支持实时迁移到 GZRS。
手动迁移
手动迁移比实时迁移更为灵活。 例如,由于你可以控制时间,所以如果需要在固定日期前完成,则可以使用手动迁移。
若要进行手动迁移,你可以使用 AzCopy
实用工具,或者可用的各种第三方工具。
例如,通过 AzCopy
,你可以在终端中运行以下命令,该命令会将存储帐户中的所有 Blob、目录和容器复制到另一个存储帐户中。
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/?<your-SAS-token>'
'https://<destination-storage-account-name>.blob.core.windows.net/' --recursive