ElasticSearch Remote Access

本想着把ElasticSearch 服务装在vmware的CentOS中，让本机的c#程序去装载数据到ES。 搭建的过程着实费了一点劲。

原本在vmware中安装好ElasticSearch，基于默认安装，访问ES的默认URL是localhost:9200. 那想当然的以为，想从主机访问虚拟机的9200端口，只需要把localhost替换成虚拟机的IP地址就可以了。IFConfig一查IP, 192.168.134.107. 从主机chrome访问192.168.134.107:9200. 失败。Ping一下这个IP, 能通。只有两个原因：

1. 虚拟机的CentOS防火墙不允许主机访问端口
2. 主机与虚拟机的网络设置是NAT类型，本机的9200已经被占用。

修改CentOS的防火墙属性，设置网卡使用的Zone类型为允许通过9200，并且把NAT改成bridge. 结果依然不能访问ES。

这种情况就很让人费解了，为什么CentOS本机搭建的ES能够通过localhost:9200来访问呢？而我在本机访问虚拟机，并且已经是Bridge虚拟网络配置下，完全是类似远程访问服务器一样嘛。难道是ES服务没有绑定到IP地址上？ google一下，在一篇配置elasticsearch cluster的文章中，嗅出了端倪。ElasticSearch.conf文件中，有一项是配置network.host，配置成network.host:[“192.168.51.101”, “127.0.0.1”, “localhost”] 之后，就能向cluster宣称自己加入cluster组织了，并且公开声明在192.168.51.101找到自己。

然后重新启动ES Service。 再次执行启动程序的时候，新的问题来了。经典的max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]。google了一把，网络上的大部分案列都说通过修改/etc/security/limits.conf，加入两行配置就能解决问题，如下：

* soft nofile 65536
* hard nofile 65536

然而并不能解决问题。看/etc/security/limits.conf文件开头注释，说要提防/etc/security/limits.d文件夹下面的配置文件，有可能会覆盖/etc/security/limits.conf的配置，赶紧把limits.d下面的文件也都改成了上面两行，结果依然不行。

最终从老外的一篇Blog中找到了答案，ulimit -n用来查询当前用户的资源限制。linux/unix都是多用户模型，如果有500个用户，他们同时登陆，同时打开500个文件，将会极度消耗资源。为了能让一台机器服务更多的用户，只能给每个用户一定的资源，每个用户需要酌情考虑资源的消耗，并及时关闭使用完毕的资源来平衡使用。所以我们需要修改的就是这个地方，/etc/sysctl.conf, 加入一行：

fs.file-max = 512000

然后执行命令使配置生效： sysctl – p

重启ES Service。

接下来，在本机chrome输入192.168.51.101:9200 就能打开那ElasticSearch的大门了。

欢迎关注个人微信公众号【有关SQL】