Azure負載平衡器在超時後拒絕請求

Question

我在調查從AWS切換到Azure，並已開始運行有關負載平衡器級別默認4分鐘超時的一些問題。他們似乎最近做了一些更改，現在您可以將此值最多配置爲30分鐘（http://azure.microsoft.com/blog/2014/08/14/new-configurable-idle-timeout-for-azure-load-balancer/），但這不是重點。

當我嘗試將我的hg存儲庫克隆到我的VM實例時，該問題目前正在顯現。回購是相當大的，大約15分鐘到克隆，傳輸完成，所有網絡活動停止，回購處理開始，我幾乎立即得到以下錯誤信息：

「abort：error：連接嘗試失敗因爲連接方在一段時間後沒有正確響應，或建立連接失敗，因爲 連接的主機未能響應「

我假設這是由於LB超時發生的，雖然我本來預計它會發生hg克隆網絡活動停止後4分鐘，而不是之後立即。

的有關部分（與我的問題的核心）是後我收到此錯誤信息，我馬上嘗試再次克隆，我立即再次得到以下信息：

「中止：錯誤：連接嘗試失敗，因爲連接的方沒有正確一段時間後響應或已建立的連接失敗，因爲 連接的主機未能響應」

的LB似乎立即拒絕了我的請求發生超時後！如果我等待10-20分鐘，我可以嘗試再次克隆。如果我猜測，也許這是一個反DOS'ing機制？ 我的問題是：

• 我的推測是否正確？
• 有什麼我可以做的，以在發生超時後立即修改這種「拒絕/阻塞」行爲？
• 是否有其他人在超時發生後立即看到這種「拒絕/阻止」行爲？

對我工作的項目主要用例涉及上傳大文件（最大100MB），如果客戶端超過分配的超時窗口，我不希望被訪問我的服務阻止他們。

Answer 1

我建議重新檢查所有參與負載平衡的機器。這聽起來像負載平衡器確定傳入數據包是一個新的對話，這會引發主機選擇，並通常會將您發送到您正在與之通話的機器以外的機器，但是一些參與LB的主機不會偵聽正確的端口爲您服務。如果服務級別的監控已經配置完成，服務級別的監控應該會抓住這一點，但是您提到這是一個新的實現。

上面描述的使用模式也可以通過第一次獲得一臺好機器，然後是一臺壞機器進行回購處理，然後在重試時出現壞機器來解釋。