区域级永久性磁盘是一种存储选项,可让您在 Compute Engine 中实现高可用性 (HA) 服务。区域级永久性磁盘可在同一区域中的两个可用区之间同步复制数据,并在遇到一个可用区级故障时确保磁盘数据的高可用性。
本文档介绍如何使用区域级永久性磁盘构建高可用性服务。
使用区域级永久性磁盘构建高可用性服务
本部分介绍如何使用区域级永久性磁盘构建高可用性服务。
设计考虑事项
在开始设计高可用性服务之前,请先了解应用、文件系统和操作系统的特性。这些特性是设计的基础,有助于排除各种不适合的方法。例如,如果应用不支持应用级层复制,则某些对应的设计选项不适用。
同样,如果应用、文件系统或操作系统无法容忍崩溃,则可能无法使用区域级永久性磁盘甚至可用区级永久性磁盘快照。崩溃容忍度定义为从突然终止中恢复而不会丢失或破坏崩溃前已经提交到永久性磁盘中的数据的能力。
在设计高可用性时考虑以下因素:
- 使用区域级永久性磁盘或其他解决方案对应用和磁盘写入性能的影响。
- 服务恢复时间目标。了解您的服务必须从可用区级服务中断恢复的速度以及服务等级协议 (SLA) 要求。
- 构建灵活可靠的服务架构的费用。
就费用而言,以下选项适用于同步和异步应用复制:
使用两个数据库和虚拟机实例。在这种情况下,总费用由以下几项决定:
- 虚拟机实例费用
- 永久性磁盘费用
- 维护应用复制的费用
使用具有区域级永久性磁盘的单个虚拟机。如需使用区域级永久性磁盘实现高可用性,请使用同样的虚拟机实例和永久性磁盘组件,但还应包括区域级永久性磁盘。区域级永久性磁盘每个字节的费用是可用区级永久性磁盘的两倍,因为它们会在两个可用区中复制。
但是,使用区域级永久性磁盘可能会降低维护费用,因为数据会自动复制到两个副本,而无需维护应用复制。
在需要故障切换之前,请勿启动第二个虚拟机。如果您只在故障切换期间按需启动备份虚拟机,而不是将虚拟机维持在热备用状态,还可进一步降低主机费用。
比较费用、性能和弹性
下表着重介绍了不同服务架构在费用、性能和弹性方面的权衡取舍。
HA 服务 架构 |
可用区级永久性磁盘 快照 |
应用级层 同步 |
应用级层 异步 |
使用区域级 永久性磁盘的 HA 解决方案 |
---|---|---|---|---|
防范应用、虚拟机、可用区故障1 | ||||
针对应用损坏的缓解措施(示例:应用的崩溃容忍度) | 2 | 2 | ||
费用 | $ |
$$
|
$$
|
$1.5x - $$
|
应用性能 |
|
|
|
|
适用于要求低 RPO 的应用(对数据丢失容忍度极低) |
|
|
|
|
灾难发生后的存储恢复时间4 |
|
|
|
|
1 使用区域级永久性磁盘或快照不足以防范和缓解故障及崩溃。您的应用、文件系统以及可能的其他软件组件必须具备崩溃一致性,或使用某种静默方法。
2 复制某些应用确实可以减轻特定应用崩溃的影响。例如,MySQL 主应用崩溃不会导致其副本虚拟机实例也遭到损坏。如需了解详情,请查看您的应用文档。
3 数据丢失意味着提交到永久性存储空间的数据丢失且不可恢复。任何未提交的数据仍会丢失。
4 故障切换性能不包括文件系统检查和故障切换后的应用恢复及加载。
使用区域级永久性磁盘构建高可用性数据库服务
本部分介绍了使用区域级永久性磁盘和 Compute Engine 为有状态数据库服务(MySQL、Postgres 等)构建高可用性解决方案的主要概念。
如果 Google Cloud 发生广泛中断,例如整个区域变得不可用,您的应用可能变得不可用。根据您的需求,请考虑跨区域复制技术以实现更高的可用性。
数据库 HA 配置通常至少包含两个虚拟机实例。这些虚拟机实例最好属于一个或多个代管式实例组:
- 主可用区中的主虚拟机实例
- 辅助可用区中的备用虚拟机实例
主虚拟机实例至少有两个永久性磁盘:一个启动磁盘和一个区域级永久性磁盘。区域级永久性磁盘包含数据库数据以及在发生服务中断时应保留到其他可用区的其他任何可变数据。
例如,备用虚拟机实例需要单独的启动磁盘才能从与配置相关的服务中断(可能由操作系统升级引起)中恢复。在故障切换过程中,您无法将启动磁盘强制挂接到其他虚拟机。
主虚拟机实例和备用虚拟机实例配置为根据健康检查信号将负载均衡器与定向到主虚拟机的流量结合使用。这种配置也称为热备用。数据的灾难恢复场景简要介绍了其他故障切换配置,这些配置可能更适合您的使用场景。
数据库复制面临的挑战
下表列出了设置和管理应用同步或半同步复制(如 MySQL)的一些常见挑战,以及它们与使用区域级永久性磁盘的块复制的比较。
挑战 | 应用同步 或半同步复制 |
使用 区域级永久性磁盘的块复制 |
---|---|---|
在主实例和故障切换副本之间保持稳定复制。 | 可能会发生多种问题,并导致虚拟机实例脱离高可用性模式:
|
存储故障由区域级永久性磁盘处理。这对应用而言是透明的,除了磁盘性能可能出现波动。 必须通过用户定义的健康检查来发现应用或虚拟机问题并触发故障切换。 |
端到端的故障切换时间比预期要长。 | 故障切换操作所花费的时间没有上限。等待所有事务执行完成(上述步骤 2)所需的时间并不固定,具体取决于数据库的架构和负载。 | 区域级永久性磁盘提供同步复制功能,因此故障切换时间受以下延迟时间总和的限制:
|
脑裂 | 为避免出现脑裂情况,这两种方法都需要通过预配来确保一次只有一个主实例。 |
健康检查
负载均衡器使用的健康检查由健康检查代理实现。健康检查代理用于实现以下两个目的:
- 健康检查代理位于主虚拟机和辅助虚拟机中,用于监控虚拟机实例并与负载均衡器通信以定向流量。配置了实例组时,此方法效果最佳。
- 健康检查代理会与特定于应用的区域控制平面同步,并根据控制平面行为做出故障切换决策。控制平面必须与健康状况受监控的虚拟机实例位于不同可用区。
健康检查代理本身必须具有容错性。例如,请注意在下图中,控制平面与主虚拟机实例是彼此独立的,主虚拟机实例位于 us-central1-a
可用区,而备用虚拟机位于 us-central1-f
可用区。
后续步骤
- 了解如何创建和管理区域级永久性磁盘卷。
- 了解如何在 Google Cloud 上构建可扩缩的弹性 Web 应用。
- 查看灾难恢复计划指南。