本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
可用性与持久性:单可用区和多可用区文件系统
适用于 Windows File Server 的 Amazon FSx 提供两种文件系统部署类型:单可用区和多可用区。以下各节提供了帮助为工作负载选择正确部署类型的信息。有关该服务的可用性 SLA(服务等级协议)的信息,请参阅 Amazon FSx 服务等级协议
单可用区文件系统由单个 Windows 文件服务器实例和单个可用区(AZ)内的一组存储卷组成。对于单可用区文件系统,在大多数情况下,数据会自动复制,以保护其免受单个组件故障的影响。Amazon FSx 会持续监控硬件故障,并通过更换发生故障的基础设施组件自动从故障事件中恢复。在故障恢复事件期间,以及在为文件系统配置的计划内维护时段,单可用区文件系统通常会经历约 30 分钟的停机时间。对于单可用区文件系统,在极少数情况下,文件系统故障可能无法恢复,例如由于多个组件故障,或者由于单个文件服务器的非正常故障导致文件系统处于不一致状态,在这种情况下,您可以从最新的备份中恢复文件系统。
多可用区文件系统由分布在两个可用区(首选可用区和备用可用区)的 Windows 文件服务器高可用性集群组成,利用 Windows Server 失效转移群集(WSFC)技术和两个可用区上的一组存储卷。数据在各可用区内和两个可用区之间同步复制。相对于单可用区部署,多可用区部署通过进一步跨可用区复制数据来提高持久性,并通过自动失效转移到备用可用区来提高计划内系统维护和计划外服务中断期间的可用性。这样您可以继续访问数据,并有助于保护您的数据免受实例故障和可用区中断的影响。
选择单可用区或多可用区文件系统部署类型
鉴于多可用区文件系统提供的高可用性和持久性模型,我们建议将多可用区文件系统用于大多数生产工作负载。单可用区部署是为测试和开发工作负载、某些在应用程序层内置复制功能且不需要额外存储级冗余的生产工作负载,以及可用性和恢复点目标(RPO)需求较为宽松的生产工作负载设计的一种经济高效的解决方案。在计划内文件系统维护或计划外服务中断的情况下,可用性和 RPO 需求较为宽松的工作负载最长可以承受可用性暂时丧失 20 分钟,在极少数情况下,可承受自最近一次备份以来的数据更新丢失。
此外还建议您查看文件系统的可用性模型,并确保在文件系统维护、吞吐能力更改和计划外服务中断等事件期间,您的工作负载能够适应所选部署类型的预期恢复行为。
按部署类型划分的功能支持
下表汇总了 FSx for Windows File Server 文件系统部署类型支持的功能:
| 部署类型 | SSD 和存储 | HDD 存储 | DFS 命名空间 | DFS 复制 | 自定义 DNS 名称 | CA 共享 |
|---|---|---|---|---|---|---|
| 单可用区 1 | ✓ | ✓ | ✓ | ✓ | ||
| 单可用区 2 | ✓ | ✓ | ✓ | ✓ | ✓* | |
| 多可用区 | ✓ | ✓ | ✓ | ✓ | ✓* |
注意
* 虽然您可以在单可用区 2 文件系统上创建持续可用的(CA)共享,但在 SQL Server HA 部署中,您应该在多可用区文件系统上使用 CA 共享。
故障转移过程
出现以下情况时,多可用区文件系统会自动从首选文件服务器失效转移到备用文件服务器:
-
可用区发生中断。
-
首选文件服务器不可用。
首选文件服务器进行计划内维护。
从一台文件服务器失效转移到另一台文件服务器时,新的活动文件服务器会自动开始处理所有文件系统的读取和写入请求。当首选子网中的资源可用时,Amazon FSx 会将失效自动恢复到首选子网中的首选文件服务器。从在活动文件服务器上检测到故障到将备用文件服务器提升为活动状态,失效转移通常会在 30 秒内完成。原始多可用区配置的失效自动恢复也会在不到 30 秒的时间内完成,并且只有在首选子网中的文件服务器完全恢复后才会发生。
在您的文件系统进行失效转移和失效自动恢复的短时间内,I/O 可能会暂停,Amazon CloudWatch 指标可能暂时不可用。对于多可用区文件系统,在失效转移和失效自动恢复期间发生的任何文件读写活动,都需在主文件服务器和辅助文件服务器之间进行同步。对于采用 HDD 存储的文件系统,以及写入密集型和 IOPS 密集型的工作负载,此过程可能需要长达数小时。我们建议在文件系统负载较小时测试失效转移对应用程序的影响。
Windows 客户端上的失效转移经验
从一台文件服务器失效转移到另一台文件服务器时,新的活动文件服务器会自动开始处理所有文件系统的读取和写入请求。首选子网中的资源可用后,Amazon FSx 会将失效自动恢复到首选子网中的首选文件服务器。由于文件系统的 DNS 名称保持不变,因此失效转移对 Windows 应用程序是透明的,这些应用程序无需手动干预即可恢复文件系统的操作。从在活动文件服务器上检测到故障到将备用文件服务器提升为活动状态,失效转移通常会在 30 秒内完成。原始多可用区配置的失效自动恢复也会在不到 30 秒的时间内完成,并且只有在首选子网中的文件服务器完全恢复后才会发生。
Linux 客户端的失效转移经验
Linux 客户端不支持基于 DNS 的自动失效转移。因此,在失效转移期间,它们不会自动连接到备用文件服务器。在多可用区文件系统失效自动恢复到首选子网中的文件服务器之后,它们将自动恢复文件系统的操作。
在文件系统上测试失效转移
您可以通过修改多可用区文件系统的吞吐能力来测试其失效转移。当您修改文件系统的吞吐能力时,Amazon FSx 会关闭文件系统的文件服务器。当 Amazon FSx 首先替换首选文件服务器时,多可用区文件系统会自动失效转移到辅助服务器。然后文件系统会失效自动恢复到新的主服务器,Amazon FSx 将替换辅助文件服务器。
您可以在 Amazon FSx 控制台、CLI 和 API 中监控吞吐能力更新请求的进度。成功完成更新后,您的文件系统已失效转移到辅助服务器,并将失效自动恢复到主服务器。有关修改文件系统的吞吐能力和监控请求进度的更多信息,请参阅 管理吞吐能力。
单可用区和多可用区文件系统资源
单可用区和多可用区文件系统对子网和弹性网络接口的使用方式有所不同,如以下各节所述。
子网
创建虚拟私有云(VPC)时,其可跨越 AWS 区域 中的所有可用区(AZ)。可用区是被设计为可以隔离其他可用区的故障的不同位置。在创建 VPC 之后,您可以在每个可用区中添加一个或多个子网。每个可用区中默认 VPC 有一个子网。子网是您的 VPC 内的 IP 地址范围。子网必须位于单个可用区中。
FSx for Windows File Server 单可用区文件系统需要一个子网,该子网需在创建时指定。您选择的子网将定义所创建文件系统中的可用区。
多可用区文件系统需要两个子网,分别用于首选文件服务器和备用文件服务器。您选择的两个子网必须位于同一 AWS 区域的不同可用区中。
对于 AWS 中的应用程序,我们建议您在与首选文件服务器相同的可用区中启动客户端,以最大限度减少延迟。
文件系统弹性网络接口
弹性网络接口是 VPC 中表示虚拟网卡的逻辑网络组件。当您创建 Amazon FSx 文件系统时,Amazon FSx 会在您与文件系统关联的 VPC 中预置一个或多个弹性网络接口。弹性网络接口使客户端能够与文件系统通信并挂载该文件系统。该弹性网络接口虽然是您账户 VPC 的一部分,但仍视作在 Amazon FSx 的服务范围内。多可用区文件系统有两个弹性网络接口,每个文件服务器一个。单可用区文件系统只有一个弹性网络接口。
警告
请勿修改或删除与文件系统关联的弹性网络接口。修改或删除该网络接口可能会导致永久丢失您的 VPC 和文件系统之间的连接。
下表汇总 FSx for Windows File Server 单可用区文件系统和多可用区文件系统的资源利用率:
| 文件系统部署类型 | 子网的数量 | 弹性网络接口的数量 | IP 地址数 |
|---|---|---|---|
| 单可用区 2 | 1 | 1 | 2 |
| 单可用区 1 | 1 | 1 | 1 |
| 多可用区 | 2 | 2 | 4 |
创建文件系统后,在删除文件系统之前,其 IP 地址不会更改。
重要
Amazon FSx 不支持从公共互联网访问文件系统,也不支持将文件系统向公共互联网公开。如果弹性 IP 地址(可从互联网访问的公有 IP 地址)附加到文件系统弹性网络接口,Amazon FSx 会将其自动分离。