Elasticsearch集群规划建议

规划集群可用区

为防止数据丢失，并确保在服务中断情况下能降低集群的停机时间，从而增强集群的高可用性，CSS服务支持跨可用区（即多可用区）部署。用户可以在同一个区域内选择两个或三个不同的可用区进行集群部署。

在创建集群时，如果用户选择了两个或三个可用区，CSS服务将自动开启跨AZ的高可用性特性，确保节点在这些可用区内均匀分配。具体的节点分布情况，包括不同数量的节点如何在各个可用区中分布，可以参考表1。

• 在创建集群时，选择的任意类型的节点数量都要大于等于所选的AZ数量，否则跨可用区部署会失败。
• 部署跨AZ集群时，任意类型的节点都会被均匀的分布在不同的AZ上，满足各个AZ之间节点数量的差小于等于1。
• 当集群中数据节点和冷数据节点的数量和可用区的数量不是整数倍关系时，集群的数据会分布可能会不均匀，从而影响数据查询或写入业务。

表1 节点数量和AZ分布

集群节点个数	单AZ	两AZ		三AZ
	AZ1	AZ1	AZ2	AZ1	AZ2	AZ3
1个节点	1	不支持		不支持
2个节点	2	1	1	不支持
3个节点	3	2	1	1	1	1
4个节点	4	2	2	2	1	1
…	…	…	…	…	…	…

当采用多可用区部署时，如果某个可用区发生故障，相关的业务故障行为分析及应对策略请参见表2。

表2 AZ故障的业务故障行为分析

可用区数量	主节点个数	业务中断行为及应对建议
2	0	如果节点个数为2的倍数： 一半的数据节点故障，需要替换故障可用区中的一个节点，才能继续选择主节点。 如果节点数为奇数： 故障AZ含多一个节点，需要替换故障可用区中一个节点，才能继续选择主节点。相关替换请联系技术支持。 故障AZ含少一个节点，不中断业务，能够继续选择主节点。
2	3	有50%机会的停机时间。当两个专用主节点分配到一个可用区中，一个主节点分配到另一个可用区中时： 如果具有一个专用主节点的可用区遇到中断，则剩余可用区具有两个专用主节点，这两个专用主节点可以选择出主节点。 如果具有两个专用主节点的可用区遇到中断，剩余可用区只有一个专用主节点，无法选择出主节点，业务中断，需要联系技术支持。
3	0	当您选择3个可用区，节点个数为4，三个可用区的节点分布数为2，1，1，如果节点个数为2的可用区故障，那么此时业务中断，建议您选择三个可用区时避免选择4个节点。 一般不会出现业务中断时间。
3	3	无业务中断时间。

当集群创建完成后，支持切换可用区，具体操作请参见切换Elasticsearch集群可用区。

切换可用区包含两大场景：可用区高可用改造和可用区平移切换。

• 可用区高可用改造：适用于单AZ改造成两AZ、单AZ改造成三AZ或两AZ改造成三AZ的场景，目的是为了提升集群的高可用性。
• 可用区平移切换：适用于从一个AZ完全迁移到另一个AZ的场景，目的是为了解决当前可用区资源不足的问题。

规划集群版本

选择Elasticsearch集群版本时，建议综合考虑业务需求、特性支持、性能改进、安全性更新和长期支持等因素，以确保选择的版本能够满足当前和未来的业务发展，同时提供稳定和安全的运行环境。

• 当首次使用CSS服务的Elasticsearch集群时，建议选择最新版本。
• 当需要将自建或第三方Elasticsearch集群迁移到CSS服务，且仅迁移集群不改造集群时，建议版本号和源集群一致。
• 当需要将自建或第三方Elasticsearch集群迁移到CSS服务，且需要对集群进行代码改造时，建议选择7.10.2或7.6.2版本。

规划节点类型

在Elasticsearch集群中，合理规划不同节点类型对于优化性能和资源利用率至关重要。在创建集群时，应根据业务需求、查询负载、数据增长模式和性能目标来确定添加哪些类型的节点，以实现合适的集群性能和资源管理。表4是介绍了不同节点类型的适用场景，建议用户根据具体的业务需求和性能预期来选择是否启用该类节点。

• 如果创建集群时未启用Master节点或Client节点，当业务运行一段时间后，发现数据节点压力太大时，支持单独添加Master节点或Client节点，具体操作请参见添加Master或Client节点。
• 如果创建集群时未启用冷数据节点，则集群创建完成后不支持单独添加冷数据节点，请在创建集群时合理选择是否启用冷数据节点。

规划节点存储

• 规划节点机型

  CSS服务支持多种节点机型，每种机型适用于不同的业务场景，建议用户根据具体的业务需求和性能预期来选择最合适的机型，以优化存储性能和成本效益。

  表5 节点机型适用场景

  节点机型	磁盘类型	规格说明	适用场景
  计算密集型	云盘	CPU:内存=1:2	推荐场景，用于数据量较少（单节点<100GB）的搜索场景。
  通用计算型	云盘	CPU:内存=1:4	通用场景，用于单节点数据量在100-1000GB间的搜索与分析场景，例如中等规模的电商搜索、社交搜索、日志搜索等场景。
  内存优化型	云盘	CPU:内存=1:8	通用场景，用于单节点数据量在100-2000GB间的搜索与分析场景。 适合向量检索场景，大内存有利于提升集群的性能与稳定性。
  磁盘增强型	本地盘	挂载HDD盘	适合日志场景，用于存储冷数据，对冷数据的数据查询性能要求低，并且数据需要更新的场景。
  超高I/O型 （CPU架构为鲲鹏计算）	本地盘	挂载SSD盘	适用大型日志场景，用于存储热数据。
  超高I/O型 （CPU架构为X86计算）	本地盘	挂载SSD盘	适用大型搜索与分析场景，场景对计算或磁盘I/O均有较高要求，例如舆情分析、专利检索、以及部分数据库加速场景。

• 规划节点规格

  在规划节点规格时，推荐优先考虑高配置但节点数量较少的方案。例如，一个由3个节点组成的集群，每个节点配置为32核CPU和64GB内存，通常比一个由12个节点组成的集群，每个节点配置为8核CPU和16GB内存，在集群的稳定性和扩展性方面更具优势。

  优势主要体现在如下方面。

  • 集群稳定性：高配置节点通常能提供更强的处理能力和更大的内存空间，从而提高集群的整体稳定性。
  • 扩容便捷性：当高配置集群遇到性能瓶颈时，可以通过横向扩展轻松解决，即简单地向集群中添加更多具有相同高配置的节点。这种扩展方式简单直接，易于实施。
  • 维护简便：较少的节点数量意味着更少的维护工作和更低的管理复杂性。

  相比之下，低配置集群在需要扩容时，往往需要进行纵向扩展，即提升单个节点的配置。这不仅可能涉及更复杂的迁移和升级过程，还可能增加额外的维护成本和技术挑战。

  因此，在规划集群时，应综合考虑性能、成本、维护和扩展性，选择最适合业务需求的节点规格。

• 规划存储容量

  在规划CSS集群的存储容量时，应考虑数据量、副本因子、数据膨胀率和磁盘使用率等多个关键因素。以下是一个推荐的计算方法，用以确定所需的集群存储容量。

  存储容量=源数据x（1+副本数量）x（1+数据膨胀率）x（1+预留空间比例）

  • 源数据：首先确定预期存储的原始数据量。
  • 副本数量：设置副本因子，默认建议值为1，以保证数据的高可用性。
  • 数据膨胀率：集群在索引过程中可能会产生额外的数据膨胀，通常建议按照25%的膨胀率进行计算。
  • 磁盘空间使用率：考虑到操作系统和文件系统本身占用的空间，以及留出一定的空间以优化磁盘性能和冗余，建议将磁盘使用率控制在70%，即预留空间比例为30%。

  将具体数值代入公式：存储容量=源数据x2x1.25x1.3

  简化计算，如果源数据量已知，最终的存储容量大约是源数据的3.25倍。这个计算方法提供了一个基础的估算，但实际配置时还需要根据具体业务场景和增长预期进行调整。

规划节点数量

创建集群时，集群的节点数量应当基于业务性能需求和预期负载进行规划。表6提供了计算方式用以确定合适的节点数量。通过这个计算方式可以更科学地规划集群的节点数量，以满足业务需求并保证集群的性能和稳定性。

当一个集群包含的节点类型不同时，各节点类型支持的节点数量不同，设置节点数量时可以参考表7。

规划虚拟私有云和子网

CSS服务支持在非共享VPC和共享VPC内创建集群。

共享VPC和非共享VPC相比，有如下优势：

• 在一个账号内统一创建资源，并将资源共享给其他账号，其他账号无需创建重复资源，可以精简资源数量以及网络架构，提升管理效率并节约成本。

  比如不同账号下的VPC网络互通需要建立对等连接，使用共享VPC后，则不同账号用户可以在同一个VPC创建资源，免去了对等连接配置，有效的简化组网结构。

• 在一个账号内统一管理运维资源，便于企业集中配置业务安全策略，并且利于对资源使用情况的监控和审计，支撑业务的安全诉求。

规划集群安全模式

当访问安全模式的集群时，需要输入用户名和密码通过安全认证才能访问。CSS服务支持以下两类用户的安全认证：

• 集群的管理员：管理员账户名默认为admin，密码为创建集群时设置的管理员密码。
• 集群的用户：集群的管理员通过Kibana创建集群的用户和密码。创建方式请参见创建Elasticsearch集群用户并授权使用。

当集群创建完成后，支持切换安全模式，具体操作请参见更改Elasticsearch集群安全模式。

切换安全模式包含三大场景：非安全模式切换为安全模式、安全模式切换为非安全模式、安全模式的协议切换。

规划索引分片数

在使用集群的过程时，特别是在进行数据导入操作之前，建议根据具体的业务需求，提前对集群的数据结构和分布进行规划。这包括合理设计索引和确定分片数量。为了确保集群在性能和可扩展性方面达到最佳状态，以下是一些建议。

• 单个分片大小：建议将每个分片的大小控制在10GB到50GB之间。这有助于在存储效率和查询性能之间取得平衡。
• 集群总分片数量：为了管理方便和避免过度扩展，建议将集群的总分片数量控制在3万以内。这有助于保持集群的稳定性和响应速度。
• 内存与分片比例：在资源分配上，建议每1GB的内存空间放置20到30个分片。这样可以确保每个分片都有足够的内存资源进行索引和查询操作。
• 单节点分片数：为了避免单点过载，建议每个节点上的分片数量不超过1000个。这有助于避免节点资源竞争，确保节点的稳定运行。
• 索引分片与节点数的关系：对于单个索引，建议其分片数与集群的节点数保持一致，或者设置为节点数的整数倍。这有助于实现负载均衡，优化查询和索引的性能。

通过以上建议，可以更有效地规划和管理CSS集群的索引分片，从而提升集群的整体性能和可维护性。