用于 system_auth 的复制因子 [英] Replication Factor to use for system_auth

问题描述

在 Cassandra 中使用内部安全性时，您为 system_auth 使用什么复制因子?

When using internal security with Cassandra, what replication factor do you use for system_auth?

较旧的文档似乎建议它应该是 N，其中 N 是节点数，而较新的文档建议我们应该将其设置为大于1.我可以理解为什么它更高是有意义的 - 如果发生分区并且一个部分没有副本，则没有人可以登录.

The older docs seem to suggest it should be N, where N is the number of nodes, while the newer ones suggest we should set it to a number greater than 1. I can understand why it makes sense for it to be higher - if a partition occurs and one section doesn't have a replica, nobody can log in.

但是，是否需要所有节点?将其设置为所有 ndos 的缺点是什么?

However, does it need to be all nodes? What are the downsides of setting it to all ndoes?

推荐答案

让我通过提出另一个问题来回答这个问题:

Let me answer this question by posing another:

如果(由于某些不可预见的事件)您的所有节点都出现故障，除了一个；您是否仍希望能够登录(并使用)该节点?

If (due to some unforseen event) all of your nodes went down, except for one; would you still want to be able to log into (and use) that node?

这就是为什么我确实确保我的 system_auth 密钥空间复制到我的所有节点.您无法预测节点故障，为了保持您的应用程序运行，安全总比后悔好.

This is why I actually do ensure that my system_auth keyspace replicates to all of my nodes. You can't predict node failure, and in the interests of keeping your application running, it's better safe than sorry.

我认为这样做没有任何明显的缺点.system_auth 密钥空间不是很大(我的是 20kb)所以它不会占用很多空间.唯一可能的情况是，如果其中一个节点关闭，并且对 system_auth 中的列族进行了写入操作(在这种情况下，我认为写入会被拒绝......取决于您的写入一致性).无论哪种方式， system_auth 都不是一个非常写重的密钥空间.因此，只要您不打算在节点故障期间执行用户维护，就可以了.

I don't see any glaring downsides in doing so. The system_auth keyspace isn't very big (mine is 20kb) so it doesn't take up a lot of space. The only possible scenario, would be if one of the nodes is down, and a write operation is made to a column family in system_auth (in which case, I think the write gets rejected...depending on your write consistency). Either way system_auth isn't a very write-heavy keyspace. So you'll be ok as long as you don't plan on performing user maintenance during a node failure.

将system_auth的replication factor设置为集群中的节点数应该没问题.至少，我会说你应该确保它复制到你所有的数据中心.

Setting the replication factor of system_auth to the number of nodes in the cluster should be ok. At the very least, I would say you should make sure it replicates to all of your data centers.

如果您仍然对问题的这一部分感到疑惑:

In case you were still wondering about this part of your question:

较旧的文档似乎建议它应该是 N，其中 n 是节点数，而较新的文档建议我们应该将其设置为大于 1 的数字."

The older docs seem to suggest it should be N where n is the number of nodes, while the newer ones suggest we should set it to a number greater than 1."

我今天在 2.1 文档中偶然发现了这一点配置身份验证:

I stumbled across this today in the 2.1 documentation Configuring Authentication:

将 system_auth 密钥空间的复制因子增加到 N(节点数).

Increase the replication factor for the system_auth keyspace to N (number of nodes).

只需确保建议清晰即可.

Just making sure that recommendation was clear.

附录 20181108

所以我最初在我管理过的最大集群有 10 个节点时回答了这个问题.四年后，在花了三个人为一家大型零售商管理大型(100 多个)节点集群之后，我对此的看法有所改变.可以说，我不再认同我四年前的这个说法了.

So I originally answered this back when the largest cluster I had ever managed had 10 nodes. Four years later, after spending three of those managing large (100+) node clusters for a major retailer, my opinions on this have changed somewhat. I can say that I no longer agree with this statement of mine from four years ago.

这就是为什么我确实确保我的 system_auth 密钥空间复制到我的所有节点.

This is why I actually do ensure that my system_auth keyspace replicates to all of my nodes.

几次在大型(20-50 个节点)集群上，我们已经部署了 system_auth，其中 RF 高达 8.只要您不四处移动节点，它就可以工作，并假设默认的 cassandra/cassandra 用户不再参与.

A few times on mind-to-large (20-50 nodes) clusters , we have deployed system_auth with RFs as high as 8. It works as long as you're not moving nodes around, and assumes that the default cassandra/cassandra user is no longer in-play.

在有大小波动趋势的集群上可以看到缺点.当然，由于跨多个提供商的高吞吐量要求，集群大小通常会发生变化，这使事情变得更加复杂.我们注意到，应用程序团队偶尔会报告此类集群上的身份验证失败.通过在所有 system_auth 表上运行 SELECT COUNT(*)，我们能够快速纠正这些情况，从而强制读取修复.但是，下次我们添加/删除多个节点时，问题往往会再次出现.

The drawbacks were seen on clusters which have a tendency to fluctuate in size. Of course, clusters which change in size usually do so because of high throughput requirements across multiple providers, further complicating things. We noticed that occasionally, the application teams would report auth failures on such clusters. We were able to quickly rectify these situation, by running a SELECT COUNT(*) on all system_auth tables, thus forcing a read repair. But the issue would tend to resurface the next time we added/removed several nodes.

由于较大的集群大小可能会发生波动，因此我们现在像对待任何其他键空间一样对待 system_auth .也就是说，我们在每个 DC 中将 system_auth 的 RF 设置为 3.

Due to issues that can happen with larger clusters which fluctuate in size, we now treat system_auth like we do any other keyspace. That is, we set system_auth's RF to 3 in each DC.

这似乎工作得很好.它可以帮助您解决在高吞吐量、动态环境中管理太多副本所带来的问题.毕竟，如果 RF=3 对您的应用程序数据来说足够好，那么对于 system_auth 来说可能就足够了.

That seems to work really well. It gets you around the problems that come with having too many replicas to manage in a high-throughput, dynamic environment. After all, if RF=3 is good enough for your application's data, it's probably good enough for system_auth.

这篇关于用于 system_auth 的复制因子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！