写点什么

x86 和 ARM 混合部署下的两地三中心方案验证

  • 2022 年 7 月 11 日
  • 本文字数:3427 字

    阅读完需:约 11 分钟

作者: h5n1 原文来源:https://tidb.net/blog/ac6fd148


【是否原创】是


【首发渠道】TiDB 社区


【首发渠道链接】其他平台首发请附上对应链接


【正文】

1. 概述

  两地三中心架构,即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案。在这种模式下,两个城市的三个数据中心互联互通,如果一个数据中心发生故障或灾难,其他数据中心可以正常运行并对关键业务或全部业务实现接管。相比同城多中心方案,两地三中心具有跨城级高可用能力,可以应对城市级自然灾害。


  TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建设,并保证数据库集群数据的一致性和高可用性。而且因同城数据中心网络延迟相对较小,可以把业务流量同时派发到同城两个数据中心,并通过控制 Region Leader 和 PD Leader 分布实现同城数据中心共同负载业务流量的设计。

2. 系统架构

  为更接近真实环境本验证方案使用北京、西安两地的机房进行部署,其中西安机房中使用 2 个网段 IP 模拟 2 个不同的 IDC 机房,全部为 ARM CPU,北京机房全部为 x86 CPU ,共同组建成两地三中心架构,在此架构中任何一个机房出现故障都不会影响对外提供服务,如果同城的两个中心同时故障则 在异地灾备中心进行故障恢复,然后提供服务,因为异步传输、网络延迟等情况可能会出现数据丢失情况。


  通过对 tikv 存储节点设置具有层级关系的 label 可让 TiDB 具备机房、机架、主机的物理位置感知能力,比如层级关系设置为 city、zone、rack、host,在机房、机架、主机数量充足时,tidb 能保障同一主机不会有相同副本、同一机架内不会相同副本,且根据中心数量进行分散。本次验证方案设计 label 为[‘city’,’zone’,’host’],整体部署结构如图:



  正常时为保障性能防止读写请求会发送到灾备中心机房,因此将灾备中心上的副本 leader 全部驱逐到西安 2 个中心。西安双中心同时对外提供服务,所有副本的 leader 运行于此。北京中心作为异地灾备中心与西安双中心网络延迟较高,经实际测试延迟在 20ms 左右,且由一定波动。



  通过 /etc/hosts 文件设置多个相同主机名条目,分别指向北京和西安的负载均衡 HAProxy,模拟 DNS 功能,当西安双中心故障后注释该中心对于 IP。


3. 系统优化

: 本方案验证并非性能测试仅对以下参数进行了调整,数据库仅分配 6G 内存且整个集群、表结构未进行任何调整优化。


消息压缩传输


  设置参数 server.grpc-compression-type: gzip 开启 TiKV gRPC 消息压缩传输,降低跨机房间的网络传输


调整 PD balance 容忍度


  设置参数 schedule.tolerant-size-ratio: 20.0,当两个 store 的 leader 或 Region 的得分差距小于指定倍数的 Region size 时,PD 会认为此时 balance 达到均衡状态。


延迟选举


  在北京灾备中心 tikv 设置参数,拉长灾备中心参与 raft leader 选举时,尽量避免参与选举。


  raftstore.raft-min-election-timeout-ticks: 1000


  raftstore.raft-max-election-timeout-ticks: 1200


设置副本数量


  config set max-replicas 5


驱逐灾备中心 leader


  可以使用 evict-leader 调度器或 placement-rules 进行驱逐,本次验证使用 evict-leaer 方式,使用 placement-rules 配置时注意设置 group 的 override 否则会和默认的 rule 叠加导致副本数超预期。


  pd-ctl scheduler add evict-leader-scheduler 1


调整 PD 优先级


  调整 pd 优先级使 pd leader 仅在西安双中心内选举产生 pd leader


  member leader_priority PD-10 5

4. 验证内容

4.1 两地三中心性能验证

  不驱逐北京灾备中心 leader 情况下,使用 sysbench 分别进行 5 分钟的 oltp_select_points、oltp_insert、oltp_delete 测试, 验证 2 地 3 中心的全部 tikv 提供服务时 2 个城市的网络延迟对系统性能影响。


  驱逐北京灾备中心 leader 仅西安 2 个中心提供服务,使用 sysbench 分别进行 5 分钟的 oltp_select_points、oltp_insert、oltp_delete 测试。


  预期结果:仅西安 2 个中心提供服务时的性能要好于两地三中心同时提供服务。

4.2 任一中心故障后服务可用性验证

  使用 sysbench 进行 128 线程压测 (oltp_select_points),压测期间使用 mv 重命名所有相关文件 (pd、tidb、tikv) 模拟该机房整体故障


  由于 sysbench 无自动重试机制遇到错误会退出整个进程,因此停止一个中心后会导致 sysbench 退出,需手动再次执行 sysbench,以模拟应用重试。


预期结果:


  A. 停止一个中心后 sysbench 退出 。


  B. 重新执行 sysbench 不报错,TPS 会降低。


  C. 整个过程可通过 tidb server CPU 监控反应

4.3 异地灾备恢复验证

  使用 sysbench(oltp_read_write) 进行 128 线程读写压测,使用 mv 重命名所有相关文件 (pd、tidb、tikv、haproxy),模拟西安同城 2 个中心完全故障,然后对北京灾备中心进行多副本失败恢复。


  由于 sysbench 无自动重试机制遇到错误会退出整个进程,因此停止 2 个中心后会导致 sysbench 退出,需手动再次执行 sysbench,以模拟应用重试。


预期结果:


  关闭西安 2 中心后 sysbench 退出,再次启动不成功。


  在灾备中心进行多副本失败恢复后,sysbench 启动成功,TPS 降低。

5. 验证结果

5.1 两地三中心性能验证

  2 地 3 中心 tikv 同时提供服务时 leader 分布



  仅西安同城 2 中心提供服务时 leader 分布



  Sysbench 测试对比:


5.2 任一中心故障后服务可用性验证

  模拟西安 IDC2 中心故障后集群状态



  sysbench 退出,TPS 在 11 万左右



  Leader 分布状态。


  此时西安 IDC1 中心只有 2 个 tikv,同一主机有多个 region 副本。



  4、 重新启动 sysbench 无报错,由于 tidb、tikv 数量减少 TPS 在 7 万左右



  5、检查 tidb server CPU (每中心 1 个 tidb server)



  10:14 开始压测,通过 DNS 将流量转发至西安 2 个中心的 tidb server,北京灾备中心无流量 (绿色线)。


  10:26 分左右停止西安 IDC2 中心, sysbench 退出后所有 tidb server 无流量。


  10:28 分左右重启启动 sysbench,由于流量仅发往西安中心且 IDC2 中心完全故障,因此仅流量全部发往西安 IDC1 中心

5.3 异地灾备恢复验证

  模拟故障后集群状态



  3 关闭西安 2 个中心 sysbench 退出,qps 在 7.4 万



  重新启动 sysbench 报错



  北京灾备中心进行多版本失败恢复


  PD、tikv 多副本相关失败恢复操作可在 TUG 内搜索相关字。


    (1) 从 pd、tidb、tikv 日志或监控中找到 cluster-id 和 alloc-id


    (2) PD 多副本失败恢复


    tiup pd-recover –endpoints http://10.161.67.82:2379 -cluster-id 7033562212132084087 -alloc-id 20000


    (3)tikv 多副本失败恢复


      每个存活 tikv 主机执行:


       tikv-ctl –data-dir /data/dr_tidb/tidb-data/tikv-20162 unsafe -recover remove -fail-stores -s 1,2,3,4,8 –all-regions


  多副本恢复、剔除故障节点后集群状态



  再次启动 sysbench 测试



  此处注释 /etc/hosts 文件使主机名指向北京灾备 HAProxy,由于北京灾备中心主机为 1 块普通 SAS 盘因此恢复后 QPS、TPS 均比西安 2 中心要低

6. 方案优缺点

  该方案的优缺点如下:


优点:


  利用 raft 原生高可用性,通过多副本功能实现强一致性,相比主从复制方案架构简单、数据一致性强。


  (1) 数据副本 leader 位于同城的 2 个中心,可同时提供服务,实现同城双活功能,系统资源利用率较高。


  (2) 可保证任一中心发生意外后数据不丢失、服务不中断。


缺点:


  (1) 需配置 5 副本,数据冗余度增加,存储空间增加。


  (2) 2 个城市网络要求较高可能成本较高。


  (3) 异地灾备仅 1 份副本,当同城双中心全部出现故障后,异地灾备中心需进行多副本失败恢复,服务中断,数据有丢失可能。

7. 生产环境思考

  1、 需制定各场景故障下的详细应急预案及操作手册


  2、 系统上线前要经过多次压力测试、切换演练测试,不断完善应急恢复脚本


  3、 tiup 等管理工具可使用 rsync 等工具配置自动同步,以在各中心都保存一份。


  4、为进一步提高系统可用性,可考虑建立一套同步集群,使用 TiCDC 进行复制,可避免单集群故障问题,同时也可以进行容灾演练测试


  5、 多副本恢复时需要 cluster_id、alloc-id、store_id 来恢复 pd,可定时从监控数中获取并远程保存,降低恢复时获取复杂度。


  6、同一中心要考虑机架、主机的分布,避免相同副本位于同一主机。


参考文档:https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
x86和ARM混合部署下的两地三中心方案验证_实践案例_TiDB 社区干货传送门_InfoQ写作社区