嘗試使用負載均衡器在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集羣時出現連接錯誤

回答

相關問題