摘要: 在 2018 年 1 月 25 日的数据库直播上由阿里云 HBteam 的玄陵带来了以 "ApsaraDB-HBase 双集群和稳定性" 为主题的分享, 通过对云 HBase 双集群方案的必要性, 常见跨集群数据复制方案, 云 HBase 跨集群数据复制, 云 HBase 双集群方案选择以及云 HBase 服务的稳定性进行了详细的介绍.
直播视频: https://yq.aliyun.com/video/play/1333
PPT 下载: https://yq.aliyun.com/download/2460
以下内容为精彩视频整理:
云 HBase 双集群方案的必要性
介绍一下做双集群的必要性, 双集群常见于一些在线服务, 因为对于在线服务来说它可能更倾向于服务的敏感性, 服务的可用性, 它更倾向于选双集群的灾备或者说一个多活的方案. 也涉及数据的可靠性, 当检测到 Master 集群不可用才可以把流量切换到备份集群, 这就是一个灾备. 当 Slave 挂掉了以后, Master 顶上来以后切换到主机群, 这样就是一个集群的状态检测.
常见跨集群数据复制方案接下来先介绍一下数据复制这一模块常见的解决方案以及它的原理. 这一模块它会涉及到增量复制以及全量复制, 先来介绍一下增量复制以往的一些解决方案, 大概归纳为下面几个方面:
ï¼1ï¼双写: 现在有两个集群 Master 和 Slave, 在业务层做双写的服务, 把流量在主集群写一份, 备份集群写一份, 任何一条写请求过来的话, 可以保证在主集群 Master 上和备份集群 Slave 上都写成功后, 这次写才是成功的. 当发现主集群挂掉了, 可以把流量倒到备份集群上;
ï¼2ï¼复制 log: 在增量复制的时候要先复制 log, 比方一个主库一个备库, 先把写流量打到主库, 备库做解析. 常见的有 mysqul 复制 binlog,mongo 复制 oplog,HBase 复制 WALlog;
(3)EACH_QUORUM/LOCAL_QUORUM: 同过 C*cross dc back up 方案;
(4)Consentsus 协议复制: Consentsus 是做内部的数据同步;
(5) 其它;
全量复制大概有下面几个方面:
(1) 批量跑 Map Reduce 导数据 (copytable);
(2)Copy file+bulkload, 从文件级别 copy 到备份集群, bulkload 是直接从数据文件把数据 load 起来, 最终在内存里面以及在物理磁盘上可能会有新增的索引文件;
(3) 数据库自身方案: 云 HBase 有一套一键迁移工具和 C*rebuild 工具;
全面复制的特点如下:
云 HBase 一键迁移工具可以做到表级别的复制, 使用起来比较快捷, 可以做到容错和灾备, 还可以在线的调整它的速度.
除此之外还有一个 Distcp 的功能, 它就是 copy file+bulkload, 但单机 bulkload 资源消耗的比较严重, 影响在线的备份速度.
Copy table 是在源端做一个 scan 请求, 对在线的源端大量的 scan 是影响它的内存, 以及影响它的在线请求.
云 HBase 跨集群数据复制
对云 HBase 做 replication 我们也会提供异步复制, 异步复制和社区相比会有一些优点, 下面从这几方面介绍一下它的优点:
(1) 提升源端发送效率: 在复制 HLog 这一流程的时候, 是对 HLog 进行的一个串行的读取.
让源端发送的过程进行多线程并发的操作, 这样对发送的效率有所提高, 进而对接收效率也进行提高;
(2) 提升目标端 Sink 的效率: 源端预合并 HLog, 目标端进行并行化消费;
(3) 热点辅助: 进行基于历史监控的负载均衡算法均衡请求, 进行人工运维;
这是我们在原有异步复制上面的一个优化, 除此之外我们还做了一个基于云 HBase 同步 replication, 因为原来的 replication 是异步的, 所以就 HBase 这个版本除此之外它还有一个同步的 replication 分量复制.
同步复制是发一条请求在本地先写 WALlog, 同时并发在备份 Cluster 上写一条 RemoteLog, 在本地写 memstore. 同时在下面主备之间的 Log 复制逻辑用的是原来的异步复制逻辑. 当我现主集群挂了, 把流量切到备份集群, 这时备份集群自己要做一个恢复, 恢复的时候就需要在 RemoteLog 上做一个同步的恢复. RemoteLog 并不会一直存在, 当发现主集群的 Log 异步复制备份之后, 就可以把 RemoteLog 删掉了.
下面总结一下云 HBase 在增量复制这一块的优点,
(1) 支持强同步复制: 保证主备集群写入强一致同步, 一旦主集群挂掉了, 可以在备份上读到最全的数据;
(2) 对同步和异步做到了同存: 同步复制表不影响异步复制表的读写;
(3) 灵活切换模式: 当主集群挂了或者异步集群挂了, 同步复制可以一键切换为异步复制, 不阻塞主集群写入;
(4) 高性能复制: 复制性能比社区是高一倍的, 尽可能的并行化处理;
云 HBase 双集群方案选择
对于在线服务会有灾备的需求, 也可能会有双活的需求常见的方案有业务层做一些切换以及重试, consensus 协议保证, 云 HBase:DB 层面做灾备 / 双活, 业务无感知.
介绍一下之前做双集群方案的调研.
第一种是有主备的 hbase, 主备集群可以共用一套 Zk, 在 Zk 里面丢上主集群的地址和备集群的地址. 当发现主集群是挂掉了, 可以人工的在 Zk 里把地址做一个替换, 请求就会直接访问备份集群不会访问主集群. 它的优点是架构比较简单, 缺点是一旦 Zk 挂掉之后, 主备集群就会完全无法工作.
第二种方案是主备 hbase 和各自的 Zk, 这个的好处是不会依赖于共有的 Zk,Zk 不会成为致命点. 但在配置管理 + 消息推送这会有一个配置管理的工具, 它专门的去存储地址.
第三种就是我们自己的主备 hbase+client retry, 大部分逻辑是丢在 client 层面, 在 client 上做一些判断. 还有智能的不可服务的诊断系统, 当发现主机不可服务后会在网络层面把这个事做一个锁定, Client 层面感知到这个锁定后会把流量自动的切到备份. 对于 put/get/delete/batch 多样化的复制, 来一个 put 请求丢到主机里复制备份, 当 client 层面发现主集群不可服务了, client 自己会把流量切到备份. Client 也有方毛刺抖动的预防功能和云 HBase 异步复制的功能.
我们之所以选择第三种方案, 因为在云上的环境比较复杂, 而方案一, 二都需要依赖其他的组件, 如果再在云上加一个组件整个流程是比较复杂的, 所以我们选择了一个最简单的方案, 后期还可以在 client 层面做一些策略的路由, 这样可以支持后续多活的延续.
云 HBase 服务稳定性
双集群的稳定性, 现在购买双集群实现的逻辑是在同 region 下, 不同的 Az 和相同的 Az 都是可以支持服务的, 这样可以防止区域性外界原因造成的服务不可用问题. 出现单集群某些机器出现 OOM 问题可以把风险降到很低, 不影响整体服务可用性. 除此之外后续还会有一个双活的规划, 后续支持可配策略的访问模式, 主备异构.
本文由云栖志愿者小组陈欢整理, 百见编辑.
来源: https://yq.aliyun.com/articles/411487