通过JBOD通过LVM设置运行KafkaStreams应用程序的Kafka集群。
在多个云（AWS）卷上使用LVM很方便，因此您无需重启就可以增加可用磁盘空间。
但是，我不确定在将增长的集群中将卷与Kafka Brokers关联的最佳布局（某些主题具有完全保留）。 分区遵循均匀分布，因此那里没有热点。
经纪人被泊入服务器，每个服务器可能有许多容器（经纪人）。
我不确定Kafka集群的最佳布局（还是明智的选择）。 我将显示一些带有注释的设置来说明。
设置1
S个服务器，每个服务器负责将N个物理卷（PV）分组为1个卷组（VG），并在具有目录的安装点（例如
/kafka）中分组为1个逻辑卷（LV）分隔每个经纪人的数据（例如/kafka/data/broker-N）
使用机架感知，您可以指定每台服务器的代理构成一个机架，因此分区副本将转到单独的代理，以确保一个分区的一个PV不超过一个副本。
在此设置中，您可以添加更多代理，只需在服务器上的LV中添加目录即可。通常，您还可以在添加代理时增加存储，您可以这样做，但这将完全脱钩。另外，无需为重新平衡而费心-
我在这里担心的是，代理将写入服务器VG正在处理的任何PV（线性与条带化之间的模式会有所不同，但是在某些时候，来自代理分区的数据可能会分开磁盘）。 _使用时会不会降低性能？
那么可靠性呢？任何发生故障的PV都可能影响（很可能会影响 ）该服务器的所有代理分区，因此必须重新同步所有受影响的分区，这可能需要大量时间和带宽才能恢复，除了在不同服务器中出现两个故障的PV之外，您的群集还必须重新同步大多数分区（假设复制3）。
我可能会缺少的其他专业人士吗？
设置2
S个服务器，每个服务器照顾N个
PV，它们被分组为N个VG，每个服务器都被划分为N个LV，它们分别位于不同的装入点（例如，{{1} }），它将保存其他经纪人的所有数据。因此，经纪人的数据是分开的。
这样做，每个代理将连接到其设备。因此，它不会使代理创建与添加存储脱钩。但是，通常在大多数情况下，添加代理时，您可能会想做这件事（即，添加处理能力但还添加磁盘空间...，但不一定）。
与往常一样，新节点的新卷将为空白，因此需要重新平衡。
如果磁盘发生故障，则仅影响由该代理处理的那些分区，因此通过网络传输的分区数据要少得多。
但是，这增加了一些负担，因为您需要处理大量的VG和LV。不确定这将如何影响性能。另外，服务器在可以使用的安装点（VG）数量方面有限制（AWS linux = 26）。
问题
哪个（如果有的话）设置更明智？ 这些真的是禁忌吗？为什么？ 在Kafka上是否还有其他更明智的LVM设置？ 使用RAID会受益吗？
PS。最初假设少于9-12个经纪人，以及3个服务器-由于存在完全保留主题，将来应该会增长。 Kafka版本为1.1.0。 PS2。云提供商是AWS。每个服务器最多可容纳26个VG。