我们知道为每个可用性区域分配计算资源的弹性需求。（如果这些是实际（专用）节点或共享资源，这是未知的）
......因此，增加可用性区域不仅会影响HA POV，还将有效地为群集提供额外的计算资源。
现在的问题是：
将3个AZ定义为具有1个主索引+1个副本索引是否有意义？
由于索引是在Kibana中定义的，而AZ是在ES-cloud GUI中定义的，因此这是可能的......它会带来任何改进吗？
注意，我们正在一个繁重的搜索集群上，我们希望优化搜索。
我们知道为每个可用性区域分配计算资源的弹性需求。（如果这些是实际（专用）节点或共享资源，这是未知的）
......因此，增加可用性区域不仅会影响HA POV，还将有效地为群集提供额外的计算资源。
现在的问题是：
将3个AZ定义为具有1个主索引+1个副本索引是否有意义？
由于索引是在Kibana中定义的，而AZ是在ES-cloud GUI中定义的，因此这是可能的......它会带来任何改进吗？
注意，我们正在一个繁重的搜索集群上，我们希望优化搜索。
1条答案
按热度按时间qlfbtfca1#
将3个AZ定义为具有1个主索引+1个副本索引是否有意义？
当然！您为集群提供了更多的自平衡空间（如果您有多个索引）。
然后，许多因素实际上起作用：数据的性质、保留策略、接收管道对资源的占用程度等。
要获得真正平衡和优化的集群，您必须在经过某个增长点后考虑到这一点，但总的来说，这是主要优势。
由于索引是在Kibana定义的
嗯？不，它们不是-只有索引模式才是。
定义或使用索引Kibana是100%可选的。