部署Elasticsearch前对硬件的准备
1、CPU上的选择
在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。常见的集群使用两到八个核的机器
2、硬盘上的选择
*如果你负担得起 SSD，它将远远超出任何旋转介质（注：机械硬盘，磁带等）。 基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。
如果你使用旋转介质，尝试获取尽可能快的硬盘（高性能服务器硬盘，15k RPM 驱动器）
*I/O 调度算法的选择，大多数默认 *nix 发行版下的调度程序都叫做 `cfq`（完全公平队列）它是为旋转介质优化的，但对 SSD 来说deadline 或者 noop磁盘IO调度算法 应该被使用。
这意味着使用普通的机械硬盘不用改调度算法。如果使用了SSD磁盘，调度算法最好改成noop（https://www.cnblogs.com/cobbliu/p/5389556.html）。更改磁盘IO调度算法如下：
1>查看当前调度算法
cat /sys/block/sda/queue/scheduler
2>更改算法
echo 'noop' > /sys/block/sda/queue/scheduler。
*使用 RAID 0 是提高硬盘速度的有效途径，对机械硬盘和 SSD 来说都是如此。没有必要使用镜像或其它 RAID 变体，因为高可用已经通过 replicas 内建于 Elasticsearch 之中。虽说提供了高可用功能，集群在少量机器故障后仍能继续正常运行，但这是有代价的（集群的再平衡、分片的生成、都会给网络和磁盘造成巨大压力，给系统带来性能和稳定性的影响，更不要说还要再次更换硬盘，会再一次造成系统的压力）。所以对于一个对性能和稳定性要求较高，并且易于维护的场景来说使用RAID10还是不错的。不差那点钱。需要注意一点一定要避免使用NAS存储设备，因为它还是太慢了
3、网络上的要求
快速可靠的网络显然对分布式系统的性能是很重要的 。 低延时能帮助确保节点间能容易的通讯，大带宽能帮助分片移动和恢复。现代数据中心网络（1 GbE, 10 GbE）对绝大多数集群都是足够的。
即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
Elasticsearch 假定所有节点都是平等的--并不会因为有一半的节点在150ms 外的另一数据中心而有所不同。更大的延时会加重分布式系统中的问题而且使得调试和排错更困难。
4、内存方面的要求
*Elasticsearch是java开发的。因此对内存方面的要求涉及到java虚拟机的一些特性。
（JVM简介看下边的链接）
https://www.elastic.co/guide/cn/elasticsearch/guide/current/_monitoring_individual_nodes.html#garbage_collector_primer
看了上边链接可以知道，java虚拟机分配堆内存给应用（Elasticsearch）,这个 堆内存是由新生代和老生代组成，老生代分配内存可到30G，新生代通常就100-500M。因此在垃圾回收的时候（垃圾回收主要是老生代，因为它太大了。回收一次代价比较大）会发生“停止时间”环节，这个停止时间是非常要命的，对ES集群稳定性有很大影响（如果时间太长，相当于机器故障，是会发生集群再平衡的）。
*上边说了那么多，就是想知道到底配个多大的内存？
（请看下方链接）
https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
看完之后得出结论：64GB的内存最合适，分给Elasticsearch30-31G，剩下的都给Lucene缓存“段”，可以加快搜索性能。
*当然没有64GB内存机器，32G也勉强凑活，把一半的可用内存分给Elasticsearch，剩下的给Lucence即可。
什么？你很有钱上百G内存、1TB内存？怎么办，太有钱了也不好办，解决方式如下：
1>你主要做全文检索吗？考虑给 Elasticsearch 4 - 32 GB 的内存， 让 Lucene 通过操作系统文件缓存来利用余下的内存。那些内存都会用来缓存 segments，带来极速的全文检索。
你需要更多的排序和聚合？而且大部分的聚合计算是在数字、日期、地理点和 非分词 字符串上？你很幸运，你的聚合计算将在内存友好的 doc values 上完成！ 给 Elasticsearch 4 到 32 GB 的内存，其余部分为操作系统缓存内存中的 doc values。(所有机器还是按照给ES分配30-31G内存其余给Lucence即可)
2>你在对分词字符串做大量的排序和聚合（例如，标签或者 SigTerms，等等）不幸的是，这意味着你需要 fielddata，意味着你需要堆空间。考虑在单个机器上运行两个或多个节点，而不是拥有大量 RAM 的一个节点。仍然要坚持 50％ 原则。
假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene。
如果你选择这一种，你需要配置 cluster.routing.allocation.same_shard.host: true 。 这会防止同一个分片（shard）的主副本存在同一个物理机上（因为如果存在一个机器上，副本的高可用性就没有了）。（所有这些机器上布置2个以上的ES实例，每个实例30-32G其余给Lucence，并配置副本与主分片不在一个物理机器上。不要告诉我你只有一台上百G内存的机，一个正常且稳定性好的集群至少3台机器）
5、至少几台机器？
至少3台，多多益善。
（参看下方链接地址中“最小主节点数位置”）
https://www.elastic.co/guide/cn/elasticsearch/guide/current/important-configuration-changes.html
由此可见，3个节点才可以最大限度防止脑裂情况的发生，对于一个对稳定性要求很高，数据一致性要求高的场景，最少要有3个节点。
6、总则
获取真正的高配机器在今天是可能的： 成百 GB 的 RAM 和几十个 CPU 核心。 反之，在云平台上串联起成千的小虚拟机也是可能的。哪种方式是最好的?通常，选择中配或者高配机器更好。避免使用低配机器， 因为你不会希望去管理拥有上千个节点的集群，而且在这些低配机器上运行 Elasticsearch 的开销也是显著的。与此同时，避免使用真正的高配机器。它们通常会导致资源使用不均衡（例如，所有的内存都被使用，但 CPU 却没有）而且在单机上运行多个节点时，会增加逻辑复杂度。
参看网址：https://www.elastic.co/guide/cn/elasticsearch/guide/current/deploy.html
