# 规划集群可用区与高可用性 介绍如何通过多可用区部署提高集群的高可用性，包括节点在不同可用区的分布规则、副本数量配置建议，以及应对可用区故障的策略。 可用区（Availability Zone，AZ）指在同一区域（Region）下，电力、网络隔离的物理区域。同一地域内的可用区之间通过内网互通，但彼此在物理层面保持隔离，以降低单点故障风险。 多可用区部署是CSS服务提供的高可用性解决方案。通过在同一个地域内选择2个或3个不同的可用区部署集群，可有效防止数据丢失并降低服务中断风险。 #### 多可用区部署建议 创建集群时，如果选择多可用区部署，CSS服务会自动启用跨AZ高可用特性，确保节点在所选可用区中均匀分布（各AZ的节点数量差异不超过1）。 多可用区部署时，建议优先选择3个可用区，而非2个可用区。当仅选择2个可用区时，如果其中一个可用区发生故障，可能导致无法选举Master节点，从而引发集群不可用风险。 #### 节点分配规则 [表1]、[表2]和[表3]分别展示了数据节点、冷数据节点、Master节点和Client节点的AZ数量与节点的分布情况。多可用区部署的节点分配规则： - 多可用区部署时，系统会自动将节点均匀分布在多个可用区，同一类型的节点在不同可用区间的数量差值不超过1。 - 为保障服务高可用性并避免单节点负载过高，多可用区部署需满足以下节点数量要求： - **双可用区部署**：数据节点/冷数据节点数量≥4，确保每个可用区至少具备2个节点；Client节点数量≥2，确保每个可用区至少具备1个节点。 - **三可用区部署**：所有节点类型的节点数量分别≥3，确保每个可用区至少具备1个节点。 - 如果某类型的节点未部署（如无冷数据节点），则不受最小节点数量约束。 - 当数据节点或冷数据节点数量与可用区数量不是整数倍时（如，2个可用区共配置5个数据节点），可能出现数据分布不均，影响集群的查询或写入性能。建议规划时确保节点数量为可用区数量的整数倍。 表1数据/冷数据节点数量和AZ分布 | 节点总数 | 单可用区 | 双可用区 || 三可用区 ||| | 节点总数 | |---|---|---|---|---|---|---| | AZ1 | AZ1 | AZ2 | AZ1 | AZ2 | AZ3 | | **1个节点** | 1 | 不支持 || 不支持 ||| | **2个节点** | 2 | 不支持 || 不支持 ||| | **3个节点** | 3 | 不支持 || 1 | 1 | 1 | | **4个节点** | 4 | 2 | 2 | 2 | 1 | 1 | | **5个节点** | 5 | 3 | 2 | 2 | 2 | 1 | | **6个节点** | 6 | 3 | 3 | 2 | 2 | 2 | | **7个节点** | 7 | 4 | 3 | 3 | 2 | 2 | | **...** | ... | ... | ... | ... | ... | ... | 表2Master节点数量和AZ分布 | 节点总数 | 单可用区 | 双可用区 || 三可用区 ||| | 节点总数 | |---|---|---|---|---|---|---| | AZ1 | AZ1 | AZ2 | AZ1 | AZ2 | AZ3 | | **3个节点** | 3 | 2 | 1 | 1 | 1 | 1 | | **5个节点** | 5 | 3 | 2 | 2 | 2 | 1 | | **7个节点** | 7 | 4 | 3 | 3 | 2 | 2 | | **9个节点** | 9 | 5 | 4 | 3 | 3 | 3 | 表3Client节点数量和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 | | **...** | ... | ... | ... | ... | ... | ... | #### 副本配置建议 在多可用区部署中，建议合理配置副本数，以便更高效地利用跨AZ高可用特性。 - 双AZ部署时，当一个AZ不可用时，为保证另一个AZ可以继续提供服务，索引的副本数至少配置为1**。**当集群对查询性能有更高要求时，也可以增加副本数。 - 三AZ部署时，为了保证其中任意一个AZ不可用时，剩余的AZ可以继续提供服务，索引的副本数至少配置为1个。为了提高集群的查询能力，也可以增加副本数。 Elasticsearch和OpenSearch默认索引副本数为1，当需要增加副本数时，可以修改setting配置，下面提供了修改副本数示例。 - 已有索引调整副本数： curl -XPUT http://ip:9200/{index_name}/_settings -d '{"number_of_replicas":2}' - 新建索引可以通过模板设置副本数： curl -XPUT http://ip:9200/_template/templatename -d '{ "index_patterns": "*", "settings": {"number_of_replicas": 2}}' 其中，"ip"表示集群内网访问地址，"index_name"表示索引名称，"templatename"是模板名称，"template"是索引名称的匹配规则（即满足这个规则的索引会自动使用模板配置，此处\*表示全部新建索引都生效），"number_of_replicas"表示修改后的索引副本个数，此处以修改为2个索引副本为例。 #### 业务故障行为分析 Master节点负责管理集群中所有节点任务，如集群元数据、索引及分片分配。在有Master节点的集群中，由Master节点承担这些功能；在没有Master节点的集群中，数据节点和冷数据节点会协同承担Master节点的职责。 当某个AZ故障时，如果在无故障的AZ中，承担Master节点功能的节点数小于或等于全部承担Master节点功能的节点数的一半，则业务会受影响，需要参考[表4]执行业务恢复操作。 例如，集群有3个Master节点，分布在2个AZ中。当有1个Master节点的AZ故障时，另一个AZ可以正常工作，业务不会中断。但是，当有2个Master节点的AZ故障时，另一个AZ中的Master节点无法满足"节点数大于总节点数的一半"，业务将中断，需要参考[表4]恢复业务。 表4AZ故障的业务故障行为分析 | 可用区数量 | Master节点数量 | 业务中断行为及应对建议 | |:---|:---|:---| | 2 | 0（此时由数据节点和冷数据节点来承担Master节点的功能） | - 如果数据节点数和冷数据节点数之和为2的倍数： 故障AZ导致一半的节点故障，需要正常AZ通过扩容增加一个节点，集群才能继续选择主节点。如需操作请联系技术支持处理。 - 如果数据节点数和冷数据节点数之和为奇数： - 故障AZ含多一个节点，需要正常AZ通过扩容增加两个节点，集群才能继续选择主节点。如需操作请联系技术支持处理。 - 故障AZ含少一个节点，不中断业务，能够继续选择主节点。 | | 2 | 3 | 有50%机会的停机时间。当两个Master节点分配到一个AZ，一个Master节点分配到另一个AZ时： - 如果只有1个Master节点的AZ故障，则另一个AZ具有两个Master节点，这两个Master节点可以选择出主节点。 - 如果有2个Master节点的AZ故障，则另一个AZ只有1个Master节点，无法选择出主节点，业务中断，需要联系技术支持处理。 | | 3 | 0（此时由数据节点和冷数据节点来承担Master节点的功能） | 一般不会出现业务中断时间。但是，当选择3个AZ，数据节点数和冷数据节点数之和为4时，三个AZ的节点分布数为2、1、1，如果节点个数为2的AZ故障，那么业务会中断，建议您选择三个AZ时避免选择4个节点。 | | 3 | 3 | 单AZ故障时，无业务中断时间。 |