Kafka同城双活单写部署实践

Posted 2023-05-09

参考技术A 最近公司因为两次机房故障决定部署同城双机房，方案确定为双活单写

两个机房A.B都正常提供服务，所有写操作定位到A机房

// TODO 单写与多写的比较
// TODO 双活和冷备的比较

可以看到 两种实现方式 在B集群或专线崩溃时 受到的影响都较小
两个实现方式主要的区别是
第一种方法需要线下操作且需要保证zookeeper集群可用
第二种方法需要管理偏移量和mirrormaker

双活数据中心建设要点

同城双活数据中心建设是个复杂的系统工程，需要把握很多建设及运营的技术要点，以真正达到双活建设目标并切实发挥双活数据中心的容灾恢复能力，下面将简述各建设要点。

1、全局负载均衡

全局负载均衡（Global Server Load Balancing, GSLB）在双活建设方案中起着非常重要的作用。当用户在浏览器输入域名或点击手机银行App通过内嵌的域名向服务器发起请求后，全局负载均衡通过智能DNS解析功能，将用户请求调度到同城双活数据中心。当某个数据中心不可用时，全局负载均衡可以将用户请求切换到另一个数据中心，以达到同城容灾的建设目标。

GSLB的调度策略非常丰富，常用策略包括基于Local DNS、随机分配、按比率分配等，下面分别对这几种调度策略进行说明，在选择双活建设方案时可以根据实际情况评估哪种调度策略最适合。

• 基于Local DNS

Local DNS（本地域名服务器）指在电脑或者手机客户端的网卡配置的DNS，一般为运营商的DNS。GSLB可以导入运营商Local DNS地址列表，然后根据Local DNS所属的运营商来判断，比如联通用户分配到DCA，电信用户分配到DCB等，其他运营商的用户均分配到DCA，这种方式是GSLB常用的调度策略之一。

• 随机分配

这个比较好理解，GSLB接到域名解析请求后，随机返回DCA或DCB的IP地址，在随机分析的调度策略下，用户的请求可能在DCA和DCB之间随机波动，如果没有做好应用层的会话保持，就会出现用户session丢失的情况，影响用户使用体验。

• 按比率分配

DCA和DCB的域名解析结果可以按一定的比率返回，比如4:6，表示10次DNS解析请求中，有4次将解析值分配给DCA的IP，另6次都分配给了DCB的IP。同随机分配一样，按比率分配也存在随机性，需要做好应用层会话保持。

除了上述几种调度策略外，GSLB还可以对DC cookie（Data Center cookie）进行判断，起到优化流量调度策略的作用，以避免用户受运营商网络切换影响，同时促进双中心流量负载均衡。具体做法是，GSLB在响应用户第一次请求时，会将Data Center标签写入HTTP请求头（比如DCA代表该用户始终访问A数据中心，DCB代表该用户始终访问B数据中心），而GSLB在每次响应用户请求时会首先判断DC cookie值，如果发现DC cookie值非本中心标识，则会将请求转发到另一数据中心处理，反之则将请求转发到本中心处理。

2、跨中心同步机制

双活容灾方案中两个数据中心在应用层、中间件层、数据库层、虚拟化层、存储层的同步机制是建设重点也是建设难点。当一个机房发生灾难时，要确保能切换到另一个机房接管业务，则需要根据实际情况在这些层面均建立同步机制，以保障数据的完整性及故障的快速切换。

3、中间件集群架构

随着信息化系统去IOE进程的不断深入，开源的中间件解决方案逐步得到深度运用，而中间件属于牵一发而动全身的组件。在双活数据中心设计建设过程中，中间件集群面临的主要问题有跨中心通信、数据同步等，需要投入较多的技术力量去保障中间件集群架构可行性。

在跨中心通信方面，如果数据中心间通信链路不稳定，很容易引发集群工作异常，如集群脑裂就是最知名也最令人头疼的、需要重点考虑的问题之一。在单数据中心场景下，各中间件集群在内网环境进行通信，网络质量通常比较稳定，再结合适宜的集群部署架构，集群脑裂问题发生的概率较低。但在双活数据中心场景下，应用或中间件集群需要通过跨中心的链路进行通信，如果跨中心链路发生网络故障，集群间的通信就会出现异常，容易导致集群分裂成两个独立工作的集群，整个集群数据不再同步甚至相互冲突，即出现脑裂现象。除了应考虑网络链路通信质量以外，还应考虑集群的双活部署架构，解决集群部署的实际问题，避免出现单个数据中心整体故障后中间件集群不可用的情况。有些在单数据中心完全可行的部署方案在双活数据中心不一定适用，所以双活数据中心对中间件的架构考验极大。

中间件的数据同步，也是双活数据中心建设面临的难题。比如文件系统、缓存组件、消息队列、数据库等应该各自采取什么方案去做同步，才能既保证数据的一致性又不影响系统响应的性能，同时在发生灾难时还能满足预期的RTO、RPO目标，这些都是中间件数据同步的建设重点。

4、存储架构

基于光纤通道（Fibre Channel, FC）的集中存储架构在信息化建设中仍然发挥着重要作用，所以双活数据中心设计过程中必须考虑存储部署架构。尽管存储级跨中心复制技术已经非常成熟，但在实施阶段仍有细节需要考虑和平衡。如果双活数据中心存储采用同步复制方式，任何一个网络波动都可能影响到业务的响应；如果采用异步复制方式，又需要考虑在发生灾难时数据的一致性以及是否能够满足RPO要求。具体采用哪种复制方案，需要结合整体的架构设计以及各信息系统对响应性能的要求进行评估。

5、业务系统改造

在双活数据中心设计阶段需要考虑到，并不是所有的业务系统均天然支持跨中心双活模式运行，一些系统技术架构陈旧、建设时间较久远，只能支持单中心运行的情况也并不罕见。除此之外，应用程序在域名化、缓存组件、跑批调度、数据库等层面都可能涉及改造，因此要想建设好双活数据中心，打造适合双活容灾解决方案，业务系统的改造支持是必不可少的。在改造过程中还可能会遇到一些风险或者停机中断的情况，所以需要做好规避风险的应急预案。

6、备份方案规划

在双活架构建设方案中备份方案的重要性比较容易被忽视，因为它并不影响实时联机交易，对于双活建设也没有直接影响。从监管层面来看，银行系统要求达到5级灾难恢复等级，所以在数据备份系统方面也需要全面考虑，包括完整的数据备份频次、离线数据存储、数据远程复制等。从整体备份方案方面来看，需要从支持单中心备份拓展到支持双中心备份。从备份网络方面来看，为避免备份带宽占用过高从而影响到生产业务，建议将备份网络与业务网络物理隔离。此外，还需要设定合理的数据备份的策略，比如日志文件在线保存时长、备份系统存储时间、离线归档保存策略等。

7、容灾操作平台化管理

容灾管理平台对于双活建设完成后的双中心故障切换以及日常的业务连续性保障应急演练有着重要意义。通过平台化的灾难备份恢复管理，可以实现各类应急场景的提前编排以及自动化切换研发管理、应急切换流程的审批，以及故障或应急演练切换的全程实时进度展示等功能。容灾操作平台化管理比人工管理应急处置的方式更高效，是高质量双活数据中心运维管控的必要支撑平台。

8、运营管理保障

双活数据中心建成后，两个机房都实时对外提供服务，因此在运营层面应纳入统一管理，包括对业务运营、制度及流程规范、事件响应等的标准化管理，才能良好地保障双活数据中心的稳定运行。这也对双活架构的运营能力提出了更高的要求。

9、故障切换策略

双活数据中心的故障切换策略需要根据不同的双活建设方案及故障场景进行预设，以最大程度保证故障切换的可行性和效率。在大多数情况下，应尽可能减少跨中心调用，简化应用访问复杂度，且在单中心发生应用、中间件、存储等设备的单点故障时应尽可能在本中心内消除影响。