复制 Kafka 数据以进行灾难恢复

本页面介绍了跨区域复制 Kafka 数据以实现高可用性和灾难恢复 (HA/DR) 的推荐架构。此外,还介绍了在主要区域发生服务中断期间故障切换到次要区域的过程。

概览

Apache Kafka 具有容错和高可用性。当您写入 Kafka 主题时,数据会被复制,以便多个代理拥有一个副本。此外,Managed Service for Apache Kafka 可确保在不同的可用区中创建副本,这意味着您的集群可以容忍整个可用区完全丢失。

但是,如果整个集群不可用,则生产者和消费者将无法再写入或读取任何数据。如果集群运行状况不佳或发生区域级服务中断,则可能会出现这种情况。为了保护工作负载免受整个集群不可用的影响,您可以将集群的数据复制到另一个区域中的辅助 Kafka 集群。

架构

建议的高可用性/灾难恢复架构采用主动-被动模式。主集群处理所有活跃流量,数据会复制到单独区域中的备用集群。此架构可确保区域级冗余。如果主集群发生故障或无法访问,您可以将工作负载故障切换到备用集群。

下图展示了此架构:

Managed Service for Apache Kafka 的灾难恢复/高可用性架构

该架构包括以下组件:

  • Kafka 主集群。在正常运行条件下,此集群会处理所有活跃的生产者和消费者流量,并充当系统的可靠来源。

  • 次要(备用)Kafka 集群。此集群位于次要区域。在发起故障切换之前,它会保持空闲或只读状态。

  • Kafka Connect 集群。此 Connect 集群部署在次要区域中。它使用 MirrorMaker 2.0 连接器 来复制 Kafka 数据:

    • MirrorMaker 2.0 来源连接器。持续将主题记录从主要集群复制到次要集群。

    • MirrorMaker 2.0 检查点连接器。将消费者群组偏移量从主集群复制到次要集群。复制偏移量可让使用方在故障切换后从正确的位置恢复。

配置网络

故障切换架构可以使用单个 VPC 网络或多个 VPC 网络。

Managed Service for Apache Kafka 集群连接到单个区域中的一个或多个子网。在每个连接的子网中,该服务会为集群的引导地址和代理创建 Private Service Connect 端点。

Connect 集群连接到单个子网,称为“工作器子网”。

单个 VPC 网络

在单 VPC 网络架构中,两个 Kafka 集群都连接到同一 VPC 网络中的子网。由于同一 VPC 网络中的子网是可路由的,因此无需进行其他配置。

多个 VPC 网络

如需创建跨两个 VPC 网络的故障切换架构,请执行以下操作:

  • 将主集群挂接到主区域中主 VPC 网络的子网。

  • 将辅助集群挂接到次要区域中两个 VPC 网络的子网。

  • 在次要区域的主 VPC 网络的子网中创建 Connect 集群。

此配置可让 Connect 集群工作器访问主集群,同时仍能灵活应对区域性服务中断。以下是一个示例配置:

  • 网络:vpc-primary和vpc-dr

  • 主集群子网:vpc-primary 中的 primary-west-subnet (us-west1)

  • 次要集群子网:

    • vpc-dr的dr-central-subnet (us-central1)

    • vpc-primary的primary-central-subnet (us-central1)

  • 连接集群工作器:primary-central-subnet

如需了解详情,请参阅为 Managed Service for Apache Kafka 配置网络。

创建 Google Cloud 资源

如需创建此架构所需的资源,请参阅以下页面:

启用 DNS 解析

将 Managed Service for Apache Kafka 集群附加到子网时,该服务会在该子网中为集群的引导地址和代理创建 DNS 条目。如需向 Connect 集群工作器提供这些 DNS 条目,请将主集群的 DNS 域名添加到 Connect 集群的可解析 DNS 域名列表中。

如果您的架构跨多个 VPC 网络,请确保在这些网络之间关联私有 DNS 区域。

授予 IAM 角色

向与 Connect 集群关联的 Managed Kafka 服务代理授予以下 IAM 角色:

  • 源集群项目上的 Managed Kafka Client (roles/managedkafka.client)。此角色允许 Connect 集群工作器从源集群生成和使用数据。

  • Service Account Token Creator (roles/iam.serviceAccountTokenCreator)。如果您使用服务账号模拟或工作负载身份联合进行身份验证,请授予此角色。该角色允许 Connect 集群生成短期有效的 OAuth2 访问令牌,以进行 SASL OAUTHBEARER 身份验证。

MirrorMaker 2.0 来源设置

我们建议在 HA/DR 架构中为 MirrorMaker 2.0 Source 连接器使用以下设置。

属性 值 说明
tasks.max 至少 3 扩缩复制吞吐量。
replication.policy.class org.apache.kafka.connect.mirror.IdentityReplicationPolicy 在次要集群中保留原始主题名称,而不向名称添加前缀。此设置可让您更轻松地将客户端应用切换到次要区域。
target.cluster.producer.acks all 确保在确认之前将数据写入所有同步副本。
target.cluster.producer.enable.idempotence=true true 防止在区域网络重试期间出现重复记录。
target.cluster.producer.max.in.flight.requests.per.connection 5 平衡顺序和吞吐量。
source.cluster.consumer.isolation.level read_committed 仅复制已提交的事务。
source.cluster.consumer.auto.offset.reset earliest 确保在复制间隙期间不会跳过任何数据。
source.cluster.request.timeout.ms 60000 设置请求超时,以应对跨区域延迟时间峰值。
target.cluster.producer.delivery.timeout.ms 120000 延长记录传送的重试时间范围。

MirrorMaker 2.0 检查点设置

我们建议在高可用性/灾难恢复架构中为 MirrorMaker 2.0 Checkpoint 连接器使用以下设置。

属性 值 说明
emit.checkpoints.enabled true 启用将消费者偏移量复制到次要集群的功能。此值是 Checkpoint 连接器的默认设置。
refresh.groups.interval.seconds 60 设置连接器检查新消费者群组的频率。
sync.group.offsets.enabled true

指定连接器定期将偏移量从内部主题复制到 __consumer_offsets 主题。此设置可让使用方在故障切换后从最新提交的偏移量恢复。

如果没有此设置,消费者在故障切换后不会有提交的位置,并且会从头开始重新读取或跳到末尾。如需了解详情,请参阅 检查点连接器的工作原理。

监控主集群

为了最大限度地减少潜在的停机时间,请务必监控主集群并在发生服务中断之前提醒操作员。本部分介绍了您应监控哪些指标来检测区域级降级。此外,还介绍了触发故障切换的提醒策略。

我们建议使用两层信号,其中第 1 层故障与第 2 层异常相结合会触发故障切换。

第 1 层:基础架构完整性

此信号最为关键。这表示主集群无法再管理自己的分区。任何大于零的值都意味着生产者无法写入特定分区,从而导致数据丢失或应用背压。

  • 指标:offline_partitions
  • 资源类型:managedkafka.googleapis.com/Cluster
  • 阈值:> 0 持续 1 分钟或更长时间
第 2 层级:应用使用方延迟时间

此信号用于衡量使用方的处理积压情况。持续的高延迟表示使用速度跟不上高容量生产者的速度,如果发生故障,您可能会面临比预期更大的延迟风险。

  • 指标:offset_lag
  • 资源类型:managedkafka.googleapis.com/TopicPartitionConsumerGroup
  • 过滤条件:resource.cluster_id=CLUSTER_ID, consumer_group_id=CONSUMER_GROUP_ID
  • 阈值:将触发器设置为在特定时长内达到阈值,以避免在出现暂时性峰值时误报。

    • 警告:5 分钟内记录数超过 100,000 条
    • 严重:2 分钟内超过 500,000 条记录或增加 20%

offset_lag 指标不反映 MirrorMaker 2.0 将 Kafka 记录和检查点写入辅助集群所引入的延迟时间。在计算恢复点目标 (RPO) 时,请考虑此因素。

配置提醒

使用以下 PromQL 查询在 Cloud Monitoring 中定义提醒政策。

  • 第 1 层级:主要集群分区故障。如果主集群的分区未分配或不可用超过 1 分钟,则会触发。

    max_over_time(
      managedkafka_googleapis_com:offline_partitions{
        monitored_resource="managedkafka.googleapis.com/Cluster",
        cluster_id="PRIMARY_CLUSTER_ID"
      }[1m]
    ) > 0
    
  • 第 2 层级:关键应用使用者积压。如果应用使用方群组的所有分区中的总积压量在 5 分钟的评估期内超过 500,000 条未读消息,则触发。

    sum by (consumer_group_id) (
      managedkafka_googleapis_com:offset_lag{
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup",
        cluster_id="PRIMARY_CLUSTER_ID",
        consumer_group_id="CONSUMER_GROUP_ID"
      }
    ) > 500000
    

替换以下内容:

  • PRIMARY_CLUSTER_ID:主 Kafka 集群的名称

  • CONSUMER_GROUP_ID:要监控的使用方的消费群组 ID

定义故障切换条件

虽然在服务中断期间进行故障切换很重要,但不因假正例而进行故障切换也同样重要。使用多个信号来触发故障切换。请勿仅依赖于使用方延迟时间,因为此指标本身可能反映使用方应用中的问题,而不是基础架构故障。

下表显示了您可能会遇到的一些情况。

场景 指标指示器 观察到的行为 响应
应用处理瓶颈

offline_partitions == 0

offset_lag > 500,000

生产者是正常的。应用使用方进度落后。 没有故障切换功能。扩容使用方以处理负载或解决下游瓶颈。
入站流量分区或网络隔离

offline_partitions == 0

提供方日志中持续出现超时异常 (TimeoutException)。

主集群运行状况良好。外部入站流量或 Private Service Connect 路由无法正常运行。 没有故障切换功能。调查 Cloud DNS 解析和 VPC 防火墙规则。
区域级服务中断

offline_partitions > 0

提供方日志中持续出现超时和网络异常(TimeoutException、NetworkException)。

主集群无法处理分区流量。生产者会被完全屏蔽。 执行区域故障切换。故障切换并提升次要区域。

在服务中断期间进行故障切换

故障切换过程会将应用从主要区域切换到次要区域。为了最大限度地缩短恢复时间目标 (RTO),目标是让使用方从最近转换的偏移量恢复。

故障切换到次要集群

如需进行故障切换,请执行以下步骤:

  1. 停止向主集群写入数据的所有生产者进程,以防止区域之间的数据不一致。

  2. 监控 MirrorMaker 2.0 检查点连接器日志,确保最后一批偏移量已发送到辅助集群。

  3. 更新生产者应用配置,以使用辅助集群的引导地址。

  4. 更新消费者应用配置,以使用辅助集群的引导地址。消费者会自动使用存储在次要集群中的转换后偏移量,在接近主要集群故障点的位置恢复。

故障切换回主集群

当主要区域再次稳定后,您可以执行故障恢复操作,并将应用切换回主集群。

  1. 验证主集群的运行状况。

    1. 确认主集群 (offline_partitions==0) 中的所有分区均处于在线状态。

    2. 验证网络连接,确保 Connect 集群可以访问主集群的引导地址。

  2. 停止 MirrorMaker 2.0 连接器。

  3. 将主集群与次要集群同步。为此,您可以为主集群部署临时 Connect 集群,并使用 MirrorMaker 将数据从次要集群复制到主集群。

  4. 监控反向复制的进度。验证主集群主题分区中的日志结束偏移量是否与次要集群中的最新偏移量一致。如果它们匹配,则表示主集群已完全赶上服务中断期间生成的所有数据。

  5. 将应用切换回主集群。为确保在最终切换期间不会丢失数据,请按如下方式执行割接:

    1. 停止生产者:停止对次级集群的所有写入操作。

    2. 排空并停止次要消费者:允许次要集群上的消费者完成对所有剩余传输中记录的处理,直到组延迟时间达到 0。然后将其关闭,以冻结已提交的偏移量。

    3. 等待反向 MirrorMaker 2.0 源连接器复制最终记录。

    4. 确认反向 MirrorMaker 2.0 检查点连接器已将最新偏移量写入主集群的 __consumer_offsets 主题。

    5. 删除临时反向连接器,以防止循环复制循环和资源开销。

    6. 更新生产者和消费者配置,以使用主集群的引导地址。

  6. 在次要区域中,重启 MirrorMaker 2.0 连接器,开始将数据复制到次要集群。

后续步骤

Apache Kafka® 是 Apache Software Foundation 或其关联公司在美国和/或其他国家/地区的注册商标。