AWS 和 Auto Scaling cassandra答案

【问题标题】：AWS and auto scaling cassandraAWS 和 Auto Scaling cassandra
【发布时间】：2015-11-17 06:55:16
【问题描述】：

我已经设置了一个带有 cassandra 的 AWS 实例，然后还设置了一个自动扩展组，以根据警报启动另外 4-8 个实例。但是 Cassandra 是如何知道自动缩放何时启动的呢？它如何知道要连接到哪些其他节点？我是否需要在 Cassandra 中配置一些东西才能嗅探节点？

当我运行节点工具时，自动缩放节点不显示...

[root@ip-10-205-119-104 bin]# sh nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns    Host ID                               Rack
UN  127.0.0.1  107.12 MB  256     ?       a50294ac-2150-4d9e-9dd2-0a56906e9531  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

【问题讨论】：

标签： amazon-web-services cassandra

【解决方案1】：

Cassandra 中自动发现的最佳选择是种子节点，它们是“锚”节点，当新节点出现时应该始终存在，并且可以在每个节点查询集群的节点列表需要的时间。

因此，您在每个节点的配置文件中提供一个种子节点列表（包括种子本身），一旦它启动，它将从种子中获取节点列表。当然，这要求种子节点是静态的并且始终运行（当然，为了冗余，您必须拥有多个种子节点）。 Cassandra 要求它也按其 IP 列出（以避免 DNS 出现问题）。

不过，我认为自动缩放 Cassandra 并不是一件好事。 Cassandra 将其数据（行）跨节点分区，每次添加或删除节点时，它都需要重新分区和重新分配行，这取决于数据的大小，需要很长时间（并且可能需要其他管理操作，例如维修等）。即使您有足够的副本来承受突然的节点丢失（使用自动缩放将发生这种情况），那也很麻烦。首先，因为 Cassandra 不会自动停用节点 - 集群会知道节点不可用，但它只是等待它回来，并尝试保持集群尽可能健康（包括将写入保存到其他节点在一段时间内不可用）。

因此，您需要观察您的节点并从外部管理这些起伏。而且，您甚至可能没有时间停用一个节点并在另一个节点出现之前再次将所有内容（您的数据）设置到位，然后再次关闭，所有这些都可能真正将您的集群彻底搞砸。

嗯，也许有人在做这件事，但根据我对 Cassandra 的了解和经验，它不像 Web 应用程序那样自动缩放那么简单和神奇，而且你可能会最终会丢失数据并拥有一个非常不一致和不稳定的系统。

【讨论】：

【解决方案2】：

使用自动缩放的另一个问题是，没有即时的满足感。在集群重新平衡之前，您无法真正看到新节点的好处，这可能需要很长时间，具体取决于您的集群。

当重新平衡正在进行时，您最终会在原始节点上增加额外的负载，这会破坏增加容量的目的。

【讨论】：