Das Überschreiben von `tcp.publish_port` bricht das Clustering, wenn sich elasticsearch in einem Container befindet

Question

Ich versuche, einen ElasticSearch-Cluster auszuführen, wobei jeder ES-Knoten in einem eigenen Container ausgeführt wird. Diese Container werden unter Verwendung von ECS über mehrere Maschinen bereitgestellt, auf denen möglicherweise andere Container ohne Bezug ausgeführt werden. Um Portkonflikte zu vermeiden, wird jedem Port, den ein Container freigibt, ein zufälliger Wert zugewiesen. Diese zufälligen Ports sind über alle laufenden Container desselben Typs hinweg konsistent. Mit anderen Worten, alle laufenden Es-Node-Container ordnen den Port 9300 derselben Zufallszahl zu.

Hier ist die Config ich benutze:

network: 
    host: 0.0.0.0 

plugin: 
    mandatory: cloud-aws 

cluster: 
    name: ${ES_CLUSTER_NAME} 

discovery: 
    type: ec2 
    ec2: 
    groups: ${ES_SECURITY_GROUP} 
    any_group: false 
    zen.ping.multicast.enabled: false 

transport: 
    tcp.port: 9300 
    publish_port: ${_INSTANCE_PORT_TRANSPORT} 

cloud.aws: 
    access_key: ${AWS_ACCESS_KEY} 
    secret_key: ${AWS_SECRET_KEY} 
    region: ${AWS_REGION} 

In diesem Fall _INSTANCE_PORT_TRANSPORT ist der Port, der 9300 auf dem Host-Rechner gebunden ist. Ich habe bestätigt, dass alle oben verwendeten Umgebungsvariablen richtig eingestellt sind. Ich setze auch network.publish_host auf die lokale IP-Adresse des Host-Computers über eine Befehlszeile arg.

Wenn ich gezwungen _INSTANCE_PORT_TRANSPORT (und wiederum transport.publish_port) 9300 zu sein, alles hat super funktioniert, aber sobald es einen Zufallswert gegeben ist, kann Knoten nicht mehr miteinander zu verbinden. Ich sehe Fehler wie diese mit logger.discovery=TRACE:

ConnectTransportException[[][10.0.xxx.xxx:9300] connect_timeout[30s]]; nested: ConnectException[Connection refused: /10.0.xxx.xxx:9300]; 
    at org.elasticsearch.transport.netty.NettyTransport.connectToChannelsLight(NettyTransport.java:952) 
    at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:916) 
    at org.elasticsearch.transport.netty.NettyTransport.connectToNodeLight(NettyTransport.java:888) 
    at org.elasticsearch.transport.TransportService.connectToNodeLight(TransportService.java:267) 
    at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing$3.run(UnicastZenPing.java:395) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
    at java.lang.Thread.run(Thread.java:745) 

Es scheint, wie der Hafen ein Knoten bindet, ist der gleiche wie der Hafen es Pings bei dem Versuch, zu anderen Knoten zu verbinden. Gibt es eine Möglichkeit, sie anders zu machen? Wenn nicht, was ist der Sinn von transport.publish_port?

Answer 1

Die Art und Weise, wie das discovery-ec2 Plugin funktioniert, ist, dass es eine Liste von IP-Adressen mit AWS EC2 API sammelt und diese Liste als Unicast-Liste von Knoten verwendet.

Aber es sammelt keine Informationen aus dem laufenden Cluster. Offensichtlich ist der Knoten noch nicht verbunden! So weiß es nichts über die publish_port anderer Knoten.

Es fügt nur eine IP-Adresse hinzu. Und das ist alles. Elasticsearch dann is using the default port das ist 9300.

So gibt es nichts, was Sie IMO tun können, um das in der kurzen Zeit zu beheben.

Aber wir können uns vorstellen, ein neues Feature hinzuzufügen, das dem entspricht, was für Google Compute Engine implementiert wurde. Wir verwenden bestimmte Metadaten, um diesen Port von den GCE-APIs zu beziehen.

Wir könnten das gleiche für Azure und EC2 tun. Wollen Sie open an issue, damit wir den Aufwand verfolgen können?