當沒有可用的後端服務器時，AWS TCP ELB拒絕連接

我們有一個TCP應用程序，它接收我們沒有設計和不控制的協議中的連接。該協議將假定如果可以建立TCP連接，則它可以發送消息並確認該消息。當沒有可用的後端服務器時，AWS TCP ELB拒絕連接

如果直接連接到計算機，如果機器或應用程序關閉，tcp連接將被拒絕或丟棄，並且客戶端將嘗試重新傳送消息，這很有效。

當我們使用AWS彈性負載均衡器時，無論是否有可用的後端服務器來滿足請求，ELB都將與客戶端建立TCP連接。因此，如果我們的應用程序或服務器崩潰，那麼我們會丟失消息。

ELB將在此後不久關閉TCP連接，但它不夠好。

有沒有辦法讓ELB，只有建立連接，如果它可以到達後端服務器？我們有什麼選擇（在AWS生態系統內）平衡基於TCP的服務，但如果無法提供服務，仍會拒絕連接。

2015-10-07 Magnus

我不認爲這是通過ELB實現的。通過設計，負載平衡器將管理2組連接（前端 - LB和LB - 後端）。負載均衡器將嘗試儘量減少爲接收的流量提供服務所需的時間。這意味着當LB查找後端連接以使用/重用時，將建立FE-LB連接。所有後端主機都死的情況就是這樣一種邊緣情況，最終導致您看到的行爲。通常情況下，這並不是什麼大問題，因爲一旦LB發現無法爲流量提供服務，請求就會斷開。

回到你的協議：對我來說，你會認爲建立連接等同於消息傳遞的能力似乎很奇怪。這聽起來像你正在使用TCP，但不等待郵件實際上在目的地收到的確認。對我來說這似乎是錯誤的，最終會讓你陷入麻煩或者沒有負載均衡器。

而不是聽起來太悲觀（我明白我們不是生活在一個理想的世界）我會在這種特定的情況下做什麼，如果你可以在客戶端部署額外的軟件，將是使用tcp代理當負載平衡器不健康/無法提供流量時，客戶端會自動禁用。指示客戶端連接到此代理。遠非理想，但它應該做的伎倆。

來源

2015-10-07 17:53:29 Mircea

是的這是一個非常愚蠢的協議，我們也不控制客戶端。 – Magnus

你控制什麼？服務器部署？ – Mircea

是的，我們控制服務器，我們提供的所有客戶端都是IP和端口。 – Magnus

您可以從ELB創建運行狀況檢查，以驗證後端EC2實例是否在TCP端口上響應。請參閱ELB Health Checks

然後，您將監控由ELB發送到CloudWatch的EC2實例的運行狀況。

一旦確定沒有任何EC2實例在TCP端口上響應，您可以從ELB中刪除TCP偵聽器。請參閱Delete ELB Listeners

希望在此時ELB會停止接受TCP連接。

請注意，我沒有測試過這個解決方案。

來源

2015-10-07 06:38:52

我認爲問題在於最初ELB建立了連接，而不管後端發生了什麼。 – Mircea

這可以工作，但對我們來說可能有點太精細了。 – Magnus

@Mircea我認爲如果刪除了列表器，ELB將不會接受該端口上的任何連接。我會測試它，但似乎OP不打算使用它。 –

當沒有可用的後端服務器時，AWS TCP ELB拒絕連接

回答

相關問題