HBase实践|京东JDHBase异地多活实践

JDHBase在京东集团作为线上kv存储,承担了大量在线业务,11.11、6.18 均经历了每天万亿级读写访问请求,目前规模达到7000+节点,存储容量达到了90PB。 场景涉及商品订单、评价、用户画像、个性推荐、金融风控、物流、监控等700+业务。

JDHBase上承载了大量核心业务,遍布全球多个Data Center。为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。

HBase Replication原理

HBase是典型的LSM(Log-Structured Merge-Tree)结构数据库,服务端响应客户端写请求过程中,会写入Memstore(内存)中和顺序的写入WAL日志(HDFS文件)中,WAL日志确保数据真正写入磁盘,从而在节点故障时恢复未被持久化的内存数据。

HBase的Replication是基于WAL日志文件的。在主集群中的每个RegionServer上,由ReplicationSource线程来负责推送数据,在备集群的RegionServer上由ReplicationSink线程负责接收数据。ReplicationSource不断读取WAL日志文件的数据,根据Replication的配置做一些过滤,然后通过replicateWALEntry的rpc调用来发送给备集群的RegionServer,备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作,以batch的形式写入到备集群中。

因为是后台线程异步的读取WAL并复制到备集群,所以这种Replication方式叫做异步Replication,正常情况下备集群收到最新写入数据的延迟在秒级别。

JDHBase异地多活架构

JDHBase服务端与客户端交互主要包含三个组件: Client、JDHBase集群、Fox Manager。

Client启动时首先向Fox Manager端汇报用户信息,Fox Manager进行用户认证后,返回集群连接信息,Clinet收到集群连接信息后,创建集群连接HConnection,从而与Fox Manager指定的集群进行数据交互。

1

Fox Manager配置中心

负责维护用户及JDHBase集群信息,为用户提供配置服务,同时管理员做配置管理。

  • Policy Server:分布式无状态的服务节点,响应外部请求。数据持久化目前为可选的Mysql或Zookeeper。Policy Server中还包含了一个可选的Rule Engine插件,用于根据规则和集群的状态,自动修改用户配置,如集群连接地址信息、客户端参数等。

  • Service Center:Admin配置中心的UI界面,供管理员使用。

  • VIP Load Balance:对外将一组Policy Server提供统一访问地址并提供负载均衡能力。

2

JDHBase Cluster

JDHBase Cluster提供高吞吐的在线OLTP能力。我们对可靠性要求比较高的业务做了异地多活备份。

  • Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。

  • Standby Cluster:异常情况下,全部或部分业务会切换到此集群运行。在此集群上运行的业务数据也会异步备份到Active Cluster上。

两个集群间通过Replication备份数据,根据集群ID防止数据回环。主备集群间数据达到最终一致性。

实际生产中,我们根据两个建群间的Replication,构建了多集群间的Replication拓扑,使得集群互为主备。一个集群上会承载多个业务,不同的业务的备份也会散落在不同的集群上,形成多集群间的拓扑结构。

3

Client

Client负责拉取Fox Manager端配置信息,根据配置信息为用户提供接口,与主集群或者备集群进行数据交互,同时将客户端状态上报给Fox Manager端。

集群切换

HBase在读写数据时,需要先经过数据路由,找到数据所在(或应当所在)的节点位置,然后与节点进行数据交互。 简单来说包含以下三步:

1、client端访问HBase集群的zookeeper地址,通过访问znode获取集群META表所在位置。

2、访问META表所在节点,查询META表获取数据分片(Region)信息。同时缓存META表数据。

3、根据数据分片信息访问数据所在节点,进行数据交互。

JDHBase在client端数据路由前,多加了一步访问Fox Manager的步骤,这一步骤主要有两个作用:一是进行用户认证;二是获取用户集群信息;三是获取客户端参数。

对集群切换来说,重要的是用户集群信息和客户端参数。Client端拿到具体的集群信息(zk地址),然后进行正常的数据路由,这样业务的client端不需要关心访问哪个集群,Fox Manager端只要保证为client提供的路由集群可用即可。

Fox Manager还会为Client提供一些特殊配置参数,例如重试、超时等,这些配置参数依据两个维度:集群特性和业务属性。这些参数的设置需要结合业务场景和要求长期观察,属于专家经验;也包括一些极端情况下的临时参数。

我们也在client sdk中添加了metrics,用于评估client端视角的服务可用性。基于metrics,我们为一些极度敏感的业务开启客户端切换,当客户端可用率降低生效。

在client sdk中添加的metrics,用于评估client端视角的服务可用性。Client启动后会与Fox Manager建立心跳,一方面通过心跳上报客户端状态以及部分metrics指标到Fox Manager,这些数据能够帮助我们分析服务运行状态;另一方面Client端能够获取Fox Manager端对Client的配置更新。这样,当管理员在Fox Manager为Client更新了集群配置,Client端能够及时感知并重建数据路由。

另外,我们也做了对Client的精准控制。一方面可以使业务的部分Client实例路由到不同集群,另一方面可以作为一些极端情况下单个Client实例强制更新集群信息并切换的备用手段。

自动切换

在有了主备集群切换之后,我们仍面临时效性的问题。 故障情况下,我们从监控到异常到报警,到人工介入,最快仍需要分钟级恢复服务可用性。 这对一些线上业务来说仍然不可接受。

为了提高服务SLA质量,我们开发了基于策略的主备集群自动切换。可以根据策略在服务异常时,触发切换,将故障恢复时间控制到秒级。

首先我们在HMaster上做了状态检测插件,用于收集一些影响服务可用性的指标信息,heartbeat的方式上报到Fox Manager的PolicyServer中。

PolicyServer 是对外提供查询和修改策略的服务,它所有策略数据会存储在MySQL中。可以通过加节点的方式动态扩展形成一个服务集群,避免单点问题。

PolicyServer中的Rule Engine负责根据HMaster上报的集群状态的指标信息推测执行切换策略。服务可用性对不同指标的敏感度不同,本质上Rule Engine在多个时间窗口上对不同的指标或多个指标的组合执行策略。

Rule Engine不需要高吞吐,重要的是保障可用性,因此基于Raft做了高可用。Active的Rule Engine节点挂掉后,立即会被另外一台节点接管。

动态参数&自动调速

Replication本身是通过RegionServer发送到备机群,而RegionServer本身有大量线程用于客户端请求,Replication Source的线程和负载很难与客户端请求相匹配,在大量写或者有热点的情况下,很容易出现Replication积压。

这个问题我们可以通过调节Replication 参数来缓解这种积压的情况。HBase本身基于观察者模式支持动态参数,更新RegionServer节点参数后,执行update config动作即可生效。我们扩展了动态参数,将Replication的一些参数做成了动态生效的。当Replication积压比较严重时,可以在集群上或者在响应的分组、节点调整参数,不需要重启节点。

虽然Replication动态参数不需要重启RegionServer,但是上线还是比较麻烦的,需要人工参与,并且写热点积压不可预测,依然很难做到Replication平稳顺滑。因此我们进一步在Replication Source端根据当前节点积压的情况(几个阈值),在一定范围内自动调节Replication参数,从而达到自动调速的功能。目前参数自动调节范围在基础参数值的1-2倍之间。

跨机房异地数据中心的之间的带宽是有限的,在业务流量高峰期不能将有限的网络资源用于同步数据。因此在Fox Manager端我们也做了对集群的相应控制,分时段调整Replication速度。

串行Repication

主备集群间的Replication本身是异步的,正常情况下两个集群可以达到最终一致性。 但是某些情况下并不能完全保证。

在HBase的Replication中,通过读取每个RegionServer中的WAL将数据变化推到备集群。HBase在zookeeper中维护了一个对WAL文件的队列,因此可以按创建时间顺序读取这些WAL文件。但是当Region发生移动或者RegionServer故障转移,那么Region所在的新的RegionServer上的WAL日志可能会先于老的WAL日志推送到备集群,这种情况下备集群上的数据写入顺序与主集群是不一致的。更极端的情况,如果这种顺序不一致发生在同一条数据上,那么可能会导致数据永久不一致。

举个例子,首先在主集群中执行Put,然后执行Delete来删除它,但是Delete操作先replication到了备集群,而备集群如果在接收Put之前进行了major compact,major compact过程会删除掉delete marker,随后备集群接收到了这条put,那么这条put在备集群上将没有机会再delete,将会一直存在。

解决这个问题需要保证任何情况下,Replciation的顺序与主集群的mutation顺序是一致的,即串行Replication(Serial Replication, backport form v2.1)。例如当Region发生移动从RegionServer1移动到了RegionServer2,那么RegionServer2应当等待RegionServer1将此region的所有数据推送完,再进行推送。

串行Replciation使用Barrier和lastPushedSequenceId来解决这个问题。每当Region发生Open时,都会在meta表中记录一个新的Barrier,这个Barrier为当前Region的最大SequenceId + 1。lastPushedSequenceId为当前region推送到备集群的SequenceId,在Replciation的过程中,每个batch成功,会在Zookeeper中记录最大的SequenceId,即lastPushedSequenceId。

如图所示,一个Region从RegionServer1移动到RegionServer2,又到RegionServer3,发生多次Region Open,记录了多个Barrier,构成多个Range:[ Barrier(n) , Barrier(n+1) )。期间有多个mutation操作记录的SequenceId:s1、s2、s3、……

RegionServer在进行数据Replication前,首先检查lastPushedSequenceId 是否大于自己区间的起始Barrier。例如上图中RegionServer3会首先检查,当lastPushedSequenceId >= Barrier1 – 1时才会进行Replication,而此lastPushedSequenceId = s2,则说明lastPushedSequenceId所在Range的RegionServer2正在进行Replication,那么RegionServer3需要等待。这样就保证了数据抵达备集群的顺序与主集群的写入顺序是相同的。

总结与展望

JDHBase在不断吸收业界异地灾备经验的同时,也经过一系列的实践和演进,目前SLA已经能够达到99.98%,从毫无异地容灾措施到完善的监控、告警、切换、一致性保障机制,为业务提供稳定可靠的存储服务。

同时随着业务的增多和数据量的增大,集群规模也越来越大,仍面临一些挑战,未来我们在异地灾备方面将会着力在同步的Replication、去zookeeper依赖、客户端视角自动切换、降低数据冗余等方面继续提升可靠性及稳定性。

References

1、https://hbase.apache.org/book.html#_cluster_replication

2、https://mapr.com/blog/in-depth-look-hbase-architecture/

3、hhttps://issues.apache.org/jira/browse/HBASE-20360

4、https://issues.apache.org/jira/browse/HBASE-20046

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章