带有 Raid-0 条带化的 AWS 上的 Kafka

Kafka on AWS with Raid-0 striping

AWS confluent quickstart 为 Kafka log.dirs 配置了 4 个 512GB EBS 块设备和 RAID-0 条带化以获得更高的吞吐量,并且还有助于绕过块设备的 1TB 限制而无需预置 IOPS。我刚刚了解到丢失 RAID-0 组中的块设备会导致该组中的所有其他设备发生故障,有人可以帮助澄清一下吗

既然Kafka允许log.dirs下有多个目录,我们能不能把每个块设备挂载在不同的挂载点下,配置成log.dirs下的目录列表?

如果这是可能的(我想是的),权衡取舍是什么?

有几点需要注意。

首先,EBS 卷没有 1TB 的限制。目前,Amazon st1 卷可以达到 16TB。这些是您希望在 Kafka 部署中使用的卷类型,因为它们针对顺序写入进行了优化,而这正是 Kafka 最擅长的。

其次,是的——Kafka 允许多个日志目录。这允许您跨磁盘分布存储,这样您就不会用所有的 io 使单个磁盘负担过重。也就是说,拥有多个日志目录比拥有一个目录要好,尤其是当您处理大量数据时——但在处理 EBS 时,还需要牢记其他因素。如果您选择更小的 st1 卷而不是单一的 st1 卷,这意味着您将拥有更小的突发存储桶和每个卷更低的 iops 基线。超过 iops 基线后,您将开始使用存储桶中的 iops--see details here。监控 CloudWatch 中的突发余额以确保它不会经常耗尽非常重要,这通常会导致整个集群变慢,代理的请求和响应队列填满,这可能导致消费者和生产者应用程序发生灾难性故障。

至于 RAID 条带化,如果您在每个 EBS 卷上启用它,则所有已安装的卷都将位于同一个 RAID 组中,这意味着 Kafka 日志文件将分布在组中的设备上,而不是驻留在单个设备上,其后果是如果这些设备中的一个发生故障,则组中的其他设备也将发生故障。然而,这应该比其他设置更高效。

在 Kafka 1.0 之前,代理上的单个磁盘发生故障和该代理上的每个磁盘发生故障之间没有操作上的区别——两者都会导致代理宕机。 See discussion here.

更新:从 Kafka 1.0 开始,故障磁盘不会关闭代理 (see docs)。感谢@RobinMoffat 指出。最终,通过 RAID-0 条带化,您可以用从故障磁盘快速恢复的能力换取整体 io 性能。也就是说,具有单个故障磁盘的代理上的所有分区都需要重新分配条带化,但如果没有条带化,则只有故障磁盘上的那些分区需要重新分配。