原文地址:https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
硬件
如果您遵循了正常开发步骤,您可能已经在笔记本或小型的集群上部署了Elasticsearch。但是,当需要部署到生产环境时,有些建议需要您考虑。部署到集群机器上的Elasticsearch可以用于各种任务,这里没有一成不变的规则。但是这些建议是个很好的开始,因为它基于我们的生产集群的经验。
内存
如果有种资源最先被耗尽,很有可能就是内存。排序和聚合操作都非常耗内存,所以有充足的堆空间来存放这些数据是很重要的。即使需要的堆空间相对较小,剩余的内存还可以用作操作系统的文件缓存。因为lucene使用的很多数据结构都是基于磁盘格式的,Elasticsearch利用操作系统的缓存可以起到很好的效果。
64GB内存的机器是理想的配置,但是32GB和16GB内存配置的机器也很常见。少于8GB的机器会适得其反(您最终会需要很多小配置的机器),大于64GB内存配置的机器也有问题,这一点我们将在 Heap: Sizing and Swapping.章节中讨论。
CPUs
多数的Elasticsearch部署对CPU的要求比较小。例如,准确的处理器参数设置远小于其他资源的设置。你应该选择多核的处理器,通常集群使用2-8核的机器。
如果你需要在更快和多核CPU之间选择,请选择多核CPU。多核CPU提供的并发能力要远高于时钟速度稍快些的CPU。
硬盘
对于集群来说,硬盘是重要的,尤其对于索引任务繁重的集群(例如搜集日志数据)。硬盘是服务器中最慢的子系统,这意味着写任务繁重的集群会很容易使它们的硬盘满负荷,这将会成为集群中的瓶颈。
如果您考虑购买SSDs,他们比旋转式媒介更优越,基于SSD的节点将会提升查询和索引的性能。如果您考虑购买,SSD是很好的选择。
检查您的I/O
如果您使用SSD,请确保正确的配置了I/O调度程序。当您往硬盘上写数据时,I/O调度程序决定了何时将这些数据写到硬盘。在多数*nix操作系统中,默认的调度程序是cfq(完全公平队列)。
这个调度程序分配时间片给每一个进程,然后优化这些不同队列到硬盘的传输。但它只是对旋转媒介进行的优化:由于旋转盘片的物理分布特性,可以更有效的写入数据到硬盘。
但它不适用于SSD,因为SSD中没有旋转的盘片,所以替代它的是deadline或noop,deadline调度程序是基于写入等待时间来优化的,而noop就是简单的FIFO队列。
这个简单的改变会产生很大的影响。我们见到提升了500倍的写吞吐量,就是由于使用了正确的调度程序。
如果您使用的是旋转媒介,尽可能使用最快的硬盘(高性能服务器硬盘15k RPM)。
对于旋转硬盘和SSD来说,使用RAID 0 可以有效的提高硬盘盘速度,不需要使用镜像和奇偶形式的RAID,因为Elasticsearch通过副本实现了高可用。
最后,避免使用网络附属存储(NAS)。人们通常认为他们的NAS比本地存储更快更可靠,尽管NAS并不像所宣传的那样。NAS通常比较慢,延迟很大,并且有单点故障的风险。
网络
在分布式系统中,快速稳定的网络对于性能是非常重要的。低延迟可以保证节点间的通信更容易,而高带宽有助于分片的移动和恢复。现代数据中心的网络(1 GbE, 10 GbE)是可以满足大多数集群的。
避免集群跨越多数据中心,即使数据中心的位置很近。当然也要避免集群跨越大的地理距离。
Elasticsearch集群假定所有的节点是平等的,不会有一半的节点在另一个数据中心并有150ms的延时。在分布式系统中,更大的网络延迟会使问题恶化并且很难调试和解决。
就像和NAS的讨论一样,每个人都认为数据中心间的线路是可靠的和低延迟的。这是对的--直到它不对时(网络故障迟早都会发生,你尽管相信就好了)。从我们的经验来讲,处理跨数据中心的集群问题是得不偿失的。
总体考虑
当今时代获得巨型的机器是可能的(百GB的内存和几十核的CPU),反之,在EC2之类云平台上搭建上千台的小虚拟机也是可能的,那么哪一种方式是最好的?
通常来讲,选择中大型机器是比较好的。避免使用小机器,因为您不会想去管理一个有上千节点的集群的,而且在这些小机器上简单地运行Elasticsearch的日常开销也是很明显的。
同时,也避免使用真正的巨型机器。它们会导致资源使用的不均衡(例如,全部的内存都被使用,但CUP却没有占用),并且如果您要在每台机器上运行多个节点也会增加逻辑复杂度。