构建群集时，通常首先从网络拓扑开始。在您的例子中，您选择的2个区域向我表明您希望有两个逻辑Cassandra DC，每个DC具有3个节点。

网络拓扑

为了获得最佳实践，我们建议在每个DC中将密钥空间配置为replication factor（RF）为3。这意味着（a）有3个数据副本，并且（b）您的群集已配置为高可用性。
使用RF:3时，需要在每个DC中具有相同数量的逻辑C * 机架，但在您的情况下这是不可能的，因为您只有2个AZ，因此拓扑设计意味着您需要将所有节点放置在一个逻辑C * 机架中。

告密者

告密者确定哪些DC和机架节点属于哪些。有几个snitch可供选择，您对snitch的选择将决定要配置哪个.properties文件。
GossipingPropertyFileSnitch（GPFS）使用gossister自动更新所有节点。在所有情况下都建议使用GPFS，因为它将保证集群的未来性。除非您有C * 的专业知识，并且对其他告密者有强烈的偏好，否则最好坚持使用GPFS。使用GPFS时，需要在cassandra-rackdc.properties文件中定义节点的DC和机架。有关详细信息，请参见GossipingPropertyFileSnitch。
PropertyFileSnitch（PFS）是GPFS的前身，它根据您在cassandra-topology.properties文件中配置的内容确定网络拓扑。使用PFS，每个节点都有集群中所有节点的完整列表，因此当您添加/删除节点时，必须更新每个节点（details here）上的cassandra-topology.properties文件。这是乏味的，这就是为什么用户更喜欢GPFS。
警告：如果您没有使用PropertyFileSnitch，我们建议您删除每个节点上的cassandra-topology.properties文件，因为众所周知，它会导致间歇性的gossip问题，正如我在这里记录的那样-https://community.datastax.com/questions/4621/。
还有其他可用的告密者（参见docs here），但我不会在这里详细介绍，因为我们认为GPFS在所有情况下都是正确的选择。干杯!

Erick在这里提供了一些很棒的背景，应该对你有帮助。为了得到一个简单的解决方案，我建议这样做：

• 确保您在cassandra.yaml中使用GossipingPropertyFileSnitch。
• 删除cassandra-topology.properties。
• 编辑cassandra-rackdc.properties，为3个西面节点设置dc=eu-west-1;对于中心节点同样是dc=eu-central-1。
• 将机架保留为默认值，因为您在2个可用性区域（AZ 1a和1b）中只有3个节点。

如果您使用的是AZ 1a、1b和1c，我建议将其用于rack属性。Erick提到用RF值3来定义你的键空间，这是一个很好的建议。通常情况下，您会希望AZ的数量与您的RF匹配，以获得均匀的数据分布和可用性，这就是为什么我建议将rack保留为默认值的原因。
同样，你的keyspace定义看起来像这样：

CREATE KEYSPACE keyspace_name WITH REPLICATION = 
    {'class':'NetworkTopologyStrategy',
     'eu-west-1':'3',
     'eu-central-1':'3'};

要考虑的主要问题是，您的数据中心名称 * 必须 * 在keyspace定义和cassandra-rackdc.properties文件中的条目之间匹配。