Cassandra集群部署规划

国内关于Cassandra的比较详细的资料还是太少，以下是根据国外的一些资料翻译总结的内容，大家有需要可以参考参考！ 还没写完，我会边写边上传！

---

 

                                         Cassandra集群部署规划

         在规划正式生产环境中的Cassandra集群部署时，首先必须考虑计划存储的数据量，以及前端主要应用系统常态情况及极值情况下的负载(读/写)压力。

硬件选择：

         对任何应用系统而言，合理的硬件资源选择往往意味着在内存、CPU、硬盘、网络这4项基础资源中通盘考虑并获取一个最佳的配置平衡。

内存：

         Cassandra节点拥有越多的内存，集群的读取性能越优秀。更多的内存允许更大的缓存大小,同时也能减少磁盘I / O读。更多的内存也允许设置更大的内存表(memtables)来存储最近的读取的数据，这将有效减少在一次读过程中扫描及读取的文件（索引文件、 SSTable文件等）。在正式生产环境中单节点采用8GB~16GB是普遍现象，建议最低不低于4GB内存，目前有部分生产集群采用32GB或更高的内 存配置。理想的内存配置往往取决于频繁读取中的数据流大小。

CPU：

         在实际应用Cassandra集群的系统中，“写频繁”的应用往往在达到内存的处理极限之前其CPU已经不堪重负了。Cassandra的高并发特性决定 了其将直接受益于更多的处理器数量。目前，拥有8个CPU内核的节点通常能提供最好的性价比。而在虚拟服务平台上，我们可以考虑使用云服务提供商，他们往 往拥有密度更高的处理器单元，能提供更强大的处理能力。（比如纽约时报就租用亚马逊的云服务平台来处理所有历史报纸的扫描件的解析存储工作）。

硬盘：

         选择硬盘的两个重要依据是：容量 （有多少数据要存储）及I/O （读写吞吐率）。存储方面的优化将有效减少昂贵的SATA硬盘数量，并能够通过扩展节点来增强集群的存储能力及I/O性能（当然这往往也意味着更多的内存投入）。

         固态硬盘（SSDs）也是Cassandra集群的一个有效替代选择。基于SSDs，并配合Cassandra的“顺序流”的写模式将能极大降低对写入效率的不良影响。

         Cassandra通过两个操作将数据持久化到硬盘中：它首先先将“写入数据”附加到内存中的Commit Log中，并周期性的将内存中的数据顺序刷新到硬盘，写入SSTable（列簇数据的存储文件）中。强烈推荐为CommitLog和SSTables文件 采用不同的磁盘存储。CommitLog并不需要太多的存储空间，但其能有有效平衡你的写入负载压力。数据目录不仅要满足存储持久数据的要求，同时也要有 足够的吞吐率以满足可以意料到的数据“读取”压力、数据“写入”和压缩的I/O需求。

         Cassandra在运行后台的数据压缩及数据修复操作时，硬盘利用率往往会临时增长到实际数据目录容积的2倍多。因此，建议在每个节点中实际使用的容量不要超过磁盘最大容量的50%。

         同时考虑磁盘故障影响及数据冗余需求，有两个合适的搭配方式：

• 存储采用RAID0，通过Cassandra的数据备份机制来解决硬盘故障的影响。一旦某个节点的磁盘出现故障，我们可以通过Cassandra的修复操作来自动找回失去的数据。
• 存储采用RAID10，这样可以通过纯粹硬件上的水平扩展来解决单个磁盘的故障，这样可以关闭Cassandra的自动备份操作。

         如果在磁盘存储方面由足够的投资，推荐采用RAID10，这样可以减少Cassandra副本备份策略所带来的额外存储操作，减少网络负载。反之，则推荐采用RAID0。

网络：

         Cassandra是一个分布式数据存储平台，它基于网络来处理读/写请求，同时通过网络来进行节点间的数据备份。Cassandra对副本数据的选择策略是，同机架上节点的优先于不同机架上的节点。同个数据中心的节点优于不同数据中心的节点。

         Cassandra使用如下端口，在实际生产环境中如果存在防火墙，必须确保同一集群中的节点可以通过这些端口互相访问。

端口号	描述
7000	Cassandra内部节点间的通信端口
9160	Thrift客户端访问端口
7199	JMX的监控端口（早期版本是8080）

 

 

容量规划

         本节所介绍的方法可以作为在Cassandra集群中进行数据容积估算的参考。为了更好的估算，我们首先要对我们在Cassandra中所操作的数据有一 个客观全面的了解。同时我们也需要知道我们准备在cassandra中如何构建数据的存储模型（列簇的划分、行集、每行多少列，等等…）

可用磁盘容量计算

         计算你的Cassandra集群节点们能管理多大的数据量，同时计算每个节点的可用磁盘容量，并将所有节点的容量进行叠加。要谨记，在实际生产集群 中，Commit Log和实际数据目录（datadirectories）务必被存储在不同的磁盘上。以下公式可以用于存储最小可用容量的估算。

         让我们首先计算我们的磁盘的原始容量：

                   原始容积 =硬盘大小*硬盘数量

         算上硬盘格式化所需的文件系统开销及我们所使用的磁盘阵列的层级模式，比如，假设我们使用的是RAID10模式，则容积计算公式如下：

         (原始容积* 0.9) / 2 = 数据可用的磁盘空间

         在日常操作中，Cassandra进行数据压缩和修复操作都需要消耗一定的磁盘空间，为了平衡性能要求和集群稳定性，强烈推荐你给你的磁盘空间留出一定的余地，仅使用少于50%的可用磁盘空间，时刻记住这一点，我们可以采用如下公式计算实际使用的空间：

        数据可用的磁盘空间* 0.5 = 实际使用的磁盘空间

用户数据规模计算

         和所有的存储系统类似，原始数据一旦进入Cassandra中存储，由于存储开销的影响，其存储容积往往要大于原始数据大小。一般来说，入库后将膨胀到原 始大小的两倍。具体膨胀多少还依赖于系统所使用的字符集及，以下内容可以用于磁盘存储数据的估算（内存临时数据的容量计算不在本节讨论范围中）。

         列开销 - 每一个列在Cassandra中占用15个字节的开销。因为列簇（Column Family）中的每一行都可以拥有大量不同的列及不同的列名，每一列的元数据都需要被存储起来。对于counter columns及被设置了生命周期的columns，还需要额外的8字节的定义开销（共23字节的额外开销）。因此计算一个正常列的开销的公式如下：

        column总长度 = column名称长度 + column值长度 + 15字节

         行开销 - 和列类似，每一行也需要占用23字节的开销。

         主键索引开销 - 每个列簇同样包含一个行集的主键索引，在我们拥有大量“窄行”的情况下，主键索引尤其重要（不用遍历整个数据集）,采用以下公式可以大概估算主键索引所占用的空间：

        主键索引 = 行总数 * (32 + 主键大小的均值)

         复制开销 – 备份策略中的复制数因子在磁盘容量使用方面扮演了一个重要角色。如果复制数因子为1，则系统没有额外的复制开销（集群中只有一份数据），一旦复制数因子大于1，可以用如下公式计算复制开销：

        复制开销 = 总数据大小 * (复制数因子 - 1)

节点配置选择的合理选择

         规划Cassandra集群配置的一个主要工作就是理解并合理设置各个节点的配置参数。本小节将解释针对单节点、多节点、多数据中心而言，在集群中可以采用哪些部署配置。

本节所提及的配置属性均可在cassandra.yaml 这个配置文件中找到，每个集群节点均必须在启动前进行正确的配置。

存储设定：

         缺省情况下，每个节点的数据存储路径被设置为/var/lib/cassandra。在实际生产集群部署中，, 我们必须修改commitlog_directory 和data_file_directories 这两个参数所指定的路径，以保证日志文件目录和数据文件目录在不同的磁盘存储中。

Gossip设定：

         Gossip设置用来指定集群中节点的通信模式及节点如何被集群所识别。

 

属性	描述
cluster_name	节点所在集群名称
listen_address	Cassandra集群中的其它节点连接到本节点的IP地址或主机名. 必须从localhost修改为本主机所对应的公共IP。
seeds	用逗号分隔的种子节点IP列表。每个节点此值都必须一致。在多数据中心中，每个数据中心至少必须有一个节点在此列表中。
storage_port	内部节点通信端口（默认为7000），对每个节点都必须一致。
initial_token	这个值直接决定了本节点所负责的数据范围（采用一致性hash进行计算），也可以不设置，有系统自动指定，并可以定期采用Cassandra定期进行load blance以达到平均存储的目的（详细可以参考RingRange）。

清除节点的Gossip状态

         每个节点都可以自动缓存Gossip状态信息，并在下次重启中自动加载，而不必等待Gossip服务的回复。可以在 cassandra-env.sh 脚本文件中添加如下定义来强制清除缓存中的Gossip状态：

               -Dcassandra.load_ring_state=false

cassandra-env.sh文件一般位于/usr/share/cassandra目录或 $CASSANDRA_HOME/conf目录中。

分区器设置：

         在实际生产环境中，我们要确保集群中的每个节点存储的数据量大体相等，这就是所谓的“负载平衡”。这种功能是通过在每个节点中配置分区器（partitioner）并正确合理的设置initial_token的值来实现的。

         强烈推荐在所有集群中采用RandomPartitioner分区器（同时它也是默认配置），基于此配置，集群中的每个节点都会被分配一个0~2**127的hash值。

 

         对于所有节点都在同一个数据中心的Cassandra集群而言，我们可以在集群中的节点总数中换分范围来获得token值。在多数据中心的部署中，每个数据中心必须单独考虑负载平衡。多数据中心及单数据中心的不同tokens值的分配方式可以在Calculating Tokens 中获得详细信息。

Snitch设置：

         Snitch能够帮助你获取你在网络拓扑结构中所处的位置。它直接影响副本放置的位置以及副本间的请求路由。endpoint_snitch属性将配置节点的Snitch属性。所有节点的Snitch配置都必须一致。

         对于单数据中心的集群而言，使用SimpleSnitch策略即可满足要求。但如果我们将在未来将我们的集群扩展为多机架多数据中心的话，一开始就设置每个节点所在的机架及数据中心会让事情更简单一些。

配置PropertyFileSnitch

         PropertyFileSnitch要求我们在 cassandra-topology.properties 配置文件中定义每个节点的详细网络信息。

         如下内容是此文件的一个配置实例，其中表示共有两个数据中心，每个数据中包含了两个机架，同时包含一个第三方逻辑数据中心用以进行数据复制分析。

# 数据中心1

175.56.12.105=DC1:RAC1

175.50.13.200=DC1:RAC1

175.54.35.197=DC1:RAC1

120.53.24.101=DC1:RAC2

120.55.16.200=DC1:RAC2

120.57.102.103=DC1:RAC2

# 数据中心2

110.56.12.120=DC2:RAC1

110.50.13.201=DC2:RAC1

110.54.35.184=DC2:RAC1

50.33.23.120=DC2:RAC2

50.45.14.220=DC2:RAC2

50.17.10.203=DC2:RAC2

# Analytics Replication Group

172.106.12.120=DC3:RAC1

172.106.12.121=DC3:RAC1

172.106.12.122=DC3:RAC1

# default for unknown nodes

default=DC3:RAC1

 

         在以上的snitch配置中，你可以任意定义你的数据中心和机架的名称。但必须确保cassandra-topology.properties配置文件中的名称和你在keyspace strategy_options定义中所用的名称是一致的。