Geo-replication: 从 Copysets 到 Tiered Replication

对于分布式存储系统,我们都会使用多副本的机制来保证数据的安全性。譬如对于 TiKV 来说,我们默认会使用 3 个副本,如果需要更高等级的安全性,譬如在银行领域,我们则会使用 5 个副本。但无论使用几个副本,我们都会面临一个问题,我们如何在集群中放置这些副本。

机器都是有寿命的,磁盘,内存等硬件在运行的时候也时不时会坏掉。假设现在我们使用 3 个副本,有 N 台机器,如果同时有 3 台机器坏掉,而悲催的是刚好 3 个副本在这 3 台机器上面,那么我们就会面临数据丢失问题。所以我们需要尽量减少数据丢失的概率。

Random replication

最简单的做法就是选择任意 3 台机器来放置副本,但是这个策略其实不好。假设机器坏掉的概率是 1%,对于 3 副本来说,同时坏掉的概率是 0.0001%,看起来这个是很低的,但实际中,我们不光只有一份数据。

在 TiKV 里面我们会将数据切分成多个 region,每个 region 对应一份数据,在实际生产环境中,region 数量是非常多的,一些集群都已经过了百万了,这时候如果有 3 个节点同时损坏,一些 region 副本全丢掉的概率会非常的大。

下图是 Copysets paper 里面给出的数据,可以看到,那么随着节点数的增多,使用随机复制方式的 3 副本掉数据的概率会急剧的增大:

Copysets replication

为了解决 Random replication 的问题,有人提出了 Copysets,也就是论文 Copysets: Reducing the Frequency of Data Loss in Cloud Storage,相比于使用 random 方式,Copysets 引入了 scatter width,将整个集群节点进行分组,然后在分组的集合里面选择节点进行复制。

Copysets 的算法其实比较简单,假设集群数量是 N,复制因子是 R(其实就是选择几个副本),scatter width 是 S,那么:

  1. 创建 S / (R - 1) 个节点排列
  2. 将每个排队分成 R 组
  3. 随机选择一个节点当成副本的 primary 副本
  4. 在分组的包含 primary 节点的集合里面随机选择 secondary 副本

譬如,假设我们有 9 个节点,R 是 3,而 S 是 2,那么就有 2 / (3 - 1) = 1 个排列,譬如 [1, 6, 5, 3, 4, 8, 9, 7, 2],然后我们分成 3 组,也就是 [1, 6, 5], [3, 4, 8], [9, 7, 2]

对于 3 副本,假设我们选择 1 作为 primary 副本存放的节点,那么剩下两个 secondary 副本只能在 6 和 5 上面选取。

使用 Copysets,能有效的降低丢失数据的概率,根据 Paper 里面描述,在 5000 个节点下面,如果有 1% 的节点同时挂掉,random 丢失的概率是 99.99%,而 Copysets 则是 0.15%。

Tiered Replication

当然,copysets 并不是银弹,它并不能解决集群动态扩容的问题,于是 copysets 的作者,继续研究了另一个解决方案,也就是 Tiered replication,Paper 是 Tiered Replication: A Cost-effective Alternative to Full Cluster Geo-replication。

Tiered Replication 的原理其实也比较简单,仍然有 Copysets 的概念 scatter width S,会将整个集群分成多个 Copysets,每个 Copysets 的大小是 R,对于每个节点,必须保证它至少在 S 个 Copysets 里面。另外,Tiered Replication 里面也有 primary 和 backup 节点的区分,通常两个副本会放在 primary 节点里面,而第三个副本则会放到 backup 节点里面。

Tiered Replication 的算法比较简单,大概来说:

  1. 所有节点开始的 scatter width 是 0,也就是没有属于任何 Copysets。
  2. 创建一个 Copysets,选择最小 scatter width 的 R 个节点加进去。
  3. 重复上面的过程,直到所有的节点的 scatter width 至少是 S。

详细的算法可以看 Paper,而源码在这里,使用起来还是很简单的,譬如:

# not rack aware
>>> trepl.build_copysets(['node1', 'node2', 'node3'], R=2, S=1)
[['node1', 'node2'], ['node1', 'node3']]

# rack aware, node1 and node2 can not share a copyset since they're in
# the same rack
>>> rack_map = { 'node1': 'rack1', 'node2': 'rack1', 'node3': 'rack3' }
>>> trepl.build_copysets(
      rack_map.keys(), R=2, S=1,
      checker=trepl.checkers.rack(rack_map),
    )
[['node1', 'node3'], ['node2', 'node3']]

对于集群的动态更新,譬如新加入一个节点,就直接按照上面的算法,将这个节点加入到不同的 Copysets 里面,直到这个新加入的节点的 scatter width 为 S。而对于删除节点,一个简单的做法就是将包含这个删除节点的 Copysets 干掉,而在这些 Copysets 里面的其他正常节点的 scatter with 也会减少,然后会创建新的 Copysets 替换老的。在老的 Copysets 里面的正常副本可能会重新复制到其他节点上面。

总结

说了这么多,对 TiKV 来说有什么借鉴意义呢?现在 TiKV 是通过打 label 的方式来支持 Geo-replication 的,假设我有 3 个 Rack,每个 IDC 有 3 台机器,我们会给每个启动在机器上面的 TiKV 进程打上类似 rack = rack1, host = host11 这样的标签,PD 就会将 3 个副本分散到不同 Rack 的不同机器上面,但在 Rack 机器的选择上面,我们还是一个 random 算法。也就是说,即使能保证副本在不同的 Rack 上面,但随着每个 Rack 机器数量的增多,我们 3 副本同时丢失的概率就会增大,所以自然需要一个更好的副本复制策略。如果你对这方面感兴趣,欢迎联系我 [email protected]

你可能感兴趣的:(Geo-replication: 从 Copysets 到 Tiered Replication)