Cassandra 集群 - 数据密度(每个节点的数据大小) - 寻求反馈和建议

Question

我正在考虑 Cassandra 集群的设计。

用例将存储大行微小样本的时间序列数据(使用 KairosDB)，数据几乎是不可变的(非常罕见的删除，无更新)。这部分工作得很好。

但是，几年后，数据将相当大(最大大小将达到数百 TB - 考虑到复制因子，超过 1 PB)。

我知道建议每个 Cassandra 节点不要使用超过 5TB 的数据，因为压缩和修复期间 I/O 负载很高(这对于旋转磁盘来说显然已经相当高了)。由于我们不想为此用例构建具有数百个节点的整个数据中心，因此我正在研究在旋转磁盘上使用高密度服务器是否可行(例如，在 RAID10 中使用旋转磁盘每个节点至少 10TB 或 20TB或 JBOD，服务器将具有良好的 CPU 和 RAM，因此系统将受到 I/O 限制)。

Cassandra 每秒的读/写量可由小型集群管理，没有任何压力。我还可以提到，这不是一个高性能事务系统，而是一个用于存储、检索和一些分析的数据存储，并且数据几乎是不可变的 - 因此，即使压缩或修复/重建需要在多个服务器上花费几天的时间同时，这可能根本不会成为问题。

我想知道是否有人对使用旋转磁盘的高服务器密度有经验反馈以及您使用的配置(Cassandra 版本、每个节点的数据大小、每个节点的磁盘大小、磁盘配置:JBOD/RAID、硬件类型)。

预先感谢您的反馈。

致以诚挚的问候。

Answer 1

超密集节点的风险不一定是在修复和压缩期间最大化 IO - 它是无法可靠地解决整个节点故障。在您对 Jim Meyer 的回复中，您指出不鼓励使用 RAID5，因为重建期间发生故障的可能性太高 - 同样的潜在故障是反对超密集节点的主要论点。

在 vnode 出现之前，如果您有一个 20T 节点死亡，并且必须恢复它，则必须从相邻 (2-4) 个节点传输 20T 节点，这将最大化所有这些节点节点，增加了故障的可能性，并且需要(数小时/天)来恢复故障节点。那时，您的运行冗余会减少，如果您重视数据，这可能会带来风险。

vnode 受到许多人赞赏的原因之一是它可以将负载分配给更多邻居 - 现在，用于引导替换节点的流操作来自数十台计算机，从而分散了负载。但是，您仍然遇到根本问题:您必须在 Bootstrap 失败的情况下将 20T 数据传输到节点上。长期以来，流媒体比预期的更加脆弱，并且在云网络上流媒体 20T 且无故障的可能性并不理想(尽管它再次变得越来越好)。

可以运行20T节点吗？当然。但有什么意义呢？为什么不运行 5 个 4T 节点 - 您可以获得更多冗余，可以相应地缩小 CPU/内存，并且不必担心一次重新引导 20T。

我们的“密集”节点是采用 Cassandra 2.1.x 的 4T GP2 EBS 卷(x >= 7 以避免 2.1.5/6 中的 OOM)。我们使用单个卷，因为虽然您建议“cassandra 现在很好地支持 JBOD”，但我们的经验是，依赖 Cassandra 的平衡算法不太可能给您带来您所想象的效果 - IO 将在设备之间惊群(压倒性的，然后压倒下一个，依此类推)，它们会不对称地填充。对我来说，这是反对大量小卷的一个很好的论据 - 我宁愿只看到单个卷上的一致使用。