聊聊计算存储分离

  |   0 评论   |   2,670 浏览

背景

今天看到了云版本的HBase2.0上线了,其中使用了计算存储分离。

这里的计算存储分离只是云Hbase 2.0中不起眼的一个小细节,但是其做为一种思想,已经用在了绝大多数的云服务中。

这里简单记录一下计算存储分享的实践过程。

发展过程

网络IO瓶颈阶段

以前,计算和存储是放在同一台机器上的,计算直接操作本机的存储,来避免网络IO对性能的影响。

然后,随着数据量的增加,单机无法提供横向扩展性,因此有了分布式的应用,引入了跨机器复制数据的操作。但是这里的操作原则依然是尽量的本地化,来避免跨节点网络IO对性能的影响。

资源使用率瓶颈阶段

当前,数据中心已经有了25G, 50G和100G的网络,网络IO已经不再是瓶颈了。

此时,关注点变为了减少低资源使用率的机器,同时服务可以云化。最终实现初期流量低时,使用少量资源,流量上升后,可以动态增加机器,来扩充服务能力的目标。

怎么实现这个目标呢?即计算存储分离,按需使用资源。

  • 存储端有状态,只存储数据,不处理业务逻辑。
  • 计算端无状态,只处理逻辑,不持久化存储数据。

实现方式

通过学习HBase 2.0的架构图,来学习一般的实现方式。

计算存储分离

第一步是实现计算层和存储层的分离。如图所示:

png

  • 计算层:负责逻辑运算,读写远程的存储
  • QOS层:保证数据读写质量,保障性能和安全要求
  • 存储层:通过副本形式保障数据安全,能够容忍单节点的不可用

通过这种方式,实现了按需使用,弹性扩充。

冷热数据分离

第二步是冷热数据分离,分级存储。

这个通常是在实现了第一步的基础上进行的。

即把不常访问的数据放在成本较低的存储上,被访问时延时会稍微高一些,但是也能满足业务需求。

这种方式,最重要是可以实现把读写较快的存储,用来存放对于实时性要求高的数据,来提高性能,同时降低成本。

png

技术难点

计算存储分离中,有状态的数据均放在了存储层。因此难点都落在了存储层上。

下面是几个常见的方面:

单机failover

如何保证存储层的高可用性和数据一致性呢?

目前互联网中通用的解决方案是使用Paxos/raft强一致性协议,来实现5秒级别的failover自动恢复。

与一般方案不同的是Cassandra,其使用的是gossip协议来进行节点发现,用户来配置读和写的一致性级别[4]。

毛刺优化

在读写中,常常会遇到毛刺现象,即部分长尾请求的响应时间偏长。一般是网络抖动、磁盘抖动、负载、GC等原因。

这种情况的解决方法,也是上面提到的解决方法,即使用多数节点读取写入成功时即认为成功的策略(commit majority feature)。

流控

在负载高时,适应降低后台同步服务的资源占用,来降低读写的毛刺。

当然更好的解决方法是,优化后台同步逻辑,来进一步资源占用。

高可用部署

数据至少部署在两个DC,Zookeeper类似的服务部署在三个DC。

参考

  1. 八年磨一剑,阿里云ApsaraDB for HBase2.0正式上线
  2. 容器化RDS|计算存储分离架构下的 IO 优化
  3. 2017双11技术揭秘—阿里数据库计算存储分离与离在线混布
  4. How is the consistency level configured?

评论

发表评论

validate