→ Wishmaster: $$$$$$$$ 01/01 04:55
→ asdfghjklasd: 任何HA 就是用錢堆出來的啊 01/02 15:41
→ Wishmaster: 是這樣沒錯，但不是這樣 XDDDDDDD 01/04 11:28
NLB故障是很正常的事，嚴謹一點做兩組NLB，在DNS上面解析這兩組NLB CNAME,
然後DNS起health check，只要health check失敗就拿掉故障的解析，可以
增加你的系統可靠度。
※ 引述《kino818 (要運動)》之銘言：
: 最近公雲AWS上website主機前端的SSL termination L4負載平衡障礙了一個多小時
: a. 同一公雲多系統，僅一個LB tls加解密失效（firewall traffic log看到的app_proto =
: tls變為unknown），其他系統與LB都狀態正常
: b. aws nlb底層是nginx docker容器，過程中確定異常容器不會自動kill故障容器，再重啟
: 新容器，nlb屬於軟體定義網路
: c. 非website憑證效期問題，且nslookup正常
: d. 多系統共享地端至公雲傳輸專線與網路，僅一個系統nlb tls失效，其他系統地端至公雲
: nlb網路連線網站正常
: e. 非aws sg問題，非aws fw問題，障礙期間aws用戶資源都沒組態變動，一個多小時後，此
: nlb自動恢復tls正常，網站連線恢復正常。推測aws底層單一實體機障礙導致nlb容器障礙，
: aws解決底層硬體問題後，恢復nlb運作
: 請教各位大大有過這樣或類似經驗？
: nlb log如何外拋至cloudwatch或cloudtrail？
: 如何偵測nlb失效與復原作業？
: Azure LB與GCP LB類似經驗？
: 謝謝閱讀與指教
: 參考：
: （1）AWS Network Load Balancer在 OSI 模型的第4層（傳輸層）運作，主要處理 TCP 和
: UDP 流量。它可實現高可用、高擴展性的負載平衡，支援跨可用區部署，並能處理極高的連
: 線數量與低延遲需求。適合需要直接控制流量轉送、需要支援靜態 IP 或需要處理非 HTTP(
: S) 協定的應用場景。
: （2）AWS Application Load Balancer 在 OSI 模型的第7層（應用層）運作，專門處理 HT
: TP 和 HTTPS 流量。支援基於請求內容（如 URL、HTTP 標頭、主機名稱等）的進階路由功
: 能，可實現微服務架構、容器化應用的精細流量管理。提供 SSL/TLS 加密、支援 Lambda
: 函數、容器化應用，以及豐富的監控與自動擴展功能。
: （3）Azure Application Gateway，提供 HTTP(S) 等第7層的流量路由與進階功能（如 WAF
: 、URL 路由等）。
: （4）Azure Load Balancer，負責 TCP/UDP 的第4層負載平衡，支援高可用性與跨區域部署
: 。Azure Load Balancer 主要功能支援 TCP 和 UDP 協定的流量分發。可部署在虛擬網路內
: 或對外提供服務。支援區域與跨區域負載平衡，具備高可用性與低延遲。
:
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 211.22.182.100 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/MIS/M.1766855303.A.828.html