To remove a node from 2 node cluster in AWS I ran
nodetool removenode <Host ID>
After this I was supposed to get my cluster back if I put all the cassandra.yaml and cassandra-rackdc.properties correctly.
I did it but still, I am not able to get back my cluster.
nodetool status is displaying only one node.
significant system.log on cassandra is :
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:553 - Cassandra version: 3.9
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:554 - Thrift API version: 20.1.0
INFO [main] 2017-08-14 13:03:46,409 StorageService.java:555 - CQL supported versions: 3.4.2 (default: 3.4.2)
INFO [main] 2017-08-14 13:03:46,445 IndexSummaryManager.java:85 - Initializing index summary manager with a memory pool size of 198 MB and a resize interval of 60 minutes
INFO [main] 2017-08-14 13:03:46,459 MessagingService.java:570 - Starting Messaging Service on /172.15.81.249:7000 (eth0)
INFO [ScheduledTasks:1] 2017-08-14 13:03:48,424 TokenMetadata.java:448 - Updating topology for all endpoints that have changed
WARN [main] 2017-08-14 13:04:17,497 Gossiper.java:1388 - Unable to gossip with any seeds but continuing since node is in its own seed list
INFO [main] 2017-08-14 13:04:17,499 StorageService.java:687 - Loading persisted ring state
INFO [main] 2017-08-14 13:04:17,500 StorageService.java:796 - Starting up server gossip
Content of files:
cassandra.yaml : https://pastebin.com/A3BVUUUr
cassandra-rackdc.properties: https://pastebin.com/xmmvwksZ
system.log : https://pastebin.com/2KA60Sve
netstat -atun https://pastebin.com/Dsd17i0G
Both the nodes have same error log.
All required ports are open.
Any suggestion ?
It's usually a best practice to have one seed node per DC if you have just two nodes available in your datacenter. You shouldn't make every node a seed node in this case.
I noticed that node1 has - seeds: "node1,node2" and node2 has - seeds: "node2,node1" in your configuration. A node will start by default without contacting any other seeds if it can find it's IP address as first element in - seeds: ... section in the cassandra.yml configuration file. That's what you can also find in your logs:
... Unable to gossip with any seeds but continuing since node is in its own seed list ...
I suspect, that in your case node1 and node2 are starting without contacting each other, since they identify themselves as seed nodes.
Try to use just node1 for seed node in both instance's configuration and reboot your cluster.
In case of node1 being down and node2 is up, you have to change - seeds: ... section in node1 configuration to point just to node2's IP address and just boot node1.
If your nodes can't find each other because of firewall misconfiguration, it's usually a good approach to verify if a specific port is accessible from another location. E.g. you can use nc for checking if a certain port is open:
nc -vz node1 7000
References and Links
See the list of ports Cassandra is using under the following link
http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureFireWall.html
See also a detailed documentation on running multiple nodes with plenty of sample commands:
http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html
This is for future reference. My problem has been solved just by opening 7000 port for same security group in AWS. Although it was open but security group was something different.
When I ran:
ec2-user#ip-Node1 ~]$ telnet Node2 7000
Trying Node2...
telnet: connect to address Node2: Connection timed out
I came to know the problem could be of the security group.
And that is how it has been solved.
About seeds I am using IP of both the nodes, like this:
-seeds: "node1,node2"
It is same on both the nodes.
I have a docker container running on overlay network. My requirement is to reach the service running in this container externally from different hosts. The service is bind to container's internal IP address and doing port bind to host is not a solution in this case.
Actual Scenario:
The service running inside container is spark driver configured with yarn-client. The spark driver binds to container internal IP(10.x.x.x). When spark driver communicates with hadoop yarn running on different cluster, the application master on yarn tries to communicate back to spark driver on the driver’s container internal ip but it can’t connect driver on internal IP for obvious reason.
Please let me know if there is a way to achieve the successful communication from application master(yarn) to spark driver(docker container).
Swarm Version: 1.2.5
docker info:
Containers: 3
Running: 2
Paused: 0
Stopped: 1
Images: 42
Server Version: swarm/1.2.5
Role: primary
Strategy: spread
Filters: health, port, containerslots, dependency, affinity, constraint
Nodes: 1
ip-172-30-0-175: 172.30.0.175:2375
└ ID: YQ4O:WGSA:TGQL:3U5F:ONL6:YTJ2:TCZJ:UJBN:T5XA:LSGL:BNGA:UGZW
└ Status: Healthy
└ Containers: 3 (2 Running, 0 Paused, 1 Stopped)
└ Reserved CPUs: 0 / 16
└ Reserved Memory: 0 B / 66.06 GiB
└ Labels: kernelversion=3.13.0-91-generic, operatingsystem=Ubuntu 14.04.4 LTS, storagedriver=aufs
└ UpdatedAt: 2016-09-10T05:01:32Z
└ ServerVersion: 1.12.1
Plugins:
Volume:
Network:
Swarm:
NodeID:
Is Manager: false
Node Address:
Security Options:
Kernel Version: 3.13.0-91-generic
Operating System: linux
Architecture: amd64
CPUs: 16
Total Memory: 66.06 GiB
Name: 945b4af662a4
Docker Root Dir:
Debug Mode (client): false
Debug Mode (server): false
Command to run container: I am running it using docker-compose:
zeppelin:
container_name: "${DATARPM_ZEPPELIN_CONTAINER_NAME}"
image: "${DOCKER_REGISTRY}/zeppelin:${DATARPM_ZEPPELIN_TAG}"
network_mode: "${CONTAINER_NETWORK}"
mem_limit: "${DATARPM_ZEPPELIN_MEM_LIMIT}"
env_file: datarpm-etc.env
links:
- "xyz"
- "abc"
environment:
- "VOL1=${VOL1}"
- "constraint:node==${DATARPM_ZEPPELIN_HOST}"
volumes:
- "${VOL1}:${VOL1}:rw"
entrypoint: ["/bin/bash", "-c", '<some command here>']
It seems yarn and spark need to be able to see the each other directly on the network. If you could put them on the same overlay network, everything would be able to communicate directly, if not...
Overlay
It is possible to route data directly into the overlay network on a Docker node via the docker_gwbridge that all overlay containers are connected to but, and it's a big but, that only works if you are on the Docker node where the container is running.
So running 2 containers on a 2 node non swarm mode overlay 10.0.9.0/24 network...
I can ping the local container on demo0 but not the remote on demo1
docker#mhs-demo0:~$ sudo ip ro add 10.0.9.0/24 dev docker_gwbridge
docker#mhs-demo0:~$ ping -c 1 10.0.9.2
PING 10.0.9.2 (10.0.9.2): 56 data bytes
64 bytes from 10.0.9.2: seq=0 ttl=64 time=0.086 ms
docker#mhs-demo0:~$ ping -c 1 10.0.9.3
PING 10.0.9.3 (10.0.9.3): 56 data bytes
^C
--- 10.0.9.3 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
Then on the other host the container are reversed but it's still the local container that is accessable.
docker#mhs-demo1:~$ sudo ip ro add 10.0.9.0/24 dev docker_gwbridge
docker#mhs-demo1:~$ ping 10.0.9.2
PING 10.0.9.2 (10.0.9.2): 56 data bytes
^C
--- 10.0.9.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
docker#mhs-demo1:~$ ping 10.0.9.3
PING 10.0.9.3 (10.0.9.3): 56 data bytes
64 bytes from 10.0.9.3: seq=0 ttl=64 time=0.094 ms
64 bytes from 10.0.9.3: seq=1 ttl=64 time=0.068 ms
So the big issue is the network would need to know where containers are running and route packets accordingly. If the network were capable of achieving routing like that, you probably wouldn't need an overlay network in the first place.
Bridge networks
Another possibility is using a plain bridge network on each Docker node with routable IP's. So each bridge has an IP range assigned that your network is aware of and can route to from anywhere.
192.168.9.0/24 10.10.2.0/24
Yarn DockerC
router
10.10.0.0/24 10.10.1.0/24
DockerA DockerB
The would attach a network to each nodes.
DockerA:$ docker network create --subnet 10.10.0.0/24 sparknet
DockerB:$ docker network create --subnet 10.10.1.0/24 sparknet
DockerC:$ docker network create --subnet 192.168.2.0/24 sparknet
Then the router configures routes for 10.10.0.0/24 via DockerA etc.
This is a similar approach to the way Kubernetes does its networking.
Weave Net
Weave is similar to overlay in that it creates a virtual network that transmits data over UDP. It's a bit more of a generalised networking solution though and can integrate with a host network.
I'd really appreciate some help to get cloudera manager running on AWS EC2.
Its my first install, and I'm aiming to use the AWS Free Tier to spin up a few nodes and do some training on Hadoop cluster and the cloudera distribution. I'm using the RedHat RHEL 7.2 image on AWS EC2.
I am following the instructions here... Cloudera Manager installation
I have installed cloudera manager OK, and get to the screen where it invites you to use a browser to log-in to the cloudera manager server. But that's where the problem starts. It seems the app is not listening on port 7180, so there's no hope of connecting from another machine across the network. I can't even connect locally, on the server, yet the service appears to be running OK. But its not listening on port 7180.
Q1 - How can I confirm the config is set to use port 7180.?
Q2 - are there obvious steps that I'm missing here ?
Thanks in advance,
[Edit..]
I'm beginning to wonder if the Free EC2 host is running short on memory to run cloudera manager. I saw one comment that implied that....AWS Forum post . But the process doesn't crash or report any problems in its logfile. So it must be OK, right?
[Edit.... with more diagnostic info....]
Here's a list of the diagnostics I've checked:-
SELinux is not running [for install and testing purposes],
WAN firewalls,
EC2 firewall/Security group,
Local firewall on server,
Cloudera manager log,
Is the service up and running?
Can you connect locally?
Securtity group on the EC2 instance, it contains:-
SSH and Port 7180,
Firewall/iptables/firewalld on the RedHat instance, tried:-
adding ports to iptables, then
dissabling iptables, then
adding ports to firewalld, then
dissabling the firewalld service,
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:7180
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:7182
But I'm getting the feeling that the installation of cloudera manager is not happy, or not running correctly.
I've checked the cloudera manager log, and it ends with the following.
$ tail /var/log/cloudera-scm-server/cloudera-scm-server.log
2016-02-25 11:02:23,581 INFO main:com.cloudera.cmon.components.MetricSchemaUpdate: persisting 19264 new metrics
2016-02-25 11:02:28,920 INFO main:com.cloudera.cmon.components.MetricSchemaUpdate: persisting 0 updated metrics
2016-02-25 11:02:28,924 INFO main:com.cloudera.cmon.components.MetricSchemaManager: Cross entity aggregates processed.
And when I use tail -f, and restart the cloudera-scm-server service, the log scrolls a lot, and comes back the same state. If I search for ERROR, there are no lines with "ERR".
$ sudo service cloudera-scm-server start
Starting cloudera-scm-server (via systemctl): [ OK ]
$ sudo systemctl status cloudera-scm-server
● cloudera-scm-server.service - LSB: Cloudera SCM Server
Loaded: loaded (/etc/rc.d/init.d/cloudera-scm-server)
Active: active (exited) since Thu 2016-02-25 12:23:03 EST; 44s ago
Docs: man:systemd-sysv-generator(8)
Process: 747 ExecStart=/etc/rc.d/init.d/cloudera-scm-server start (code=exited, status=0/SUCCESS)
So, if I try to test the service, by connecting from the local machine I get the sort of behavious that makes me thing its just not listening, and maybe not started correctly.
Try poke it with a curl from the same shell as the cloudera-scm-server service was started
$ curl localhost:7180
curl: (7) Failed connect to localhost:7180; Connection refused
$ wget localhost:7180
--2016-02-25 08:00:16-- http://localhost:7180/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:7180... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:7180... failed: Connection refused.
Try check what ports are listening on that machine, no 7180 , what's up with that???
$ netstat -nltp
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:7432 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp6 0 0 :::7432 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
Here's what to look for, and a possible solution - give it more memory...
Check the status of the cloudera-scm-server service using [depending on your flavour of linux]
$ sudo service cloudera-scm-server status
OR
$ sudo systemctl status cloudera-scm-server
Look for the status - Active: active (running)
But if you find - Active: active (exited)
you may have a problem during the startup of the cloudera-scm-server.
In which case, look at the log files for cloudera-scm-server
$sudo ls -l /var/log/cloudera-scm-server
$sudo cat /var/log/cloudera-scm-server/cloudera-scm-server.out
JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x000000078dc58000, 265809920, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 265809920 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /tmp/hs_err_pid831.log
[ec2-user#ip-172-31-31-166 ~]$ sudo tail -100 /var/log/cloudera-scm-server/cloudera-scm-server.out
JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x000000078dc58000, 265809920, 0) failed; error='Cannot allocate memory' (errno=12)
Use the command top to indicate how much memory is available to your system.
Possible solution - have a look at this discussion at Cloudera forum
In this case the java heap size was too small.
As we see that heap was exhausted, assuming this is not a memory leak
or something of the sort, Cloudera Manager may need more heap to
operate. This can be configured in:
/etc/default/cloudera-scm-server You could, for instance, change "-Xmx2G" to "-Xmx3G" or "-Xmx4G" If the problem still
happens, perhaps the heap dumps will yeild some clues.
I'd suggest you tail the logs. If you are using the free tier, cloudera manager will take a while to come up... possibly up to 5 minutes or more after you start the cloudera-scm-server.
The logs should show if there are any errors, possibly issues with memory allocation since the free tier servers have limited memory available. The little snippet of log entries looks fine and typical - it will go through a long list of processes before the UI comes up on 7180.
Also while that is going on, run top or even free -g to see how much resources are being used - particularly memory.
I was having the exact same issue, cannot hit the CM login using public DNS or IP on port 7180.
Following steps will help you :
iptables stopped (service iptables stop)
SELinux disabled (got to /etc/selinux/config and disbaled the selinux)
curl/wget localhost:7180 works (check the curl status)
ufw allow 7180
service httpd status should be running.
check va/log/cloudera-scm-server log : if any error found then troubleshoot the error
cloudera-scm-server status (should be running state)
netstat -nap | grep 7180 returns (if running other service then kill it)
telnet localhost 7180 (should be connected)
Cannot connect to Cloudera Manager, not listening on port 7180
1] Check the status:
sudo service cloudera-scm-server status
*cloudera-scm-server.service - LSB: Cloudera SCM Server Loaded: loaded (/etc/rc.d/init.d/cloudera-scm-server; bad; vendor preset: disabled) Active: active (exited) since UTC; 47min ago Docs: man:systemd-sysv-generator(8) rm /var/run/cloudera-scm-server.pid
NOTE : The Cloudera Manager service will not be running as it exited abnormally.
Running service cloudera-scm-server status will print following message "cloudera-scm-server dead but pid file exists".
Reason: Out of memory.
Solution : Examine the heap dump that the Cloudera Manager Server creates when it runs out of memory. The heap dump file is created in the /tmp directory, has file extension .hprof and file permission of 600. Its owner and group will be the owner and group of the Cloudera Manager server process, normally cloudera-scm:cloudera-scm.
Link : http://www.cloudera.com/documentation/manager/5-0-x/Cloudera-Manager-Diagnostics-Guide/cm5dg_troubleshooting_cluster_config.html
Check the status of `cloudera-scm-server` and follow the instructions ahead:
[root#quickstart ~]# `service cloudera-scm-server status`
By default, Cloudera's QuickStart VM manages CDH using Linux's configuration
and service management. To use Cloudera Manager instead, you must shut down
and disable the existing CDH services and then start Cloudera Manager. You can
do this by running the following command:
`sudo /home/cloudera/cloudera-manager`
[root#quickstart ~]# `sudo /home/cloudera/cloudera-manager `
`[QuickStart] Shutting down CDH services via init scripts...
JMX enabled by default
Using config: /etc/zookeeper/conf/zoo.cfg
[QuickStart] Disabling CDH services on boot...
[QuickStart] Starting Cloudera Manager services...
[QuickStart] Deploying client configuration...
[QuickStart] Starting CM Management services...
[QuickStart] Enabling CM services on boot...
[QuickStart] Starting CDH services...`
________________________________________________________________________________
Success! You can now log into Cloudera Manager from the QuickStart VM's browser:
http://quickstart.cloudera:7180
Username: cloudera
Password: cloudera
When I tried connecting to Elasticsearch using the
curl http://localhost:9200 it is working fine.
But when I run the curl http://IpAddress:9200 it is throwing an error saying
Failed to connect to localhost port 9200: Connection refused
How to resolve this error?
Edit /etc/elasticsearch/elasticsearch.yml and add the following line:
network.host: 0.0.0.0
This will "unset" this parameter and will allow connections from other IPs.
By default it should bind to all local addresses. So, assuming you don't have a network layer issue with firewalls, the only ES setting I can think to check is network.bind_host and make sure it is either not set or is set to 0.0.0.0 or ::0 or to the correct IP address for your network.
Update: per comments in ES 2.3 you should set network.host instead.
In my case elasticsearch was started.
But still had
curl: (7) Failed to connect to localhost port 9200: Connection refused
The following command was unsuccessful
sudo service elasticsearch restart
In order to make it work, I had to run instead
sudo systemctl restart elasticsearch
Then it went all fine.
Tried everything on this page, and only instructions from here helped.
in /etc/default/elasticsearch, make sure these are un-commented:
START_DAEMON=true
ES_USER=elasticsearch
ES_GROUP=elasticsearch
LOG_DIR=/var/log/elasticsearch
DATA_DIR=/var/lib/elasticsearch
WORK_DIR=/tmp/elasticsearch
CONF_DIR=/etc/elasticsearch
CONF_FILE=/etc/elasticsearch/elasticsearch.yml
RESTART_ON_UPGRADE=true
make sure /var/lib/elasticsearch is owned by elasticsearch user:
chown -R elasticsearch:elasticsearch /var/lib/elasticsearch/
Why don't you start with this command-line:
$ sudo service elasticsearch status
I did it and get:
"There is insufficient memory for the Java Runtime..."
Then I edited /etc/elasticsearch/jvm.options file:
...
################################################################
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
#-Xms2g
#-Xms2g
-Xms512m
-Xmx512m
################################################################
...
This worked like a charm.
None of the proposed solutions here worked for me, but what eventually got it working was adding the following to elasticsearch.yml
network:
host: 0.0.0.0
http:
port: 9200
After that, I restarted the service and now I can curl it from both within the VM and externally. For some odd reason, I had to try a few different variants of a curl call inside the VM before it worked:
curl localhost:9200
curl http://localhost:9200
curl 127.0.0.1:9200
Note: I'm using Elasticsearch 5.5 on Ubuntu 14.04
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error='Cannot allocate memory' (errno=12)
be sure that the server is started. I've seen this problem when my virtual machine had too litle RAM and es could not start.
sudo systemctl status elasticsearch
the above will show you if es is indeed running.
Edit elasticsearch.yml and add the following line
http.host: 0.0.0.0
network.host: 0.0.0.0 didn't work for
For this problem, I had to use :
sudo /usr/share/elasticsearch/bin/elasticsearch start
to be able to get something on ports 9200/9300 (sudo netstat -ntlp) and a response to:
curl -XGET http://localhost:9200
I experienced a similar issue.
Here's how I solved it
Run the service command below to start ElasticSearch
sudo service elasticsearch start
OR
sudo systemctl start elasticsearch
If you still get the error
curl: (7) Failed to connect to localhost port 9200: Connection refused
Run the service command below to check the status of ElasticSearch
sudo service elasticsearch status
OR
sudo systemctl status elasticsearch
If you get a response (Active: active (running)) like the one below then you ElasticSearch is active and running
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2019-09-21 11:22:21 WAT; 3s ago
You can then test that your Elasticsearch node is running by sending an HTTP request to port 9200 on localhost using the command below:
curl http://localhost:9200
Else, if you get a response a different response, you may have to debug further to fix it, but the running the command below, will help you detect what caveats are holding ElasticSearch service from starting.
sudo service elasticsearch status
OR
sudo systemctl status elasticsearch
If you want to stop the ElasticSearch service, simply run the service command below;
sudo service elasticsearch stop
OR
sudo systemctl stop elasticsearch
N/B: You may have to run the command sudo service elasticsearch status OR sudo systemctl status elasticsearch each time you encounter the error, in order to tell the state of the ElasticSearch service.
This also applies for Kibana, run the command sudo service kibana status OR sudo systemctl status kibana each time you encounter the error, in order to tell the state of the Kibana service.
That's all.
I hope this helps.
I had the same problem refusing connections on 9200 port.
Check elasticsearch service status with the command sudo service elasticsearch status. If it is presenting an error and you read anything related to Java, probably the problem is your jvm memory. You can edit it in /etc/elasticsearch/jvm.options. For a 1GB RAM memory machine on Amazon environment, I kept my configuration on:
-Xms128m
-Xmx128m
After setting that and restarting elasticsearch service, it worked like a charm. Nmap and UFW (if you use local firewall) checking should also be useful.
Open your Dockerfile under elasticsearch folder and update "network.host=0.0.0.0" with "network.host=127.0.0.1". Then restart the container. Check your connection with curl.
$ curl http://docker-machine-ip:9200
{
"name" : "vI6Zq_D",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "hhyB_Wa4QwSX6zZd1F894Q",
"version" : {
"number" : "5.2.0",
"build_hash" : "24e05b9",
"build_date" : "2017-01-24T19:52:35.800Z",
"build_snapshot" : false,
"lucene_version" : "6.4.0"
},
"tagline" : "You Know, for Search"
}
For versions higher than 6.8 (7.x) you need two things.
1. change the network host to listen on the public interface.
In the configuration file elasticsearch.yml (for debian and derivatives -> /etc/elasticsearch/elasticsearch.yml).
set the network.host or network.bind_host to:
...
network.host: 0.0.0.0
...
Or the interface that must be reached
2. Before going to production it's necessary to set important discovery and cluster formation settings.
According to elastic.co:
v6.8 -> discovery settings that should set.
by e.g
...
# roughly means the same as 1
discovery.zen.minimum_master_nodes: -1
...
v7.x -> discovery settings that should set.
by one single node
discovery.type: single-node
#OR set discovery.seed_hosts : 127.0.0.1:9200
at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured.
In this case, first of all you need to check the java version using below command:
java -version
after running this command you get something like this:
java version "1.7.0_51"
OpenJDK Runtime Environment (rhel-2.4.5.5.el7-x86_64 u51-b31)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
then use this command:
update-alternatives --config java
and select the below version
*+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51-2.4.5.5.el7.x86_64/jre/bin/java
2 /usr/java/jdk1.8.0_73/jre/bin/java
Enter to keep the current selection[+], or type selection number: 2
curl -XGET http://127.0.0.1:9200
My 2 cents,
I just followed the install procedure on Digital Ocean, apparently the package available in the repos is not up to date, I deleted everything and followed the install procedure direct from Elastic Search and everything is working now, basically the out of the box behaviour is on a localhost pointing to 9200. Same thing/issue found with Kibana, the solution for me was too, to remove everything and just follow their procedure, Hope this saves someone two hours (the time I spent figuring out how to setup ELK!)
en
Update your jdk to latest minimum version for your elasticsearch.
Change the network.bind to 0.0.0.0 and http:port to 9200. The bind address 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.
If you encounter the Connection refused error, simply run the command below to check the status of ElasticSearch service
sudo service elasticsearch status
This will help you decipher the state of ElasticSearch service and what to do about it.
For those of you installing ELK on virtual machine in GCP (Google Cloud Platform), make sure that you created firewall rule of Ingress type (i.e. for incoming to VM traffic). You can specify in the rule multiple ports at a time by separating them with comma: 5000,5044,5601,9200,9300,9600.
In that rule you may want to specify a tag (pick tag's name as you like, for example docker-elk that will target your VM (Targets column):
On VM's settings page assign that tag to your VM:
After doing that I was able to access Elasticsearch in my browser via port 9200. And I didn't have to edit elasticsearch.yml file whatsoever.
I have run across this problem every time I install or upgrade ES (7.0+). And the solution was ALWAYS just wait for ES to fully start. It takes about a minute for the REST API to be reponsive. No matter what service status says.
service elasticsearch start
*started
*wait for at least a minute
curl now works and returns responses on the port 9200
After utilizing some of the answers above, don't forget that after an apt install, a total reboot might be in order.
Just to add on this, I've came across many docs through google that said to set network.host to localhost.
Doing so gave me the infamous connection refused. You must use an IP address (127.0.0.1), not a FQDN.
Jeff
Make sure that port 9200 is open for my case it was an amazon instance so when i opened it in my security group the curl command worked.
Disabling SELinux worked for me, although I don't suggest it - I did that just for a PoC
My problem was I could not work with localhost I needed to set it to localhost's IP address
network.bind_host: 127.0.0.1
In my case, the problem is with java version, i installed open-jdk 11 previously. Thats creating the issue while starting the service. I changed it open-jdk 8 and it started working
I experienced this on CentOS 7, and the issue was that /etc/hosts had the following:
127.0.0.1 localhost.localdomain
which I updated to include localhost as follows:
127.0.0.1 localhost localhost.localdomain
after that, no issues.
you have to edit /etc/elasticsearch/elasticsearch.yml
by default all configurations will be commented ,add following configuration
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: [0.0.0.0]
then restart the service
I ran into a related situation recently.
Here's my take on the subject: Accessing Elastic 5.5 in vagrant guest from host through a private network
TL;DR
The settings:
network.host: 0.0.0.0
http.port: 9200
work fine. One just needs to wait enough time for ES to complete its initialization procedure, bind to the network iface and start listening on the port.
Now, from within the guest, curl http://localhost:9200 works and from the host, curl http://192.168.54.2:9200 works as well.
For Windows user try,
https://localhost:9200/
It worked for me.
Just now i created a 3 node cassandra cluster on my local machines using vagrant, running cassandra 2.0.13
following is my cassandra.yaml config for each node
node0
cluster_name: 'MyCassandraCluster'
num_tokens: 256
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "192.168.33.10,192.168.33.11"
listen_address: 192.168.33.10
rpc_address: 0.0.0.0
endpoint_snitch: RackInferringSnitch
node1
cluster_name: 'MyCassandraCluster'
num_tokens: 256
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "192.168.33.10,192.168.33.11"
listen_address: 192.168.33.11
rpc_address: 0.0.0.0
endpoint_snitch: RackInferringSnitch
node2
cluster_name: 'MyCassandraCluster'
num_tokens: 256
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "192.168.33.10,192.168.33.11"
listen_address: 192.168.33.12
rpc_address: 0.0.0.0
endpoint_snitch: RackInferringSnitch
when i run
nodetool status
i get following result
Datacenter: 168
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.33.12 88.34 KB 256 67.8% b3d6d9f2-3856-445b-bad8-97763d7b22c7 33
UN 192.168.33.11 73.9 KB 256 66.4% 67e6984b-d822-47af-b26c-f00aa39f02d0 33
UN 192.168.33.10 55.78 KB 256 65.8% 4b599ae0-dd02-4c69-85a3-05782a70569e 33
According to tutorial i have attended from datastax each node should own 33% of data but here it show each node owns around 65% of data i am not able to figure own what am i doing wrong.
I have not loaded any data in cluster nor have created any keyspace , its brand new cluster without any data.
pls help me figure out the problem
thanks
If there is no data loaded into the cluster, there shouldn't be any percentage owned. Also, your nodetool output IP addresses do not match what you put earlier for your IPs- maybe you are looking at different machines that already have data loaded? Last, you may not want to use a RackInferringSnitch since it seems that all your nodes are in the same rack. If you are just playing around in a single datacenter, you can use the simple snitch. Otherwise, NetworkTopology is good for multiple datacenters
For the Owns / Load column to be accurate in nodetool status, you need to specify a keyspace.
Try nodetool status <keyspace name> and it will actually show you the %'s for how much data is stored in each node.