尝试使用负载均衡器在AWS ECS上尝试dask.distributed集群时出现连接错误

我们尝试在AWS上使用ECS启动dask集群。我们目前的设置：尝试使用负载均衡器在AWS ECS上尝试dask.distributed集群时出现连接错误

两种服务 - dask-scheduler服务和dask-worker服务，每个服务都有一个任务定义。每个服务都有一个任务（将来可以扩展出沙盒工作任务）。
dask-scheduler将端口8786,8787,& 9786从容器映射到主机。 dask-worker任务不映射端口。
传统的负载均衡器位于dask-scheduler的前面，并在TCP上的这三个端口上侦听。尽管我们只有一个dask调度程序任务，但负载平衡器在调度程序重新启动时提供了一个静态地址。
dask-worker使用负载均衡器的参数启动。 dask-scheduler启动时没有参数。

不幸的是，我没有太多的运气。我得到这些日志消息：

 
06:10:24 
distributed.core - INFO - Connection from 172.31.35.94:49003 to Scheduler 
 
06:10:24 
distributed.core - INFO - Lost connection: ('172.31.35.94', 49003) 
 
06:10:24 
distributed.core - INFO - Close connection from 172.31.35.94:49003 to Scheduler 
 
06:10:54 
distributed.core - INFO - Connection from 172.31.35.94:49009 to Scheduler 
 
06:10:54 
distributed.core - INFO - Lost connection: ('172.31.35.94', 49009) 
 
06:10:54 
distributed.core - INFO - Close connection from 172.31.35.94:49009 to Scheduler 
 
06:11:07 
distributed.core - INFO - Connection from 172.31.35.94:49018 to Scheduler 
 
06:11:07 
distributed.core - INFO - Connection from 172.31.35.94:49019 to Scheduler 
 
06:11:07 
distributed.scheduler - INFO - Receive client connection: 941a5c1a-8ac2-11e6-a74c-0242ac110001 
 
06:11:24 
distributed.core - INFO - Connection from 172.31.35.94:49023 to Scheduler 
 
06:11:24 
distributed.core - INFO - Lost connection: ('172.31.35.94', 49023) 
 
06:11:24 
distributed.core - INFO - Close connection from 172.31.35.94:49023 to Scheduler 
 
06:11:54 
distributed.core - INFO - Connection from 172.31.35.94:49033 to Scheduler 
 
06:11:54 
distributed.core - INFO - Lost connection: ('172.31.35.94', 49033) 
 
06:11:54 
distributed.core - INFO - Close connection from 172.31.35.94:49033 to Scheduler

我认为这是负载平衡器的问题。当我运行与静态IP相同的设置时，它工作正常。

任何想法，为什么这应该是一个问题？我试着用--no-nanny模式运行，我试过在调度器上传递负载平衡器地址到--host，但没有效果。

来源

2016-10-05 Maximilian

首先，很酷的设置。我很感兴趣，看看这是怎么回事。除了确保您需要打开的端口打开并且每个人都可以在网络中看到对方之外，我个人在此没有任何建议。 – MRocklin

谢谢@MRocklin。你知道工作人员是否需要映射任何端口？这和http端口有什么关系？我找不到任何有关这些文件的文档。 – Maximilian

在离开计划程序运行并闲置一段时间后，我每五秒钟就会得到三个文件：'distributed.core - INFO - 收集未使用的数据流。打开：512，活动：0' – Maximilian

我一直在努力解决同样的问题，这里是我发现的。

您必须以awsvpc网络模式运行ECS任务，让ECS为其启动的每个码头集装箱分配一个唯一的IP地址。如果你看一下错误信息可以看到，工人们正在从是内部的泊坞窗地址连接

distributed.core - 信息 - 从172.31.35.94:49023连接到计划

是172.31.35.94在网络上并不存在ip的AWS 实例，它在docker内部 - 但docker容器在不同的机器上运行，因此调度程序无法在该地址上找到worker。我还没有找到告诉dask-worker运行容器的aws实例的外部地址的方法。

所以，我已经找到了唯一的选择是运行全部awsvpcnetwork mode在这种情况下，ECS分配形式192.168.0.0/24的私有IP每个容器的任务。与此问题是，您无法再连接到散景仪表板，因为容器IP地址现在是私人的。

因此，您需要另外运行一些NAT服务，以将流量从公共网络传输到您的调度程序。

你需要创建一个安全组（姑且称之为dask）并打开该安全组的dask端口（8786和临时端口）至少子网的容器运行，然后启动调度程序和使用该安全组的工作人员任务。

请注意，在下面的日志中，工作人员正在从35000以上的动态端口连接，这意味着安全组必须保持这些端口至少在子网内打开。您可以选择配置每个工作人员使用--worker-port从特定端口进行连接，然后仅打开该端口。

运行调度的从容器日志应该看起来像下面

来源

2018-02-19 16:21:45

这绝对是防止实例和ECS之间通信的网络问题。为了使负载均衡器运行状况检查通过，您的dask-scheduler安全组必须允许指定端口上的入站流量。确认以下项目：

什么是您的VPC子网？是否与ECS实例使用的相同？

使用动态IP，您可以确认第2层或第3层的worker-scheduler的端到端通信吗？

如果你对服务端口执行curl操作，你会得到一个有效的响应吗？

您是否可以确认您拥有一个有效且正常工作的安全组，并且映射正确？

最后容器代理服务运行良好吗？

最好的AWS ECS任务和EC2实例网络设计指导可在AWS Git Developer文档中找到。

来源

2018-03-01 10:33:14

尝试使用负载均衡器在AWS ECS上尝试dask.distributed集群时出现连接错误

回答

相关问题