Amazon EKS上的1000节点Cassandra集群

原创 X丶 2022-10-18

205

apachecassandra是一个分布式数据库，它可以很好地处理地理分布的工作负载。另一方面，K8ssandra可以在配备了备份和仪表盘的Kubernetes上运行它。

2022年欧盟杜克日，DataStax的首席技术官，分享了在Kubernetes上运行1000个Cassandra节点 .

我要谈谈我最近要做的一个实验——在Kubernetes上运行1000个或更多的Cassandra节点。我在数据税务局工作。我认识阿帕奇·卡桑德拉6到8年了。我对Cassandra很了解。然而，我不是Kubernetes的专家。我们使用datatax作为服务产品来驱动我们的数据库。我知道Cassandra用它，而且很管用。我想看看这些经典的老式的巨型Cassandra集群在Kubernetes上是如何运行的。我们的极限是什么？我们能走多远？如果我们试图登上月球，会有什么破裂？

顺便说一句，我很喜欢把Kubernetes的工作和我们的测试工具结合起来， NoSQLBench公司，在此群集上运行测试。这是出人意料的简单。我不认为我必须描述Kubernetes，因为这里的每个人都比我更了解它。向前看，apachecassandra是一个数据库。它是分布式的，并且可以很好地处理地理分布的工作负载。 K8ssandra公司，另一方面，是在Kubernetes上运行Cassandra的一种方法，使用我们发布到开源中的操作符。它还有备份、仪表盘等。正如我提到的，NoSQLBench是一个我们用来对Cassandra进行基准测试的工具，尽管它有用于其他后端的连接器。现在，你可能会问，我们为什么在乎？我为什么关心库伯内特斯？我花了很多时间在现场与人们一起研究他们部署的Cassandra集群，他们对此有问题。我在其他会谈中也把这当作一个主题，但这是一件大事。当您有10到100个Cassandra节点时，我总是在现场做的第一件事就是去比较配置，因为无论它们是使用Ansible、Puppet还是手工制作，都有多代节点被发布，或者有人进入并进行了手动更改。配置漂移导致了许多奇怪的软件问题。这是你看到的第一件事。很多鬼虫子会来自配置漂移。

对于K8ssandra和Kubernetes，有这样一种想法：“我们是否希望在已经很难运行的东西（即K8ssandra）之上添加这个抽象层？”我会说是的。如果我们能够消除这类一致性配置问题，就像Kubernetes为我们做的那样，那么这是非常容易的，K8ssandra在部署时就知道它是统一的。如果手动配置的话，1000个节点2的想法需要几个星期的时间。此外，使用超定标仪也有一些优点，但是Kubernetes提供了很多优点。其他让我惊讶的是，我还没有深入了解Kubernetes，比如我通过安装一个服务网格获得的可见性，或者认为将日志之类的东西汇总起来并查看整个集群是多么容易。

让我谈谈什么是有效的，然后我再谈谈我在做这件事时遇到了什么问题。比如说，一周内有一个工程师站了起来，比如一个工程师站了1200人；我们在那个群集中有超过1千万字节的数据。我们看到在这个集群上每秒有上千万次的读写操作，P75延迟在10毫秒以下。我把集群上的IP地址空间搞得一团糟
必须在800个节点上销毁群集。我在五分钟内就完成了。这是一个你要小心的超级大国。但是一个小小的舵手更新，我不得不重新开始。正如我提到的，使用Kubernetes扩展负载测试也是非常容易的。

现在，什么没用？我们已经和团队讨论过K8ssandra的一些问题，就是除非你在集群上做大，否则你不会遇到它们。K8ssandra使用普罗米修斯用于在大约60个节点上进行监视。我们已经超过了K8ssandra的默认设置。请记住，我是带着对这个设置非常天真的意图而来的。我不想优化，也不想做很多配置，因为我想知道从头开始并尝试扩大其中一个的配置是什么样的。

另一个非常大的集群是K8ssandra在决定如何协调新的K8ssandra节点到机架上时需要一点爱。我想这是在努力。而且，只有当你变得非常大的时候，你才会遇到这种情况。另一方面，使用超定标仪，特别是EKS，为我节省了大量的工作和资源限制。然而，在我们试图扩展集群时，有很多停止和请求的时刻。Adobe也提到了这一点。我觉得自动缩放是个好主意。对于这些有状态的工作负载，autoscaler可能会带来更多麻烦。

最后，我阅读的大部分文档都是针对在Kubernetes节点中运行多个pod而设计的。我们使用这些数据库部署为每个节点运行一两个pod。这样做的后果之一就是我的数学不太好。我用光了大约800个节点的IP地址。我不得不回去重新检查整件事。因此，如果你想在每个节点上使用单个或有限数量的pod，那是一个很好的主意。