【李先生带你玩 CITA】链数据的高可用杀手

最近有朋友的链不出块了,找我定位问题。最后分析,大都是由于链的数据被破坏了,导致区块链无法自动恢复数据。请注意,这里的链数据被破坏,指的是这条链上的所有节点数据都有问题。

节点数据被损坏,最直接的原因是由于 CITA 系统正在写磁盘过程中被异常中断,而常见的情况有:

  • 节点停电 (收到过多次反馈)。
  • 磁盘空间不足 (收到过两次反馈)。
  • 磁盘被损坏 (尝未收到过类似反馈)。

大家也许会感到奇怪,CITA 明明是一个数据多副本的高可用系统,即使有一两个节点数据出问题,系统是能够自动从其它节点恢复数据的;但却偏偏出现了整条链的数据不可用。其实,这是由于大家不小心把一个高可用的软件部署成了一个单点系统。下面我就来数数这些不小心的杀手,看看你中了哪个?


Top 1: 将所有 4 个 CITA 节点部署在一个 Docker 容器中

这是最明显的一个单点系统部署方案。为了演示的方便,CITA 在 快速入门 中给的就是这种方案。这样可以很快地获得一个 CITA 链的测试环境,但它是一个非常明显的一个单点系统。一旦这个 docker 容器被 kill 掉,就相当于 4 个 CITA 节点同时被关机,就会出现上面所说的链数据被破坏的情况。反正是自己本地的测试环境嘛,最简单的处理方案就是直接删除所有节点下的数据,重新来过。

Top 2: 将所有 4 个节点部署在同一个物理机上

这种部署方案没有第一种那么明显,但也是一个单点的部署。也曾有朋友找过我们定位类似的问题,他的部署问题比我想象中要隐蔽;他在同一台物理机上运行了 4 个虚拟机,在每个虚拟机中部署一个 CITA 节点。

这个问题定位了蛮久的,最后才知道是 4 个虚拟机部署在同一个物理机上,而这个物理机突然断电了。这其实也是一个单点系统,一旦物理机出现宕机,整条链的数据也会同时出现问题。

Top 3: 多个节点部署在不同计算单元中,而数据却指向同一远端磁盘卷

有位朋友希望把数据与计算分离,就交 CITA 计算部分用容器云实部署,而磁盘却同时指向了远端的同一磁盘卷。最后磁盘空间不足了,也导致了所有节点的数据出了问题。

这其实比上面两种来得更隐蔽,是磁盘的单点导致了整个系统的单点。

Top 4: 将多个节点部署在云计算的同一个机房中

当机房同时出现故障,所以 CITA 节点也就有可能同时出现数据不可用。不过,这种情况还没有朋友反馈过,估计概率比较小。


当出现以上故障的时候,大多的错误日志如下面的 talk 所述:

即所有节点的 cita-bft.log 都在下一高度出现了 there is no proof 的日志,或者在所有节点的 cita-auth.log 中出现 cita-bft wal save error 日志。

在这种情况下,你可以参考下面的 talk 来手工尝试恢复链的运行:

但我并不能保证 100% 能成功。如果不成功,只能尝试重放或其它手段,得 case by case 分析了。

但是,如果在生产环境中部署 CITA,我强烈建议大家采用分布式的方式来部署,将链数据部署在不同的物理环境。如选择云供应商在不同地理位置的云主机,或者直接将节点部署到不同的云供应商的主机下。以免出现在特殊场景下造成链数据不可恢复的风险。

上一篇 : Quota 与 Quota Limit
下一篇 : …

2赞