记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

中间件PASS层组件容灾方案及实践

2022-03-28 02:05

当下,随着数字化技术不断深入,愈来愈多企业将核心业务搬到线上。业务系统高可用、可扩展、容灾能力决定企业系统的连续性,中间件作为构建企业核心系统的重要组成部分,其高可用容灾能力也将决定应用系统的。本文结合腾讯云中间件各PASS产品的容灾能力及实践,以一个行业头部客户业务容灾实践举例,来展开说明基于腾讯云中间件PASS层相关产品的实践。

下面就分别对Ckafka、ES、Redis云产品在客户业务容灾场景中的相关案例。

Ckafka的容灾能力可以分为:跨可用区容灾及跨地域级容灾。

Ckafka跨可用区容灾

跨可用区容灾:指的是在同一个地域内部,一个Ckafka集群节点跨可用区部署,作为一个大集群。这个跨可用区部署大集群的方式是原生kafka所推荐支持的。可以大幅度提升集群的容灾能力,当单个可用区出现意外的网络不稳定、断电重启等不可抗力风险 时,仍能保证客户端在短时间等待重连后恢复消息的生产和消费。

Ckafka 跨可用区部署

部署说明说明

Ckafka跨可用区集群:采用Ckafka 专享版,实例采用4个broker节点,跨2个可用区部署(广州4区与广州6区各2个broker节点)。

实例规格建议:峰值带宽:1000MB/s,Partition规格:2800个。

ZK集群:3个节点跨3个可用区部署。广州4区与6区各一个,另外在广州2区也部署一个,组成一个集群。

高可用说明:

  • 采用VIP接入, 实现跨可用区(AZ)访问能力,具有故障漂移能力。当4区与6区网络出现中断后,部署在4区 的应用可访问6区broker节点。
  • 当4、6区任意一个可用区出现故障: 触发Ckafka实例各分区leader切换,实现所有leader分区从故障节点转移到正常可用区。 客户端应用可以通过VIP从正常可用区节点请求Ckafka实例正常的broker节点。
  • 当4、6区之间网络抖动、断开(60s)之后:通过VIP切换,客户端都能够正常的进行消息生产和消费,影响对业务无感知。不影响整个集群间broker上报到ZK集群,整个实例集群正常运行。 会影响到4、6区之间分区leader节点与follow节点间数同步,当网络恢复正常之后,继续进行leader与follow数据同步。
  • 在4、6区之间网络出现抖动/断连之后,4区又出现故障,触发Ckafka的leader切换,原来的follow节点提升leader节点,因为之前数据同步延迟,可能会造成部分数据丢失。根据分布式CAP原则,需要在可用性与数据一致性作出权衡。 数据一致性优先:通过设置ack=all,可以保证在4、6区出现网络中断后,确保leader与follow节点数据一致,但是会造成因为断连导致数据写入失败,需要重试。 可用性优先:设置ack = 1,只需要leader节点写入成功。当4、6区网络异常,对正常写入无影响。但是会在一段时间内数据丢失。这里服务端可以通过优化follow与leader同步优化,客户端重试最大限度减少数据丢失量级。

Ckafka跨地域热备容灾

跨地域容灾指的是分别部署2套Ckafka集群,通过Ckafka服务端自带的实例间数据同步能力,实现实例的跨地域间同步复制。这样可以确保当某一个地域不可用时候,消息的读写请求能够正常切换到另一个区。

跨地域数据同步

双集群热备模式说明:

  • 服务端内置的Connect集群来实现跨地域间的Ckafka实例集群数据复制。
  • 客户端消息读写请求路由到某一地域的主服务实例上,当主服务实例出现异常的时候,客户端的请求将被切换到另外一个地域
    的集群上,确保客户端能够继续正常使用。
  • 整个数据读写请求不跨区 数据同步复制云上实例可以通过控制台配置同步源&目标端即可实现跨集群间数据同步。
  • 通过同步消费offset数据,可以实现切换备区之后继续无缝消费。客户侧无需部署同步组件mirrormaker,并且云上负责对同步
    组件的监控维护。可以通过双向同步或者双写来完成数据复制。 故障切换客户侧可以以每个Ckafka实例为单位,通过DNS将
    所有流量切换到备区。
  • 切换之后可以继续进行消息无缝生产/消费。

Ckafka迁移方案

双写模式:

Ckafka双写模式

操作步骤:

  • 在腾讯云消息队列 CKafka 控制台,创建 CKafka 实例,并创建对应 Topic。
  • 换修改客户侧应用,生产者将数据同时写入到自建kafka及云Ckafka实例。同时启动应用。
  • 原有消费者无需做配置,持续消费自建 Kafka 集群的数据。在某一个时间点内,同步启用新的消费者组进行消费,同时停止老的消费者消费。
  • 新消费者持续消费 CKafka 集群中的数据,迁移完毕。

同步迁移模式:

同步迁移模式:

  • 同步模式操作步骤:在腾讯云消息队列 CKafka 控制台,创建 CKafka 实例,并创建对应 Topic。
  • 客户侧生产者继续将数据写入到自建kafka实例。
  • 下载、安装并且搭建mirror-maker客户端。
  • 配置mirror-maker生产&消费properties文件。
  • 启动mirror-maker,开始执行消息数据同步操作。检查数据同步是否正常,如果出现异常,需要检查下相关配置文件。
  • 修改kafka客户侧,根据某个时间点启动新的消费。

ES跨可用区容灾

ES的容灾部署模式可以分为:大集群节点跨区部署、跨区复制CCR 2种模式。

大集群节点跨区部署

ES集群包含多个节点,可以将这些节点跨区部署,结合ES主分片&副本分片切换的特性,可以实现当某个主分片挂了情况下,能将副本分片提升为主分片继续对外提供服务。

ES跨可用区容灾

跨区部署说明:

  • ES跨可用区集群:实例采用4个数据节点组成,其中:4区2个,6区2个节点。
  • 专用主节点:在每个可用区部署一个专用主节点,从而保障任何一个可用区不可用时,依然能够选出 Master节点,确保整个集群的稳定。

高可用说明:

  • VIP实现跨可用区(AZ)访问能力,ES具有故障跨可用区漂移能力。当4区与6区网络出现中断,部署在4区的应用可访问6区ES点。
  • 当4、6区任意一个可用区出现故障:如果有一个可用区挂掉,如广州4区整体不可用,ES的Master节点依然可用,会将广州4区的节点剔除并且将广州6区各节点上副本分配提升为主分片,同时VIP会将6区的RS剔除掉,这样4区应用就不会请求到6区节点上了,这样整个集群依然能够对外提供服务,并且对客户侧是无感知的。当故障恢复之后,分片会自动均衡到2个可用区,整个集群自行恢复。
  • 当4、6区之间网络抖动、断开之后:通过VIP切换,客户端可正常对ES集群上各节点进行读写。此时因为4区到6区的网络出现抖动等异常情况时: 1)如果Master在4区,Master会将6区节点剔除,留下4区节点,将4区上的副本分片提升为主分片,整体正常对外提供服务。整个过程小于3秒,采用重试规避。 2)如果Master在6区,Master会将4区节点剔除,留下6区节点,将6区上的副本分片提升为主分片,整体正常对外提供服务。整个过程小于3秒,采用重试规避。3. 如果网络恢复正常之后,分片会自动均衡到2个可用区,并且开始执行主分片与副分片数据同步。

CCR 跨区复制模式:

CCR 跨区复制模式

高可用部署说明

  • 当四区不可用时,进行容灾切换,业务流量切换到六区1、 断开CCR同步2、 六区切换为普通单实例集群 3、业务手动将所有流量切换到六区(修改DNS等)。
  • 当四区恢复后,建立CCR从六区同步数据到四区,六区成为主集群、四区为副集群1、清空四区集群索引2、配置CCR主从同步:数据从六区主集群通过CCR复制到四区副集群。
  • 回切四区为主集群1、 断开CCR同步,由于此时数据还继续写入六区,这部分数据会丢失,无法同步到四区2、 四区改为普通单实例集群3、业务手动将所有流量切换到六区,会产生业务中断。

ES大集群部署及CCR跨区复制部署优劣比对

大集群&CCR比对

自建ES上云迁移方案

ES在线融合迁移方案

操作步骤

  1. 腾讯云ES版本需要大于等于客户自建ES集群的版本。
  2. 例如客户ES版本是6.5.1,则云上的ES版本最好是6.8.2。
  3. 创建云上ES集群的VPC选择自建集群所在的VPC。
  4. 腾讯云ES版本选择基础版或者开源版,白金版暂不支持(如果自建ES集群也是白金版可忽略),可在数据迁移完成之后升级到白金版。
  5. 确保自建ES集群没有开启security,如果开启则先关闭。
  6. 确保客户自建ES集群没有安装腾讯云ES集群不支持的插件。云上集群的配置名称需要和自建集群保持一致。

Redis跨区容灾方案

Redis容灾主要分为主从和集群。

Redis主从容灾

主从容灾

跨区部署说明

两可用区,1主3副本部署,主可用区1主1副本,备可用区2个副本,每个可用区两个节点,可保障单机故障读请求不跨可用区,单可用区故障后仍然具备主备高可用。该方案适合于对可用性和访问延迟要求较高的场景。

高可用说明:

  • VIP实现跨可用区(AZ)访问能力,多 AZ(可用区)的实例只有一个 VIP,这个 VIP 在整个Region 都可以访问,Redis 的 HA(Highly Available)并不会导致 VIP 变化。
  • 当4、6区任意一个可用区出现故障:如果有一个可用区redis挂掉,如6区整体不可用,4区依然提供服务,6区的客户端将会通过Proxys集群访问4区的redis。如果4区不可用,那么6区将选举出master节点,4区客户端将通过Proxys访问6区。如果一个可用区内的单机故障,那么就会由没有故障的节点提供服务。这样整个集群依然能够对外提供服务,对客户侧的影响是有限的,客户端做好重试即可。
  • 当4、6区之间网络抖动、断开之后:4区为主可用区,访问不受影响,6区默认15秒之后会主动fail ,此时6区的redis将不提 供服务,但是6区的客户端将会在4,6区网络断开10秒后感知到,然后通过第三方可用区网络访问4区的redis,不影响redis使用。2. 如果网络恢复正常之后,重新开始主分片与副分片数据同步,服务自动恢复正常。

Redis迁移方案

Redis迁移步骤

Proxy代理切换步骤:

  1. 整个切换采用Proxy代理模式,客户应用端可以自行控制,确保灵活、快速实现自建redis切换到云上。
  2. 应用端直连Proxy,然后通过Proxy进行灵活切换,例如由自建迁移到云上,以及当云上迁移失败,可以从云上又切换到自建。
  3. 自建redis可以通过DTS迁移到云上redis。云上的redis又可以通过redis slaveof 同步数据到线下,需要客户侧自行配置。5月份升级DTS,确保可以从云上迁移数据到自建。

文章来源于互联网:中间件PASS层组件容灾方案及实践


知识来源: https://secvery.com/7532.html

阅读:535277 | 评论:0 | 标签:无

想收藏或者和大家分享这篇好文章→复制链接地址

“中间件PASS层组件容灾方案及实践”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

黑帝公告 📢

十年经营持续更新精选优质黑客技术文章Hackdig,帮你成为掌握黑客技术的英雄

🙇🧎¥由自富财,长成起一↓

标签云 ☁