Apache Ignite Static IP node discover - amazon-ec2

I am building an Apache Ignite cluster that uses Static IP Discovery rather than Multicast IP Discovery (its in AWS EC2).
I have configured like so (https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery):
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>host1.example.com</value>
<value>host2.example.com</value>
<value>host3.example.com</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
When I start the nodes, I can see the following error:
[15:04:36,385][WARNING][main][TcpDiscoverySpi] Failed to connect to any address from IP finder (make sure IP finder addresses are correct and firewalls are disabled on all host machines): [host1.example.com/10.0.21.223:47501, host2.example.com/10.0.21.207:47501, host3.example.com/10.0.21.191:47501]
From this I can see that Ignite has correctly resolved the hostnames to ip addresses, but it can't connect to form the cluster. These hosts are all in the same subnet in AWS EC2, and I have verified that port 47500 is open between them (I am not sure what the 47501 reference is).
I have also tried used just the ip addresses, rather than the hostnames, but the result is the same.
Am I missing something here?
Please note that Ignite is running as a Docker container on each server. The necessary TCP ports for Ignite are exposed and functional.
Full Log:
[15:55:18,231][INFO][main][IgniteKernal] Config URL: file:/apache-ignite-fabric-1.6.0-bin/config/default-config.xml
[15:55:18,231][INFO][main][IgniteKernal] Daemon mode: off
[15:55:18,231][INFO][main][IgniteKernal] OS: Linux 4.4.19-29.55.amzn1.x86_64 amd64
[15:55:18,231][INFO][main][IgniteKernal] OS user: root
[15:55:18,231][INFO][main][IgniteKernal] Language runtime: Java Platform API Specification ver. 1.8
[15:55:18,232][INFO][main][IgniteKernal] VM information: Java(TM) SE Runtime Environment 1.8.0_131-b11 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.131-b11
[15:55:18,233][INFO][main][IgniteKernal] VM total memory: 3.0GB
[15:55:18,233][INFO][main][IgniteKernal] Remote Management [restart: on, REST: on, JMX (remote: on, port: 49112, auth: off, ssl: off)]
[15:55:18,233][INFO][main][IgniteKernal] IGNITE_HOME=/apache-ignite-fabric-1.6.0-bin
[15:55:18,233][INFO][main][IgniteKernal] VM arguments: [-Xms1g, -Xmx1g, -XX:+AggressiveOpts, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=true, -DIGNITE_SUCCESS_FILE=/apache-ignite-fabric-1.6.0-bin/work/ignite_success_a8723f31-1954-4ea4-b190-762a36088140, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49112, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/apache-ignite-fabric-1.6.0-bin, -DIGNITE_PROG_NAME=/apache-ignite-fabric-1.6.0-bin/bin/ignite.sh, -Xmx3g, -XX:+UseG1GC]
[15:55:18,234][INFO][main][IgniteKernal] Configured caches ['ignite-marshaller-sys-cache', 'ignite-sys-cache', 'ignite-atomics-sys-cache']
[15:55:18,234][WARNING][main][IgniteKernal] Peer class loading is enabled (disable it in production for performance and deployment consistency reasons)
[15:55:18,238][INFO][main][IgniteKernal] 3-rd party licenses can be found at: /apache-ignite-fabric-1.6.0-bin/libs/licenses
[15:55:18,284][INFO][main][IgniteKernal] Non-loopback local IPs: 172.17.0.2, fe80:0:0:0:42:acff:fe11:2%eth0
[15:55:18,284][INFO][main][IgniteKernal] Enabled local MACs: 0242AC110002
[15:55:18,294][INFO][main][IgnitePluginProcessor] Configured plugins:
[15:55:18,295][INFO][main][IgnitePluginProcessor] ^-- None
[15:55:18,295][INFO][main][IgnitePluginProcessor]
[15:55:18,347][INFO][main][TcpCommunicationSpi] IPC shared memory server endpoint started [port=48100, tokDir=/apache-ignite-fabric-1.6.0-bin/work/ipc/shmem/cb41f1a5-d2f5-453d-a1c5-e008c1e12d2a-62]
[15:55:18,348][INFO][main][TcpCommunicationSpi] Successfully bound shared memory communication to TCP port [port=48100, locHost=0.0.0.0/0.0.0.0]
[15:55:18,362][INFO][main][TcpCommunicationSpi] Successfully bound to TCP port [port=47100, locHost=0.0.0.0/0.0.0.0]
[15:55:18,383][WARNING][main][NoopCheckpointSpi] Checkpoints are disabled (to enable configure any GridCheckpointSpi implementation)
[15:55:18,405][WARNING][main][GridCollisionManager] Collision resolution is disabled (all jobs will be activated upon arrival).
[15:55:18,408][WARNING][main][NoopSwapSpaceSpi] Swap space is disabled. To enable use FileSwapSpaceSpi.
[15:55:18,409][INFO][main][IgniteKernal] Security status [authentication=off, tls/ssl=off]
[15:55:18,652][INFO][main][GridTcpRestProtocol] Command protocol successfully started [name=TCP binary, host=0.0.0.0/0.0.0.0, port=11211]
[15:55:18,719][INFO][main][TcpDiscoverySpi] Successfully bound to TCP port [port=47500, localHost=0.0.0.0/0.0.0.0]
[15:55:21,746][WARNING][main][TcpDiscoverySpi] Failed to connect to any address from IP finder (make sure IP finder addresses are correct and firewalls are disabled on all host machines): [/10.0.21.191:47500, /10.0.21.207:47500, /10.0.21.223:47500]

Default port for ignite is 47500, but in logs as you can see it tries to connect to 47501:
try to specify a port in your address list:
<value>host1.example.com:47500</value>
also checkout this doc: https://apacheignite.readme.io/v2.0/docs/aws-deployment it can be useful in your case.

First of all I would recommend to update Ignite from 1.6 to 1.9.
Second, specify port, as was suggested here.
Run your docker with --net=host, so application inside container will see network interfaces from host. This should help.
Also, it's possible to configure special S3 IpFinder

Inspite of settings in my previous answer if it is not working then it might be because your IP may not be stable.
As per Ignite docs
Node discovery on AWS cloud is usually proven to be more challenging. Amazon EC2, just like most of the other virtual environments, has the following limitations:
Multicast is disabled.
TCP addresses change every time a new image is started.
Although you can use TCP-based discovery in the absence of the Multicast, you still have to deal with constantly changing IP addresses and constantly updating the configuration. This creates a major inconvenience and makes configurations based on static IPs virtually unusable in such environments.
Please refer to this link for Amazon S3 Based Discovery
https://apacheignite.readme.io/v1.1/docs/aws-config#section-amazon-s3-based-discovery

setLocalAddress and setLocalPort on the DiscoverySPI
<!-- Initial local port to listen to. -->
<property name="localPort" value="yourport"/>
<!-- Initial local address for discovery . -->
<property name="localAddress" value="yourhost"/>
<!-- Changing local port range. This is an optional action. -->
<property name="localPortRange" value="20"/>
and use the same port in the Addresslist that you specify on IPFinder.
<bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>yourhost:yourport</value>
<value>otherhost:otherhostport</value>
</list>
</property>
</bean>
Ok all this being done should work with TCPVmIPfinder.

Related

Changing Default Ports in Moqui

Moqui Framework Version : 2.1.3
The Framework runs on the default port 8080 just fine, i would like to change the default ports and i did read https://www.moqui.org/m/docs/framework/Run+and+Deploy#a2.RuntimeDirectoryandMoquiConfigurationXMLFile
which states > "Each of these can be system environment variables (with underscores) or Java properties (with underscores or dots) using the -D command-line argument.
i did find the webapp_ variables are referenced in MoquiDefaultConf.xml as mentioned in the above material and tried using the below start command >
$sudo nohup java -Dwebapp_http_host=localhost -Dwebapp_http_port=9080 -Dwebapp_https_port=9443 -jar moqui.war conf=conf/MoquiDevConf.xml &
However the above command does not seem to change the port, Moqui is still running on default port 8080, What could i be missing?
I also tried the solution to update the webapp tag in MoquiDevConf.xml as mentioned in Running Moqui on Tomcat over SSL (setting http-port and htts-port) - return code 302 with no joy,
Appreciate any pointers, i'm really stuck
The environment variables or Java properties you mention are for setting the ports to use when building URLs. These are the external ports used for accessing your server and if a load balancer or reverse proxy is used may be different from the ports the servlet container is running on. For more information see:
https://moqui.org/m/docs/framework/Run+and+Deploy#EnvironmentVariables
If you are running Moqui with the embedded Jetty server you can specify the port it listens on using the port argument as described in the Executable WAR File section of the Run and Deploy document:
https://moqui.org/m/docs/framework/Run+and+Deploy#a3.ExecutableWARFile
Note that the embedded Jetty server can be used in production but it does not support https and is meant to be used behind a reverse proxy like nginx or Apache httpd that forwards requests to the embedded Jetty server.
If you deploy the WAR file by dropping it in a Servlet Container (ie as an actual WAR file, not treating it as an executable JAR file) then the port configuration would be done with the Servlet Container (Tomcat, Jetty, etc).

Remote Server Issue-Distributed Testing

I have a Master machine(192.xxx.x.xx) and Two Slave Machine(192.xxx.x.xx,192.xxx.x.xx).
In the Master Machine jmeter properties file , i added the two salve machine IP.
I run the server.bat file in the Slave Machine respectively.
But one of my slave machine showed an error of Port 1099 Busy.So i changed the port of that particular Salve Machine to 1098 and rerun the server.bat file.
Now when i select Remote Start ALL command in the Master Machine,the Slave Machine in which the port was changed does not execute the Test. But the other slave machine whose port is 1099 successfully executed the test.
Can anybody tell me the exact issue with the other slave machine.
You need to follow changing RMI port steps:
JMeter uses the standard RMI port 1099. It is possible to change this. For this to work successfully, all the following need to agree:
On the server, start rmiregistry using the new port number
On the server, start JMeter with the property server_port defined
On the client, update the remote_hosts property to include the new remote host:port settings
Since JMeter 2.1.1, the jmeter-server scripts provide support for changing the port. For example, assume you want to use port 1664 (perhaps 1099 is already used).
On Windows (in a DOS box)
C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER [other options]
On Unix:
$ SERVER_PORT=1664 jmeter-server [other options]
[N.B. use upper case for the environment variable]
In both cases, the script starts rmiregistry on the specified port, and then starts JMeter in server mode, having defined the "server_port" property.
The chosen port will be logged in the server jmeter.log file (rmiregistry does not create a log file).

Cannot produce events to Confluent Kafka deployed on AWS EC2 from local machine

I'm trying to connect from an external client (my laptop) to a broker in a Kafka cluster that I have running on ec2 machines. When I try and connect from my local machine I get the following error:
$ ./kafka-console-producer --broker-list AWS.PRIV.ATE.IP:9092 --topic test
>hi
>[2018-09-20 13:28:53,952] ERROR Error when sending message to topic test with key: null, value: 2 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for test-0: 1519 ms has passed since batch creation plus linger time
The topic exists because if I run (from local machine)
$ ./kafka-topics --list --zookeeper AWS.PRIV.ATE.IP:2181
__confluent.support.metrics
__consumer_offsets
_schemas
connect-configs
connect-offsets
connect-status
test
The cluster configuration is from Confluent's AWS quickstart template: https://github.com/aws-quickstart/quickstart-confluent-kafka/blob/master/templates/confluent-kafka.template and I'm running the open source version.
The three broker ec2 instances are visible to my local machine, which I verified by stopping the Kafka broker, starting a simple HTTP server on port 9092, and successfully curling that server using the internal IP address of the ec2 instance.
If I ssh into one of the broker instances I can successfully produce and consume messages across the cluster. The only update I've made to the out-of-the-box configuration provided by the template is changing listeners=PLAINTEXT://ec2-AWS-PUB-LIC-IP.compute-1.amazonaws.com:9092 in server.properties on each machine and then restarted the kafka server.
I can provide more configuration or debugging info if necessary. Believe the issue is something regarding IP address discoverability/visibility but I'm not entirely sure what.
You need to set advertised.listeners too.
See https://rmoff.net/2018/08/02/kafka-listeners-explained/ for details.

Installing Kubernetes on mac with vagrant and virtualbox

This is my first attempt to install and use Kubernetes. I am trying to install an environment on Mac for developing my own apps and deploying them for test locally with Kubernetes. I am familiar with using Vagrant, VirtualBox and Docker for the same purpose. When I saw this page https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/vagrant.md I assumed it would be trivial. I executed these lines:
export KUBERNETES_PROVIDER=vagrant
curl -sS https://get.k8s.io | bash
This created a master VM and a Minion, but Kubernetes seems to have failed to start on the master. On the master /var/log/salt/master is full of python Traceback errors, like this:
2015-07-17 22:14:42,629 [cherrypy.error ][INFO ][3252] [17/Jul/2015:22:14:42] ENGINE Started monitor thread '_TimeoutMonitor'.
2015-07-17 22:14:42,736 [cherrypy.error ][ERROR ][3252] [17/Jul/2015:22:14:42] ENGINE Error in HTTP server: shutting down
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cherrypy/process/servers.py", line 187, in _start_http_thread
self.httpserver.start()
File "/usr/lib/python2.7/site-packages/cherrypy/wsgiserver/wsgiserver2.py", line 1824, in start
raise socket.error(msg)
error: No socket could be created
Vagrant is version 1.7.3. VirtualBox is version 4.3.30
Have I made an obvious stupid mistake?
I don't yet know the fix but I know what is going wrong since it happens to me as well:
OS X 10.10.3
Vagrant 1.7.4
VirtualBox 4.3.30
Kubernetes 1.0.1
When I run the default configuration of this (which creates one "master" and one "minion" VM) I see that the static IP address is not being assigned to the "eth1" interface, and I also see that the Salt API server is sitting in what appears to be an infinite retry loop because it is trying to listen on that IP address.
Also, the following message happened during boot:
[vagrant#kubernetes-master ~]$ dmesg | grep eth1
[ 9.321496] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
So basically, the static IP address didn't get assigned because eth1 wasn't ready when the system first booted, and Salt is waiting for it to get assigned.
I could fix this after boot by sshing to the box using "vagrant ssh" and running the command:
sudo /etc/init.d/network restart
on each host.
This "fixes" eth1 by assigning the static IP address, and after that Salt begins to do its thing, installs Docker, boots various containers, and so on.
What I don't know is how to make this work every time without manual intervention. It appears to be some sort of a race condition between Vagrant and VirtualBox.
If you just want to kick the tires with Kubernetes, I'd recommend installing boot2docker and then following the Running kubernetes locally via Docker getting started guide. Once you are comfortable interacting with the Kubernetes API and want a more complex local setup, you can then work on installing Vagrant.
If the Vagrant instructions aren't working, you should also feel free to file a bug in the github repository.
The tutorial pointed by Robert is realy easy to run. Just change the version to 0.21.2 (maybe 0.21.3 works too).
Else, if you prefer a vagrant solution, try with pires cluster on vagrant. It runs with almost nothing to change.
Running Kubernetes inside VirtualBox requires 4 networks and some adjustments to the configuration:
The VirtualBox HOST ONLY network will be the network used to access the Kubernetes master and nodes from the Mac or PC.
The NAT Network to download packages from the Internet.
The internal connections between Kubernetes PODs uses a tunnel network TUN
The Kubernetes Cluster IP Network is a private IP range used inside the cluster to give each Kubernetes service a dedicated IP
Vagrantfile needs to pass the node public IPs to the Ansible roles that configure Kubernetes to set KUBELET_EXTRA_ARGS environment variable with the public IP of each node (required for reading logs using kubectl).
NodePort needs to be used to publish applications running inside the Kubernetes cluster as Load Balancers are not available in VirtualBox.
See the full example and download the code at Building a Kubernetes Cluster with Vagrant and Ansible (without Minikube), it has been tested in Ubuntu but should work on a MAC as well.

Allowing access based on hostname for Manager application in Tomcat

I can't get the configuration for Tomcat right to allow access to the Manager Webapp. We have configured tomcat-users.xml, manager.xml etc. When we allow access based on the IP address it works, but based on the hostname it doesn't. This is the configuration we use:
<Context privileged="true"
docBase="/path/to/tomcat_home/webapps/manager">
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="localhost|otherhostname" deny="" />
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="172\.30\.\d+\.\d+|127\.0\.0\.1"/>
</Context>
When I remove the RemoteHostValve we can access the manager app (jmxproxy).
Any ideas?
Regards,
Johan-Kees
Check for the exact hostname that host is sending via http (for example with Wireshark), put the hostname with a prefix . into the config and make sure that the hostname is resolvable (i.e. via DNS and/or hosts)...
For reference see:
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote%20Host%20Filter
http://tomcat.apache.org/tomcat-7.0-doc/config/engine.html
http://tomcat.apache.org/migration.html#Manager_application

Resources