1. 关于raid

本文讨论的版本是kafka 0.10.x版本。

首先我们来看看官方文档中对于kafka使用raid的说明:

上面这段文字概括起来包含以下几层意思:

  1. 使用RAID需要注意数据的均衡问题,而且使用RAID对写吞吐会有影响,同时浪费大量的磁盘空间。
  2. RAID虽然可以容忍磁盘故障,但是根据经验重建RAID的代价很大,在重建RAID的时候kafka集群也是不能正常提供服务的。这并不提供比较好的可用性。

从官方文档的意思来看,貌似是不建议使用RAID的。虽说使用RAID可能花比较久的时间才能恢复,但是不管怎样,最后还是让服务重新恢复并且提供服务了。但是如果不使用RAID,磁盘挂了,是否会造成数据丢失以及kafka集群无法服务呢?

2. disk failure对kafka集群影响

2.1 实验验证

空口无凭,我们通过一些实验来验证kafka对于disk failure的反应。为了模拟磁盘故障,我们采用nfs文件系统来作为日志目录。这样可以方便的通过切断网络来模拟磁盘故障,观察kafka集群的状况。

实验结果:
某个broker发生disk failure的时候该broker进程假死,不能正常提供服务。剩余的集群可以正常服务,生产者和消费者只会稍微阻塞一会儿即继续正常服务。当重新恢复NFS文件系统(模拟重新插上磁盘)后,如果NFS文件系统里面的数据没有被清空。则集群直接开始正常服务。如果NFS文件系统里面的数据清空(模拟换上一块全新的磁盘)则该broker的服务器日志会发生如下报错。但是另外2个broker仍然能正常服务,生产者和消费者也不会受很大的影响。当重启出问题的那个broker之后,则集群又全部恢复到正常情况。

3. 总结

kafka对disk failure具有一定可用性保障,即保证剩余正常的broker继续工作,不影响生产和消费。修复问题后重新插上磁盘,如果数据还在, 则可以热恢复,如果数据没了,则必须重启该问题broker

最佳实践:如果要进行磁盘扩容,请通过同时增加broker和磁盘的方式来进行扩容。单纯增加某个broker上的磁盘,不仅要修改整个集群的配置,而且也需要将整个集群进行重启。这对可用性造成了很大的影响。

参考资料:

  1. How To Handle Broker Disk Failure
  2. How to handle broker disk failure